Vyr*_*tek 15 database-design saas
我有很多表使用Lookup/Enum引用来表示大多数列值.例如:
Person Table - PersonID | RaceCode | HairColorCode | HairStyleCode | TeethConditionCode
位置表 - LocationID | SizeCode | ExteriorColorCode | ConditionCode
Race,Size,Color,Condition等之类的东西只是代码查找表的外键引用.此代码表包含其他字段,但对我的问题并不重要.该数据库用于SaaS应用程序,这意味着每个客户端都可以拥有自己的颜色,种族,条件等列表.有些代码是静态的,客户端无法更改.
拥有1个代码表或2种类型的代码表(DynamicCodeTable用于客户定义的代码表和StaticCodeTable用于那些更改的代码表)或者我应该为每种代码类型(RaceCodeTable,HairColorTable,Condition等)提供表格更好吗？
我最担心的是所有sql连接.我正在使用的Person表有20多个这些代码属性.加入20个不同的表VS连接到同一个表20次时,性能是否有差异？拥有多个表意味着每个表都会更小,查找"应该"花费更少的时间.但是拥有一张桌子也很快.有什么建议？
Wal*_*tty 24
在过去的十五年里,在"One True Lookup Table"(缩写为OTLT)的主题下,对该主题进行了详细讨论.这种方法的优点跃向数据库新手.随着时间的推移出现了缺点.有关OTLT缺点,请参阅以下链接:
或搜索为OTLT找到更多的讨论.
如果为它们创建了许多查找表和许多维护屏幕,则可以创建一个模拟OTLT的视图,方法是创建一个巨大的UNION,其中包含存储代码描述对的表的每个代码,每个描述和表的名称. .如果您知道自己在做什么,就可以使用半自动方法生成这样的联合.我认为半自动方法可以让你为数百个查找表构建一个维护屏幕,然后在该屏幕和表格之间放置一些逻辑,这些表格会在正确的表格中插入新代码.
至于让用户引入新的代码TYPES,而不仅仅是新的代码VALUES,它打开了一大堆蠕虫.参见上面讨论EAV的文章.这非常诱人,因为它允许用户设计自己的底层数据结构.如果你忽视性能,这种方法很有效.无需从用户或主题专家那里学习数据结构,您就可以获得完美的通用数据库.
当它遇到真正的悲痛时,你会尝试使用数据,就好像它是一个集成的数据库,而不仅仅是对数据的脱节观点.此时,当您的客户期望生成例行报告时,您将进入一些严肃的数据考古学.祝好运.
(编辑将"数据挖掘"改为"数据考古学")