On 6/21/06, Bernhard Eversberg <ev_at_biblio.tu-bs.de> wrote:
> Houghton,Andrew wrote:
> >
> > In addition, any current SQL database can deal with semi-structured
> > data without the use of XML columns or full text indexing through
> > the use of stored procedures and/or business logic to shred the
> > semi-structured data into a relational form.
> Yes, but what about performance? [I know, buy a bigger machine and
> larger disks...]
We're very happy with the performance of tsearch2 in Postgres, and
with built in inverted indexes coming soon ... well, imagine the speed
of Lucene and the power of SQL (for better or worse ;)).
>
> >
> > You cannot display a SQL index since it is an internal mechanism
> > that is used in relation to the data stored in the tables in your
> > database. This doesn't mean you cannot support "index browsing".
> >
> But why do so many SQL-based applications not do it?
Because their developers don't want to? Because they believe the "ALL
QUERIES MUST BE PORTABLE" cargo-cult mantra? Because they made design
decisions early on that locked them out of the possibility without
extreme pain? It's certainly not because it can't be done.
>
> >
> >>Further, SQL doesn't support structured fields. A field
> >>content cannot have subfields, or rather, SQL has no tool to
> >>do anything with them.
> >
> >
> > This is just not true. Lets take the MARC standard. Each field
> > has a one to many relationship with its subfields. In a relational
> > database this *could be* modeled with two tables.
> Yes, it "could". Again, this must in many cases be ruled out because
> of inefficiency and the sheer bulk of the tables you end up with.
I see 3 tables there: record, tag and subfield.
>
> >
> > This may not be the best database architecture for modeling MARC in
> > a relation database,
> Sorry, but shouldn't "next generation" be aiming at the best, and
> not compromise using inappropriate standards (just because they are
> standards)?
>
And instead adopt more library-specific processes and "standards" that
will end up pushing us farther from the rest of the world? [Although
that sounds snarky, it's a real option (though undesirable, IMHO)]
> > Again, a relational database can contain keyword indexes either
> > through full text indexing a column or using appropriate business
> > logic and/or a stored procedures to shred the information and
> > store the data in a table.
> >
> Again, who does it, and why not?
Evergreen, for one. :)
> >
> > Not saying that would be the best approach... but it might invoke
> > that 80-20 rule where using a relational database is good enough.
> >
> "Good enough" is, but I may be overly ambitious, not "next generation".
>
You may be, if you want to see an implementation in your lifetime.
But, then again, I may just be a cynic. ;-)
> B. Eversberg
>
--
Mike Rylander
mrylander_at_gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org
Received on Wed Jun 21 2006 - 10:40:11 EDT