> Not *one* table. I never advocated that. It is perfectly normal to split
> your data into different tables *vertically* (i.e. things that do not
> have any intersection between their data, should go into different
> tables), but it very rarely (if at all) makes any sense to split it
> *horizontally* (so that identical columns sit in different tables, just
Okay, so I shouldn't merge the tables then. Let me show you my schema:
Sponsor -> object_id, name, url, representatvie (points to rep table),
city (points to city table), primary contact (points to contact table),
active
Payments -> object_id, sponsor (points to sponsor table), when_paid,
payment_type, payer_contact (points to contact table), company address
(points to addresses table), billing address (points to addresses table),
CC Info (I won't spell it all out for you), amount
Notes -> object_id, noted_object (points to ANY table), note_title,
note_text, note_creation_date, not_creator(points to user table), active
So, since Notes can be attached to any table, I don't see how you are
saying I should combine them, except to combine EVERYTHING into a single
table, and have a value at the beginning to use as the record "type".
> No. They would have a base class of "Object" (or whatever), and the
> 'notes' would be linked to the Object.
> This would in fact, be a *beatiful* solution... it's a shame really that
> it doesn't work.
As I said, the tool is limitted.
Jon