Relational Databases Lack Relationships

[Eric]

Following a recent catastrophic computer failure I found myself having
to browse the internet with the interruption of many more advertisements
than I am used to. One amazingly pervasive ad offered me a free download
of a book about graph databases. Obviously from a company that makes a
"graph database system", whatever that is. Still, after about the 47th
viewing, why not, I might learn something.

What I have learnt so far is that they use the subject of this post as a
section heading, followed by:

"For several decades, developers have tried to accommodate connected,
semi-structured datasets inside relational databases. But whereas
relational databases were initially designed to codify paper forms
and tabular structures—something they do exceedingly well—they
struggle when attempting to model the ad hoc, exceptional relationships
that crop up in the real world. Ironically, relational databases deal
poorly with relationships."

Aside from needing to find out what on earth they mean by
"semi-structured" and "ad-hoc, exceptional relationships", has anyone
ever heard, from any other source, that codifying paper forms and tabular
structures is what relational databases were designed to do?

I'm not actually sure how much I care, but...

Eric
--
ms fnd in a lbry

[Nicola]

Alas, often. A part of the XML community had a similar mindset, for
instance. And I work with people who dismiss the relational model as a way
to have data uncomfortably spread across different tables.

Alas, I happen to have read the chapter you cite. The whole section is a
pearl. It may be previewed on Google Books (Section 2):

https://books.google.com/books?id=jzvcCQAAQBAJ&printsec=frontcover

You must realize that when they say "relational databases", they
really mean MySQL. Just to put things in perspective.

And as a cherry on the cake, I find it kind of ironic that their example
is about social networks, when (a heavily customized and distributed
version of) MySQL was used to build Facebook!

Nicola


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Eric]

On 2015-10-23, Nicola <nvitac...@gmail.com> wrote:
> On 2015-10-22 16:20:18 +0000, Eric said:
>
>> Following a recent catastrophic computer failure I found myself having
>> to browse the internet with the interruption of many more advertisements
>> than I am used to. One amazingly pervasive ad offered me a free download
>> of a book about graph databases. Obviously from a company that makes a
>> "graph database system", whatever that is. Still, after about the 47th
>> viewing, why not, I might learn something.
>>
>> What I have learnt so far is that they use the subject of this post as a
>> section heading, followed by:
>>
>> "For several decades, developers have tried to accommodate connected,
>> semi-structured datasets inside relational databases. But whereas
>> relational databases were initially designed to codify paper forms

>> and tabular structures - something they do exceedingly well - they

>> struggle when attempting to model the ad hoc, exceptional relationships
>> that crop up in the real world. Ironically, relational databases deal
>> poorly with relationships."
>>
>> Aside from needing to find out what on earth they mean by
>> "semi-structured" and "ad-hoc, exceptional relationships", has anyone
>> ever heard, from any other source, that codifying paper forms and tabular
>> structures is what relational databases were designed to do?
>
> Alas, often. A part of the XML community had a similar mindset, for
> instance. And I work with people who dismiss the relational model as a way
> to have data uncomfortably spread across different tables.

And unable to even consider that they have missed a point somewhere?

> Alas, I happen to have read the chapter you cite. The whole section is a
> pearl. It may be previewed on Google Books (Section 2):
>
> https://books.google.com/books?id=jzvcCQAAQBAJ&printsec=frontcover

I know what you mean but I wouldn't want anyone to think that it was as
pretty or valuable as a pearl!

> You must realize that when they say "relational databases", they
> really mean MySQL. Just to put things in perspective.

MySQL - My Little [young animal of choice]! Like the graph stuff,
created by people with no perspective on anything except their own
immediate concern. The problem is, they are all programmers with no idea
that data has an independent existence and may be used by some program
other than the one they are writing right now. If you tell them this
they, almost without exception, offer you an API which will never provide
the data accessibility or performance that will inevitably be needed.

To be fair, MySQL has improved a bit over the years, though never to the
point that I would choose to use it.

> And as a cherry on the cake, I find it kind of ironic that their example
> is about social networks, when (a heavily customized and distributed
> version of) MySQL was used to build Facebook!

Indeed.

