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.
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.
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.
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?
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.".
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.
-- Darren Duncan
