YAGNI 和数据库创建脚本

发布于 2024-09-06 03:57:18 字数 274 浏览 5 评论 0原文

现在,我有在主数据库访问类中创建数据库的代码(只需在 SQLite 数据库上执行一些 CREATE 查询)。这似乎没有必要,因为我无意使用该代码。如果出现问题并且需要重新创建数据库,我只需要它。我应该...

  1. 保持原样,即使数据库创建代码大约是我的文件大小的四分之一。
  2. 将数据库创建代码移至单独的脚本中。无论如何,如果我需要再次运行它,我很可能会手动运行它,这会使其在处理主代码时看不见或忘记。
  3. 如果我发现自己再次需要它,请删除数据库创建代码并依赖修订控制。

Right now, I have code which creates the database (just a few CREATE queries on a SQLite database) in my main database access class. This seems unnecessary as I have no intention of ever using the code. I would just need it if something went wrong and I needed to recreate the database. Should I...

  1. Leave things as they are, even though the database creation code is about a quarter of my file size.
  2. Move the database-creation code to a separate script. It's likely I'll be running it manually if I ever need to run it again anyway, and that would put it out-of-sight-out-of-mind while working on the main code.
  3. Delete the database-creation code and rely on revision control if I ever find myself needing it again.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

め七分饶幸 2024-09-13 03:57:18

我认为最好保留代码。更重要的是,每次数据库模式更改时,您都应该维护(或生成)此代码。

由于以下原因,它很重要。

  1. 您可能会惊讶地发现自己有多少次需要它。如果您需要迁移您的服务器,或者设置另一个环境(例如TEST或DEMO)等。
  2. 我还发现我在编码时经常引用 DDL SQL,特别是当我有一段时间没有接触系统时。
  3. 您可以为您做出的决策提供参考,例如您创建的索引、唯一键等。

如果您对此没有严格的方法,我发现数据库架构可能会随着时间的推移而发生临时更改,这可能会导致一些模糊的问题,直到您访问数据库才能发现这些问题。更糟糕的是,如果没有严格的方法(即模式的参考定义),您可能会发现不同的数据库具有细微不同的模式。

I think it is best to keep the code. Even more importantly, you should maintain this code (or generate it) every time the database schema changes.

It is important for the following reasons.

  1. You will probably be surprised how many times you need it. If you need to migrate your server, or setup another environment (e.g. TEST or DEMO), and so on.
  2. I also find that I refer to the DDL SQL quite often when coding, particularly if I have not touched the system for a while.
  3. You have a reference for the decisions you made, such as the indexes you created, unique keys, etc etc.

If you do not have a disciplined approach to this, I have found that the database schema can drift over time as ad-hoc changes are made, and this can cause obscure issues that are not found until you hit the database. Even worse without a disciplined approach (i.e. a reference definition of the schema) you may find that different databases have subtly different schema.

﹎☆浅夏丿初晴 2024-09-13 03:57:18

如果出现问题我就需要它
错了,我需要重新创建
数据库。

重新创建数据库绝对不是特例。该代码是您在新的/不同的系统上部署过程的一部分,它代表您的代码期望使用的数据库结构。您实际上应该进行集成测试来证实这一点。您不应该依赖于无限期地使用单个数据库服务器(其架构是在开发过程中通过手动分派 SQL 语句增量创建的)。

但是,是的,它应该与访问代码分开;所以选项2是正确的。然后,单独的脚本可以用于测试以及部署。

I would just need it if something went
wrong and I needed to recreate the
database.

Recreating the database is absolutely not an exceptional case. That code is part of your deployment process on a new / different system, and it represents the DB structure your code expects to work with. You should actually have integration tests that confirm this. Working indefinitely with a single DB server whose schema was created incrementally via manually dispatched SQL statements during development is not something you should rely on.

But yes, it should be separated from the access code; so option 2 is correct. The separate script can then be used by tests as well as for deployment.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文