activity 的数据库架构与许多实体相关
Database schema for activity related to many entities
如何为数据库中的活动构建良好的模式？
一个 activity 可以与 50 个不同实体之一相关。
目前我只看到 3 个解决方案：
Table "activity" 包含 50 个带有其他实体外键的列。
这导致table非常大，我不喜欢。
每个实体都有自己的"activity"-Table。
此解决方案使我的数据库中的 table 几乎翻了一番，但更清晰。仍然不是最好的解决方案。
肮脏的："activity"-table 包含一个 "entityType"-列，其中包含实体-table-名称和另一个 "entityId"-带有实体 ID 的列。
但是这个解决方案破坏了所有外键并允许在我的 activity table.
[=37 中存储垃圾数据=]
也许你们中有人构建了 CRM 并且不得不面对同样的问题。
有没有人有更好更干净的解决方案？
就像我看到的，只有一个决定要做。第一种和第二种可能性很好，因为保持了数据库的一致性。就我而言，我决定使用 1. 可能性。
如何为数据库中的活动构建良好的模式？ 一个 activity 可以与 50 个不同实体之一相关。
目前我只看到 3 个解决方案：
Table "activity" 包含 50 个带有其他实体外键的列。
这导致table非常大，我不喜欢。
每个实体都有自己的"activity"-Table。
此解决方案使我的数据库中的 table 几乎翻了一番，但更清晰。仍然不是最好的解决方案。
肮脏的："activity"-table 包含一个 "entityType"-列，其中包含实体-table-名称和另一个 "entityId"-带有实体 ID 的列。
但是这个解决方案破坏了所有外键并允许在我的 activity table.
[=37 中存储垃圾数据=]
也许你们中有人构建了 CRM 并且不得不面对同样的问题。 有没有人有更好更干净的解决方案？
就像我看到的，只有一个决定要做。第一种和第二种可能性很好，因为保持了数据库的一致性。就我而言，我决定使用 1. 可能性。