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 ««12345»»»

Decoupling in Relational Databases Expand / Collapse
Author
Message
Posted Tuesday, March 2, 2010 4:25 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:18 PM
Points: 5,327, Visits: 3,016
jacroberts (3/2/2010)
It's not decoupling but designing for resolving many-to-many releationships.


Surely, depending on ones perspective the many-to-many relationship is defined in a link table that decouples entities at either end of the relationship from the definition of the relationship itself.

Whilst the author uses unorthodox terminology in this context, I believe what he is saying is essentially correct.

Someone from a non-SQL background may understand this article better because of such use of different terms. The article would be improved, however, if it then went on to show what the accepted terms are and to what they apply e.g. bridge tables being link tables.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #875003
Posted Tuesday, March 2, 2010 4:32 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, July 13, 2011 4:11 AM
Points: 113, Visits: 144
OK Gaz - maybe the language was a bit intemperate. But I did feel that some of the comments were a little dismissive. We were ALL 'newbies' once - making elementary mistakes and learning (I hope I still am) by doing.

May all your SPIDS be well behaved!

Bill
Post #875006
Posted Tuesday, March 2, 2010 4:48 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:18 PM
Points: 5,327, Visits: 3,016
No worries Bill.

I feel it is essential to correct people when they are wrong or mistaken. I rely on people correcting me ALL the time.

We are all noobz at something


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #875013
Posted Tuesday, March 2, 2010 5:16 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 9, 2013 11:30 PM
Points: 1, Visits: 17
Why a surrogate PK in the User/Group table? A significantly more technical sounding title and teaser lead to a much different article than expected.
Post #875033
Posted Tuesday, March 2, 2010 5:18 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, August 1, 2014 9:56 AM
Points: 338, Visits: 1,422
Gary Varga (3/2/2010)
jacroberts (3/2/2010)
It's not decoupling but designing for resolving many-to-many relationships.


Surely, depending on ones perspective the many-to-many relationship is defined in a link table that decouples entities at either end of the relationship from the definition of the relationship itself.

Whilst the author uses unorthodox terminology in this context, I believe what he is saying is essentially correct.

Someone from a non-SQL background may understand this article better because of such use of different terms. The article would be improved, however, if it then went on to show what the accepted terms are and to what they apply e.g. bridge tables being link tables.


Most of us go by common usage of words, to decouple is to stop a dependance of one thing on another. The dependance is still there but in another table. The problem solved was resoving a many to many reletionship.

I know the difference between unorthodox and incorrect, decoupling is an incorrect term.
Post #875034
Posted Tuesday, March 2, 2010 5:37 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, July 8, 2013 5:04 AM
Points: 10, Visits: 154
What surprises me is that this was the number one 'featured article' in this week's mailing from sqlservercentral.com. This must either be because:
A) The 'featured articles' are just chosen at random, in which case it would be better to call them 'randomly-chosen articles', OR...
B) The person who chooses the featured articles wasn't able to tell (like surely most SQL Server developers would be able to at a glance) that this is a significantly flawed article - which would be rather scary.
Something went wrong here.
Post #875046
Posted Tuesday, March 2, 2010 5:46 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 1:39 PM
Points: 245, Visits: 735
I don't think any thing went wrong. The author presented an idea they felt strongly about, the community responded, yes Bill, I think a little harshly, but the end result was that many readers learned something. I think it went very right.

The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs ... Theodore Roosevelt


<><
Livin' down on the cube farm. Left, left, then a right.
Post #875051
Posted Tuesday, March 2, 2010 6:55 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, August 21, 2014 5:54 AM
Points: 1, Visits: 178
whether we call it decoupling or more formally normalization, the article itself is a good reminder that often times, databases are designed by people who aren't practiced in database design. After 20+ years of being a dba, I sometimes need that reminder in this fashion.
Post #875102
Posted Tuesday, March 2, 2010 6:56 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, April 18, 2013 8:56 AM
Points: 22, Visits: 140
I really had no idea that my (somewhat unintended) misnomer would have caused such a stir. Indeed, I appreciate that some commenters have replied that this is basic relational design.

I wrote this article from a programmer's point of view, in that classes that one builds in an object oriented paradigm should ideally be loosely coupled.

If I were building an application to represent the data that was stored in the User, Group, and User_Group tables, I would build the classes such that the User and Group classes could be loosely coupled and exist independently of one another...that is my justification of using "decoupled".

Like I said, I do agree that this article represents the basics of relational design, it becomes a more robust situation when "coupled" with the programming side of it.
Post #875104
Posted Tuesday, March 2, 2010 7:00 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:18 PM
Points: 5,327, Visits: 3,016
Tim,

As a IT practitioner I am sure that you understand that common terminology is essential in maintaining clarity. It is a good article as an introduction to the technique for programmers with the caveats previously posted. I hope you took the constructive input as such. Some phrasing is occasionally harsh but usually it is not intended as such on these forums.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #875110
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse