Re: database constraints

On Wed, Oct 06, 2004 at 10:07:43AM -0700, Joshua D. Drake wrote:
> >>
> >>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.

Coding standards are a Good Thing(TM). :)

> >especially when the current maintainer has never met the designer,
> >a common situation.
>
> What is what documentation is for.

And in a perfect world... ;)

> >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
> :)

This brings up an interesting idea. What if it were possible to set
some kind of rules on DDL at database creation time? For example, I'd
like to be able to throw an error if somebody tries to name an object
any of the SQL keywords.

Other possible rules:

* Every table must have a comment
* noCamelCaps
* downcase all entities
* underbar_separators_required
* abbrev_w_beg, nt_by_rmvng_vwls
* Your favorite algorithmic coding standard here

What do y'all think?

Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!