Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Relational Database Without Relations Expand / Collapse
Author
Message
Posted Monday, July 15, 2002 12:00 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

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
Posted Sunday, July 28, 2002 2:52 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, December 6, 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
Posted Sunday, July 28, 2002 3:06 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Friday, August 29, 2014 8:46 AM
Points: 6,783, Visits: 1,881
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
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #37572
Posted Monday, July 29, 2002 2:56 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 3:43 AM
Points: 7,005, Visits: 8,453
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


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

- 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"


Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me
Post #37574
Posted Monday, July 29, 2002 10:29 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, June 14, 2014 8:10 AM
Points: 3, Visits: 4
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
Posted Monday, July 29, 2002 1:39 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, January 5, 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
Posted Monday, July 29, 2002 2:40 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 12:57 PM
Points: 33,206, Visits: 15,361
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
Posted Sunday, August 4, 2002 1:41 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum 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
Posted Sunday, August 4, 2002 3:32 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Friday, August 29, 2014 8:46 AM
Points: 6,783, Visits: 1,881
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
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #37579
Posted Sunday, August 4, 2002 4:22 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, December 6, 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 »

Add to briefcase 12»»

Permissions Expand / Collapse