Rails CMS：静态文件还是数据库记录？
我试图找出“文本条目”何时应存储在数据库中与作为静态文件存储的截止点。这里有什么经验法则吗？文本条目最多为几个段落，并具有到图像和表格的链接（以及到其他文本条目的超链接）。文本输入的一些标准：
- 我正在考虑使用 DITA 作为内容格式
- 文本应该是可搜索的
- 如果文本被修改，将创建一个新版本，
提前致谢，Chuck
I'm trying to figure out the cut-off with respect to when a "text entry" should be stored in the database vs. as a static file. Are there any rules of thumb here? The text entries will be at the most several paragraphs and have links to images and tables (and hyperlinks to other text entries). Some criteria for the text entry:
- I'm thinking of using DITA as the content format
- The text should be searchable
- If the text is revised, a new version will be created
thanks in advance, Chuck
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“rails way”将使用数据库。
该解决方案将更具可扩展性，因此速度更快，并且可能更容易开发（使用迁移等）。使用文件系统，您将必须自己构建许多功能，这些功能已经为数据库使用而实现。
您可以创建一个模型（例如）文档并轻松使用现有的版本控制系统，例如 paper_trail 。当使用索引搜索时，您可以只拥有一个 has_many 关系，使您能够实现模型之间的依赖关系（破坏模型意味着破坏搜索索引）。
The "rails way" would be using a database.
The solution will be more scalable, therefore faster and probably easier to develop with (using migration and so on). Using the file system, you will have to build lots of functions on your own, that are already implemented for database usage.
You could create a Model (e.g.) Document and easily use existing versioning systems, like paper_trail. When using an indexed search, you can just have an has_many relation enabling you to realise the depencies between the models (destroy a model means to destroy the search index).
您可以查看数据库提供的内容，并问问自己这些功能是否有用，而不是截止日期。进行隔离（ACID 中的 I）：如果您担心多个人可能会尝试隔离同时编辑一个条目，数据库可以很好地处理这个问题，而您必须自己处理文件的锁。或者原子性：您可能想同时更新两个内容（例如索引页和条目页），并且知道它们要么都成功，要么都失败。
数据库除了 ACID 之外还可以做很多事情，例如利用多种数据类型、使查询更容易以及允许扩展。这是一个值得问的问题，因为大多数数据库最终都会将数据存储在磁盘上的一堆文件中。如果您自己使用文件，您最终会编写一个小型数据库吗？
此外，如果您使用 Rails，您还介意利用其 ActiveRecord 功能，并可以使用许多需要数据库的插件。
即使是小型的单用户 Rails 应用程序，我也会使用数据库。
Rather than a cut-off, you could look at what databases provide and ask yourself if those features would be useful. Take Isolation (the I in ACID): if you have any worries that multiple people could be trying to edit an entry at the same time, a database would handle that well while you'd have to handle the locks yourself working with files. Or Atomicity: you might want to update two things at once (e.g. an index page and an entry page) and know they will either both succeed or both fail.
Databases do a number of things beyond ACID, such as taking advantage of multiple datatypes, making querying easier, and allowing for scaling. It's a question worth asking since most databases end up having data stored in a bunch of files on disk. Would you end up writing a mini-database if you used files yourself?
Besides, if you're using rails you mind as well take advantage of its ActiveRecord functionality, and make it possible to use the many plugins that expect a database.
I'd use a database for even a small, single user rails app.