October 29, 2020 at 6:59 pm
I did an article called Constraint Yourself! back in October 2008 on how to use DDL constraints to assure data integrity. One of the topics in that piece was a look at state transition constraints via an auxiliary table. I did not go into much detail since this was one of several topics I was covering. I introduced the topic of transition constraints to show how such constraints could be modeled as a state-transition diagram in order to enforce the rules when an entity can be updated only in certain ways. There is an initial state, flow lines that show what are the next legal states, and one or more termination states. The original example was a simple state change diagram of possible marital states, you can get some more details on this technique at
https://www.red-gate.com/simple-talk/sql/t-sql-programming/state-transition-constraints/
(08 October 2010),
This method avoids problems with simply using assembly language style flags. I've also done articles on why I don't like bit flags and RDBMS. See: https://www.red-gate.com/simple-talk/sql/t-sql-programming/bit-of-a-problem/
Thank you, some interesting reading. Unlikely to be able to apply to the system in question, there is much hardcoded into the core product which relies on bit fields, but still good to know.
"Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it. When we enquire into any subject, the first thing we have to do is to know what books have treated of it. This leads us to look at catalogues, and at the backs of books in libraries."
— Samuel Johnson
I wonder, would the great Samuel Johnson have replaced that with "GIYF" now?
November 3, 2020 at 3:20 pm
I see no need to use a 4 digit year here. Almost no businesses go back and analyze 100-year-old data, so there's no ambiguity. Even more so if you get used to using military/European-style format where if day is given it is first (i.e. 19-Oct-20 is Oct 19, 1920, and 20-Oct-19 is Oct 20, 2019, and the 19 and 20 are still not ambiguous).
What about 06-07-08 ? Which is the year ?
YYYY can't hurt.
November 3, 2020 at 3:56 pm
I see no need to use a 4 digit year here. Almost no businesses go back and analyze 100-year-old data, so there's no ambiguity. Even more so if you get used to using military/European-style format where if day is given it is first (i.e. 19-Oct-20 is Oct 19, 1920, and 20-Oct-19 is Oct 20, 2019, and the 19 and 20 are still not ambiguous).
What about 06-07-08 ? Which is the year ?
YYYY can't hurt.
The year is 08. See my earlier examples. The rule is "if day is given it is first", month is second, year last. The extra year digits are annoying and wasteful to read thru in the format the OP presented here: mmm-yy.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply