Re: Recursive queries in slow database

From: Roy Hann <specially_at_processed.almost.meat> Newsgroups: comp.databases.theory
Subject: Re: Recursive queries in slow database Date: Tue, 11 Jan 2011 18:13:23 +0000 (UTC) Organization: Aioe.org NNTP Server
Lines: 47
Message-ID: <igi6k3$331$1_at_speranza.aioe.org> References: <0dc6b909-6344-4dfd-a640-5cb8b53e8468_at_s5g2000yqm.googlegroups.com> NNTP-Posting-Host: fUEh9+sMLTMq2OZR54fPQw.user.speranza.aioe.org Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse_at_aioe.org
X-Notice: Filtered by postfilter v. 0.8.2 User-Agent: XPN/1.0.0 (Monkey Business ; Windows) Xref: textnews.cambrium.nl comp.databases.theory:34776

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.

-- 
Roy