March 1, 2010 at 9:33 pm
Comments posted to this topic are about the item Decoupling in Relational Databases
March 2, 2010 at 12:49 am
The article is of course correct but 'decoupling databases' is not what it is about. What you describe is the very basics of database design. And the tabels are relation tables, not bridge tables... So nothing is being decoupled here, just properly designed.
March 2, 2010 at 12:55 am
I have to agree that this article is both mis-named and really a no-brainer. Just good design practice. There is really no simpler way of implementing many-to-many relationships in relational databases
March 2, 2010 at 1:36 am
My understanding is that in this standard relational database design pattern (as highlighted by the previous posters) and what the article refers to as a 'bridge table' is commonly referred to as a 'link table'.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 2, 2010 at 2:54 am
Hi Timothy,
Normalization and decoupling are one and the same?
March 2, 2010 at 3:05 am
sqlusers (3/2/2010)
Hi Timothy,Normalization and decoupling are one and the same?
Just to butt in, I would say that normalisation is the standard way of decoupling data in a relational database.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 2, 2010 at 3:06 am
Give the guy a break - this is aimed at newbies.
Right - it is a no-brainer for us grizzled database developers. I can add a little constructive criticism though Tim. Your link table has an IDENTITY column - why? If you create a composite key of your fk_user + fk_group columns (check out your naming as well) and set this as the PRIMARY KEY to this link table you are killing a couple of birds with one stone.
(1) You have eliminated a redundant column
(2) You have ensured that you are not duplicating USER-GROUP membership (PK uniqueness)
(3) You can either eliminate your duplicate checking SQL and let the UI layer deal with an error, or simplify your checking to ignore the error completely
Bill
March 2, 2010 at 3:47 am
bill.sugden (3/2/2010)
Give the guy a break - this is aimed at newbies.Right - it is a no-brainer for us grizzled database developers. I can add a little constructive criticism though Tim. Your link table has an IDENTITY column - why? If you create a composite key of your fk_user + fk_group columns (check out your naming as well) and set this as the PRIMARY KEY to this link table you are killing a couple of birds with one stone.
(1) You have eliminated a redundant column
(2) You have ensured that you are not duplicating USER-GROUP membership (PK uniqueness)
(3) You can either eliminate your duplicate checking SQL and let the UI layer deal with an error, or simplify your checking to ignore the error completely
Bill
Bill,
I will say that I feel that most of the comments are constructive criticisms. Particularly as this is aimed at the more novice practitioner, we need to ensure the accuracy of the article. Personally, I don't think that terms such as 'no brainer' and 'newbies' helps but some people find them helpful descriptives. Interestingly, there is a recent thread discussing how to inform authors or errors, mistakes and corrections ().
Regards,
Gary
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 2, 2010 at 3:48 am
This is a good article that proves how normalization helps you design and maintain a database.
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
March 2, 2010 at 4:15 am
It's not decoupling but designing for resolving many-to-many releationships.
March 2, 2010 at 4:25 am
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!!!
March 2, 2010 at 4:32 am
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
March 2, 2010 at 4:48 am
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!!!
March 2, 2010 at 5:16 am
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.
March 2, 2010 at 5:18 am
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.
Viewing 15 posts - 1 through 15 (of 98 total)
You must be logged in to reply to this topic. Login to reply