1)我不知道这是否是一个“官方的”反模式，但我不喜欢并试图避免在数据库列中使用字符串文字作为魔法值。

MediaWiki表'image'中的一个例子:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(我只是注意到不同的大小写，另一个要避免的事情)

我设计了这样的情况，int查找表ImageMediaType和ImageMajorMime与int主键。

2)日期/字符串转换，依赖于特定的NLS设置

CONVERT(NVARCHAR, GETDATE())

没有格式标识符

我一直对大多数程序员倾向于在数据访问层混合他们的ui逻辑感到失望:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

通常，程序员这样做是因为他们想要将数据集直接绑定到一个网格上，而且在服务器端使用SQL Server格式比在客户端使用SQL Server格式更方便。

像上面所示的查询是非常脆弱的，因为它们将数据层与UI层紧密耦合在一起。最重要的是，这种编程风格彻底阻止了存储过程的可重用性。

同一查询中的相同子查询。

过度使用临时表和游标。

使用主键作为记录地址的代理，使用外键作为嵌入在记录中的指针的代理。

我需要把我自己目前最喜欢的放在这里，只是为了使列表完整。我最喜欢的反模式是不测试您的查询。

这适用于以下情况:

您的查询涉及多个表。 您认为您有一个查询的最优设计，但不需要测试您的假设。 您接受第一个有效的查询，不知道它是否接近优化。

任何针对非典型或不充分数据进行的测试都不算数。如果它是一个存储过程，将测试语句放入注释中并保存它，并保存结果。否则，将其与结果一起放入代码中的注释中。