时间限制层次结构的最佳关系数据库表示
每个人都认为 SQL 中有时限层次结构的最佳表示是什么？
我的意思是：
- 在任何给定的日期，您都有正常的树层次结构
- 此层次结构每天都会发生变化
仍然只有一个父母。
- 每个孩子在任何给定日期第 1 天...
Business
|
|-Joe
| |-Happy
| |-Sneezy
| |-Doc(*)
|
|-Moe
|-Bashfull
|-Sleepy
第 2 天...
Business
|
|-Joe
| |-Happy
| |-Sneezy
|
|-Moe
|-Doc(*)
|-Bashfull
|-Sleepy
在任何时候，孩子都可以第一次加入层次结构，或完全离开层次结构。 （例如，新员工和退休员工。）
主要考虑事项：
- 更新层次结构
- 查看某个日期范围内的整个层次结构
- 报告层次结构内的整个子树
- 报告某个日期范围内的整个子树
我知道如何目前正在这样做，但对其其他人如何做到这一点很感兴趣:)
编辑
我天真地假设了一些考虑因素，因此会更加明确......
- 每个“团队”或“个人”都会有其他地方的维度表中的唯一 ID
- 其他事实表将使用这些 ID（例如，存储性能指标）
- 该结构需要促进跨日期范围的历史报告
- 使用 ETL 或触发器来维护替代结构 是一种选择
通用性是最重要的重要的（仅形成通用关系模式的一部分），与驱动报告的易用性（针对任何日期范围内的树的任何部分）以及可靠更新的能力相结合。
What in everyone's opinion is the best representation for a time-bound hierarchy in SQL?
What I mean by this is:
- On any given date you have a normal tree hierarchy
- This hierarchy can change from day to date
- Each child still only has one parent on any given date
Day 1...
Business
|
|-Joe
| |-Happy
| |-Sneezy
| |-Doc(*)
|
|-Moe
|-Bashfull
|-Sleepy
Day 2...
Business
|
|-Joe
| |-Happy
| |-Sneezy
|
|-Moe
|-Doc(*)
|-Bashfull
|-Sleepy
At any time, a child can join the hierarchy for the first time, or leave the hierarchy completely. (For example, new employees, and retired employees.)
The main considerations:
- Updating the hierarchy
- Viewing the whole hierarchy across a date range
- Reporting on whole sub-trees within the hierarchy
- Reporting on whole sub-trees across a date range
I know how I do it at present, but am intrigued as to how other people may do it :)
EDIT
I naively assumed a few considerations so will be more explicit...
- Each 'team' or 'person' will have a unique ID in a dimension table elsewhere
- Other fact tables will use those IDs (storing performance metrics, for example)
- The structure needs to facilitate historical reporting across date ranges
- Use of ETL or triggers to maintain alternative structures Is an option
The generic nature is most important (forming just one part of a generic relational mode), combined with ease of use for driving report (for any part of the tree across any range of dates) and the ability to be updated reliably.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这里有几本不同的相关书籍 - 一套是关于“时态数据库”的，另一套是关于“RDBMS 中的层次结构”的。
你的问题的棘手部分，它在我看来，是：
其他项目即使不是直接的，也可以使用书中概述的技术以及其他答案中建议的方式进行管理。 部分问题在于理解这两个要点的含义。 从某种意义上说，它们是“相同的”；从某种意义上说，它们是“相同的”。 “整个层次结构”只是“整个子树”的一个特例。 但更深层次的问题是“你想如何展示——可视化、表示——层次结构随时间的变化？” 您是否想要比较开始和结束时间的状态，或者是否也想要查看中间的变化？ 您想如何表示层级中个人的举动？
问题多于答案 - 但我希望这些指示能有所帮助。
There are several different books of relevance here - one set is for 'temporal databases', and the other for 'hierarchical structures in RDBMS'.
The tricky parts of your question, it seems to me, are:
The other items are, if not straight-forward, then manageable using the techniques outlined in the books, and along the lines suggested in other answers. Part of the problem is understanding what those two bullet points mean. In one sense, they are 'the same'; the 'whole hierarchy' is just a special case of 'whole sub-trees'. But the deeper question is 'how do you want to demonstrate - visualize, represent - the changes in the hierarchy over time?' Are you seeking to compare the states at the start and end times, or are you seeking to see the intermediate changes too? How do you want to represent the moves of an individual within a hierarchy?
More questions than answers - but I hope the pointers are some help.
几张平板桌子就可以在这里工作。 对于每一行，我们需要列 ID、Name、ParentID 和 InactivatedDatetime（默认为 null）。 设置属于 Joe 的旧文档的日期时间，表明该记录不再有效，并将其移至存档表（为了清洁），然后为新文档创建一个新行（原始行的近似副本）以 Moe 的 ID 作为 ParentID。 这种方法的缺点是被转移的人必须获得新的身份证，这可能不太方便。
A couple of flat tables can work here. For each row, we need columns ID, Name, ParentID, and InactivatedDatetime (which defaults to null). Set the datetime for the old Doc belonging to Joe indicating that that record is no longer valid and move it off to an archive table (for cleanliness), and then create a new row (a near copy of the original row) for a new Doc with Moe's ID as the ParentID. The drawback with this approach is that the person being moved must get a new ID, which may not be convenient.
我可以想到一些合理的解决方案，具体取决于您的数据的使用方式及其变化方式。
1）假设今天的等级制度是最重要的。 我将在每条记录中使用传统的 ParentId 列存储今天的层次结构。 对于以前版本的层次结构，我有一个历史记录表，
每当层次结构发生更改时，您都会向历史记录表添加一个新行。
2）如果任何/所有层次结构都同等重要，我将存储基线层次结构，然后实现层次结构事务表。
I can think of a couple of reasonable solutions, depending on how your data is being used and how it changes.
1) Assuming today's hierarchy is the most important. I'd store today's hierarchy with a conventional ParentId column in each record. For previous versions of the hierarchy I'd have a history table of
Any time the hierarchy changes, you add a new row to the history table.
2) If any/all of the hierarchies are of equal importance, I'd store a base line hierarchy and then implement a hierarchy transaction table.
这些链接将在一定时间内存储树的表示形式。
该结构表示一个网络而不是简单的层次结构，但它支持在层次结构中移动事物，但也可以及时回顾。 应用程序逻辑中需要检查的一些事情是不允许 joe 同时链接到层次结构中的不同位置。
通过先验子句连接（在 Oracle 中），报告相对容易。
如果要指定关系上的附加数据，其他详细信息可以与项目甚至项目链接相关。
The links will store the representation of the tree for a certain time
This structure represents a network instead of a plain hierarchy but it supports moving things in a hierarchy but also look back in time. Some things need to be checked in application logic is to disallow joe being linked at different places in the hierarchy at the sametime.
Reporting is relatively easy with connect by prior clause (in oracle)
Other details can be related to item or even item link if it is to specify additional data on the relation.