One Rule, Umpteen Constraints

  • Comments posted to this topic are about the item One Rule, Umpteen Constraints

    Best wishes,
    Phil Factor

  • But.... that makes sense! We can't have none of that 'round here'! Perhaps you'll then be wanting a good data dictionary so that you could define elements in one place and use them throughout your schema in a standardized fashion.

    You're mad, I tell you, Phil! MAD!!!! 😛

    (and I must edit to add: my 1,000th post!)

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • Hi,

    I have been a database developer for only two years. I have had a number of instances where I would like to define rules so for precisely the reasons that you have stated, but have not done so because of the warning given by MS that it is deprecated. I use SQL Server 2008 and 2008 R2. If rules are still available in 2014, then I may as well go ahead and use them and save myself a bunch of work. By the time my organisation gets around to SQL Server 2014 or beyond, I will be long gone!

  • I have used SQL Server for quite a while now (first used v7 in 1999 for anyone interested) and did not know of the existance of RULEs. Possibly this was due to the preferences of the SQL Server mentors that I had early on or just (mis)fortune what I have read.

    I have always wanted to define types with more rigour than just an alias. So it turns out that it was there all along but might be gone anytime from the next version. Although the liklihood of that occurring is probably minimal I could not justify starting to use a feature that has already been deprecated. Shame really.

    Gaz

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

  • Unfortunately, the computer industry is full of organisations that suffer from NIH (not invented here) syndrome.

    So if one company comes up with a good idea (in this case, Sybase/Microsoft and data type rules defined in the DB schema), the odds are pretty slim of getting a) the other 'mainstream' vendors (e.g. arch-nemesis Oracle in this case) and b) Academia (because there will be some philosophical problem with the implementation), to endorse the idea or move to get the idea formalized into the relevant standard.

    What is more likely to happen is that the SQL standards 'committee of experts' come up with something that will include some of the concepts, but is sufficiently different from what has already been developed by the 'inventor' that the 'inventor' doesn't get any kind of perceived or actual advantage in the marketplace by having come up with the idea first. In the mean time, the competitors will be setting about coming up with something 'better'.

    In the end, the standards body will come up something so arcane and obtuse that nobody bothers to use it, or they use vendor-specific 'versions' because they're easier and 'more efficient'.

  • "in much the same way that rabbits seem to run straight for the wheels of your car. " Gruesome but such an accurate comparison! LOL

    Thanks for the article, Phil.

    - webrunner

    -------------------
    A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
    Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

  • When I did the SQL6.5 courses they emphasised the usefulness of binding rules to user defined types.

    It was only later that I realised that tables created with user defined types represented items stamped out by a template. Changing the user defined type did not update tables previously created with them.

    I can understand the desire to be able to change a rule and have that one rule affect all things bound to it but can you imagine the impact if this meant that existing data was deemed to be invalid?

    I feel that what is needed is a schema version aware rule where there is an option to validate the existing data against an updated rule or to accept old data tracked to the appropriate version of a rule.

  • David.Poole (3/31/2015)

    I feel that what is needed is a schema version aware rule where there is an option to validate the existing data against an updated rule or to accept old data tracked to the appropriate version of a rule.

    +1

    And this may be a nitpick, but "umpteen" is technically greater than twelve. :hehe:


    Here there be dragons...,

    Steph Brown

  • Stephanie J Brown (3/31/2015)


    David.Poole (3/31/2015)

    I feel that what is needed is a schema version aware rule where there is an option to validate the existing data against an updated rule or to accept old data tracked to the appropriate version of a rule.

    +1

    And this may be a nitpick, but "umpteen" is technically greater than twelve. :hehe:

    +umpteen

    🙂

    -------------------
    A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
    Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Viewing 9 posts - 1 through 8 (of 8 total)

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