Re: [Linkbat-devel] Data format, XML to DB conversion

[James M. <lin...@ji...>]

On Wednesday 20 November 2002 18:33, Shanta McBain wrote:
> On Wed, 2002-11-20 at 10:46, James Mohr wrote:
> > That's exactly it: "when a host that dose not have access to SQL" and
> > that's really the only reason.  A corollary is someone who does not have
> > the skill or desire to set up an SQL database, but that is less important
> > to me than someone who cannot set it up. However, it will be a while
> > before it is a "product" that we can package and make available on
> > SourceForge, etc. I just don't want to paint ourselves into a corner.
>
> That is why I like to store my data in SQL. It allows me to manipulate
> the data as I see fit. This includes exporting data to cvs files.

In principle I don't have a problem with that. However, it requires the 
intermediate step to be SQL. If you have already inserted it into an SQL DB, 
why bother exporting it to CSV? (unless you want to move it a server that has 
no SQL DB) Although not necessarily efficient, I see a "friendlier" approach 
to first parse the XML into CSV and then import that into SQL. 

> > > I will have the CSV s files into MySQL in a few hours. I have code to
> > > do this by simply importing the contents into the SQL Table.PHP but it
> > > works.  From that point on to switch the code from on DataSource to
> > > another takes a simple change in one variable in the site setup file.
> > > Export the contents of the SQL table to a | delimited file though and
> > > delimiter can be used.  and there you have switched.
> >
> > Does that  mean there would be little change in the eXtropia code to
> > reflect a CSV data source as opposed to SQL?
>
> In my setup 0 change exempt one variable in the Global site setup.
> $DataSource = "file"; or $DataSource = "MySQL";

What about the code itself? If a single file = MySQL in terms of being a data 
source, I do not see how you could get around the problem of having to redo A 
LOT of code. If a file equaled a MySQL Table, then I see a 1:1 relationship 
between fields in MySQL and fields in the file, so there would be very litle 
code change necessary. 


> > > Validation, field
> > > contents, required fields and many other checking is already in
> > > eXtropia one just has to tell it what you which to check for.  Don't
> > > know if this is what you are referring to with XML validation as I know
> > > little of XML.
> >
> > I'm refering to the actual XML files before they are imported into the
> > database. If someone forgets a closing tag or something else, we should
> > know about it before we try to read it into the database.
>
> Ok. but that is why one develops on a separate server. could be added to
> eXtropia but XML in the form View would likely be easier

What about performance. An XML files is at least 10 times larger. Plus we have 
the issues of the inter-relationships between the various KUs. To what extent 
can this be handle by eXtropia when directly reading the XML files?

Even if eXtropia could read the XML files directly and be able to present the 
relationships correctly. I cannot see how that would **not** lock us into 
eXtropia as the delivery mechanism. If in a CSV text file or SQL DB, then we 
can do standard queries on the data. 

I think I'll draw a diagram of what I was thinking about it and post it.

Regards,

jimmo
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info