SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Decoupling in Relational Databases


Decoupling in Relational Databases

Author
Message
Gary Varga
Gary Varga
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19795 Visits: 6534
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!!!
bill.sugden
bill.sugden
SSC-Enthusiastic
SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)SSC-Enthusiastic (145 reputation)

Group: General Forum Members
Points: 145 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
Gary Varga
Gary Varga
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19795 Visits: 6534
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!!!
shan plourde
shan plourde
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
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.
Jonathan AC Roberts
Jonathan AC Roberts
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1193 Visits: 1913
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.
jinlye
jinlye
SSC Rookie
SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)

Group: General Forum Members
Points: 30 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.
Tobar
Tobar
SSChasing Mays
SSChasing Mays (659 reputation)SSChasing Mays (659 reputation)SSChasing Mays (659 reputation)SSChasing Mays (659 reputation)SSChasing Mays (659 reputation)SSChasing Mays (659 reputation)SSChasing Mays (659 reputation)SSChasing Mays (659 reputation)

Group: General Forum Members
Points: 659 Visits: 758
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.
bwilson-600995
bwilson-600995
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
Points: 1 Visits: 263
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.
timclaason
timclaason
Valued Member
Valued Member (64 reputation)Valued Member (64 reputation)Valued Member (64 reputation)Valued Member (64 reputation)Valued Member (64 reputation)Valued Member (64 reputation)Valued Member (64 reputation)Valued Member (64 reputation)

Group: General Forum Members
Points: 64 Visits: 143
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.
Gary Varga
Gary Varga
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19795 Visits: 6534
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!!!
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search