Decoupling in Relational Databases

  • DCPeterson (3/3/2010)


    There is no need to be as condescending and rude as you were, period.

    A valid point, and I agree.

    For some reason, people seem to find fault in others as if there is some type of reward or financial gain for it. The Internet and "internet muscles" have only amplified the problem.

    Might I point everyone's attention Dale Carnegie's How to Win Friends and Influence People: Chapter 1: "Do not Critcize, Condemn or Complain". It will embarrass the criticizers, condemners and complainers...though they probably won't catch it.

  • btw you were at least as rude as I was. You were much ruder in a sense. Whereas my sentence strictly reflects the content of the article (the author himself tels us how bad his code was and how he learnt to implement an n-to-n relationship), you are making up some assumptions which are not based on anything and which could normally hurt me

    but don't worry, I understand your will to do justice in this world and to protect poor people, you are very noble and I admire you for that

  • Gosh, these comments have taken a turn toward the hostile. I felt inclined to post this article because I am aware of the frustrations one can experience in trying to learn something, and I thought that framing the article in the manner in which I did would be more helpful to aspiring database professionals than simply writing a grandiose article chock full of overly-technical terms that may scare such an aspiring database professional away.

    And although the "SQL Ninjas" out there were quite offended by the simplicity of the article, along with non-standard terms I used (normalization versus decoupling, bridge tables versus link tables), I personally think that this article could be beneficial to people trying to grasp concepts that they may have missed in their "relational databases 101" class in school.

    This article's intended audience was not the 20-year veteran of database technologies, nor did it claim to be, nor would I expect a 20-year professional to conclude it would, nor would I have ever made that assertion about this article. Evidently, explicitly stating the intended audience would have been a useful thing to do in the article's construction. In any case, I know there's something I've learned from this experience, and I hope that those who had such a visceral response to this article may learn to exercise some discernment of identifying the intended audience of an article, before (effectively) anonymously bashing its author and contents.

  • Tim,

    While I participated in an engaging (albeit, short) discussion with two others that spun from your article, I neglected to state a hearty, "Thank You" for your contribution. The drawback to posting something on the Internet is that any fool can read it, and many of them normally respond. (Yes, that was hax0red from Ben Franklin)

    😉

    Thanks again.

  • Hi Tim

    Don't let the trolls get ya down.

    I'm a 25+ years of experience data person. Even have a B.Sc. in a program that specializes in database design. Yet I learned a few things from your having taken the time to post your thoughts. They might not have been the take-aways that you had planned, but that the great part about communities - we all have something to learn from everyone.

    Keep on sharing your thoughts and taking feedback like a professional. That's the way we all advance.

    Karen

  • Thanks for your kind words, thisisfutile. This being my first article posted on SSC, one of the things I've realized is that I clearly don't have the stomach for some of the responses that posting is likely to generate (although I'm sure the 3 other upcoming articles will undoubtedly generate similar responses 🙂 ).

    I think that, as professionals, peer review and constructive criticism are crucial to our personal growth. I also think that it's a good thing when people come together and fiercely protect the integrity of a professional website. I've appreciated some of the discussions that the article has generated, and I've become more aware of some of the semantic nuances of this community. Some of the critical posts, though, are clearly not constructive nor protective of the professional integrity of SSC, rather, some of the posts I've read in response to this article are petty, lacking insight, and mean spirited -- mistaking the simplistic tone in the article for deficiencies in my understanding of the topic.

    Honestly, I've quite taken aback by some of the responses, because I don't usually get such critical feedback in the rest of my daily life...I suppose it's an exercise in "thick-skinnedness", and ultimately, a good experience to have had, but like I mentioned above, I don't really have the stomach for such unfiltered criticisms.

    Thanks again thisisfutile (and Karen Lopez)

  • Please confine the discussion to the article and not attack each other.

    Debating whether or not the terms used are appropriate, accurate, or even necessary is one thing. Saying that the article should not have been written is another thing.

    Andrei, whether your statement was factual is irrelevant. Your tone that this work wasn't worth publishing and paraphrasing that the author was one of the worst designers is rude. It's an asinine comment and one that I would hope you wouldn't make in your place of work.

    Tim's efforts to show how he's grown, especially from a developer point of view would likely carry more weight with other developers than a high brow, heavy handed writing from any database expert that talks down to others.

    Tim,

    Thanks for the article and I hope to see more from the developer point of view.

  • Tim,

    Some of us believe you did a fine job on your first article. I agree with Steve, Karen, and ThisisFutile. Don't let the high-brows beat you down over it.

    Personal attacks should stay far from the forum. If there is a question about the information being presented - confine the criticism to the information. Post the relevant information and question in a tactful manner, provide something that could provide further learning to other readers. Bickering over petty things like terminology is not conducive to effective learning and quality criticism. The idea is really to help each other learn in a civil manner while building a great community.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Tim, please accept my apologies, I realize now how useful it is for the community to have contributions like yours.

    Steve, thank you for your comments, they are equally useful for me. They tell me a lot about this community. Regarding my place of work, I have to admit you are correct: I am not as rude and asinine there as I am in my private life.

  • Steve Jones - Editor (3/3/2010)


    Thanks for the article and I hope to see more from the developer point of view.

    Yeah! Let's get him experienced enough at writing articles that we can really rip apart his ideas!

    :w00t:

  • Tim,

    Your article is essentially completely correct. I like your honest style, admitting how you used to design database tables before you found out about adding this extra type of table. This is the discussion thread for the article so expect all the faults to be found, the only criticism seems to be that the article title was slightly misleading for problem the article actually solved. A lot of other SQLServerCentral articles are completely correct and generate no responses in the discussion thread, your's raised a lot of discussion and I even learned something from it about all the different names there are for this type of table. This is also one of the most important concepts to understand about database design and it seems like a lot of people who didn't know about this method before you wrote the article know now. So it was a very useful article.

  • Thanks for your kind words...hopefully part 2 (scheduled for March 23) is less offensive 😀

  • Well said and to add to the name menagerie, I have always called them Join Tables since they join one entity to another.

    For those who think this is "bad design", the world is filled with many-to-many relationships that need to be represented in the architecture of many databases. I'm with you on this point.

    As for the "n00b"ness of the article, I have no problem with that since I would think n00bs would turn to a publication such as this for part of their learning experience. I do think the title was an unfortunate choice, and save the redundant key, it was right on target for someone trying to learn the fundamentals of good design.

  • Karen Lopez - InfoAdvisors (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.

    Agreed... I've also heard them being referred to as "Mapping" tables, "Dual ID" tables, and a couple of names not fit for print. 🙂

    I don't agree that there's no such thing as a many-to-many relationship in the real world, though.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Tim,

    I certainly hope that none of my comments caused offence. I always intend to improve my own knowledge and try to achieve that through reading followed by intelligent debate. The internet has both improved this and been a retrograde step.

    I now can discuss with the author and a group of people of differing experience, skill sets and backgrounds about the given topic.

    Unfortunately, with the terseness of forums, the immediacy and permenancy of comments together with the fact that some of the commenters are writing in English which is not their first language (take the Americans for example - oh come on, of course I am joking!!!), people tend to rush in with criticisms as they get exasperated when they select something that takes up their precious time but is not applicable to them.

    You might have noticed that the comments which appeared to be more vitriolic in content, as opposed to discussing the content from a theoretical and practical viewpoint, all seemed to be posted by 'Forum Newbie's. Although I have been coming to this website for many years (the joining date on my profile lies - don't ask), I have only been really active in the last twelve months yet over all that time the discussions often get heated but rarely to vicious.

    To sum up: Keep posting.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 15 posts - 61 through 75 (of 98 total)

You must be logged in to reply to this topic. Login to reply