哪个更重要？数据库设计还是编码？

Question

哪个更重要？数据库设计还是编码？

Jos*_*osh 29 database database-design

哪个更重要:数据库的设计？还是应用程序代码的设计？

有很多关于可重用代码的信息(来自dnrtv.com的 Carl Franklin ,CSLA.net等人),但我没有看到太多关于数据库设计及其对生命周期的影响的信息.应用程序(特别是早期设计决策的糟糕程度会影响应用程序的"生命周期".

Answer 1

Pau*_*ier 84

通常,数据库结构更重要,因为它提供了开发代码的结构框架.通常(和YMMV非常相似),在完成开发阶段后重构数据库结构比简单地重构依赖于稳定数据库的代码要困难得多.原因很简单; 重构数据库结构通常会强制更改代码; 相反的情况很少如此.

很简单,您的代码依赖于您的数据库,而不是数据库取决于您的代码.(如果不是这种情况,您可能需要重新考虑您的设计.)

解决您的编辑问题; 我认为很多关于这类问题的人写作/写博客往往来自事物的"编码"方面,这些类型的人倾向于认为数据库设计是微不足道的,而不是编写有趣的解决方案.从本质上讲,对于那些喜欢解决"棘手问题"(往往是博客更多人)的人来说,编码方面比基本设计问题更有趣.虽然基本设计问题不是"性感",但它们非常重要(数据库设计是一个非常基本的设计问题).

数据库设计应该*永远不会成为代码的结构框架.它们必须通过强大的抽象层彼此隔离.您的代码根本不应该依赖于您的数据库; 数据库应设计为支持您的代码.你完全倒退了.(但遗憾的是,它应该是*应该如何*,而不是它在实践中的方式.) (8认同)
@le Dorfier:所以你的应用程序将永远存在,但你的数据来来去去？我倾向于相反相反.我可以想到几十种语言/框架/样式/分发方法,但在过去30多年里,它实际上只是数据库中的一个重要平台.我们的数据库有应用程序来来去去.添加应用程序以进行新分析...当不再支持该技术时删除应用程序...但数据仍然存在. (5认同)
我不确定为什么这会被贬低.+1来对付它. (3认同)
重要提示:数据库在以某种方式编码的应用程序中更为重要.如果您在强域模型(例如DDD)中抽象数据,那么代码设计比数据库的外观更重要.大多数应用程序可能会从混合方法中受益.例如,一个强大的域模型来封装业务逻辑(数据库不那么重要)和表单数据用于报告(数据库设计变得非常重要). (3认同)
问题来了,数据库服务的目的是什么？它只是一个持久层吗？或者,持久化数据的结构是否具有内在价值,以及由于其结构而可以对该数据执行的操作？ (3认同)
我曾经说过,当你有非常富有表现力的结构时,编码会更容易,因为你只需连接点.数据库只是:具有完整性的可查询数据结构. (2认同)

Answer 2

Tom*_*röm 26

简短回答:两者都有.这条链与最薄弱的环节一样强大.

Answer 3

Otá*_*cio 18

如果你对任何一个都不认真,那你就注定要失败.

Answer 4

Joh*_*yre 15

数据库设计是最重要的.

我是一名程序员,我更喜欢代码,但是......如果搞砸数据库设计,你的代码将是一场噩梦. 你的代码没有机会!

即使你试图重构数据库设计,你也会有很多关于代码的工作,修复它们将是压倒性的.

这不是偏好,甚至不是偏好,它非常倾向于DB设计最重要.

编辑:即使您有一些键值对表,其中所有内容都被转储到其中,这仍然是基于业务需求的数据库设计.

Answer 5

syb*_*eon 10

释义Knuth -

使用有效的数据结构更为重要.无论您的算法如何,糟糕的结构都会降低您的应用程序的速度,良好的结构甚至可以消除对某些算法的需求.

我认为这同样适用于DB.您最终构建了一个大规模链接的数据结构.如果你没有使用正确的方法,你的应用程序将会很慢,无论你投入多少诡计.

Answer 6

Jee*_*Bee 8

在使用过令人震惊的数据库设计之前,我必须把我的帽子放在数据库(或数据模型/ ORM)设计环中.

与在公司/客户中了解有关问题区域的一些人一起,获取纸上所需的所有数据,按逻辑区域分组,然后您将开始形成一个数据模型,您可以将其转换为对象,数据库模式或者.xsd等.每个数据项都有一个名称,一个类型,可能是字符串的最大长度,或者是某个最小或最大容量的集合或列表或映射.

无论您是在此之后首先设计数据库,还是OO模型都取决于您,但至少您已经努力预先获得一个理智的分区模型.

事实上,在MVC设计中,我将OO数据模型(Java/C#中的类)分类为模型,并与数据库模式本质上相关联(当然还增加了瞬态和实用方法).您的控制器 - 您的问题中的"编码" - 应该使用模型实际实现业务逻辑,该模型由您通过DAO/ORM从数据库中提取的对象表示.

我没有看到如何通过根据用户和任务要求设计逻辑数据模型来限制用户界面的设计. (5认同)
那么设计过程就有缺陷了.如果您从架构开始并以这种方式返回代码,那么您最终会得到最糟糕的应用程序 - 数据库上的一个薄层,可以将用户转变为数据录入员,在不考虑用户工作流的情况下进行表维护. (2认同)

Answer 7

Rad*_*Rad 8

以这种方式看待它

更改代码意味着更改代码
更改数据库可能会强制您更改代码

因此,尽早使数据库尽可能稳定非常重要

Answer 8

knu*_*nut 6

域模型应独立于持久性实现细节(尽管该技术确实对模型施加了一些约束) - http://www.infoq.com/articles/ddd-in-practice

您应该关注域模型.使用像Hibernate/NHibernate这样的ORM技术,数据库只是一个实现细节.

如果您正在进行.NET Web开发,您应该阅读的书籍:

Answer 9

HLG*_*GEM 5

根据我的经验(我已经参与修复数据库问题大约30年并处理了数百个不同的数据库),数据库性能中的许多问题都来自于重用代码的不适当尝试.函数比内联代码慢得多.重用一次插入一条记录的存储过程的游标比基于集合的代码要远,远,远(光年)慢.重用一个可以回收你需要的东西和其他十个字段的过程会浪费服务器和网络资源.当您只需要来自其中三个表的信息时,使用连接到十个表的现有视图会浪费服务器资源.数据库中的代码重用并不像其他地方那样好.这并不是说如果需要,代码不应该被重用.只是它永远不应该优先于性能.遗憾的是,数据库没有很好地重用代码.大多数数据库不是面向对象的,在设计或访问它们时面向对象的思维通常会导致设计不佳.

在您考虑代码重用之前,您需要拥有一个坚如磐石的规范化数据库设计.您需要考虑如何提取以及将数据插入数据库.一旦有许多用户和记录,您需要考虑这种工作的效果,因为此时重新设计基本数据库结构通常会变得过于昂贵和耗时.重构应用程序代码通常比基本数据库结构容易得多,并且通常情况下,数据库重构无法完成.如果您将表结构更改为从非规范化表转换为父子结构,因为您发现当前结构不符合您的需求,那么您最终可能会针对此表更改数百甚至数千个查询.这就是为什么花费大量时间进行数据库设计很重要的原因,由于时间/金钱的限制,您将无法在以后重新访问它.如果您将数据库视为房屋的基础,并将应用程序代码视为结构,您将会看到为什么这是真的.用它上面的结构改变基础比移动内壁要困难得多.数据库和访问它们的应用程序是相同的方式.

Answer 10

Kan*_*niu 5

两者都不重要,但......

糟糕的数据库设计可能使编写好的程序成为不此外,您通常可以重写错误的代码,但如果数据库中有大量数据,您只需要忍受在设计阶段做出的错误决策.

归档时间：	16 年，4 月前
查看次数：	4863 次
最近记录：	14 年，2 月前