我最担心的是450列的访问表，这些表是由总经理最好的朋友狗美容师的8岁儿子整理的，还有那个不可靠的查找表，它之所以存在，是因为有人不知道如何正确地规范化数据结构。

通常，这个查找表是这样的:

ID INT,
Name NVARCHAR(132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR(255),
CharValue2 NVARCHAR(255),
Date1 DATETIME,
Date2 DATETIME

我已经记不清有多少客户的系统依赖于这种可恶的东西了。

FROM TableA, TableB WHERE语法用于连接而不是FROM TableA内部连接TableB上 假设查询将以某种方式返回，而不放入ORDER BY子句，因为这是在查询工具中测试时显示的方式。

我只是把这个放在一起，基于一些SQL响应这里在SO。

认为触发器之于数据库就像事件处理程序之于OOP是一种严重的反模式。有一种看法是，任何旧的逻辑都可以放入触发器中，当一个事务(事件)在表上发生时被触发。

不正确的。最大的区别之一是触发器是同步的——而且是完全同步的，因为它们在集合操作上是同步的，而不是在行操作上。在OOP方面，正好相反——事件是实现异步事务的有效方法。

不必深入浅出:不使用准备好的语句。

应用程序连接 不仅仅是一个SQL问题，而是在寻找问题的描述和发现这个问题时，我很惊讶它没有被列出。

正如我所听到的那样，应用程序连接是指从两个或多个表中取出一组行，然后用一对嵌套的for循环将它们连接到(Java)代码中。这给系统(应用程序和数据库)带来了负担，必须识别整个叉乘，检索它并将其发送给应用程序。假设应用程序可以像数据库一样快地过滤叉乘(不确定)，只是更快地削减结果集意味着更少的数据传输。

也许这不是一个反模式，但它惹恼了我，当某些数据库的DBA(好吧，我在这里说的是Oracle)用Oracle风格和代码约定编写SQL Server代码，当它运行如此糟糕时抱怨。受够了游标Oracle的人!SQL是基于设置的。