我最不喜欢的是

Using spaces when creating tables, sprocs etc. I'm fine with CamelCase or under_scores and singular or plurals and UPPERCASE or lowercase but having to refer to a table or column [with spaces], especially if [ it is oddly spaced] (yes, I've run into this) really irritates me. Denormalized data. A table doesn't have to be perfectly normalized, but when I run into a table of employees that has information about their current evaluation score or their primary anything, it tells me that I will probably need to make a separate table at some point and then try to keep them synced. I will normalize the data first and then if I see a place where denormalization helps, I'll consider it. Overuse of either views or cursors. Views have a purpose, but when each table is wrapped in a view it's too much. I've had to use cursors a few times, but generally you can use other mechanisms for this. Access. Can a program be an anti-pattern? We have SQL Server at my work, but a number of people use access due to it's availabilty, "ease of use" and "friendliness" to non-technical users. There is too much here to go into, but if you've been in a similar environment, you know.

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

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

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

我看到视图定义是这样的:

CREATE OR REPLACE FORCE VIEW PRICE (PART_NUMBER, PRICE_LIST, LIST_VERSION ...)
AS
  SELECT sp.MKT_PART_NUMBER,
    sp.PRICE_LIST,
    sp.LIST_VERSION,
    sp.MIN_PRICE,
    sp.UNIT_PRICE,
    sp.MAX_PRICE,
...

视图中大约有50个列。有些开发人员以不提供列别名而折磨他人为傲，因此必须计算两个位置的列偏移量，以便能够找出视图中对应的列。

回复:使用@@IDENTITY代替SCOPE_IDENTITY()

两者都不能用;使用输出代替

参见https://connect.microsoft.com/SQLServer/feedback/details/328811/scope-identity-sometimes-returns-incorrect-value

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

使用无意义的表别名:

from employee t1,
department t2,
job t3,
...

使得阅读一个大的SQL语句比它需要的要困难得多