关于数据库,每个开发者都应该知道什么?[英] What should every developer know about databases?

本文是小编为大家收集整理的关于关于数据库,每个开发者都应该知道什么?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

无论我们是否喜欢它,如果我们大多数人都经常使用数据库,或者可能有一天必须与一个数据库一起工作.并考虑到野外的滥用和滥用的数量,以及每天出现的与数据库相关的问题的数量,可以公平地说开发人员应该知道某些概念 - 即使他们不设计或合作今天的数据库.

开发人员和其他软件专业人员应该了解数据库的一个重要概念是什么?

推荐答案

开发人员对数据库的第一件事是: 的数据库是什么?它们如何工作,也不是您如何构建一个,甚至如何编写代码以检索或更新数据库中的数据.但是他们是为了什么?

不幸的是,答案是一个移动的目标. 在数据库的Heydey中,1970年代到1990年代初,数据库用于共享数据.如果您使用数据库,并且您没有共享您参与学术项目的数据或者您正在浪费资源,包括您自己.设置数据库和驯服DBM是如此巨大的任务,以至于在多次利用数据方面,投资回报必须是巨大的才能符合投资.

在过去的15年中,数据库已被用于存储与仅一个应用程序相关的持续数据.构建一个 mysql sql Server 已经变得非常例行,以至于数据库几乎已成为普通应用程序的日常零件.有时,随着数据的真实价值变得显而易见,最初的有限任务会被任务蠕变向上推动.不幸的是,当设计出一个单一目的的数据库时,当它们开始被推动到企业范围和任务至关重要的角色时,通常会急剧失败.

开发人员需要了解数据库的第二件事是全球的整体以数据为中心的视图.以数据为中心的世界观与以过程为中心的世界观有所不同.与此差距相比,结构化编程和面向对象的编程之间的差距相对较小.

开发人员至少在概述中需要学习的第三件事是数据建模,包括概念数据建模,逻辑数据建模和物理数据建模.

概念数据建模从以数据为中心的角度真正的需求分析.

逻辑数据建模通常是将特定数据模型应用于概念数据建模中发现的要求.关系模型的使用远远超过任何其他特定模型,并且开发人员肯定需要学习关系模型.为非平凡要求设计强大而相关的关系模型并不是一项琐碎的任务.如果您误解了关系模型,则无法构建优质的SQL表.

物理数据建模通常是特定于DBM的,并且不需要详细学习,除非开发人员也是数据库构建器或DBA.开发人员需要了解的是,可以通过调整物理设计可以完成物理数据库设计可以与逻辑数据库设计分开的程度,以及可以通过调整物理设计来完成高速数据库的程度.

开发人员需要学习的下一件事是,虽然速度(性能)很重要,但设计优点的其他度量更为重要,例如修改和扩展数据库范围的能力在道路上或编程的简单性.

最后,任何与数据库混乱的人都需要了解数据的价值通常会超过捕获它的系统.

哇!

其他推荐答案

好问题.以下是一些没有特定顺序的想法:

  1. 归一化,至少是第二个正常形式,至少是必不可少的.

  2. 参考完整性也是必不可少的,并具有适当的级联删除和更新注意事项.

  3. 良好且正确使用检查约束.让数据库做尽可能多的工作.

  4. 不要在数据库和中间层代码中分散业务逻辑.选择一个或另一个,最好在中层代码中选择.

  5. 确定主键和群集键的一致方法.

  6. 不要超越索引.明智地选择您的索引.

  7. 一致的表和列命名.选择标准并坚持下去.

  8. 限制数据库中将接受null值的列数.

  9. 不要被触发器带走.他们有自己的使用,但会急忙使事情复杂化.

  10. 请小心UDFS.它们很棒,但是当您不知道他们在查询中可能被打电话的频率时可能会导致性能问题.

  11. 获取Celko关于数据库设计的书.这个人傲慢,但知道他的东西.

其他推荐答案

首先,开发人员需要了解数据库有一些了解.它们不仅是您放入SQL并拿出结果集的魔术设备,而且还具有自己的逻辑和怪癖非常复杂的软件.

第二,有不同目的的数据库设置.如果有数据仓库,您不希望开发人员从在线交易数据库中进行历史报告.

