July 15, 2002 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/EBereznuk/relationaldatabasewithoutrelations.asp
July 28, 2002 at 2:52 pm
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
July 28, 2002 at 3:06 pm
Not sure I agree either. Can you show me a real world problem that this solves more cleanly than a standard RDBMS solution?
Andy
July 29, 2002 at 2:56 am
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
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- 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
July 29, 2002 at 10:29 am
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.
July 29, 2002 at 1:39 pm
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 http://www.dbdebunk.com
July 29, 2002 at 2:40 pm
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
August 4, 2002 at 1:41 pm
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
August 4, 2002 at 3:32 pm
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
August 4, 2002 at 4:22 pm
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
August 5, 2002 at 9:48 am
Didn't get through the white paper, but did look at 3 of their sample apps. All look the same. Not sure there's anything great here.
Steve Jones
August 21, 2002 at 10:27 am
Dear oh dear !
I always worry when the phrase "I just want to..." turns up, I really do. Reminds me of "I don't want to learn to drive, I just want to get in a car and go places" !
Perhaps the "whacky schemas" referred to earlier occur because those designing the schemas don't really understand the relational model properly, and instead of viewing a database as a collection of predicates & facts lapse into programmerese and think of a database as a collection of records in files !
It's been said before in the replies above, but a visit to http://www.dbdebunk.com can only help (although it can get a little heated at times...)
- Tony
In a world without walls or fences, what need have we of Windows or Gates ?
In a world without walls or fences, what need have we of Windows or Gates ?
August 21, 2002 at 10:34 am
And also ...
In response to Andrew C-S, who said that EF Codd's "abstract mathematical concept [of a relation] corresponds closely to the table in modern databases" ... well, sadly, it doesn't. Relations can't have duplicates (for two reasons; relations are sets, and sets can't have duplicates; and relations form assertions of fact, so it's pointless asserting the same fact twice in the absence of "fuzzy" or weighted logics). Also, as originally defined, relations don't allow null.
SQL tables both allow duplicates and allow nulls, so strictly aren't relations (although if you're sensible, you'll always design your tables to prevent duplicates, and avoid using null because of tri-value logic horrors).
- Tony
In a world without walls or fences, what need have we of Windows or Gates ?
In a world without walls or fences, what need have we of Windows or Gates ?
May 9, 2005 at 9:28 am
A small note to the author: Relational databases are so called, not because the tables relate to each other, but because the data within any given table is all related. As my source for this tidbit of information, I quote Paul Nielson, author of the "Microsoft SQL Server 2000 Bible."
Andj
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply