I generally can appreciate what Joe Celko brings to the table in terms of SQL programming and theory, but a recent article of his had me scratching my head, even considering his sometimes Ivory Tower approaches.
The article is at Intelligent Enterprise here.
What caught my eye was the following paragraph. He’s discussing his own classification system of keys in databases and one of the types is described thusly:
3. An “exposed physical locator” is not based on attributes in the data model and is exposed to the user. There is no reasonable way to predict it or verify it, since it usually comes from the physical state of the hardware at the time of data insertion. The system obtains a value thru some physical process in the storage hardware totally unrelated to the logical data model ” for example, IDENTITY columns or other proprietary, non-relational auto-numbering devices.
Technically, these are not really keys at all, since they are attributes of the physical storage and are not even part of the logical data model. But they are handy for lazy, non-RDBMS programmers who do not want to research or think! This is the worst way to program in SQL
So, to paraphrase, he’s saying that if you use IDENTITY columns in your database schemas, you’re “lazy” and “do not want to research or think”
Uhuh.
So how about it, you lazy, slovenly, heathen SQL programmers out there that dare to use Identity columns?
And in case it’s not obvious, I can’t disagree more with Celko on this point<g>
3 Comments
Actually, I agree with him.
In fact, I’ve taken it a step farther and stopped explicitly typing my data elements. Aside from the moral implications of enforcing stereotypes on innocent data, I realized that by mixing up all these different "things" in the database together was just making me crazy.
So now I use 255 character text fields for everything. Sure, it’s delivered a minor performance hit but oh, the freedom! I no longer have to worry about "dates" or "numbers". And since I’ve abolished identity columns, there’s no ugly "relationships" to worry about, so finding stuff is as easy as iterating through every field in every table and looking at it.
And the best part of all? It’s backwards compatible with all my old dBase-II projects.
Reminds me of an article I once read in Dr Dobbs.
This guy actually wrote an article and got it published that proposed creating a database indexing structure by means of they file system.
Data goes in DATA
And each key goes in a separate dir
KEY1
Then, the first character of KEY1
KEY1\A
KEY1\B
etc
Then the second character of the key
KEY1\A\N
KEY1\B\A
etc
and so on, till you got to the final dir
KEY1\A\N\D\Y
and in that dir were files that pointed back to the actual DATA file
Yeah, this was a real article, but I can’t find a link on the DR Dobbs website (maybe they took it off in shame<g>).
I used to make copies of it and hand it to interviewees to get their reaction.
My god. And I thought *I* had some hare-brained ideas.