Brian B. wrote:
I’m designing a db with several types of organization-type entities,
e.g., company, school, etc… each one of which can have one or more
addresses, phone numbers, fax numbers, etc. Therefore, wouldn’t it be
best to give addresses, phone numbers etc. their own tables to have this
kind of flexibility?
Sometimes, sometimes not. You may find it more useful to de-normalize
to a certain extent and have a single “contacts” or perhaps “locations”
table which combines addresses and phone numbers, depending upon how the
information is commonly grouped and retrieved. Your design process will
have to ferret this out.
Also, is it me or does the use of single table inheritance in your
database make it extremely difficult (if not impossible?) to use foreign
key constraints (FKC) when forming associations with other entities? If
so, this is not good, because I thought using FKC to mark associations
was considered best practice in SQL.
DHH evidently does not like DBMS level consistency constraints of any
sort and so FK is not part of Rails (so far). I, and many others, do
not subscribe to this school of thought. FK constraints are, in my
opinion, an absolute requirement for relational data implementations
because the data exists independently of the applications that access
it. In any large scale system, at some point Ruby and Rails are only
going to be one of the ways the data is accessed, used, and modified.
Once that happens, all your carefully crafted AR models are so much
cruft and only the DBMS stands between your data and whatever is trying
to screw you up. Foreign keys, stored procedures and triggers should
all be employed to the maximum extent possible to protect your data from
all comers.
