Re: GEDOM as a database format

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
API.

Tony Proctor


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!
.

Relevant Pages

  • Re: GEDOM as a database format
    ... further support the suggestion of an object-orientated API. ... database, thus opening up data access to other software. ... full support for the issues you mention), historical notes, etc. ... vendors having valid grounds for objecting if they were then expected to ...
    (soc.genealogy.computing)
  • Re: 3vl 2vl and NULL
    ... > or API to the stored data is of primarily interest to me. ... >> designers are capable of defining the world for application programmers, ... I am more of an end-user (aka developer) looking to those ... But building an enterprise database is a lot more than succeeding at a lot ...
    (comp.databases.theory)
  • Re: "Set" command anomaly results in Null
    ... For API stuff in Access, ... Hence a database solution became necessary. ... programmatically controlling the scrollbars, like Excel does. ... A form is not a class object unless it has a module, ...
    (microsoft.public.access.formscoding)
  • Re: Big numbers
    ... information on how the API converts database values ... This is a numeric struct as defined by the ODBC standard: ... Database binding tends to be very specific either to the database (in ...
    (comp.lang.c)
  • Re: On-Demand Anti-Virus Checking Software
    ... I've always disliked the extra scanners that McAfee and others ... > Not really an API, but most scanners nowadays AFAIK still have a command ... But the vendors seem to have moved away from this with basic installations. ... ScanFile.wcx - dial up/telnet uploads ...
    (microsoft.public.security)
Loading