While nobody can question that Joe Celko's online attitude borders on the
criminal can be quite abrasive, his answers are often
correct. The problem is, while he might be well-versed in ANSI standards that were drafted before Sony invented the Walkman, he espouses misconceptions about actual vendor implementations in very particular places, such as the SQL Server newsgroups on msnews.microsoft.com. So SQL Server users end up believing in non- or half-truths, and Celko is blissfully ignorant that he has given bad advice, simply because he doesn't have any experience with SQL Server. (I toyed with saying, "he doesn't know any better." I find that kind of rude and possibly misleading in and of itself, but I mention it because (a) it's funny, to me at least, and (b) I'm sure he *does* know better.)
Today he implied that SQL Server does not support foreign keys across schema, an allegation which I promptly proved wrong. To be fair, he did not come out and say, "SQL Server does not do this," but prior to further prodding, he made a generic enough statement that several people assumed he meant SQL Server (we were in a SQL Server newsgroup, after all). Here is his statement from the thread (littered with [sic] like he so often does to poor users):
A scheam [sic] is suppose [sic] to be a complete data model. If Sales, Orders and Products have a realtinship [sic] among themselves, then they have to be in the same schema for DRI to work. This is foundations, not advanced stuff.
And here is a code sample that proves he is leading the user down the wrong path because he *thinks* he knows how SQL Server implemented those standards from so long ago. Note that I used an additional file and filegroup to show that the physical aspect he mentioned later in the thread is not relevant either.
USE [master];
GO
CREATE DATABASE Celko;
GO
ALTER DATABASE Celko ADD FILEGROUP fg2;
GO
ALTER DATABASE Celko ADD FILE
(
NAME = CelkoExtraFile,
FILENAME = 'C:\Celko2.mdf',
SIZE = 1MB,
MAXSIZE = 10MB,
FILEGROWTH = 1MB
) TO FILEGROUP [fg2];
GO
USE Celko;
GO
CREATE SCHEMA s1 AUTHORIZATION [dbo];
GO
CREATE SCHEMA s2 AUTHORIZATION [dbo];
GO
CREATE TABLE s1.Table1
(
s1_ID INT PRIMARY KEY
) ON [PRIMARY];
GO
CREATE TABLE s2.Table2
(
s1_ID INT NOT NULL
FOREIGN KEY REFERENCES s1.Table1(s1_ID)
) ON [fg2];
GO
INSERT s1.Table1(ID) SELECT 5;
GO
-- succeeds:
INSERT s2.Table2(s1_ID) SELECT 5;
GO
-- fails:
INSERT s2.Table2(s1_ID) SELECT -1;
GO
USE [master];
GO
DROP DATABASE Celko;
GO |
And this is not the first time something like this has happened; my
expectation is that, like before, he will not respond to my post where
I corrected his misconception. Though I fear that in a lot of cases,
the damage is already done.
Heck, I'm wrong occasionally, and I probably guess more often than you might expect. When responding to people requesting help, in most cases I have tested what I'm saying and in many of those cases I post sample code to prove it. And I am hardly the luminary or "expert" that Celko is, whose word is taken at gospel just because he is accomplished, has books, etc. So I think often his rantings are assumed accurate and people start to believe in his mindset without getting a second opinion. After all, I haven't published any complete books on SQL, only chapters and tech edits, so what the heck could I possibly know?