关系数据库设计混乱，有没有更好的方法来关联表呢？

Question

我正在尝试创建一种非常基本的形式，例如关系数据库设计。

这个想法是有服务的卖家和服务的买主。

卖家可以提供超过1项服务。

买家可以购买超过1项服务（工作）。

一份工作可以有超过1名卖家在工作。

卖家可以从事一份以上的工作。

以下是我提出的设计。

问题是它似乎太麻烦了，例如，如果买家登录，那么我们将不得不通过所有服务表来获取他所购买的服务（工作），然后我们将不得不通过所有的sell_job_relationship为了获得所有卖家工作的ID，我们将不得不通过所有卖家表来获取有关所有卖家的信息。

那么有没有更好的方法将这些表链接在一起，还是它的工作方式？

这是我第一次尝试使用数据库，所以真的很困惑。

Answer 1

您的设计适用于关系数据库。

一些改进建议：

• 重命名＆＃34; services_provided_by_seller＆＃34;只是＆＃34;服务＆＃34;。卖方的提供是通过seller_service表定义的。不要使用复数形式的名称。

• 您可以删除＆＃34; _relationship＆＃34;后缀，在我看来没有任何好处。

• 您可以简化外键（FK）属性的名称：因此在＆＃34; seller_service＆＃34;打电话给他们＆＃34;卖家＆＃34;和＆＃34;服务＆＃34;或＆＃34; provided_service＆＃34;。在工作表＆＃34;买家＆＃34;足够了。因为它们是外键（并且在DB中以声明方式标记），所以它必须是id（FK总是引用PK =主键）。
  命名与FK所扮演的角色相对应的FK属性：例如，在 order 表中，您可能有三个FK全部到同一个 person 表：orderer，invoicee，consignee。

• 对于m：n关系表（seller_services和seller_job），您可以删除代理主键＆＃34; id＆＃34; - 从关系的角度来看不需要它 - 并且使用复合主键（id_seller + id_service，因为每个卖家可能只提供一次服务，我猜）。
  但请注意，某些持久性框架对这种主键的支持不足。

使用SQL和连接获取数据很简单。例如，获取买方的所有服务（＆＃34;？＆＃34;是参数）：

select s.service_name
  from service s
  join seller_service ss on (ss.service = s.id)
  join seller_job sj on (sj.seller = ss.seller)
  join job j on (j.id = sj.job)
 where j.buyer = ?
 order by s.service_name

或者只是在服务实体上使用WHERE子句：

select service_name
  from service
 where id in (
     select ss.service
       from seller_service ss
       join seller_job sj on (sj.seller = ss.seller)
       join job j on (j.id = sj.job)
      where j.buyer = ?)