Re: Hello there!
I think that's a good idea. I realise I was stretching with the idea
of making the schema database "agnostic". Derek correctly pointed out
that making it agnostic would be more of a challenge than it's worth.
For example, the MySQL attribute "AUTO INCREMENT" is applied
(usually) to an integer. It's Postgres equivalent is the serial
datatype. The Sybase Transact-SQL equivalent is the identity
datatype. In the case of Postgres, the serial datatype is an integer
implemented with a sequence, while Sybase uses a numeric datatype,
although it is declared as "Identity" for column definition purposes.
I do like the idea of providing a csv file that has somewhat generic
table names, field names, datatypes, and other information. It's a
"psuedo code" sort of way to publish. Then people can write their own
scripts to generate DDL for thier database of choice. Then with
approval, these scripts could be made available to those who want
I do realize that some database specific structure files will have to
be published. Not everybody is going to be willing to script for the
databaes they want to use.
--- In email@example.com, Tangotiger <tangotiger@y...>
> Ok, that clears it up. In that case, to make
> something "agnostic", you really need to have a
> standard that is agnostic. The best way to do this is
> to provide a csv file of the field and data types, and
> then write a program to generate the CREATE TABLE ddl.
> So, something like this:
> Then, the various Oracle, MySQL, Postgresql, etc
> developers can write a rather simple perl or sql
> script to generate the CREATE TABLE. The benefit is
> that as the tables get modified, you don't have to
> worry about recoding anything.
> You come up with the various "agnostic" datatypes, and
> each developer comes up with the translation to their
> --- Derek Adair <dadair@i...> wrote:
> > On Tue, 27 Sep 2005, nacc_whatever wrote:
> > > I'm not advocating having dump files published for
> > all the various
> > > platforms you mentioned. I was asking if the
> > schema (the structure)
> > > was going to be published in different forms.
> > Looking at the files
> > > availble, the table INSERT statements meet the SQL
> > standard, but the
> > > CREATE TABLE sql is MySQL dependant. While I
> > could convert it to be
> > > used on Postgres, I was wondering if that was in
> > the plans or already
> > > done.
> > >
> > > I don't have a problem taking the formated text
> > data files and
> > > inserting them into a database, even without the
> > INSERT statements. I
> > > was wondering if the CREATE TABLE statements
> > (database structure) was
> > > going to be provided in a more database agnostic
> > form. Currently,
> > > they are provided in MySQL format.
> > >
> > > I hope that clears up my inquiry.
> > I believe it's very likely we'll be producing
> > structure statements ready
> > for import into Postgres with the direction we're
> > heading. That said, if
> > someone else on the list is already importing data
> > into Postgres, and has
> > their statements available, it would be of benefit
> > to the group.
> > On the more general point that was raised, regarding
> > supporting other
> > databases, I'm not sure it's possible to provide the
> > structure in a
> > "database agnostic form." I'd be all ears if people
> > have ideas here, but
> > with the differences in datatypes alone, I imagine
> > it woulde be quite a
> > hurdle.
> > I believe we'll likely actively support a couple of
> > different import types
> > (MySQL and Postgres, if I had to guess), but that
> > clearly doesn't stop
> > anyone else from submitting import files they've
> > created (and hopefully
> > updating them as well).
> > Regards,
> > Derek
> Yahoo! Mail - PC Magazine Editors' Choice 2005