我有几种类型的用户:拳手,裁判,观众,推广人,LOCATION_PROVIDER。它们都有一些参数,有些是常见的,有些是特殊的。我认为,为每种类型的用户创建一个单独的表是合乎逻辑的。每个这样的表将只存储与特定类型的用户数据相关的数据。
我可以从这里的文档中看到:
https://github.com/typeorm/typeorm/blob/master/docs/entity-inheritance.md
TypeOrm提出了一些暗示继承的解决方案,但它们都是为了减少代码量。例如,名为单表继承的模式允许在代码方面对实体进行一些分离,但是所有类型的用户都将被转储到单个表中,从模式的名称可以明显看出这一点。其他的解决办法对我来说也没有更好。
我正在考虑创建一个表users
来存储公共数据,然后创建所有其他表来存储特定类型的数据。
例如,
user
有first_name
,second_name
,age
等域。
fighter
有weight
、wins
、losses
、draws
等字段。
但问题是这些表碰巧是不相关的。这是否意味着我需要编一些逻辑来使它们相关?我不知道该怎么做才好。
对这类问题最好的回答是:看情况。说真的,这取决于您将如何访问数据以及堆栈的哪一部分对您更重要。如果您将处理用户,而不考虑他们的类型,并将他们一起查询,那么将他们放在一起是有意义的。但是,如果每个类型都将被单独访问和处理,那么最好将每个具体类型保存在它自己的表中。
我通常通过考虑以下情况来处理这些问题:
-
数据库设计是最重要的,应用程序是始终运行的每次只支持一种用户类型
如果你想专注于数据库的设计,让我们说一个规范化的模式,你的应用程序更有可能只操作一种用户类型,在这种情况下,我会添加一个
user
表,是一个"root"它有user_id
和其他一些常见的个人信息栏。对于其他具体类型的用户,我将在user
表user_id
列中添加一个带有外键的单独表。 -
从数据库的角度来看,我可以忍受不完美的设计,应用程序将同时在不同的用户类型上运行
在这种情况下,添加一个
user
表,其中包含所有可能的类型特定列,当然这些列将是可空的。除了必需的常见列,如first_name
, 'last_name'等…您需要一个列来告诉您用户的类型。你可以创建一个单独的表user_type
(1 -战斗机,2 -法官等),并从user
表引用它,或者你保持简单,只保存一个字符串" Fighter ", " Judge "直接在user
表中,并在应用程序端使用一些enum
类型来处理它。
我通常更喜欢第一个选项,因为它更合乎逻辑,更干净,但如前所述,这取决于您的最终用例。