每个开发人员都应该了解数据库？ [英] What should every developer know about databases?
问题描述
无论我们喜欢还是不喜欢，许多（如果不是大多数）我们的开发人员经常使用数据库，或者可能有一天需要工作。考虑到野生动物滥用和滥用的数量，以及每天出现的数据库相关问题的数量，可以公平地说，开发人员应该知道某些概念，即使他们不设计或使用数据库。所以：
开发人员和其他软件专业人员应该了解数据库的重要概念？
回应：
保持您的名单短暂。
一个概念每个答案最好。
具体。
$ $ $ b数据建模可能是一个重要的技能
b $ b为什么你的概念很重要？不要只说使用索引。不要陷入最佳实践。
反映您同意的最佳解答。
首先阅读其他人的答案。一个高排名的答案是比两个低排名的答案更有效的语句。如果您有更多要添加的内容，请添加评论或引用原始内容。
不要因为不适用于您个人而对其进行downvote。
我们都在不同的域中工作。这里的目标是为数据库新手提供方向，以获得对数据库设计和数据库驱动开发的充分的理解，而不是争夺最重要的标题。
<开发人员应该了解数据库的第一件事是：什么是数据库？不是他们如何工作，也没有如何构建一个，也不知道如何编写代码来检索或更新数据库中的数据。但是他们是什么？
不幸的是，这个答案是一个移动目标。 在20世纪70年代到90年代初期的数据库数据库中，数据库用于共享数据。如果您使用的是数据库，并且您没有共享数据，那么您将参与一个学术项目或者你在浪费资源，包括你自己。设置数据库和驯服DBMS是这样巨大的任务，在数据利用多次的回报，必须是巨大的匹配投资。
在过去的15年中，数据库已经用于存储与一个应用程序相关的持久性数据。为 MySQL 或访问或 SQL Server 已经变得如此常规，数据库几乎成为普通应用程序的常规部分。有时，由于数据的真正价值变得明显，最初的有限任务被任务爬行推向上。不幸的是，设计用于单一目的的数据库，当他们开始被推入一个企业范围和任务关键的角色时，往往失败了。
需要了解数据库是整个数据中心视图的世界。以数据为中心的世界观与以过程为中心的世界观相比，更多的不同于大多数开发人员所学到的。与这种差距相比，结构化编程和面向对象编程之间的差距相对较小。
开发者需要学习的第三件事，至少在概述中，是数据建模，包括概念数据建模，逻辑数据建模和物理数据建模。 >
概念数据建模实际上是从数据为中心的需求分析。
strong>逻辑数据建模通常是将特定数据模型应用于概念数据建模中发现的需求。关系模型的使用远远超过任何其他特定模型，开发人员需要确定地学习关系模型。为一个非平凡的需求设计一个强大的和相关的关系模型不是一个简单的任务。如果您误解关系模型，则无法构建良好的SQL表。
物理数据建模通常是DBMS特定的，要非常详细地学习，除非开发人员也是数据库构建器或DBA。开发人员需要了解的是，物理数据库设计与逻辑数据库设计的分离程度，以及通过调整物理设计可以实现高速数据库的程度。
开发人员下一步需要学习的是：虽然速度（性能）很重要，但其他设计优点的衡量标准更重要，例如修改和扩展数据库的范围越来越小，或编程的简单性。
最后，任何混淆数据库的人都需要了解，数据的价值往往超过捕获它的系统。
哇！
Whether we like it or not, many if not most of us developers either regularly work with databases or may have to work with one someday. And considering the amount of misuse and abuse in the wild, and the volume of database-related questions that come up every day, it's fair to say that there are certain concepts that developers should know - even if they don't design or work with databases today. So:
What are the important concepts that developers and other software professionals ought to know about databases?
Guidelines for Responses:
Keep your list short.
One concept per answer is best.
Be specific.
"Data modelling" may be an important skill, but what does that mean precisely?
Explain your rationale.
Why is your concept important? Don't just say "use indexes." Don't fall into "best practices." Convince your audience to go learn more.
Upvote answers you agree with.
Read other people's answers first. One high-ranked answer is a more effective statement than two low-ranked ones. If you have more to add, either add a comment or reference the original.
Don't downvote something just because it doesn't apply to you personally.
We all work in different domains. The objective here is to provide direction for database novices to gain a well-founded, well-rounded understanding of database design and database-driven development, not to compete for the title of most-important.
The very first thing developers should know about databases is this: what are databases for? Not how do they work, nor how do you build one, nor even how do you write code to retrieve or update the data in a database. But what are they for?
Unfortunately, the answer to this one is a moving target. In the heydey of databases, the 1970s through the early 1990s, databases were for the sharing of data. If you were using a database, and you weren't sharing data you were either involved in an academic project or you were wasting resources, including yourself. Setting up a database and taming a DBMS were such monumental tasks that the payback, in terms of data exploited multiple times, had to be huge to match the investment.
Over the last 15 years, databases have come to be used for storing the persistent data associated with just one application. Building a database for MySQL, or Access, or SQL Server has become so routine that databases have become almost a routine part of an ordinary application. Sometimes, that initial limited mission gets pushed upward by mission creep, as the real value of the data becomes apparent. Unfortunately, databases that were designed with a single purpose in mind often fail dramatically when they begin to be pushed into a role that's enterprise wide and mission critical.
The second thing developers need to learn about databases is the whole data centric view of the world. The data centric world view is more different from the process centric world view than anything most developers have ever learned. Compared to this gap, the gap between structured programming and object oriented programming is relatively small.
The third thing developers need to learn, at least in an overview, is data modeling, including conceptual data modeling, logical data modeling, and physical data modeling.
Conceptual data modeling is really requirements analysis from a data centric point of view.
Logical data modeling is generally the application of a specific data model to the requirements discovered in conceptual data modeling. The relational model is used far more than any other specific model, and developers need to learn the relational model for sure. Designing a powerful and relevant relational model for a nontrivial requirement is not a trivial task. You can't build good SQL tables if you misunderstand the relational model.
Physical data modeling is generally DBMS specific, and doesn't need to be learned in much detail, unless the developer is also the database builder or the DBA. What developers do need to understand is the extent to which physical database design can be separated from logical database design, and the extent to which producing a high speed database can be accomplished just by tweaking the physical design.
The next thing developers need to learn is that while speed (performance) is important, other measures of design goodness are even more important, such as the ability to revise and extend the scope of the database down the road, or simplicity of programming.
Finally, anybody who messes with databases needs to understand that the value of data often outlasts the system that captured it.
Whew!
这篇关于每个开发人员都应该了解数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
