We could give it some smarts. For example, we know that in our game, we can only choose X or O, so we could put a data constraint on the
Playcolumn. And we know that in our game, you can’t play on the same space more than once, so we could put a unique constraint on the combination of
Position. You could even be really creative and enforce our game’s alternating player moves by putting a data constraint on the
Playercolumn such that it equaled 1 when
(Turn Modulo 2)equaled 1 and 2 otherwise. (Really it wouldn’t need to be a data column at that point, just a calculated column.)
But imposing those restrictions robs our data structure from its raison d’être. It’s no longer a general purpose game play storage system; it only works for our game.
Instead of saddling the data storage itself with all of those rules, we could enforce all of the game mechanics through our data interpretation and manipulation logic. When we saved a game move, we could make sure that an X or O was played and it could check to see whether the specified square was already used. When we analyzed a game to determine a win, all of the criteria could be housed in that consuming query. But this flexible design isn’t done inflicting its complexity on us.
Riley covers a number of T-SQL features in the process of this post.