我们所有使用关系数据库的人都知道(或正在学习)SQL是不同的。获得期望的结果,并有效地这样做,涉及到一个乏味的过程,其部分特征是学习不熟悉的范例,并发现一些我们最熟悉的编程模式在这里不起作用。常见的反模式是什么?


当前回答

select some_column, ...
from some_table
group by some_column

假设结果将按some_column排序。我在Sybase上看到过这种情况,其中假设成立(目前)。

其他回答

Human readable password fields, egad. Self explanatory. Using LIKE against indexed columns, and I'm almost tempted to just say LIKE in general. Recycling SQL-generated PK values. Surprise nobody mentioned the god-table yet. Nothing says "organic" like 100 columns of bit flags, large strings and integers. Then there's the "I miss .ini files" pattern: storing CSVs, pipe delimited strings or other parse required data in large text fields. And for MS SQL server the use of cursors at all. There's a better way to do any given cursor task.

编辑是因为有太多了!

反向观点:过度痴迷于正常化。

大多数SQL/ rbdb系统提供了许多非常有用的特性(事务、复制),即使对于非标准化的数据也是如此。磁盘空间很便宜,有时操作/过滤/搜索获取的数据比编写1NF模式更简单(更容易的代码,更快的开发时间),并处理其中的所有麻烦(复杂的连接,讨厌的子选择等)。

我发现过度标准化的系统通常是不成熟的优化,特别是在开发的早期阶段。

(再想想……http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/)

把东西放在临时表中,特别是那些从SQL Server切换到Oracle的人有过度使用临时表的习惯。只需使用嵌套的选择语句。

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

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

盲目相信用户输入 不使用参数化查询 明文密码