Re: Universal Astrological Database Format

From: Bernard Peek <bap_at_shrdlu.com>
Date: Tue, 15 Jul 2003 17:09:33 +0100
Message-ID: <mJ3mbPV9cCF$EwJ+_at_diamond9.demon.co.uk>


In message <45878464.0307121327.2d14dc78_at_posting.google.com>, Bill Kneuper <b_kneuper_at_hotmail.com> writes
>> Whatever format you choose you need to start out by defining the
>> structure of the metadata. The traditional tool for that is the Entity
>> Relationship Diagram, usually abbreviated to ERD. To a first
>> approximation an entity equates to a single table in a database.
>>
>> I think that's enough to get you started.
>
>
>
>
>Allright, I’ve done a little homework and have a few questions.
>
>
>1. Isn’t an xml database really a flat file?

Don't confuse flat-file and text file. The term flat-file in a database doesn't necessarily mean a text file. It means that the database only supports a single data table, with no support for linking to other tables. You rarely see them these days.

By extension if you export the data from a single table into a text file it was often referred to as a flat text file. That's where the confusion comes in.

On the other hand XML data is structured and can hold data from more than one table, and hold details of the relationship between the tables. So an XML file is a text file, but it is only a flat file if it holds data from a single table.

>
>2. If I add an entry to an XML file doesn’t it have to be ‘inserted’
>in the proper section of the file? Is this insertion handled by the
>programmer or is there an ‘engine’ that handles reads and writes to
>the file? (Visual Basic uses the Jet DB engine). If the programmer has
>to handle writes then it seems the entire file has to be rewritten
>every time there is an update.

You have a choice. There's nothing stopping a programmer from writing their own code to write data into XML files and insert records. There's nothing stopping you from writing an XML file with a text-editor either. In practise XML handling is invariably handled by some sort of 'engine.'

>
>3. Are there ODBC dll’s to connect to an xml database?

More than you can count.

>
>4. Is there an XML editor (preferable free) out there to build tables
>and relationship connections?

More than you can count. I started by using a non-free XML editor called XMLSpy. I believe there is a downloadable version. It has been included in the covermount CD with some computer magazines in the UK. There are lots more, many of them completely free or open-source.

>
>5. Can you run SQL queries on an xml file?

Yes, sort of. XML is an excellent medium for exchanging data between databases but it's a lousy medium for storing data in large databases. Every time a transaction changed the data the DBMS would have to read in the entire file, modify it and write it out again. No problem if your database only has a dozen records. If your database had 50 million records you could die of old age before it finished an update.
>
>6. Is XML really the best solution for designing an analytical
>relational database?

Not if you intend to store more than a dozen records.

>
>One thing I don’t like about the xml format is the fact that you can
>open it with a word processor. I’m planning this database file to be
>the storage format for a program I intend to write (it won’t be web
>based). It seems the text-based nature of xml makes it more
>‘tinkerable’, easily corruptible by someone with good intentions. It
>also seems the data file would be much larger than necessary due to
>the formatting,
><FirstName>Fred</FirstName>. Twenty tree characters to store ‘Fred’.
>Or, <TimeZone>CST</TimeZone>, twenty characters to store ‘CST’.

That's not a problem if you compress the data. XML files are very compressible. That's fine if you only use XML to transfer data but you can't do that if you have to keep updating the file.

Use the right tool for the right job. XML is very good for moving data between systems, particularly when they use different architectures. It's not suitable for transaction processing systems, use a real RDBMS system for that.

-- 
Bernard Peek
London, UK. DBA, Trainer & Author. Will work for money.
Received on Tue Jul 15 2003 - 18:09:33 CEST

Original text of this message