我应该使用哪个数据库模型在运行时动态修改实体/属性？ [英] Which database model should I use for dynamic modification of entities/properties during runtime?
问题描述
我正在考虑为各种类型的数据创建一个开源数据管理Web应用程序。
I am thinking about creating an open source data management web application for various types of data.
特权用户必须能够
- 添加新实体类型例如'user'或'family'）
- 向实体类型添加新属性（例如'gender'删除/修改实体和属性。
这些将是特权用户的常见任务。他将通过应用程序的Web界面执行此操作。最后，所有数据必须可由应用程序的所有类型的用户搜索和排序。两个问题困扰我：
These will be common tasks for the privileged user. He will do this through the web interface of the application. In the end, all data must be searchable and sortable by all types of users of the application. Two questions trouble me:
a）数据应如何存储在数据库中？我应该在运行时动态添加/删除数据库表和/或列吗？
我没有数据库专家。我困惑于关系数据库的想象，应用程序必须能够在运行时动态添加/删除表（实体）和/或列（属性）。我不喜欢这个想法。同样，我想如果这样的动态数据应该在NoSQL数据库中处理。
I am no database expert. I am stuck with the imagination that in terms of relational databases, the application has to be able to dynamically add/remove tables (entities) and/or columns (properties) at runtime. And I don't like this idea. Likewise, I am thinking if such dynamic data should be handled in a NoSQL database.
无论如何，我相信这种问题有一个智能的规范解决方案，我只是没有找到和想到迄今为止。
Anyway, I believe that this kind of problem has an intelligent canonical solution, which I just did not find and think of so far. What is the best approach for this kind of dynamic data management?
b）如何在Python中使用ORM来实现这个功能， NoSQL？
如果您推荐使用关系数据库模型，那么我想使用SQLAlchemy。但是，我没有看到如何在运行时使用ORM动态创建表/列。这是为什么我希望有一个比在运行时创建表和列更好的方法的原因之一。 推荐的数据库模型可以使用SQLAlchemy有效地实现？
If you recommend using a relational database model, then I would like to use SQLAlchemy. However, I don't see how to dynamically create tables/columns with an ORM at runtime. This is one of the reasons why I hope that there is a much better approach than creating tables and columns during runtime. Is the recommended database model efficiently implementable with SQLAlchemy?
如果您推荐使用NoSQL数据库，我喜欢使用Redis - 您可以想象一个基于Redis的有效实现吗？
If you recommend using a NoSQL database, which one? I like using Redis -- can you imagine an efficient implementation based on Redis?
感谢您的建议！
编辑以回应一些评论：
这个想法是，所有实例某些实体（表）共享同一组属性/属性（列）。但是，如果某些实例对于某些属性/属性具有空值，则它将是完全有效的。
The idea is that all instances ("rows") of a certain entity ("table") share the same set of properties/attributes ("columns"). However, it will be perfectly valid if certain instances have an empty value for certain properties/attributes.
基本上，用户将通过网站上的简单表单搜索数据。他们查询具有属性P的实体E的所有实例具有高于T的值V.结果可以通过任何属性的值排序。
Basically, users will search the data through a simple form on a website. They query for e.g. all instances of an entity E with property P having a value V higher than T. The result can be sorted by the value of any property.
数据集不会变成太大了。因此，我认为即使最愚蠢的方法仍然会导致一个工作系统。然而，我是一个爱好者，我想应用现代和适当的技术，以及我想知道理论瓶颈。我想使用这个项目来收集设计Pythonic，最先进，可扩展和可靠的Web应用程序的经验。
The datasets won't become too large. Hence, I think even the stupidest approach would still lead to a working system. However, I am an enthusiast and I'd like to apply modern and appropriate technology as well as I'd like to be aware of theoretical bottlenecks. I want to use this project in order to gather experience in designing a "Pythonic", state-of-the-art, scalable, and reliable web application.
我看到第一个意见倾向于推荐NoSQL方法。虽然我真的很喜欢Redis，它看起来很愚蠢的不利用Mongo / Couch的文档/集合模型。我一直在寻找mongodb和mongoengine的Python。
I see that the first comments tend to recommending a NoSQL approach. Although I really like Redis, it looks like it would be stupid not to take advantage of the Document/Collection model of Mongo/Couch. I've been looking into mongodb and mongoengine for Python. By doing so, do I take steps into the right direction?
编辑2以回应一些答案/评论：
从大多数答案中，我得出结论，在关系图片中动态创建/删除表和列是不的方式。这已经是有价值的信息。另外，一种观点认为动态修改实体和属性的整个想法可能是坏的设计。
From most of your answers, I conclude that the dynamic creation/deletion of tables and columns in the relational picture is not the way to go. This already is valuable information. Also, one opinion is that the whole idea of the dynamic modification of entities and properties could be bad design.
正是这种动态特性应该是主要目的/功能应用程序，我不放弃这个。从理论的角度来看，我接受在动态数据模型上执行操作必须比在静态数据模型上执行操作慢。这是完全正常的。
As exactly this dynamic nature should be the main purpose/feature of the application, I don't give up on this. From the theoretical point of view, I accept that performing operations on a dynamic data model must necessarily be slower than performing operations on a static data model. This is totally fine.
以抽象的方式表示，应用程序需要管理
Expressed in an abstract way, the application needs to manage
- 数据布局，即有效实体类型的动态列表和每个有效实体类型的属性的动态列表
- em>数据本身
- the data layout, i.e. a "dynamic list" of valid entity types and a "dynamic list" of properties for each valid entity type
- the data itself
我正在寻找一种智能和高效的方法来实现这一点。从你的答案，看起来NoSQL是去这里的方式，这是另一个重要的结论。
I am looking for an intelligent and efficient way to implement this. From your answers, it looks like NoSQL is the way to go here, which is another important conclusion.
推荐答案
概念化你的实体作为文档，然后这个整个问题映射到非sql解决方案很好。如所评论的，您将需要有一种类型的模型层，它位于文档存储的顶部，并执行类似验证的任务，并且可能强制（或鼓励）某种模式，因为没有隐式后端需求
So, if you conceptualize your entities as "documents," then this whole problem maps onto a no-sql solution pretty well. As commented, you'll need to have some kind of model layer that sits on top of your document store and performs tasks like validation, and perhaps enforces (or encourages) some kind of schema, because there's no implicit backend requirement that entities in the same collection (parallel to table) share schema.
允许特权用户更改您的模式概念（而不是仅仅向各个文档添加字段 - 这很容易支持）提出一个挑战 - 您必须处理迁移现有数据以自动匹配新模式。
Allowing privileged users to change your schema concept (as opposed to just adding fields to individual documents - that's easy to support) will pose a little bit of a challenge - you'll have to handle migrating the existing data to match the new schema automatically.
阅读您的编辑，Mongo支持那种搜索/ order你正在寻找，并且会给你对你需要的空单元格（缺少特定键的文档）的支持。
Reading your edits, Mongo supports the kind of searching/ordering you're looking for, and will give you the support for "empty cells" (documents lacking a particular key) that you need.
如果我是你我偶然在一个类似的，但更简单的产品在工作），我会坚持使用Mongo，并研究一个轻量级的Web框架如Flask提供前端。你会自己提供的模型，但你不会打击框架的隐式建模选择。
If I were you (and I happen to be working on a similar, but simpler, product at the moment), I'd stick with Mongo and look into a lightweight web framework like Flask to provide the front-end. You'll be on your own to provide the model, but you won't be fighting against a framework's implicit modeling choices.
这篇关于我应该使用哪个数据库模型在运行时动态修改实体/属性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
