Ryan W. Frenz wrote:
>
> table derived1 looks like:
> | INT id | TEXT name |
>
> table derived2 looks like:
> | INT id | DOUBLE d |
Yes, and the problem with that is that you can't have a separate table
that refers to these id values. An example:
table Person {
int id
string name
}
table Manager : Person {
int firings_per_month
}
table SysAdmin : Person {
int lartings_per_month
}
table Salaries {
int person_id
decimal(2) filthy_lucre
}
You can't then say "SELECT filthy_lucre FROM Salaries WHERE person_id=5"
because there can easily be two rows with id 5, one in the Manager table
and another in the SysAdmin table. Thus, there would have to be two
Salaries rows and a way to disambiguate them, like a type column:
SELECT filthy_lucre FROM Salaries WHERE person_id=5 AND type="SysAdmin"
Now you're inventing an OO system on top of a relational DB, which is
never pretty.
If you don't have another table referring to generic records by id, it
doesn't seem like there's a reason that there's an is-a relationship
between them at all, from the DB standpoint at least. There's no reason
your C++ data design has to match up 1:1 with your DB design.
None of this has anything to do with SSQLS, but since your problem with
SSQLS will go away if you change the DB schema, I think it's worth
considering.
> My problem is simply one of the macro-expansion I'm trying to do not
> working the way I expect. In a way more general, non mysql++ related
> example:
>
> #define FIRSTARGS a0, a1
> #define SECONDARGS a2, a3
> #define MACROREQUIRINGFOURARGS(a,b,c,d) ...
>
> MACROREQUIRINGFOURARGS(FIRSTARGS, SECONDARGS) // does not work
>
> The way I understand cpp's macro expansion, this should first expand to:
> MACROREQUIRINGFOURARGS(a0, a1, a2, a3)
>
> and as a result work fine. But I'm wrong.
I understood your first post just fine. As I said, two different
compilers reject this code, so it's probably specifically disallowed in
the C++ standard. I can go dig up chapter and verse if you want, but
why not just assume I'm right and start looking for a different
solution? You could build header files automatically with m4 or perl,
for instance. Or, you can redo the schema design.
