Re^3: Mapping objects to database tables

ad John Smith's uniqueness:
I think that derby's data structure exactly reflects described situation. Once you have two or more J.S. _without_ some related rows in other tables, you really cannot distinguish between them. But it is not disadvantage of derby's normalization, it is lack of informations. You can, for instance, add some external (real) unique identifier into database table Person (insurance number? passport number? e.t.c.)

ad other:
I don't understand exactly what do you need. But I think that you can create some database views or some more complicated (perl) structures representing derby's data structure in proper format...

Comment on Re^3: Mapping objects to database tables

Replies are listed 'Best First'.
Re^4: Mapping objects to database tables by clinton (Priest) on Nov 07, 2006 at 14:34 UTC
Re extracting the person's name into a separate table.... I could do it, but all it buys me is a small reduction in table size, and it costs me an extra join (or two) for every announcement lookup. It would be a bit like extracting a date into its own table.	[reply]
Re^5: Mapping objects to database tables by pajout (Curate) on Nov 07, 2006 at 14:48 UTC
Yes, this is up to you :>) My experience is that only experience in time shows the optimal solution - normalization is good advice, but it is not an idol. Somebody prefers optimization for reading and somebody for updating.	[reply]