[Nicola]

On 2015-10-24 16:29:23 +0000, Eric said:

> On 2015-10-23, Nicola <nvitac...@gmail.com> wrote:
>> On 2015-10-22 16:20:18 +0000, Eric said:
>>>
>>> Aside from needing to find out what on earth they mean by
>>> "semi-structured" and "ad-hoc, exceptional relationships", has anyone
>>> ever heard, from any other source, that codifying paper forms and tabular
>>> structures is what relational databases were designed to do?
>>
>> Alas, often. A part of the XML community had a similar mindset, for
>> instance. And I work with people who dismiss the relational model as a way
>> to have data uncomfortably spread across different tables.
>
> And unable to even consider that they have missed a point somewhere?

People are not rational :)

Another area where the "relational data model turns out to be too poor" (to
quote a popular textbook) is spatial databases. The argument by which spatial
data do not fit into tabular form, hence the relational model is unsuitable,
is commonplace.

[Norbert_Paul]

Commonplace but maybe wrong:
http://comjnl.oxfordjournals.org/content/53/1/69

Norbert

[Eric]

Oh, we knew it was wrong, but thank you for the link to help prove it!

[Norbert_Paul]

Oh, I didn't know you knew it. Your post made me think you shared
Egenhofer's point of view.
You are welcome.

> Eric
Norbert

[Norbert_Paul]

Eric wrote:
> Following a recent catastrophic computer failure I found myself having
> to browse the internet with the interruption of many more advertisements
> than I am used to. One amazingly pervasive ad offered me a free download
> of a book about graph databases. Obviously from a company that makes a
> "graph database system", whatever that is. Still, after about the 47th
> viewing, why not, I might learn something.
>
> What I have learnt so far is that they use the subject of this post as a
> section heading, followed by:
>
> "For several decades, developers have tried to accommodate connected,
> semi-structured datasets inside relational databases. But whereas
> relational databases were initially designed to codify paper forms
> and tabular structures—something they do exceedingly well—they
> struggle when attempting to model the ad hoc, exceptional relationships
> that crop up in the real world. Ironically, relational databases deal
> poorly with relationships."

Relational databases were initially designed to implement the ideas
Codd has developed [1] and which he managed to get broad acceptance.
Obviously he had to struggle for that:
"... my determination to fight for what I believed was right
during the ten or more years in which government, industry,
and commerce were strongly opposed to the relational approach
to database management." (dedication in [2])

> Aside from needing to find out what on earth they mean by
> "semi-structured" and "ad-hoc, exceptional relationships", has anyone
> ever heard, from any other source, that codifying paper forms and tabular
> structures is what relational databases were designed to do?

I have often heard of that "tabular structure". It is a misconception.
It is also not surprising to me that a company which sells graph databases
gives away free books containing criticism on the relational model.

> I'm not actually sure how much I care, but...

... you seem to care.

> Eric
Norbert

References:
[1] https://technology.amis.nl/wp-content/uploads/images/RJ599.pdf
[2] https://books.google.de/books/about/The_Relational_Model_for_Database_Manage.html?id=ZZckAQAAIAAJ

[Nicola]

I have followed (distractedly, though) your interesting discussion in
this group about your topological model a few months ago, but I have not
read your paper (btw, just a few days ago I was searching for your
Lisp implementation, but I could not find it).

As for my point of view, I do not share the opinion that the relational
model is not expressive enough to capture, say, spatial data. On the other
hand, I think that there is a tension between what you choose to represent
as a data type and what you represent as a relational schema, which is
determined not only by expressiveness, but also by the succintness of the
representation, by the desired level of granularity of the
representation, and by the data integrity requirements.
For some kinds of data, it may be legitimately, and perhaps
convincingly, argued that the tension resolves favorably on the side of
using specialized data types. As an aside, having worked with both spatial
and genetic data, I find it curious that for the latter no one, as far as
I know, has argued in that sense, which in my opinion would be more
justified than for the former.

