Front page | perl.gedcom |
Postings from August 2011
Re: How about Gedcom2 for a new namespace?
Thread Previous
|
Thread Next
From:
Ron Savage
Date:
August 5, 2011 00:29
Subject:
Re: How about Gedcom2 for a new namespace?
Message ID:
1312529240.13656.477.camel@zigzag.savage.net.au
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
Thread Previous
|
Thread Next