Re: database constraints

>>
>>SELECT * FROM foo
>> JOIN bar on (foo.id = bar.id)
>>
>>Personally I would rather see, and write that then:
>>
>>SELECT * FROM foo
>> JOIN bar on (foo_id = bar_id)
>
>
> With all due respect, Josh, naming your columns with decipherable
> names, i.e. *not* having 50 different things called "id" in your db
> helps enormously with maintenance,

I agree 100%. For us, it makes sense to have id, because if we have
table foo, bar, and baz. We know that the primary key is always, foo.id,
bar.id and baz.id.

especially when the current
> maintainer has never met the designer, a common situation.

What is what documentation is for.

> Also, many
> databases have documents that are inadequate, out of date, or both, so
> decipherable names, along with as much other self-documentation, is a
> big plus.

Agreed. Which is why we make exhaustive use of the comment command :)

> Cheers,
> D
>
> P.S. As a rule, SELECT * doesn't belong in production code.</nit>

Heh, I agree with this. SELECT * is bad for many, many reasons :). I was
just making an example.

Sincerely,

Joshua D. Drake

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL