YAGNI适用于数据库设计吗？
在代码中，通常很容易添加新类来提供附加功能等。 我对重构代码及其涉及的内容有相当好的理解，因此 YAGNI 通常对我。
我不太熟悉的是在部署关系数据库后如何使用和更新它。 我正在开发一个小宠物项目，我计划练习 尽早发布，经常发布，我想知道是否应该考虑在初始版本中不会使用但在计划功能列表中的数据？ 添加表和调整模式是否像添加新类一样容易？ 或者我应该尝试为我可以使用但不打算在不久的将来使用的东西设置表格？
In code, it's generally pretty easy to add new classes to provide additional functionality and such. I have a fairly good understanding of refactoring code and what's involved so YAGNI generally makes sense to me.
What I'm not as familiar with is working with and updating a relational database once it's deployed. I'm developing a little pet project that I'm planning on practicing Release Early, Release Often on and I'm wondering if I should be considering data that won't be used in the initial release, but is on the planned features list? Is it as easy to add tables and tweak schemas around as it is to add new classes? Or should I try to have tables set up for things I could conceivably use, but aren't planning to in the immediate future?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
这是一个很好的问题。 我个人发现修改数据库模式并将所有数据转换为新的表示形式比重构代码困难得多。 事实上，每当我开始一个将使用新数据库的项目时，我总是会花时间坐下来编写任何代码以尽可能彻底地了解我的规范。 这通常需要预测功能并将对它们的支持合并到数据库中，即使我不打算立即实现它们。
如果您使用提供更改数据库机制的框架或其他类似层，您可能可以更灵活地进行数据库重构，但如果您直接编写 SQL，那么我建议您投入适量的资金设计和实现一个未来不太可能需要更改的模式。
This is an excellent question. I've personally found that modifying a database schema and converting all the data to the new representation to be far more difficult than refactoring code. So much so, in fact, that whenever I start a project that will use a new database I always take time before I sit down and write any code to get my spec as thorough as possible. What this often entails is anticipating features and incorporating support for them into the database, even if I don't plan on immediately implementing them.
You might be able to be a bit more nimble with database refactoring if you're using a framework or other similar layer that provides a mechanism for altering the database, but if you're writing straight SQL then I would recommend investing a modest amount of time designing and implementing a schema that is less likely to require changing in the future.
如果您对数据库进行了良好的测试，我会将 YAGNI 扩展到您的数据库设计中。
一般来说，添加列和表很容易，但显着删除或修改它们则不太容易。 设计表时要考虑到这一点（即，如果一个客户可以有多个用户，则不要将 userid 添加到您的客户表中。第一次就做对）。
If you have good testing that hits the database, I would extend YAGNI to your database design.
In general, it is easy to add columns and tables, and less easy to remove or modify them significantly. Take that into consideration when you design tables (i.e. if a customer can have multiple users, don't add userid to your customers table. Do it right the first time).
我的观点是，YAGNI 适用于一切，编码、数据库设计、家庭工作（我的妻子在这一点上强烈反对我）等等。
我曾经开发过的每个基于 DBMS 的应用程序都会定期更新场景，因此应该在流程中对此进行规划。 DBA 不会喜欢您的提案中的“经常发布”部分，因为这对他们（或者您，如果它是非 DBA 数据库）来说是更多的工作。
但这就是他们存在的目的。
My opinion is that YAGNI applies to everything, coding, database design, work around the house (my wife disagrees with me vehemently on this one), and so on.
Every DBMS-based application I've ever worked on has had updates regularly to the scema so this should be planned for in processes. The DBAs won't like the "release often" part of your proposal since that's more work for them (or you if it's a non-DBA database).
But that's what they're there for.
关于数据库设计和实现有很多敏捷思维。 您可能有兴趣查看 最佳实践，网址为 www.agiledata.org 了解 Scott Ambler 关于该主题的一些想法。 就我自己而言，我通常让数据库的设计随着应用程序的开发而发展。 我很少提前创建表格。 审计和权限之类的例外情况是贯穿整个设计的事情。 即使我实际上没有预先为它们创建任何表，我也会考虑如何实现这些事情。 横切方面确实会影响表格的设计，即使这些功能并不总是首先出现的。
There is a whole host of agile thinking about database design and implementation. You might be interested in looking through the best practices at www.agiledata.org for some of Scott Ambler's thoughts on the subject. For myself, I generally let the design of the database grow as the application develops. I rarely create tables ahead of time. Exceptions to this would be things like auditing and permissions, things that cut across the entire design. I will think about how to implement these things even if I don't actually create any tables for them upfront. Cross-cutting aspects do affect the design of tables even if those features aren't always the first ones out of the gate.
数据库设计有一个概念基础。
在经典的数据库设计中，存在三种模型：概念模型、逻辑模型和物理模型。
概念模型产生于需求分析，并随着底层主题的发展或随着对主题的理解的发展而发展。 概念模型将基本数据固定为形式和语义，但不处理表格组成等问题。
逻辑模型使用数据的关系模型。 它可以从概念模型中推导出来，但它也处理关系的组成。 标准化和其他组合问题在这里发挥作用。 逻辑模型预测表设计，以及应用程序将进行的查询和更新。
物理模型将关系实现为表，并且还添加了实际构建数据库所需的所有其他功能，如索引、表空间等。 它源自逻辑模型，但数据量、负载、性能和磁盘空间都会发挥作用。
这听起来又长又乏味，但如果您知道如何做，它实际上很快。 整个事情可以在几周内完成，而团队的其他成员仍在讨论功能规格。 对于一个非常小的项目（6 个表，50 列），只需铅笔和纸即可在几天内完成。 对于较大的项目，有一些工具可以使设计更加自动化、不易出错并且易于绘制图表。
但是，当您发现概念模型不准确或不完整，并且其他两个模型和数据库本身需要更改时，会发生什么？ 这就是数据独立性发挥作用的地方。 数据独立性对于数据库设计的作用就像封装对于对象设计的作用一样。 也就是说，它可以防止一处的微小调整传播到整个应用程序对象。 对象仅依赖于它们使用的数据。
如果必须将新表添加到架构中，则任何应用程序被破坏的可能性微乎其微。 即使必须更改现有表，仅使用旧列的查询也不会看到任何差异。 即使对象依赖于更改，您仍然可以为更改的表指定一个新名称，然后使用旧名称创建一个视图，使其看起来像旧表仍然存在。
在一个好的 DBMS 中，物理数据的独立性几乎是完全的。 您可以重新组织数据、添加和删除索引等，并且不必更改任何应用程序。
简而言之，使用真正优秀的 DBMS 产品可以出色地完成变更管理。 不幸的是，许多 DBA 和程序员不知道如何充分利用这些 DBMS 功能，尽管它们已经存在多年了。
There is a conceptual basis for database design.
In classical database design, there are three models: conceptual, logical, and physical.
The conceptual model emerges from requirements analysis, and evolves as the underlying subject matter evolves or as understanding of the subject matter evolves. The conceptual model pins down elementary data as to form and semantics, but doesn't deal with such issues as table composition.
The logical model uses the relational model of data. It can be derived from the conceptual model, but it also deals with the composition of relations. Normalization and other composition issues come into play here. The logical model anticipates the table design, and also the queries and updates the application will make.
The physical model implements relations as tables, and also adds all the other features like indexes, tablespaces, etc. needed to actually build the database. It's derived from the logical model, but data volume, load, performance, and disk space all come into play.
This sounds lengthy and tedious, but it's actually fast, if you know how to do it. The whole thing can be done in a matter of weeks, while the rest of the team is still debating functional specs. For a really small project (6 tables, 50 columns) it can be done in days, with just pencil and paper. For larger projects, there are tools that make design more automatic, less error prone, and easily diagrammed.
But what happens when you discover that the conceptual model was inaccurate or incomplete, and the other two models and the database itself need to be altered? That's where Data Independence comes to the rescue. Data independence does for database design what encapsulation does for object design. Namely, it prevents a minor adjustment in one place from propagating all over the application objects. Objects are only dependent on the data that they use.
If a new table has to be added to a schema, the chances that any application will be broken is vanishingly small. Even if an existing table has to be altered, queries that only use the old columns won't see any difference. Even when objects are dependent on the change, you can still give the altered table a new name, and then create a view with the old name that makes it look like the old table is still there.
And physical data independence is almost complete in a good DBMS. You can reorganize data, add and drop indexes, etc. and you shouldn't have to change any of the application.
In short, change management can be done brilliantly using the really good DBMS products out there. Unfortunately, a lot of the DBAs and programmers don't know how to make adequate use of these DBMS features, even though they have been around for years.
该原则仍然适用。 在拥有大量数据之前，您不必担心向表等添加字段。 相当多的数据。 因此，在没有看到实际数据的情况下过早担心索引和查询计划的细节通常会浪费时间，甚至会导致以后出现架构问题。
不幸的是，如果不遵循良好的测试/发布过程，那么在生产发布后对数据库设计进行修改可能会非常可怕。 因此，比代码更重要的是，您希望第一次就可以正确使用数据库。
对于数据库，您确实需要计划如何取出数据以及将其放入和存储，因此如果您的“计划”功能包括报告，这将极大地影响数据库的设计，因此也许要为此做好计划。
调整架构不像添加类那么容易，但它是可行的。
所以总体来说，YAGNI 还是适用的。
The principle still applies. You are not going to have to worry about adding fields to tables etc until you have a lot of data. Quite a lot of data. So worrying too much too early about the details of indexing and query plans without seeing actual data is going to often be wasted time and even lead to architectural problems later.
Unfortunately, mucking about with the database design after a production release can be pretty scary if a good test/release process is not followed. So even more so than code, you want to get it right first time with a database.
With databases, you do want to plan for getting the data out as well as putting it in and storing it, so if your "planned" features include reporting, that will affect the design of the database a lot, so maybe plan for that.
It is not as easy to tweak a schema as adding a class, but it is doable.
So overall, YAGNI still applies.
不要设置您还不需要的表。 YAGNI 背后的部分原因是您无法预先预测您将需要哪些正确的东西。 当您需要更改表时，您可以轻松添加新表、更改现有表等。
一个好的框架应该有一些用于执行迁移的工具，这些工具允许您升级并轻松自动降级您的数据库。 如果你做到了这一点，并且对你的设计相当谨慎，你应该能够重构你的方式到你需要的地方，而不是试图预先提出你需要的一切。
Don't set up the tables you don't need yet. Part of the reason behind YAGNI is that you're not going to predict up front the right things that you will need. You can easily add new tables, alter existing tables, and so on when you need to change them.
A good framework should have some tools for performing migrations, which allow you to upgrade and downgrade your database easily and automatically. If you have this in place, and are reasonably careful about your design, you should be able to refactor your way to where you need to be, rather than trying to come up with everything you'll ever need up front.
数据库设计与任何其他类型的设计一样。 你的理解会逐渐增长，随着理解的加深，模式也会不断发展。
我希望能更容易地解释关系数据库模式设计实际上是如何存在概念基础的。 真正对其进行建模的唯一工具是对象角色建模，它已经出现很长时间了。 最熟悉的工具是 Visiomodeler。 为了了解它的味道，这里有几个指向 Scott Ambler 和 Scot Becker 但是我们得出的结论是对象建模类型的断言直接导致具体的关系逻辑模型； 因此，模式需要随着概念模型的变化而变化。
在实践中，如果您确实对转换表达式感到满意，您的 RDBMS 可以处理相当多的变化。 擅长它是值得的。
注意：我认为 LINQ 和对象关系模型等 SQL 避免技术只会成为不断发展的设计的障碍。 我可能错了。 有理由希望微软的实体框架能够包含对象角色建模； 但我只看到间接提及这种可能性。
Database design is like any other kind of design. Your understanding grows incrementally, and with better understanding comes an evolving schema.
I wish it were easier to explain how there is, in fact, a conceptual basis for relational database schema design. The only tool that really models it is Object Role Modeling, which has been a long time emerging. The most familiar tool was Visiomodeler. To get a flavor of it, here are a couple links to Scott Ambler and Scot Becker But the conclusion one would draw is that object-modeling-type assertions lead directly to a specific relational logical model; hence the schema will need to change as your conceptual model changes.
In practice, your rdbms can handle quite a bit of flexing if you're really comfortable with transformation expressions; and it's worth it to get good at it.
Note: I think that SQL avoidance techniques like LINQ and Object-Relational Models will just be an impediment to an evolving design. I may be wrong. There's some reason to hope that Microsoft's Entity Framework will encompass Object Role Modeling; but I've only seen oblique references to the possibility.