不管我们喜欢与否，我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库，或者有一天可能不得不使用数据库。考虑到大量的误用和滥用，以及每天出现的大量与数据库相关的问题，公平地说，有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库，开发人员和其他软件专业人员应该知道的一个重要概念是什么?
当前回答
我会说有很强的SQL基础技能。到目前为止，我见过许多对数据库了解不多的开发人员，但总是询问如何制定一个相当简单的查询的技巧。查询并不总是那么容易和简单。在查询规范化良好的数据库时，必须使用多个连接(内部连接、左连接等)。
其他回答
不要依赖于SQL查询返回的行顺序。
将非正规化视为一个可能的天使，而不是魔鬼，并将NoSQL数据库视为关系数据库的替代方案。
此外，我认为实体-关系模型是每个开发人员必须知道的，即使你不设计数据库。它将让您彻底理解数据库的所有内容。
每个开发人员都应该知道这是错误的:“分析数据库操作与分析代码完全不同。”
在传统意义上有一个明确的Big-O。当你做一个EXPLAIN PLAN(或等效)时，你看到的是算法。有些算法涉及嵌套循环，并且是O(n ^ 2)。其他算法涉及到b树查找，并且是O(n log n)。
这是非常非常严重的。这是理解为什么索引很重要的关键。这对于理解速度-标准化-非标准化之间的权衡至关重要。这对于理解为什么数据仓库使用星型模式是非常重要的，而星型模式并没有对事务更新进行规范化。
如果您不清楚所使用的算法，请执行以下操作。停止。解释查询执行计划。相应调整指标。
同样，结论是:索引越多越好。
有时，专注于一个操作的索引会降低其他操作的速度。根据这两个操作的比例，添加一个索引可能有良好的效果，也可能没有整体影响，或者对整体性能不利。
好问题。以下是一些想法，排名不分先后:
Normalization, to at least the second normal form, is essential. Referential integrity is also essential, with proper cascading delete and update considerations. Good and proper use of check constraints. Let the database do as much work as possible. Don't scatter business logic in both the database and middle tier code. Pick one or the other, preferably in middle tier code. Decide on a consistent approach for primary keys and clustered keys. Don't over index. Choose your indexes wisely. Consistent table and column naming. Pick a standard and stick to it. Limit the number of columns in the database that will accept null values. Don't get carried away with triggers. They have their use but can complicate things in a hurry. Be careful with UDFs. They are great but can cause performance problems when you're not aware how often they might get called in a query. Get Celko's book on database design. The man is arrogant but knows his stuff.
我想这里已经介绍了很多技术细节，我不想再补充了。我想说的一件事是，社交比技术更重要，作为应用程序开发人员，不要陷入“DBA知道最好的”的陷阱。
如果您在查询方面有性能问题，也要解决这个问题。自己进行研究，并要求dba解释发生了什么，以及他们的解决方案是如何解决问题的。
在你做了研究之后，也要提出你自己的建议。也就是说，我试图找到解决问题的合作解决方案，而不是将数据库问题留给dba。
