Re: Recursive queries in slow database

From: David BL <davidbl_at_iinet.net.au>
Date: Tue, 11 Jan 2011 19:58:57 -0800 (PST)
Message-ID: <ade6f06c-efae-49ad-bd8e-657d694b84c1_at_b25g2000vbz.googlegroups.com>


On Jan 12, 2:13 am, Roy Hann <specia..._at_processed.almost.meat> wrote:
> Dr. Coffee wrote:
> > Hi all.
>
> > I am the user of a database, which is ridiculously slow for
> > even the simplest queries. The vendor of the db soes a lot
> > of stuff that I am deeply suspicious of:
>
> > - They don't hire staff with SW/dB experience, but general
> > MSc's and give them OJT.
>
> > - They have had no resources to provide proper OJT on SW/dbs
>
> > - They use one generic db model with a large number of clients
>
> > - Because of the generic architecture they use variables to
> > indicate data type in the table, slowing queries down
>
> > - They claim to have come up with a particular nifty trick
> > for recursive calls into the db, that they claim to be
> > sole users of
>
> > All in all, I suspect these people are amateurs and dillettantes
> > who have no idea what they are doing. I would love to hire pros
> > to re-do the work these people are not able to, but in order to
> > do that I will need to come up with convincing arguments to
> > support a claim that there are severe problems.
>
> > Any hints on how to proceed?
>
> I assume "OJT" is on-the-job-training? You claim they claim to do
> that training but don't? One place to dig would be wherever you think
> there is evidence to support that view.
>
> Google for, and read about the Entity-Attribute-Value (EAV) Model, which
> is what your description of their approach sounds like. You will find
> ample discussion of why it is bad--not the least reason being that its
> practitioners are reimplementing the very thing an SQL DBMS is designed
> to do. It is invariably done only partially too, leaving out almost
> all of the important stuff a DBMS does, like providing data integrity
> checks, transaction isolation, etc.

How does using EAV on top of an SQL DBMS leave out transaction isolation? I would have thought you could use an arbitrarily bad schema and still have serialisability of transactions assuming the underlying DBMS uses SS2PL. Received on Wed Jan 12 2011 - 04:58:57 CET

Original text of this message