Hi Darren On Thu, 2011-08-04 at 23:29 -0700, Darren Duncan wrote: > Ron Savage wrote: > > Personally, I'll never be writing code which is deliberately crippled so > > that it only runs under 1 db server, no matter what that server may be. > > > > There are apparently 71 db servers accessible via DBI. > > I agree with you, but at the same time, you would also be crippling your code > when you write it to support the lowest common denominator, such as trying to > make it work on every SQL DBMS regardless of capabilities.
Sure. > If you want a good program rather than a mediocre one, you need to draw the > line > and set a minimum feature set that a DBMS should have to be supported. Agreed. > For example, that you only support DBMSs that you can exclusively use in ACID > and transactional mode, and you only support DBMSs that will natively enforce > foreign key and CHECK constraints, and only those with native Unicode > support, > and so on. I don't use CHECK myself, but of course I expect FOREIGN KEY/REFERENCES to be supported and not just scanned. This rules out MySQL for me as the primary db, but I don't try to restrict what other people use. It's pathetic that MySQL does not measure up on this. > This may disqualify some DBMSs, but users would still have others from which > to > choose. > > So choose a middle ground. You can always justify rejecting a particular > DBMS > for support by saying it lacks features whose absence would seriously > compromise > the quality of your product. > > I mean, would you make a brand new program now, and still support Perl 5.5? Nope. Even 5.8 is dodgy :-). > Personally for a quality project, I would reject MySQL, which among other > major > flaws doesn't support CHECK constraints: > > From http://dev.mysql.com/doc/refman/5.5/en/create-table.html (the MySQL 5.5 > manual): "The CHECK clause is parsed but ignored by all storage engines.". V 5.6 is the same, I see. > Or given its popularity, I could still make the program run with MySQL, but > that > would come with strong written caveats that users risk greater corruption > with > it, and that I offer no warranty of fitness for that configuration. > > > For me, the default db is Postgres, but my policy is the either ship > > text files and a (table) creator, and a loader, both of which use a > > config file, so the end user can configure them to use any DBI-supported > > db, or I ship an SQLite db, so the end user can use DBD::SQLite. > > A SQL database may be a good internal format for a program, but it is > generally > a bad interchange format, as internally it is quite complicated and binary. > A > much better interchange format is some kind of marked up text, such as SQL or > JSON or XML or Muldis D etc. Agreed. I only ship data in an SQL db (one those very rare occasions I do) on the assumption it'll stay there. If users which to export it, that's up to them. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622
