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.
> > 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";
DataSources currently supported by eXtropia are
file, MySQL, Oracle and a few others but they are not important.
> > 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
> > > Following are some thoughts and ideas about how the tables can be
> > > created. I have no particular affection for any of these ideas, so feel
> > > free to tell me they stink.
> > >
> > > The first thing we need to decided for the data model is how to store the
> > > KUs themselves. Since different KU types have different attributes, I do
> > > not see a way of storing them all in a single table. Instead, I would see
> > > one table for each KU type and then a central table that contains the
> > > unique KU ID and then the KU type. When making a cross reference from one
> > > KU to another, we would then go through this central table.
> > >
> > > Next is the inter-relationship between the KUs, which is a core aspect of
> > > linkbat. There is a potential that each KU (regardless of type) can
> > > reference every other type of KU. However, I cannot really imagine an
> > > index for each relationship. For example, the Concept KU has an index
> > > listing all of the Concept KUs and with pointers to all of the referenced
> > > Glossary KUs. Then another index with the MoreInfo KUs. In my mind that
> > > would mean too many tables. If there are five KU types and each has a
> > > index for the relationship to the others, then we would have 20 tables
> > > (5x4). With 6 KU tables, 30 tables (6x5). Is my math right?
> > >
> > > However, the question is whether 20 or 30 indexes is "too many". Does
> > > having seperate indexes for each relationship provide any advantages?
> > > Quicker access? If so, does it compensate for the extra work to manage
> > > 20-30 tables??
> > The SQL table takes care of that for another reason to store all data in
> > SQL.You can assign indexes within each table.
> I'm aware of that. However, these are not quite the same indexes that an RDBMS
> system like MySQL would generate automatically. It's not a index of a single
> table used to speed-up access, but rather a table containing the relationship
> between the KUs. These would be something we would have to define and fill
> ourselves I'm just curous about the performance issue of having 1 or 30
> tables versus the administration of 30 tables. Is that really an issue.
> Based on the discusion following this part, I think only a single table will
> be needed since MySQL should be able to handle the amount of data we are
> dealing with.
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> Linkbat-devel mailing list
Shanta McBain <shanta@...>