Relational Database Without Relations

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss Content Posted by Eugene Bereznuk » Relational Database Without Relations

14 posts, Page 1 of 2

1 2 »»

Relational Database Without Relations

Rate Topic

Display Mode

Topic Options

Author

Message

eugene_b

Posted Monday, July 15, 2002 12:00 AM

Grasshopper

Group: General Forum Members
Last Login: Monday, August 16, 2004 3:34 AM
Points: 13, Visits: 1

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/EBereznuk/relationaldatabasewithoutrelations.asp

Post #5474

alasdair

Posted Sunday, July 28, 2002 2:52 PM

SSC Rookie

Group: General Forum Members
Last Login: Wednesday, December 06, 2006 5:20 AM
Points: 30, Visits: 1

Ok - basic article, interesting point.

Firstly, I'm afraid you're one of many who assumes that the "relation" in "relational database" refers to the ability to link related tables via foreign keys. This is not the case. E.F.Codd's definition of a relation as an abstract mathematical concept corresponds closely to the table in modern databases.

Secondly, there are, IMHO, problems with the whole relational database concept. I've worked on three separate implementations of object stores in RDBMS's, and they're all similar to what you're describing, only more comprehensive. Before I'm burned at the stake for heresay, please check out http://www.lazysoft.com and read about the associative model of data. It comes from a similar angle, with an entity list and an association list, but the ideas are deeply researched and by far and away the best implementation I've seen.

So, read about the associative model and see just how far you can go down this road...

Alasdair.

Alasdair Cunningham-Smith

Alasdair Cunningham-Smith

Post #37571

Andy Warren

Posted Sunday, July 28, 2002 3:06 PM

SSCertifiable

Group: Moderators
Last Login: Thursday, May 09, 2013 12:38 PM
Points: 6,462, Visits: 1,384

Not sure I agree either. Can you show me a real world problem that this solves more cleanly than a standard RDBMS solution?

Andy
http://www.sqlservercentral.com/columnists/awarren/

Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter

Post #37572

ALZDBA

Posted Monday, July 29, 2002 2:56 AM

SSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 2:17 AM
Points: 6,862, Visits: 8,049

With this title I'd expect a comparison regarding DRI and non-DRI objects (even with the DRI-indexes on the non-DRI objects). The first restriction is that with your implementation you can only have one to one relations because GUIDA is your primary-key.
From a maintenance point of view , I'd not want to take a look into your relations-table to see which tables are related and which are supposed to be related an which are not. Conclusion : nice shot, but needs more fundation.

Johan

     Jul 13

Don't drive faster than your guardian angel can fly ...
but keeping both feet on the ground won't get you anywhere w00t

- How to post Performance Problems
- How to post data/code to get the best help

- How to prevent a sore throat after hours of presenting ppt ?

"press F1 for solution", "press shift+F1 for urgent solution" BigGrin

Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me Hehe

Post #37574

mingxiao

Posted Monday, July 29, 2002 10:29 AM

Forum Newbie

Group: General Forum Members
Last Login: Saturday, January 22, 2005 9:30 AM
Points: 3, Visits: 1

I don't believe the relational model is as rigid as you described. The fact is that there are many different ways to model the same business concept in the real world. I've never seen two designers came up with the same model for a business application.

The real difference? By the end, the one performs best wins. Because the best design must be measured by both functionalities and performance in the real world. Focusing on one but neglecting the other would only lead to failure of the business in the end.

Nice try though.

Post #37575

omen

Posted Monday, July 29, 2002 1:39 PM

Grasshopper

Group: General Forum Members
Last Login: Tuesday, January 05, 2010 7:05 PM
Points: 22, Visits: 7

There so many things to comment on about this article that I almost don't know where to start!

Suffice to say that the fact that the kind of solution proposed is possible (even if kludgy) indicates the flexibility and power of the relational model.
In general, never equate a particular implementation's strengths and weaknesses (MS SQL Server) to the strengths and weaknesses of the model (the Relational Model). For what may be the best information regarding the relational model, see www.dbdebunk.com

Post #37576

Steve Jones - SSC Editor

Posted Monday, July 29, 2002 2:40 PM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:26 PM
Points: 31,425, Visits: 13,738

I sort of like the idea, though I tend to agree with the posters about the downfalls.

However, the intermediate table used to relate items and allow flexibility is a technique I've used before. The are numerous downfalls, however, one of which is the fact that you are depending on both objects being there, in other words, a match. If you are going to depend on a match, then why not relate the items in the standard way?

Thanks to the other posters for the references, I'm planning on checking them out.

Steve Jones
sjones@sqlservercentral.com
http://www.sqlservercentral.com/columnists/sjones

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #37577

dskarjune

Posted Sunday, August 04, 2002 1:41 PM

Forum Newbie

Group: General Forum Members
Last Login: Thursday, August 22, 2002 12:00 AM
Points: 1, Visits: 1

I have seen similar attempts at No Relations methodology before by DBAs. Rarely does a No Relations practice ensure data quality as can be achieved with normalization and referential integrity.

The failure of Bereznuk's approach is the reliance on GUIDs for 2 reasons. Using GUIDs as an indexing means is a storage and performance hit. Using GUIDs as a default key for any table is a poor substitute for determing a logical key for an entity.

As a consultant, I've seen saw plenty of dysfunctional enterprise database systems due to some smart DBA using similar freeform tactics. The goal may be for ease, flexibility, whatever; but the result is typically an undocumented repository that is difficult to interface with.

-David Hedrick Skarjune

Post #37578

Andy Warren

Posted Sunday, August 04, 2002 3:32 PM

SSCertifiable

Group: Moderators
Last Login: Thursday, May 09, 2013 12:38 PM
Points: 6,462, Visits: 1,384

Not sure I agree about the GUID's. From a pure size perspective, GUID's will be slower because they take up a bit more space. The offsetting advantage is that you can eliminate round trips, reducing server load and bandwidth usage. I believe even substituting identity columns does fulfill your requirement for determining a logical key. "Real" keys vs identity type keys is to me..a separate discussion!

I like nicely documented, easy to follow relations. I work with an app now that fell prey to the put it all in one table plan and while it works, it's harder to work with it than it needs to be.

Just to stretch the discussion a bit, I believe there are many times when it's acceptable to design using relationships but elect not to enforce them, both to reduce the overhead and to give you the freedom to do things you couldnt do if the foreignkey was enforced.

Andy
http://www.sqlservercentral.com/columnists/awarren/

Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter

Post #37579

alasdair

Posted Sunday, August 04, 2002 4:22 PM

SSC Rookie

Group: General Forum Members
Last Login: Wednesday, December 06, 2006 5:20 AM
Points: 30, Visits: 1

OK - so did anyone check this out?

http://www.lazysoft.com/docs/whitepaper/2000amdwhitepaper2.pdf (cut straight to page 9...)

I have no axe to grind - I'm a hardcore SQL Server guy. The reason I point it out is I've seen many attempts to do the "all in one table" approach, and ended up hating them all. But they're built again and again by smart developers trying to overcome the basic limitations of the relational model that we DBA types have got so used to, we can't see them any more.

The discussions about key size and choice of clustered index are fine and we've heard them all before. Just read Kalen Delany's book. The point is to understand why these whacky schema's keep coming up and to start asking some very hard questions about the applicability of the relational model (more cries of heretic) in the web era.

So come on, who else has a "non-standard" schema, and can they defend it rigourously?

Alasdair C-S

Alasdair Cunningham-Smith

Alasdair Cunningham-Smith

Post #37580

« Prev Topic | Next Topic »

14 posts, Page 1 of 2

1 2 »»

Permissions