Re: GEDOM as a database format

I don't think we're disagreeing Robert. I, too, feel GEDCOM (& XML) would be
better kept as interchange formats. However, I regularly work with
industrial-strength SQL databases like SQL Server and Oracle. By a
'standardised schema', I mean a set of table & column definitions, together
with stuff like constraints, foreign keys, etc., that would form the base
storage, but would also accommodate private/proprietary fields too. For
instance, a core table of individuals with their identifying details. SQL
Server would automatically allocate IDs for these records as they're added.
Those same IDs would then be "foreign keys" in related tables that store
descendent relations, antecendent relations, public notes, privates notes,
..... whatever. However, my experience with small-scale databases like Access
(which would probably be more common in household use anyway) is poor, and I
don't know whether it could accurately represent the same schema.

For a long time, I worked in the area of multi-dimensional database
technology (OLAP), and there are parallels insomuch as different providers
once implemented their own proprietary storage formats. That is, until there
was a radical consolidation in the industry and there are now less than a
handful of defacto standards - some of which even use a SQL schema.

Tony Proctor

"Robert Melson" <melsonr@xxxxxxxxxxxxxxxxxxx> wrote in message
news:13fl348j2gi620c@xxxxxxxxxxxxxxxxxxxxx
In article <fddrs3$3ad$1@xxxxxxxxxxxxxxxxxxxxxx>,
"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
I'm probably not making a good enough case David. However, through
experience, you cannot rely on any software company to be around for
ever,
which is one reason for wanting my data to outlive any program, and to
be
easily passed on to any new program.

However, having an "open" data source would also spur on development of
more
utilities. At the moment, if you want to buy some specialist utility for
generating HTML pages, generating Acrobat pages, filtering out living
relatives, matching two trees, etc., then you are forced to first export
your database to some format that the utility understands, which is
usually
GEDCOM. All these are examples of "non-updating" utilities, though,
since
they do not add anything to the quality or consistency of your base
data. If
someone had a brilliant idea for such a utility then it would be much
more
convenient, in terms of development & testing as well as deployment, to
be
able to rely on a standardised SQL schema.

Tony Proctor

----- Original Message -----
From: "David Rowell" <djrpublic@xxxxxxxxxx>
To: "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 26, 2007 2:49 PM
Subject: re GEDCOM


I think you're making too much of the "problem'.

Choosing a (any?) program that you're comfortable with is a good choice
especially if it is one of the more well known (popular?) applications.
Programs like PAF will have strong support for direct import of their
data in many more capable programs. Personally I steer away from those
programs that require (or will grab) a central internet connection like
FTM does.

So - shop around trying all of those offering demo versions - find one
you like and go for it. Its the data that are important not the method
or format. All the better if it will import "ged" files placing the
unique identifiers that it doesn't understand in the 'notes' fields.
If
you Google for it there is a sample GEDCOM somewhere that you can
import
and export to get a grasp on a program's failings. For what its
worth -
I use Gramps.

Now IF those vigorously competing companies (and LDS?) could only get
together on a major update to GEDCOM that would obviously be a good
thing for all of us. It just isn't going to happen!


GEDCOM is a data exchange format, not a data storage format. To
the extent than any two programs can successfully exchange
genealogical data, then GEDCOM is a success. GEDCOM is not,
but is used as, a data storage template for genealogical data,
and it's here that things fall apart, since every program's
developer has his/her own ideas about how data - to say nothing
of what data - should be stored and displayed.

SQL, Structured Query Language, is a database query language and,
as with so many other things in computing, has a standard that's
more honored in the breach than in the observance, with each
database management system having its own preferred {sub,super}
set of SQL. SQL, however, has little or nothing to do with the
design of a database; it allows the user to ask questions regarding
the data stored and to perform more-or-less basic operations on
that data, but only after the database has been created. There's
no guarantee, however, that a schema for one DBMS will necessarily
be acceptable to any other DBMS without major tweaking.

All this is more than a bit simplistic, I know, but the point is -
or seems to me to be - that any effort to "improve" GEDCOM is
really attempting to improve the wrong thing, and any effort to
standardize the internal representation of data based on a
misunderstanding of what SQL is/is not is doomed to fail because
of differences between database engines.

So, design that schema, test it with _your_ DBMS, see how adequate
it is for long-term storage, interface it with a genealogy
program for visualization, reports, etc. Bud don't be surprised
if the world looks, points and yawns.

Sorry. Wednesdays are my pessimistic day.

Skeptical Ol' Bob

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"People unfit for freedom---who cannot do much with it---are
hungry for power." ---Eric Hoffer



.

Relevant Pages

  • Re: GEDOM as a database format
    ... your database to some format that the utility understands, ... Subject: re GEDCOM ... SQL, Structured Query Language, is a database query language and, ...
    (soc.genealogy.computing)
  • Re: Create Non Access DB with VB??
    ... but then that isn't really a database. ... Application and the "MDB" file format, yet their is a distinction between ... > And then just write a VB app to interact with one of those! ... You could also do it with ASP using either Access or SQL ...
    (microsoft.public.vb.database)
  • Re: GridView basics
    ... I must format is e.Row.DataItem.ItemArray, ... On 31 aug, 14:56, "Eliyahu Goldin" ... database. ... end up with a bulky sql. ...
    (microsoft.public.dotnet.framework.aspnet.datagridcontrol)
  • Re: Linking SQL Server 2000 to Access - Bigint datatype
    ... I'm using Access 2003 to generate the database, ... I did try converting it to Access 2002-2003 format using the ... >> I'm currently trying to create an Access database that has links to SQL ... I've narrowed down the issue to the bigint datatype; ...
    (microsoft.public.sqlserver.odbc)
  • Re: Linking SQL Server 2000 to Access - Bigint datatype
    ... I'm using Access 2003 to generate the database, ... I did try converting it to Access 2002-2003 format using the ... >> I'm currently trying to create an Access database that has links to SQL ... I've narrowed down the issue to the bigint datatype; ...
    (microsoft.public.sqlserver.server)
Loading