First of all, great work! This will definitely help developers do the right thing when writing DDL and DML.
I'd like to simplify the document so that it more closely aligns with the goals we have for Mifos documentation (see http://article.gmane.org/gmane.comp.finance.mifos.devel/3853 ) (and yes, I just wrote them). Here are some specific comments: * database names need not be lowercase, this should be recommended as opposed to mandatory. In fact, I'd rather just leave it out... I don't want others reading the document to get lost in the volume of details. * we can remove the "Schema Names" section--the difference between this and database name is a database implementation detail * same for "Synonyms" * I think 8 characters is a bit short for database names. * what are "database manager objects"? * I recommend using simply "id" for all primary keys. Context necessary to derive meaning should be present. * We don't use stored procedures, so we can remove that section or indicate they shouldn't be used. * I assume "Parameters" are parameters for stored procedures? * let's remove "User ID" and "Password". * Let's remove the "Examples" table on page 6. It is very database specific (for instance "Stogroup"?). Also, the suggested names are simply "NAME" (not very intuitive), and are in all capital letters. * the Static Consistency Check need not be comprehensive. Please first supply a patch that checks only that table names and column names are lowercase. We can add more later if we need to. * I'm not sure if we can legally cut and paste from the MySQL documentation, so I removed these sections. * I'm not too concerned about the static check looking for reserved keywords for a few reasons + it is way to complex to implement + you can usually count on a database to croak on these + we'll just recommend it, and people will not do it. :) I would add: * all identifiers will be in English * allowed characters for identifiers are [a-zA-Z0-9_] * underscores should be used to separate words, like "account_name" >From the document: > The naming convention should address future development and > it shouldn't be just a point fix. I completely agree. However, the document can evolve along with the code, and should start simple and concise. > The length is suggested should improve the database portability > (from MySql to Db2 for example) Ok. But I'm concerned that we are going to have to cut names /very/ short. Some of your examples have a maximum of 8 characters, for example. On Mon, 2008-02-18 at 12:40 +0000, Massimiliano Parlione wrote: > Feel free to amend and publish it on the knowledge center. > In our opinion any naming convention eventually agreed should be clearly > summarized in a document (in the knowledge center?) where each schema > element (columns, tables,....) is described. I migrated your content to mifos.org and made some changes. The project plan: http://mifos.org/developers/wiki/ImprovingDatabaseNaming Omissions were intentional, but please add them back if you feel something is missing. This is just the project plan... I feel like the next page is what we should kick around with a bit more scrutiny. The in-work naming convention: http://mifos.org/developers/wiki/DatabaseNamingConventions The first thing you'll notice is that the second link (the actual naming convention) points a document that is *very* concise. This is intentional. Please refer back to the overall goals for Mifos documentation for why I did this. Also, I used 64 character limits for table and column names, since these are the MySQL limits. Yep, I know this won't work in DB2. Let's think about an automated way to transform identifiers longer than DB2 limits to a length compatible with DB2. Perhaps some kind of hashing algorithm that leaves part of the name readable? For instance, customer_transactions could become customer_transa~1 etc. -- Adam Monsen ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
