Unique constraint on a nullable column

  • :cool:I am giong to get my point I lost back!;-)

  • BowieRules! (12/2/2010)


    I am sorry for confusing you with insert option, I only included it here because I found it on another blog as a solution to the problem, which I agree is not really a solution, but still a valid workaround, especially if it is put in a good InsertUpdate stored procedure.

    This is not an administrative workaround and will not enforce the contraint from a DBA perspective.

    It would not pass an Audit either. The other solutions listed would.

    :cool:I am giong to get my point I lost back!;-)

  • :cool:I am giong to get my point I lost back!;-)

    Am I being greedy?

  • SanDroid, I was wondering when you were going to show up;-)

    (I need to get mine back as well:hehe:)

    Steve Jimmo
    Sr DBA
    “If we ever forget that we are One Nation Under God, then we will be a Nation gone under." - Ronald Reagan

  • Got it right by fluke, but still trying to figure out how this one would resolve the issue:

    Create a calculated column that is based on the column that allows nulls, and then define a UNIQUE constraint on the calculated column.

    SQL DBA.

  • SanjayAttray (12/2/2010)


    Create a calculated column that is based on the column that allows nulls, and then define a UNIQUE constraint on the calculated column.

    Sanjay, Some of the more creative minds at M$ actualy list this and how to do it as a solution to this "documented limitation" of TSQL RDBMS servers in a Q article.

    http://support.microsoft.com/kb/322002

    The solutions provided in this article are the only ones supported by M$.

    ummm... Or at least that is the word on the street.... 😎

    :w00t:Still getting my POINT back:w00t:

  • The statement "I found it on another blog as a solution to the problem" worries we. Just because someone says something, especially on the internet, doesn't mean it's correct. As many have pointed out previously, enforcing something in the app isn't really enforcing anything at all, because as soon as someone uses a different app there's no enforcement at all.

    (I'd also be very amused to watch how that "solution" scaled as the number of rows increased, unless I had to support it that is).

  • Well, as has been pointed out already the 5th "correct" option doesn't handle update statements at all and even for inserts it handles only single row inserts.

    Nevertheless, it's a good question (despite that flaw in the answer) because it's thought-provoking. And I don't imagine I'm the only one who wasn't previously aware of Hugo's connect item and added a vote as a result of this, so with some luck the question has added a few votes that may help MS realise that this is a serious issue.

    It raises an interesting side-issue: how bizarre does a "work-around" have to be before it ceases to count as a real work-around. I guess any answer to that is going to be subjective. For myself, I reckon a filtered index is a good work-around, and a trigger is a passable work-around. But I'll go along with an earlier comment about the computed column solution - why do I want to invent some weird imaginary column to do something that the SQL standard says I can do without it? It works, of course, but I don't like it one bit. Neither do I like the indexed view work-around, although of course that too works; but confusing an index (an access mechanism) with a view (a derived relation) seems to me to be a step too far from the relational model.

    Tom

  • This question seems dubious. 5 required correct answers and only worth 1 point?

    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

  • Hi,

    It is always hard to get the right answer for this kind of question. There is more probability that you will miss at least one point.

    So I think rather then giving 8 options together in 1 question, it should be distributed to 2 to 3 questions and then it would be better justice.

    Regards,

    --------------------------------------------------------------------------------
    Mayank Parmar
    Software Engineer

    Clarion Technologies
    SEI CMMI Level 3 Company

    8th Floor, 803, GNFC info Tower,
    SG Highway, Ahmedabad - 380 054,
    Gujarat, India.
    www.clariontechnologies.co.in

    Email: mayank.parmar@clariontechnologies.co.in
    MSN : mayank.parmar@clariontechnologies.co.in
    Mobile: +91 9727748789
    --------------------------------------------------------------------------------

  • Thanks to everyone for the discussion, I knew the WHERE clause wasn't a real work-around...

  • UMG Developer (12/3/2010)


    Thanks to everyone for the discussion, I knew the WHERE clause wasn't a real work-around...

    I'm with UMG on this one. Besides the quibble that the WHERE clause option didn't include UPDATEs, it is still a possible "workaround", even if impractical.

    The question was simply "what is a workaround for this?", not "what is a workaround which won't get you fired or laughed at?"

  • Its depends on requirement,any one will not always correct...

  • If we want to talk about workarounds: how about threaten the halfwit who designed/built such a piece of cack and put you in a position where you had to deal with this?

    Carlton..

Viewing 14 posts - 31 through 44 (of 44 total)

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