Continuing the dialog with Joe Celko, here's more fuel to the fire.
New questions raised by Joe's latest email:
* Has anyone looked at ORM?
* I personally love ERwin. What better alternative is there?
* The next step is to ask Joe Celko if he ever recommends a
surrogate key.
Tom Nunamaker
[EMAIL PROTECTED]
=================================================
>> If I have a table with repeating information, suppose a city field in an
employee table for example, to normalize it you would break the city into a
separate table. If I used the city name as the primary key for this "city"
table, then it wouldn't accomplish anything to put it in it's own table. <<
That is a bad example. Each city in a Personnel table (remember use a
plural or collective noun for table names) is probably going to be part of
a different address -- mailing address, his/her doctor's address or
whatever. Try a Personnel table with columns called kid1, kid2, and kid3
for his dependents. Clearly having a Dependents table is much better
design -- it beats the heck out of requiring everyone to have three kids or
to kill one if they have over-breed.
>> I could create an INTEGER field in this city table and reference the
integer in the employee table. That would certainly take up less space
overall. Are you saying it's better to NOT to do something like this?
Instead, just put the repeating city name in the employee table and forget
the city table? <<
I would use the SAN (Standard Address Number) if I were in the book trade.
It is a number for all the bookstores and publishers in the US. This is
because the set of addresses can be treated like an entity in that model.
I am saying look at your model.
If Addresses are a serious part of the business model and appear in
multiple places, then I would also have a table for (zipcode, city, state)
and assemble the addresses from this and the street address line. ZIP
codes get changed more than people think.
If the addresses are not reused much, then put them with the table to which
they belong. What you save in space with a separate address code, you will
lose in doing JOINs.
>> I've 'faked it' using IDENTITY fields but I'm willing to use a better
approach if I can. How do you handle situations like this? I see
"identifier" fields in the book "Data Modeling with ERwin". I know LOTS of
developers using it. <<
I know a lot of developers who do it, too. I bill their employers $1500 to
$2000 per day to fix that kind of code. Oh, ERwin is a bad tool. It has
planar graph problems, cannot show constraints, returns only one schema,
etc. You might want to look at ORM modeling methods.
--CELKO--
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
