关于关系数据库模式的建议

Question

我正在为一家企业设计一个数据库，该数据库销售全球各种活动的门票。我不是专家（尚）在模式设计&寻找关于我迄今为止（关于表和主要/外部关键用法之间的关系等）的任何反馈/建议。

全尺寸（更易于阅读）在此链接，

http://s11.postimg.org/5x7t7ptpf/TF_schema2_Page_1.jpg

Answer 1

从字符串类型的外键望而却步。 EVENT_CATEGORIES和EVENT_SUB_CATEGORIES可以是一个表格。我会避开直接关联的类别和扩展事件信息，如TEAMS_ARTISTS;你可能更喜欢将更具体的表（如单独的TEAMS和ARTISTS表）分别与事件关联起来，并仅使用该类别来允许前端UI控制哪些细节可能与事件相关联。

而不是单独的团队艺术家等...表，你可以有一个像ASSOCIATED_ENTITIES表和ENTITY_TYPES表的东西。类型表中有诸如：“Artist”，“Team”，“Promoter”，“Vendor”等等...... （虽然我可能不会使用“ENTITY”这个词，因为它带有很多精神包袱）