多态列表和关系数据库
我在建模数据库以存储一些 Java 对象时遇到了问题（将对象映射到关系数据库的经典问题）。一个例子比长篇大论要好得多，这就是内容。
可用课程列表：
- A 类包含一个双精度数组
- B 类包含 A 的数组
- C 类包含一个 B 数组和一个 A 数组（可以这样继续......）
所有对象都实现相同的父对象（假设 StorableObject）。可以有尽可能多的组合。
如何存储所有这些值，此外，如何使用某些 FK 创建模型，在删除父对象时删除其所有子对象。我的意思是，由于子项可以存储在各种表中，因此我无法在父项的字段上放置一个简单的 FK。
谢谢 ;）
I've got an issue modelling a database to store some Java Objects (classical problem of mapping objects to a relational database). A example beeing far better than a long description, here's the stuff.
List of avaliable classes :
- Class A contains an array of doubles
- Class B contains an array of A
- Class C contains an array of B and an array of A (it can go on like that...)
All the objects implements the same parent (let's say StorableObject). There can be as many combinaisons as possible.
How can I store all theses values, and moreover, how can I create a model using some FK that deletes all its child when a parent object is deleted. I mean, since the childs can be stored in various tables, there's no way I can put a simple FK on the parent's field.
Thanks ;)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你读了太多面向对象的书，却没有一本关于关系数据库的书。首先将数据建模为数据。确保满足您的所有数据要求（根据您的问题）。然后根据实体对对象进行建模。
SO 有数百个相同的问题，由到达 完全相同的障碍。不同的表和列名称，但相同的问题。福勒把你们所有人都带到了这里。
为了仔细检查您的数据并提供有用的答案，我们需要查看您的 DDL 或类图或您拥有的任何内容。
You've read too many OO books and not one RDB book. Model the data, as data, first. Ensure all your data requirements (as per your question) are satisfied. Then model your objects after the entities.
There are hundreds of identical questions on SO, by people who have arrived at the exact same obstacle. Different table and column names, but the same identical problem. Fowler brought all of you here.
To examine your data closely and provide a useful answer, we need to see your DDL or class diagram or whatever you have.
只是我的意见，但看来你可能过于笼统了。
因为正如所描述的，听起来像是两张桌子。一张“事物”表，以及将“事物”链接到其子项的交叉引用。如果是这种情况，外键的“ON DELETE CASCADE”子句就可以解决问题。
Just my opinion, but it seems you may be overgeneralizing.
Because as described, it sounds like two tables. A table of "things", and a cross-reference that links a "thing" to its children. If this is the case, the "ON DELETE CASCADE" clause of the foreign key will do the trick.