Posted by Steve on 11/10/06 14:41

| For those who does think comments shouldn't be used, then please make a
big
| procedure with usage of functions with not that logical variables, put it
away
| and take a look in five years time and tell what you thought when you made
that.

agreed, however we are talking about database definition files here. it will
be pretty evident what the purpose of this is:

create table foo
(
id INT NULL AUTO_INCREMENT PRIMARY,
bar VARCHAR(25) NOT NULL
);

that leave commenting only for each field specifically and the possible
relationship(s) on field of one table to another field(s) in another table.
again, in this context, all that should be done in documentation.

as far as justifying comments in a database definition file because others
will look at, and edit, it...i put all of my table definitions in
alphabetical order - scroll till you find it or search for 'create table m'
to get you to where you need to be in the file. even if the file is not in
any order, the search will take care of finding tables starting with 'm'.
for new tables being defined (in a non-sorted file), just put it anywhere.

one should also think about upgrade paths for the db. the standard setup
should contain all the table definitions. there should be other, or a
single, file(s) that handles altering their definitions to support
developmental changes. at the same time that i recommend this, i seldom do
it anymore. i have a comparison tool that looks at the structure of a db
that has the 'correct', or most current, changes applied - like a staging
db. i then compare that structure to the target db. all the alterations are
handled in code to update the target system.

whether one places each table definition in its own file or in a single
file, i really couldn't care less as i don't think it matters. what does, is
making sure that the file(s) is clean and not cluttered with comments that
should be documented elsewhere. to me, the purpose of setup files is to
setup a db so a site can begin being used. documentation is to give you
queues. plus, there are plenty of good, free tools out there that not only
allow you to document a database, but also generate the definition file for
you on demand. that's the way to go.

[Back to original message]