开放式数据和数据类型的数据库结构和关联 [英] Database structure and associations for open-ended data and data types
问题描述
我想建立一个自订的CMS工具（是的，我知道 - 另一个CMS），用户可以创建任意多个嵌套的节点，因为他们想要的。
示例节点：餐馆，人，鞋，大洲...任何东西。在每个节点中，可以有所需的子节点数量等等。
通过Wordpress，Drupal ...等等，像分类法和术语这样的表格。
这看起来像是一个正常的东西，但我不能围绕它应该怎么做，他们如何做。我假设这些表与整体结构和表关系有关，但是...在线搜索来解释实际发生了什么，或者我将如何最好地设计我的数据库为这种结构。
我到目前为止的想法（显然不会被刷新或者我不会在这里请求）：
1）存储已知的数据类型和bindModel（）：
创建 data_locations 和 data_texts ，它们将具有其数据的字段。因此，在 data_locations 表中，我会有 city 和 longitude 和地址。在data_texts表中，我会有 title ， subtitle ， content bindModel（）创建关联（我猜？）。
这不会那么灵活，但也许更容易管理，并更快地运行查询...等？ Duncan。
2）具有单个数据表的每个节点的自定义字段： c $ c>表和字段表...每个节点都将有多个字段 maxLength ...等。然后，在管理员中，我列出这些字段，每个数据块 title ， shoe_size ...在与<$ p $ c>数据相关的节点和字段的表中有一行。
你的数据库是什么？考虑？在我看来，图表数据库对这种事情更为自然。
在关系数据库中，它是棘手的。嵌套任意深度的查询不是自然的（但是可行的），动态模式也是不自然的（通过google看到EAV模式，看看周围的参数），并且很难查询。
看看neo4j。我认为你可以直接自然地表达你的要求。
I'm trying to build a custom CMS tool (yes I know - ANOTHER CMS) where the users can create as many nested "nodes" as they want.
Example "Nodes": Restaurants, People, Shoes, Continents ... anything. Within each Node, there can be as many sub nodes as needed and so on and so forth.
While looking through Wordpress, Drupal... etc etc, I keep seeing tables like "taxonomy", and "terms".
This seems like a "normal" thing, but I can't wrap my head around how it should be done or how they're doing it. I assume these tables are related to the overall structure and table relationships, but... searches online come up shy of explaining what's actually going on or how best I would go about designing my database for this kind of structure.
Ideas I've had so far (that obviously aren't flushed out or I wouldn't be here asking):
1) Store known data types and bindModel():
Create tables like data_locations and data_texts that would have fields respective of their data. So - in the data_locations table, I'd have city, and longitude, and address. And in the data_texts table, I'd have title, subtitle, content, author.
Then, each time they created a new "Node", they could pick what kind of data-types it should have, and I would use bindModel() to create the associations (I guess?).
This wouldn't be as flexible, but maybe easier to manage, and faster to run queries on...etc? Dunno.
2) Custom fields for each Node with single "data" table: Have a data table, and a fields table... each node would haveMany fields - each with a type and maxLength...etc. Then, in the admin, I'd list those fields, and each chunk of data title, shoe_size...etc would have a row in the data table that related to the node and to the field.
This one seems more like what I THINK the "taxonomy" thing is - but again, I really have no idea.
Which database are you considering? Graph databases tend to be more natural for this kind of thing in my opinion.
In a relational database it is tricky. Nesting queries of arbitrary depth are not natural (but doable), dynamic schema are also unnatural (see 'EAV schemas' via google to see the arguments around that) and are very difficult to query well.
Have a look at neo4j. I think you can express your requirement directly and naturally.
这篇关于开放式数据和数据类型的数据库结构和关联的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
