YAGNI 和数据库创建脚本
现在,我有在主数据库访问类中创建数据库的代码(只需在 SQLite 数据库上执行一些 CREATE 查询)。这似乎没有必要,因为我无意使用该代码。如果出现问题并且需要重新创建数据库,我只需要它。我应该...
- 保持原样,即使数据库创建代码大约是我的文件大小的四分之一。
- 将数据库创建代码移至单独的脚本中。无论如何,如果我需要再次运行它,我很可能会手动运行它,这会使其在处理主代码时看不见或忘记。
- 如果我发现自己再次需要它,请删除数据库创建代码并依赖修订控制。
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...
- Leave things as they are, even though the database creation code is about a quarter of my file size.
- 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.
- Delete the database-creation code and rely on revision control if I ever find myself needing it again.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我认为最好保留代码。更重要的是,每次数据库模式更改时,您都应该维护(或生成)此代码。
由于以下原因,它很重要。
如果您对此没有严格的方法,我发现数据库架构可能会随着时间的推移而发生临时更改,这可能会导致一些模糊的问题,直到您访问数据库才能发现这些问题。更糟糕的是,如果没有严格的方法(即模式的参考定义),您可能会发现不同的数据库具有细微不同的模式。
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.
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.
重新创建数据库绝对不是特例。该代码是您在新的/不同的系统上部署过程的一部分,它代表您的代码期望使用的数据库结构。您实际上应该进行集成测试来证实这一点。您不应该依赖于无限期地使用单个数据库服务器(其架构是在开发过程中通过手动分派 SQL 语句增量创建的)。
但是,是的,它应该与访问代码分开;所以选项2是正确的。然后,单独的脚本可以用于测试以及部署。
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.