我们所有使用关系数据库的人都已经了解(或正在学习)SQL 是不同的。引出所需的结果并有效地完成这一过程涉及一个乏味的过程,其部分特征是学习不熟悉的范例,并发现我们最熟悉的一些编程模式在这里不起作用。您见过(或您自己承诺过)的常见反模式是什么?
我一直对大多数程序员在数据访问层中混合他们的 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 格式比在客户端格式化更方便。
上面显示的查询非常脆弱,因为它们将数据层与 UI 层紧密耦合。最重要的是,这种编程风格彻底阻止了存储过程的可重用。