XSL & Stuff

[matthew_heusser at mcgraw-hill.com]

... uhh .. sorta.  Let me try to explain ...

SQL Databases are slow, expensive, and take
clock cycles.  If you've got to store a lot of
data on a local PC, you don't want to be shipping
a copy of SQL Server with every app.  That
said ...

>What do you mean by an "XML database"?

Here's the deal.  Use a nifty, propietary way to store
data in a compact format.  Create a process to turn a
single item (product, set of products, whatever) into into
XML using MS Tools.  This is done on-demand, so
we don't need to store the data in XML format.

Use XSL to transform that XML into HTML.

This allows us to separate the data storage layer (proprietary)
from the business logic (make XML) from the presentation
layer ("Stock" HTML pages that are filled dynamically).

If you think about it, you can create several different XSL "templates",
and apply a different Template to get a different view of the data.

This is just like "skins" in windows media player, only different.

>If it's more like a data file, then I'm curious about your
>opinions/experiences with storing the data in independent hierarchical
>data structures (i.e.- the XML documents)

Too much disk space.

>in contrast to storing data in relations (tables) in a DBMS?

Too much disk space.
And too expensive.  (Or hard to maintain, if you're an open-sourcer)
And takes too many clock cycles.

If I _had_ to have the functionality of a database with >10,000,000 records
and I _needed_ to beat the performance of MS Access, I'd probably look
for a Indexed Squential Access Method (ISAM) database product, like the
old informix.  Failing that, I'd try to find a way to get some of the
functionality
of a database without the cost/performance penalty.  (Especially if you
find yourself in a sitatuation where you only need to get data out of the
database,
not add to it.)

Just my $0.02.

Is anyone using XML in Perl?  Perl.Net?  Visual Perl?  Komodo? Ruby?
Anything cool in West Michigan? (No, use cgi; does not count.)


Matt H.