Besides the above considerations, which are purely at the logical level,
there are physical issues as well. Currently, the most common
implementation of a relation in a DBMS is a row-ordered record-based file
(with a one-one mapping between a table definition and a file).
Saying that some types of data are not efficiently managed when stored
in a row-ordered record-based file (which is often what is really meant
by the misleading "data do not fit into the relational model") is an
unproblematic statement.

[Eric]

On 2015-10-28, Nicola <nvitac...@gmail.com> wrote:
8>< --------

> Currently, the most common
> implementation of a relation in a DBMS is a row-ordered record-based file
> (with a one-one mapping between a table definition and a file).

Is it really?

(not arguing with your actual point though)

[Eric]

True, of course.

>> I'm not actually sure how much I care, but...
> ... you seem to care.

Perhaps a little...

[Anne & Lynn Wheeler]

Eric <er...@deptj.eu> writes:
> Aside from needing to find out what on earth they mean by
> "semi-structured" and "ad-hoc, exceptional relationships", has anyone
> ever heard, from any other source, that codifying paper forms and tabular
> structures is what relational databases were designed to do?

I got roped into doing doing part of the implementation for original
sql/relational ... Codd's office was floor above mine.

they were somewhat competing with IMS for efficient financial
transactions (as early adopter) and table optimization allowed single
record to be fetched using account number index, that contained all the
fields for performing financial transactions.

The IMS group still criticized the implementation as requiring twice the
disk space (for the table index) as IMS with its direct record pointers
... and 4-5 the disk I/Os (doing index lookup). The counter was that IMS
required significant manual maintenance to go through and update all the
exposed record pointers anytime there was even trivial, minor change in
layout. To some extent the trade-offs inverted in the 80s when cost of
disk space enormously dropped and size of memories significantly
increased ... allowing significant amount of index caching (reducing
physical disk i/os). One of the original customer joint studies/pilots
was with large financial institution.

The next generation "official" DBMS was called EAGLE. With the
corporation preoccupied with EAGLE, we were able to do technology
transfer to Endicott and get it released as SQL/DS. Later when EAGLE
implodes, they ask how long could it would take to make it availble
... which is eventually released as DB2.

At the same time, I got sucked into doing another implementation that
directly instantiated all relationships (done fpr internal chip design
tools group) ... every field effectively became separate indexed record
and every relationship became separate indexed record. It could require
7-10 times the disk space as the original sql/implementation and
significant more disk i/os (access index for a field, then read the
field, then access the indexes for all its possible relationships, read
the relationships, and then access all the indexes for each field for
each relationship and then read all those fields.)

For really large amounts of complex data ... there was cross-over where
table joins became more expensive/overhead than directly instantiating
all fields and relationships (with forest of indexes)

--
virtualization experience starting Jan1968, online at home since Mar1970

[Nicola]

On 2015-10-29 15:35:19 +0000, Eric said:

> On 2015-10-28, Nicola <nvitac...@gmail.com> wrote:
> 8>< --------
>> Currently, the most common
>> implementation of a relation in a DBMS is a row-ordered record-based file
>> (with a one-one mapping between a table definition and a file).
>
> Is it really?

I don't have numbers, and I'd like to be proved wrong. As far as I know,
that is the layout (or among the layouts) used by the most popular DBMSs.

But even if the all the DBMSs in the world used a different storage model,
my point stands still, that is, there is a widespread misconception by
which the notion of a "relation" is inevitably associated to a specific
kind of physical representation or, even worse, to the implementation
used by a specific product - the book you've cited being an example.

[Tom Ivar Helbekkmo]

Eric <er...@deptj.eu> writes:

> "[...] Ironically, relational databases deal poorly with

> relationships."
>
> Aside from needing to find out what on earth they mean by

> "semi-structured" and "ad-hoc, exceptional relationships", [...]

Here's an entertaining text on the topic:

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

-tih
--
Elections cannot be allowed to change anything. --Dr. Wolfgang Schäuble

[Ed Prochak]

nice article. Thanks for the link.

[Tegiri Nenashi]

On Friday, November 6, 2015 at 5:35:59 AM UTC-8, Tom Ivar Helbekkmo wrote:
> http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

That's what you get when your data is in -1st (minus first) normal form! (It is no sql, and SQL is first normal form).