Re: Relational-to-OOP Tax

In article <1172487367.687875.139550@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
frebe73@xxxxxxxxx says...
Just for example, nearly nobody doing text
mining work uses relational databases

Many SQL vendors has text mining features. Oracle Text for example.

Do you really fail to see how these are two entirely different sorts of
statements?

[ ... ]

Most SQL database are designed for typical "enterprise scenarios".
Other areas like GIS and text mining are supported by many vendors,
but not all. The fact that one might chose a non-SQL database for such
areas is not because the relational model is flawed, but because the
availible DBMS implementations suffers.

The relational model is a bit like the ISO 7-layer model for networks.
Each makes a great reference model and in theory, each should work
perfectly well. OTOH, real implementations of either are few and far
between. The few that do make the attempt all share one characteristic:
stunningly awful performance.

Either one should theoretically work perfectly well -- but if you need
to get something done this week, this year or even this decade, don't
look to either one for help except as a reference model.

SQL databases are, of course real -- and while their performance may not
be as bad as the ones that try to be "more relational", they're still
pretty awful -- with considerable hand-tuning. Without a lot of careful
tuning (especially being careful about _exactly_ what's indexed) the
performance is a LOT worse than that. In fact, at one point I called up
Oracle convinced I must be doing something drastically wrong, because a
query I was using took over 12 minutes to complete on their database,
even though it took only about 15 seconds with my own custom code.

After a couple of days, they (literally) called back and offered me a
job, because even using somewhat faster hardware than mine, their gurus
hadn't gotten the query to run in under 15 minutes (fortunately I could
give them the raw data since it was all public information). They
assured me that for a query of this complexity, 12 minutes was amazingly
fast, and they were quite certain no other SQL vendor could provide any
better performance. I didn't bother telling them that my text-mining
code (written in C++, using lots of objects, thank you very much) did
the same job in around 5 seconds -- and, BTW, the theoretical minimum
necessary for the amount of data retrieved was about 3 second with that
particular machine's disk drives.

SQL supports a fairly general version of basic, structured data, but the
minute you get into less-structured data, it tends to fall apart.

Can you prove this? Or do you have some examples?

I already posted one, and I've given another above. Of course, it's
theoretically impossible to prove the absolutely general case -- in
theory, at any moment, somebody _could_ release a SQL database that
isn't dreadfully slow. OTOH, progress seems to happen only in tiny
increments on rare ocassion. I'd be surprised if it works out to a whole
percent per year, and to get performance that compares to typical
hierarachical databases, we need something like 1000+ percent
improvement...

[ ... ]

If you would have continued to read you would have found that they
also states that classes should never be mapped to tables, only to
domains (datatypes). (Se http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-printable.pdf,
p 52-61, if you need a shorter version).
"We cann't accept the equation object class = relation" and
"object class = domain"

I'm afraid that while I'm quite willing to defer to Date in deciding
what does or does not fit the relational model, I'm less impressed with
his understanding of object orientation. He seems to consider OO purely
a matter of abstract data types, which is either completely missing the
point, or one tiny step short of it.

Date states that relations and objects are orthogonal, that means that
they should not be used for the same thing. If you already have the
data in a relational way, there are no need to transform it into a
network graph.

....and you've obviously missed the point as well -- or rather, you've
missed two points. You missed both the point of object orientation, AND
his point as well.

[ ... ]

Although I have only read parts of the book, I would recommend you to
read it too.

I have -- though I'd previously read (nearly all of) _An Introduction to
Database Systems_, so this book didn't really add much. Rather the
contrary, in direct contradiction to their names, the "Introduction" is
the one that goes into real depth, while the "in depth" book is far more
an introduction.

When you would understand why O/R mapping is such stupid
thing to do.

Here we're apparently back to your poor understanding of English. If
you've seen a post where you think I advoctaed O/R mapping, please be so
kind as to cite it so I can correct your misunderstanding.

--
Later,
Jerry.

The universe is a figment of its own imagination.
.

Relevant Pages

  • Re: Data Layer architecture
    ... > the first week of>> any serious database course). ... rules were described to be inside the RDBMS, ... is not a theory which states anything about business ... > The Relational Model is nothing but a direct application of set theory ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: WWW/Internet 2009: 2nd CFP until 21 September
    ... afterwards focussed on the application of the relational model to the ... organization of data banks for large scale sharing of data. ... by a single application inside which the database is to be embedded. ... lack of transaction control wasn't really the reason reservation systems ...
    (comp.databases.theory)
  • Re: Table Design Question
    ... > requires more than two probes, no matter how large the database. ... > acceptable (in the relational model) to have an Identity attribute to ... the gap in the sequence is not filled in and the sequence ... > vin CHARNOT NULL REFERENCES Motorpool); ...
    (microsoft.public.sqlserver.programming)
  • Re: SQL
    ... >business and presentation rules in the applications. ... DBMS were created ... The fundamental purpose of a DataBase Management ... >Around a corruption of THE Relational Model. ...
    (comp.object)
  • Re: Databinding - Best Practice (object-oriented)
    ... >>relational model throughout your application severely restricts the ... The Relational Model is not SQL. ... difficult to persuade developers to ditch the database independance this ... What SQL domains should be but they are not. ...
    (microsoft.public.dotnet.framework.windowsforms)