March 2, 2010 at 5:37 am
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.
March 2, 2010 at 5:46 am
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.
March 2, 2010 at 6:55 am
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.
March 2, 2010 at 6:56 am
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.
March 2, 2010 at 7:00 am
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!!!
March 2, 2010 at 7:02 am
I was hoping to learn something new by reading the article (and I do have a lot to learn). I had not heard of the Bridge table or Decoupling, but this article did not teach me anything i did not already know. Can someone give me a quick meaning of decoupling and Bridging, or does this article cover what i need to know?
March 2, 2010 at 7:06 am
david.kelly-653902 (3/2/2010)
I was hoping to learn something new by reading the article (and I do have a lot to learn). I had not heard of the Bridge table or Decoupling, but this article did not teach me anything i did not already know. Can someone give me a quick meaning of decoupling and Bridging, or does this article cover what i need to know?
If you read all the posts you will notice that the Bridge table is equivalent to what is usually called a link table and decoupling is referring to what is achieved by the separation of entities and relationships through normalisation.
Once again, the application of terminology, like naming (or perhaps as a specific type thereof), is always important.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 2, 2010 at 7:13 am
All this discussion about what to call these tables points out that we as a profession do a lousy job of defining our profession ;-).
These tables can be referred to as:
- Associative tables
- Link Tables
- Bridge Tables
- M:N or many-to-many Tables
- Resolution Tables
- Intersectional Tables
- Relationship Tables
...depending on whom you read, when you read it, or what tools you use. Oddly enough, I'm getting lots of push back from developers these days that having such tables is "bad design". I'm trying to track down a source for this "knowledge". What devs are telling me is that the real world does not have many-to-many relationships and that these are just artifacts of a designer trying to push relational theory onto a non-relational world. I don't see that
What I enjoyed about this article is the "confession" part that showed how a bad design can get one into trouble. Articles should have such anti-patterns to show that there's a reason why something is a better solution.
March 2, 2010 at 7:25 am
As a 'newbie', this was a bit of review, but still very useful info. Hopefully when I'm a grizzled veteran I'll still appreciate posts like this one.
Good job!
March 2, 2010 at 7:25 am
Interesting. I've never heard it referred to as a link or bridge table (except in data warehousing), but instead I've always heard it referred to as an association table in relational design at the 3 places I've been at.
March 2, 2010 at 7:28 am
I had to smile when I read this post.
I've been working with databases for almost 20 years now and I was hoping to see some interesting approach to a complex problem.
I was instead reminded that not everyone is a veteran and that I wish I had an article like this one (or even the internet!) when I was cutting my teeth -- it would have saved me having to learn this stuff on my own!
March 2, 2010 at 7:31 am
I seem to be getting this response a lot (is it "bridge table" or "link table")...which is funny, because I've only ever called them "bridge tables".
As Karen Lopez points out, there are quite a lot of terms for them.
Interestingly, when I do a google search with the following terms, I get the following results:
"Link Table" sql - 22,500
"Bridge Table" sql - 27,500
Thanks for the response. I think, As Gary Varga points out on page 2 of the comments, using the accepted terminology is key.
March 2, 2010 at 7:33 am
Karen Lopez-396111 (3/2/2010)
All this discussion about what to call these tables points out that we as a profession do a lousy job of defining our profession ;-).These tables can be referred to as:
- Associative tables
- Link Tables
- Bridge Tables
- M:N or many-to-many Tables
- Resolution Tables
- Intersectional Tables
- Relationship Tables
...depending on whom you read, when you read it, or what tools you use. Oddly enough, I'm getting lots of push back from developers these days that having such tables is "bad design". I'm trying to track down a source for this "knowledge". What devs are telling me is that the real world does not have many-to-many relationships and that these are just artifacts of a designer trying to push relational theory onto a non-relational world. I don't see that
What I enjoyed about this article is the "confession" part that showed how a bad design can get one into trouble. Articles should have such anti-patterns to show that there's a reason why something is a better solution.
I hadn't heard of bridge tables so assumed (highlights myself as a fool!) that this was a carryover from development lingo (as a developer myself I have know the Bridge pattern etc). I have heard of Resolution and Intersectional tables but not for so long I would rather not admit the length of time. To be honest I always disliked the term Relationship Table for being far to generic.
I think that this "bad design" originates from ORMs that struggle with such concepts. Many to many relationships in OO programming is notoriously hard to get right (particularly before garbage collectors). As such, it has generally been considered good practice to avoid such runtime representation in applications. Servers may need to represent this design in memory but there is no reason in my opinion why this should be "bad design" for the persistent store e.g. SQL Server.
Tim's User & Group entities is a great example. You would not want to load a User only to load all their Groups and thus all the Users in all these Groups and thus all Groups these Users are in thus all the Users in all these Groups and thus all Groups these Users are in...and so on. This is an example of where one rule certainly DOES NOT apply across technical artifacts / systems etc.
FWIT, I liked the article but felt that anyone coming in should have some clarity...if only I was able to do that 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 2, 2010 at 7:34 am
A nice improvement on the original, Timothy. So many developers never get past the point you started at.
May I recommend picking up "The Art of SQL" by Stephane Faroult? And perhaps "SQL and Relational Theory" by C J Date, and maybe Joe Celko's "Thinking In Sets".
Most developers get into relational databases by accident and never get the background they need. You've obviously got the head for it, and I think you might find these books will consolidate your thinking on these matters.
Roger Reid
PS - it is true some of the terminology is off. Given that we are trying to do relational databases using SQL, I think we can cut each other a little slack on vocabulary. The C J Date book will clarify that!
Roger L Reid
March 2, 2010 at 7:36 am
bob.probst+sqlservercentral (3/2/2010)
I had to smile when I read this post.I've been working with databases for almost 20 years now and I was hoping to see some interesting approach to a complex problem.
I was instead reminded that not everyone is a veteran and that I wish I had an article like this one (or even the internet!) when I was cutting my teeth -- it would have saved me having to learn this stuff on my own!
If only I knew what to use!!! :w00t:
Always been the minority though.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 16 through 30 (of 98 total)
You must be logged in to reply to this topic. Login to reply