I'd say +1, but bear in mind I'm not a great expert in DB anyways, but seems fair and reasonable.
One comment, though: I don't know if this applies to all the cases, but I remember having DB issues because some fields where so long that they exceeded the maximum field length. I guess this only happens in specific parts of the DB (I kind of remember it was the list of Jobs in a workflow, or something like that), so I may make sense not to limit lengths in some cases. My half cent :P 2011/10/4 Christopher Brooks <[email protected]> > Hi, > > As per a discussion several weeks ago, our DB schemas are a mess. I'd > like to #propose that we adopt the following scheme naming conventions: > > 1. All names are lower case, words separated by underscores > 2. Tables are plural, fields are singular ("users" table contains a > field called "address") > 3. All table and field names are full english words subject to (4) > 4. Table and field names do not exceed 30 characters, and abbreviations > are used if the names are too long. e.g. something like > "dublin_core_metadata_unique_mappings" changes to > "dc_metadata_unqiue_mappings". > 5. Indicies and performance measures are broken up into a separate SQL > file. E.g. mysql.sql turns into mysql-base.sql and mysql-indicies.sql. > > Lots of these come from http://ss64.com/ora/syntax-naming.html , which > seems to be one of the few naming conventions I can stand (camel case > in sql? hungarian notation? wtf?). > > If you object, please object clearly to a particular numbered item, we > can vote on them separately. > > For a timeline, I'd like to suggest we clean these up for 1.3, but I > don't want to propose that because I know there was some discussion to > be had. I think the longer we wait the bigger a pia it's going to be, > but let's just chat about that first, > > Two open issues are > - Column lengths; by default a lot of our lengths are off and there may > not be ui checks. Should we document or enforce this somewhere? > Units tests explicitly for this? > - Keeping two sets of DB schemas kind of sucks. I means that the QA > team has to QA two sets of schemas. Why don't you postgres guys just > see the light? > > Regards, > > Chris > > -- > Christopher Brooks, BSc, MSc > ARIES Laboratory, University of Saskatchewan > > Web: http://www.cs.usask.ca/~cab938 > Phone: 1.306.966.1442 > Mail: Advanced Research in Intelligent Educational Systems Laboratory > Department of Computer Science > University of Saskatchewan > 176 Thorvaldson Building > 110 Science Place > Saskatoon, SK > S7N 5C9 > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
