关系数据库对于web应用程序来说非常糟糕。

例如:

螺纹评论 标签云 用户搜索 维护记录视图计数 提供撤销/修订跟踪 多步的向导

一个优秀的开发人员需要知道的不仅仅是如何编码

罗布·派克写道:“数据占主导地位。如果你选择了正确的数据结构，并且组织得很好，算法几乎总是不言而喻的。数据结构，而不是算法，才是编程的核心。”

由于现在任何重要的数据都在数百万条记录中，我认为良好的数据建模是最重要的编程技能(无论是使用rdbms还是sqlite或amazon simpleDB或谷歌appengine数据存储)。

当所有的数据都存储在这样的数据存储系统中时，就不再需要花哨的搜索和排序算法了。

Python方法声明中的显式self是糟糕的设计选择。

方法调用有语法糖，但声明没有。这是一个有漏洞的抽象(故意的!)，会导致令人讨厌的错误，包括运行时错误，在报告的参数数量中明显少了一个错误。

有很多糟糕的教学。

当Joel说大脑中有一部分是用来理解指针的，而有些人生来就没有指针时，我们开发人员就会沾沾自喜。我们许多人在这里讨论和热衷的话题都很深奥，但有时这只是因为我们把它们弄得如此深奥。

观点:数据驱动的设计本末倒置。它应该立即从我们的思想中消除。

绝大多数软件不是关于数据的，而是关于我们试图为客户解决的业务问题。它是关于一个问题域的，涉及对象、规则、流程、案例和关系。

当我们从数据开始设计，并根据数据和数据之间的关系(表、外键和x-to-x关系)对系统的其余部分建模时，我们将整个应用程序限制为如何在数据库中存储数据和如何从数据库中检索数据。此外，我们将数据库体系结构公开给软件。

数据库模式是一个实现细节。我们应该可以自由地改变它，而不需要对我们的软件设计进行任何显著的改变。业务层不应该知道表是如何设置的，或者是从视图中提取还是从表中提取，或者是从动态SQL或存储过程中获取表。这种类型的代码永远不应该出现在表示层中。

软件是用来解决业务问题的。我们要处理用户、汽车、帐户、余额、平均值、摘要、转账、动物、消息、包裹、购物车、订单和其他各种真实的有形对象，以及我们可以对它们执行的操作。我们需要根据需要保存、加载、更新、查找和删除这些项。有时候，我们必须以特殊的方式来做这些事情。

But there's no real compelling reason that we should take the work that should be done in the database and move it away from the data and put it in the source code, potentially on a separate machine (introducing network traffic and degrading performance). Doing so means turning our backs on the decades of work that has already been done to improve the performance of stored procedures and functions built into databases. The argument that stored procedures introduce "yet another API" to be manged is specious: of course it does; that API is a facade that shields you from the database schema, including the intricate details of primary and foreign keys, transactions, cursors, and so on, and it prevents you from having to splice SQL together in your source code.

把马放回马车前面。思考问题领域，并围绕它设计解决方案。然后，从问题域导出数据。