第三,开发人员需要了解基本的SQL,包括加入.

过去,这取决于开发人员的参与程度.我从事开发人员和事实上的DBA工作,DBA在过道下,DBA在他们自己的区域中脱颖而出. (我不喜欢第三.)假设开发人员参与了数据库设计:

他们需要了解基本的归一化,至少是前三种正常形式.除此之外,要获得DBA.对于那些在美国法庭上有任何经验的人(在此处计算随机电视节目),有助记符"取决于钥匙,整个钥匙,除了钥匙之外,都没有,所以请帮助您."

>

他们需要对索引有一个线索,我的意思是他们应该知道他们需要什么索引以及如何影响性能.这意味着没有无用的索引,但不害怕添加它们来协助查询.任何进一步的(例如余额)应留给DBA.

他们需要了解对数据完整性的需求,并能够指出他们在验证数据以及如果发现问题的地方进行的工作.这不必在数据库中(在其中很难为用户发出有意义的错误消息),但必须在某个地方.

他们应该有关于如何制定计划以及如何阅读它的基本知识(至少足以确定算法是否有效).

他们应该模糊地知道什么是触发器,什么是视图,并且可以分区数据库.他们不需要任何细节,但是他们需要知道向DBA询问这些事情.

他们当然应该知道不要处理生产数据,生产代码或类似的内容,他们应该知道所有源代码都进入VCS.

我无疑忘记了一些东西,但是普通的开发人员不必是DBA,只要手头上有一个真正的DBA.

本文地址:https://www.itbaoku.cn/post/597377.html

问题描述

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.

What is one important concept that developers and other software professionals ought to know about databases?

推荐答案

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!

其他推荐答案

Good question. The following are some thoughts in no particular order:

  1. Normalization, to at least the second normal form, is essential.

  2. Referential integrity is also essential, with proper cascading delete and update considerations.

  3. Good and proper use of check constraints. Let the database do as much work as possible.

  4. Don't scatter business logic in both the database and middle tier code. Pick one or the other, preferably in middle tier code.

  5. Decide on a consistent approach for primary keys and clustered keys.

  6. Don't over index. Choose your indexes wisely.

  7. Consistent table and column naming. Pick a standard and stick to it.

  8. Limit the number of columns in the database that will accept null values.

  9. Don't get carried away with triggers. They have their use but can complicate things in a hurry.

  10. 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.

  11. Get Celko's book on database design. The man is arrogant but knows his stuff.

其他推荐答案

First, developers need to understand that there is something to know about databases. They're not just magic devices where you put in the SQL and get out result sets, but rather very complicated pieces of software with their own logic and quirks.

Second, that there are different database setups for different purposes. You do not want a developer making historical reports off an on-line transactional database if there's a data warehouse available.

Third, developers need to understand basic SQL, including joins.

Past this, it depends on how closely the developers are involved. I've worked in jobs where I was developer and de facto DBA, where the DBAs were just down the aisle, and where the DBAs are off in their own area. (I dislike the third.) Assuming the developers are involved in database design:

They need to understand basic normalization, at least the first three normal forms. Anything beyond that, get a DBA. For those with any experience with US courtrooms (and random television shows count here), there's the mnemonic "Depend on the key, the whole key, and nothing but the key, so help you Codd."

They need to have a clue about indexes, by which I mean they should have some idea what indexes they need and how they're likely to affect performance. This means not having useless indices, but not being afraid to add them to assist queries. Anything further (like the balance) should be left for the DBA.

They need to understand the need for data integrity, and be able to point to where they're verifying the data and what they're doing if they find problems. This doesn't have to be in the database (where it will be difficult to issue a meaningful error message for the user), but has to be somewhere.

They should have the basic knowledge of how to get a plan, and how to read it in general (at least enough to tell whether the algorithms are efficient or not).

They should know vaguely what a trigger is, what a view is, and that it's possible to partition pieces of databases. They don't need any sort of details, but they need to know to ask the DBA about these things.

They should of course know not to meddle with production data, or production code, or anything like that, and they should know that all source code goes into a VCS.

I've doubtless forgotten something, but the average developer need not be a DBA, provided there is a real DBA at hand.