Re: How about Gedcom2 for a new namespace?

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