我应该使用哪种数据库模型在运行期间动态修改实体/属性?[英] Which database model should I use for dynamic modification of entities/properties during runtime?

本文是小编为大家收集整理的关于我应该使用哪种数据库模型在运行期间动态修改实体/属性?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我正在考虑为各种类型的数据创建一个开源数据管理Web应用程序.



特权用户必须能够




  • 添加新实体类型例如'user'或'family')

  • 向实体类型添加新属性(例如'gender'删除/修改实体和属性.



这些将是特权用户的常见任务.他将通过应用程序的Web界面执行此操作.最后,所有数据必须可由应用程序的所有类型的用户搜索和排序.两个问题困扰我:



a)数据应如何存储在数据库中?我应该在运行时动态添加/删除数据库表和/或列吗?



我没有数据库专家.我困惑于关系数据库的想象,应用程序必须能够在运行时动态添加/删除表(实体)和/或列(属性).我不喜欢这个想法.同样,我想如果这样的动态数据应该在NoSQL数据库中处理.



无论如何,我相信这种问题有一个智能的规范解决方案,我只是没有找到和想到迄今为止.



b)如何在Python中使用ORM来实现这个功能, NoSQL?



如果您推荐使用关系数据库模型,那么我想使用SQLAlchemy.但是,我没有看到如何在运行时使用ORM动态创建表/列.这是为什么我希望有一个比在运行时创建表和列更好的方法的原因之一. 推荐的数据库模型可以使用SQLAlchemy有效地实现?



如果您推荐使用NoSQL数据库,我喜欢使用Redis - 您可以想象一个基于Redis的有效实现吗?



感谢您的建议!



编辑以回应一些评论:



这个想法是,所有实例某些实体("表")共享同一组属性/属性("列").但是,如果某些实例对于某些属性/属性具有空值,则它将是完全有效的.



基本上,用户将通过网站上的简单表单搜索数据.他们查询具有属性P的实体E的所有实例具有高于T的值V.结果可以通过任何属性的值排序.



数据集不会变成太大了.因此,我认为即使最愚蠢的方法仍然会导致一个工作系统.然而,我是一个爱好者,我想应用现代和适当的技术,以及我想知道理论瓶颈.我想使用这个项目来收集设计"Pythonic",最先进,可扩展和可靠的Web应用程序的经验.



我看到第一个意见倾向于推荐NoSQL方法.虽然我真的很喜欢Redis,它看起来很愚蠢的不利用Mongo / Couch的文档/集合模型.我一直在寻找mongodb和mongoengine的Python.



编辑2以回应一些答案/评论:



从大多数答案中,我得出结论,在关系图片中动态创建/删除表和列是不的方式.这已经是有价值的信息.另外,一种观点认为动态修改实体和属性的整个想法可能是坏的设计.



正是这种动态特性应该是主要目的/功能应用程序,我不放弃这个.从理论的角度来看,我接受在动态数据模型上执行操作必须比在静态数据模型上执行操作慢.这是完全正常的.



以抽象的方式表示,应用程序需要管理




  1. 数据布局,即有效实体类型的"动态列表"和每个有效实体类型的属性的"动态列表"

  2. em>数据本身



我正在寻找一种智能和高效的方法来实现这一点.从你的答案,看起来NoSQL是去这里的方式,这是另一个重要的结论.


推荐答案

概念化你的实体作为"文档",然后这个整个问题映射到非sql解决方案很好.如所评论的,您将需要有一种类型的模型层,它位于文档存储的顶部,并执行类似验证的任务,并且可能强制(或鼓励)某种模式,因为没有隐式后端需求



允许特权用户更改您的模式概念(而不是仅仅向各个文档添加字段 - 这很容易支持)提出一个挑战 - 您必须处理迁移现有数据以自动匹配新模式.



阅读您的编辑,Mongo支持那种搜索/ order你正在寻找,并且会给你对你需要的"空单元格"(缺少特定键的文档)的支持.



如果我是你我偶然在一个类似的,但更简单的产品在工作),我会坚持使用Mongo,并研究一个轻量级的Web框架如Flask提供前端.你会自己提供的模型,但你不会打击框架的隐式建模选择.


本文地址:https://www.itbaoku.cn/post/597542.html

问题描述

I am thinking about creating an open source data management web application for various types of data.

A privileged user must be able to

  • add new entity types (for example a 'user' or a 'family')
  • add new properties to entity types (for example 'gender' to 'user')
  • remove/modify entities and properties

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) How should the data be stored in the database? Should I dynamically add/remove database tables and/or columns during runtime?

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) How to implement this in Python using an ORM or NoSQL?

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?

If you recommend using a NoSQL database, which one? I like using Redis -- can you imagine an efficient implementation based on Redis?

Thanks for your suggestions!

Edit in response to some comments:

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.

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.

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.

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?

Edit 2 in response to some answers/comments:

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

  1. the data layout, i.e. a "dynamic list" of valid entity types and a "dynamic list" of properties for each valid entity type
  2. the data itself

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.

推荐答案

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.

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.

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.