Re: database constraints

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: database constraints
Дата
Msg-id 4164265F.8060407@commandprompt.com
обсуждение исходный текст
Ответ на Re: database constraints  (David Fetter <david@fetter.org>)
Ответы Re: database constraints  (David Fetter <david@fetter.org>)
Список pgsql-general
>>
>>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@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Marco Colombo
Дата:
Сообщение: Re: Random not so random
Следующее
От: Scott Frankel
Дата:
Сообщение: postgres.h location?