将数据持久保存为一组具有公共键和类型的键值对的选项
我正在考虑编写另一个框架，以便更轻松地开发“bread'n'butter”应用程序（例如创建一个具有 N 个字段的类，免费获得一个编辑器以及数据库持久性）。
所有数据模型都可以转换为 Entity-Attribute-Value 形式
TYPE VARCHAR(32)
ID LONG INT
NAME VARCHAR(32)
VALUE VARCHAR(64000)
：也许是第二个表用于非常大的字段，所以我会在 VALUE 列中保留对 BLOB 表中条目的引用。 如果我有心情，我可以为每个值类型创建一个表（因此 int 将为 INTEGER，避免所有转换问题），并且我可以使用表来定义有效的类型等。
这将有效地使我不必担心数据库设计，因为没有数据库设计。 通过使用简单的更新，数据库可以适应模型中的任何变化。 我什至可以拥有带有附加字段的同一类的实例。
缺点是对于每个对象，我需要读取 N 行，或者需要从构建包含 N 个子查询的复杂查询开始。
有人对此有经验吗？ 有没有人以这种方式实现过更大的系统？ 除了普通的 SQL 之外，还有哪些其他选项可以保存数据？ 我特别想听听有关敏捷系统的信息，这些系统可以轻松地适应模型中的更改，或者允许“修补”模型（通常，实例会有一个名称，但对于某些实例，我还想添加评论） 。 或者有人遇到过 SQL 后的事情吗？ 下一件伟大的事情是什么？
I'm toying with the idea to write another framework to make it easier to develop "bread'n'butter" applications (like create a class with N fields, get an editor for that for free plus the DB persistence).
All data models can be converted into the Entity-Attribute-Value form:
TYPE VARCHAR(32)
ID LONG INT
NAME VARCHAR(32)
VALUE VARCHAR(64000)
with maybe a second table for really large fields so I'd keep a reference in the VALUE column to the entry in the BLOB table. If I was in the mood, I could create one table per value type (so int would INTEGER, avoiding all the transformation problems) and I could use a table to define valid TYPEs, etc.
This would effectively free me from having to worry about the DB design since there isn't one. The database could adjust to any change in my model by using simple updates. I could even have instances of the same class with additional fields.
The drawback is that for each object, I need to read N rows or I need to start with building complex queries which contain N subqueries.
Does anyone have experience with this? Has anyone ever implemented a larger system this way? What other options are out there to persist data besides the normal SQL? I'd especially like to hear about agile systems which adopt easily to changes in the model or which allow to "patch" the model (usually, an instance will have a name but for some, I'd also like to add a comment). Or has anyone encountered something post-SQL? The next great thing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我还没有使用过它，但你想要做的事情听起来像CouchDB。 在重新发明轮子之前你可能想看看那里......
I haven't used it but what you're trying to do kind of sounds like CouchDB. You may want to look there before reinventing the wheel...
Amazon SimpleDB 使用此方法。 您定义域，每个域都有包含一堆键/值对的行。 该数据被称为“半结构化”。
这种方法有一些优点。 就像您的想法一样，您不需要定义数据库模式。 您可以临时引入新表、按行引入新列，甚至可以引入具有多个值的列（而不是使用额外的表创建 has_many 关系）。 如果您的架构发生更改，您可以过渡性地引入这些更改，而不是强制迁移。
另一方面，您正在放弃关系模型数十年的开发。 你会失去速度，因为你的索引要么太笼统，要么不存在。 聚合操作（组、连接）将非常慢。 查询优化会很困难等等。Amazon
SimpleDB 和 Apache CouchDB 都通过使数据库高度化来解决这个问题分散式。 虽然这确保了可靠性和冗余，但它也有其自身的一系列问题，例如冲突解决和过时的数据。
从你的问题来看，你似乎对“敏捷”方法死心塌地，所以我会推荐这两个数据库引擎之一（取决于你是否愿意向亚马逊付费 - 尽管不多 - 还是构建自己的设置）。 它们都允许完全动态的数据库模式。 只是要小心陷阱。
This approach is used by Amazon SimpleDB. You define domains and each domains has rows with a bunch of key/value pairs in it. This data is known as 'semi-structured'.
This approach has some strengths. Like your idea, you do not need to define a database schema. You can introduce new tables ad-hoc, new columns on a per-row basis, and even have columns that have more than one value (instead of creating a has_many relationship with an extra table). If your schema changes, you can introduce these changes transitionally rather than force migration.
On the other hand, you're throwing away decades of development on the relational model. You will hemorrhage speed because your indexing will either be too general or non-existent. Aggregate operations (groups, joins) will be extremely slow. Query optimisation will be difficult, etc.
Both Amazon SimpleDB and Apache CouchDB deal with this issue by making their databases highly distributed. While this ensures reliability and redundancy, it has its own set of problems, such as conflict resolution and out-of-date data.
From your question you seem dead set on an 'agile' methods, so I would recommend one of those two DB engines (depending on whether you'd rather pay Amazon - albeit not much - or build your own setup). They both allow a completely dynamic database schema. Just beware of the pitfalls.
查看 XML 数据库（例如 eXist）。 您可以通过修改 xml 架构轻松更改“数据模型”。 您还可以使用强大的查询语言，例如 XPath 和 XQuery。
Take a look at XML databases (like eXist). You can easily change your "datamodel" by modifying the xml schema. And you can use powerful query languages like XPath and XQuery.
我从未将整个应用程序基于此原则，但在几乎所有应用程序中，我确实使用某种形式的键值对集合，当特定实体需要一些其他实体不需要的附加属性时，这些集合可以处理极端情况。
我基本上序列化字典并将其与实体数据一起存储在数据库中。 当我必须处理一些过于晦涩难懂的内容而无法保证整个模型的更改时，这就是我用于后期制作修补的方法。
使用键值对数据，我也存储类型，因此我可以自动呈现适当的 HTML 控件。 我只有基本类型：文本、多行、RTF、复选框、数字和日期。
I never based an entire application on this principle, but in almost all applications I do use some form of key-value pair collections which deal with extreme cases when the specific entity requires some additional properties which are not needed for other entities.
I basically serialize the dictionary and store it like that in the database with my entity data. That's what I use for post production patching when I have to deal with something too obscure to warrant a change in the entire model.
With the key-value pair data, I do store the type as well, so I can automatically render appropriate HTML controls. I have just basic types: text, multi-line, RTF, checkbox, number and date.