Re: GEDOM as a database format
- From: Ian Goddard <goddai01@xxxxxxxxxxxxx>
- Date: Fri, 28 Sep 2007 16:32:15 +0100
Tony Proctor wrote:
I was thinking of "interoperability" though Ian. I agree with the principles
of first defining an abstract data model, and then ensuring there's an
exchange format that can be used for import/export, email, etc. However, if
each proprietary database provides an implementation standard API then it
means other software can examine (& optionally update) data still in that
proprietary database, without the need for convoluted import/export.
A software designer with a great idea, for instance, could write their
utility conforming to the description of that API. Anyone could then use it
if the supplier of their current database offers an implementation of that
Hmmm, assuming you mean a set of data declarations and function calls as an API that's an aspect I hadn't considered.
Certainly, if I were putting together an application I would probably use an SQL database as my underlying data store. But I wouldn't consider surfacing this as an API to be accessed by my UI layer. It would be too much of a hindrance as I'd use an existing generalised application framework to address that data store directly from the user interface code with, maybe, some helper classes where appropriate. Providing a 3rd party add-on API would simply be an additional burden.
OTOH providing a standard SQL schema to allow access through tools such as Crystal reports wouldn't be a problem as such. I can see commercial vendors having valid grounds for objecting if they were then expected to provide support for databases mangled by anything from well-meaning but ill-designed 3rd party tools to direct tweaking. (I would expect most of them to have the objections you would expect from dyed-in-the-wool proprietary S/W vendors but don't regard those as valid.)
There are, however, some more fundamental problems with this.
One is that different RDBMS vendors have different DDL dialects; for instance taking just two aspects of the two vendors whose products I've used, MS & Informix have a different data type name for an auto-incrementing integer column and the VARCHAR declarations are interpreted differently. And I certainly wouldn't wish to see data locked into any specific RDBMS engine.
Another is that there are real problems with some data types. For instance, how do you collate "1726", "23/2/1726", "Early C18th" and "1720 - 1730"? Given that something less than free text would be allowed in presentation of the data I think this could be managed with an SQL interface in Informix and, from a brief reading of the documentation, in Postgres. I doubt, however that all RDMBS engines could manage it.
And finally, any software author with strong feelings about non-SQL RDMBS such as rdb or about using persistent objects would rightly feel excluded - and who's to say such implementations may not be better?
At the moment I think XML export is the appropriate way of exposing data. It provides scope for utilities aimed at alternative means of presenting the data without exposing the database itself to the risks of alternative means of manipulation (there speaks the voice of the DBA!). If the demand were really there for providing more direct access via an API then the XML solution could be extended to exposing the data as a DOM - in which case those of us following the SQL route would find ourselves with the legacy apps as the persistent object guys would have the edge!
- Re: GEDOM as a database format
- From: Tony Proctor
- Re: GEDOM as a database format
- Prev by Date: Re: GEDOM as a database format
- Next by Date: Re: GEDOM as a database format
- Previous by thread: Re: GEDOM as a database format
- Next by thread: Re: GEDOM as a database format