数据库设计 - 授权访问时，所有必需信息与执行连接的键存储密钥

发布于 2025-01-21 10:14:03 字数 594 浏览 1 评论 0原文

在考虑“公司”是否可以访问有关“客户”的信息时，以以下示例（仅伪代码）进行以下示例。我可以将FK引用存储到所有内容[选项B]中，该引用可以扩展以存储大量参考，或者随着表的增长，或在查询[选项A]上执行加入以进行访问比较。

每种方法的好处和陷阱是什么？有更好的选择吗？

选项A

CREATE TABLE Company (
  Id,
  ...
)

CREATE TABLE Client (
  Id,
  CompanyId FK
)

CREATE TABLE ClientSale (
  Id,
  ClientId FK
)

选项B

CREATE TABLE Company (
  Id,
  ...
)

CREATE TABLE Client (
  Id,
  CompanyId FK
)

CREATE TABLE ClientSale (
  Id,
  CompanyId FK,
  ClientId FK
)

编辑

是否应该将其分解为更多表[Company_Client＆amp; clientsale_client＆amp; company_clientsale]？

原文

Take the following examples (Only pseudocode) when considering whether a "Company" has access to see information about a "ClientSale". Either I can store the FK references to everything [OPTION B] which could scale to storing a lot of references as the tables grow, or perform joins on Queries [OPTION A] in order to make the access comparisons.

What are the benefits and pitfalls of each approach? Is there an even better option?

OPTION A

CREATE TABLE Company (
  Id,
  ...
)

CREATE TABLE Client (
  Id,
  CompanyId FK
)

CREATE TABLE ClientSale (
  Id,
  ClientId FK
)

OPTION B

CREATE TABLE Company (
  Id,
  ...
)

CREATE TABLE Client (
  Id,
  CompanyId FK
)

CREATE TABLE ClientSale (
  Id,
  CompanyId FK,
  ClientId FK
)

EDIT

Should I break it down into more tables [Company_Client & ClientSale_Client & Company_ClientSale] ??

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

没企图 2025-01-28 10:14:03

DBMS的期望您的FKS将形成多层层次结构，如您所示。

根据选项B重复孙子表中重复FKS的缺点是您现在正在复制信息，更新时要做额外的工作以及出现异常的风险：您的代码可能CODE> UPDATE CLOUTION CLOUINAT CLINES SET COMPANYID = ...但忘记更新clientale where clientId = ...设置CompanyId = ...。另外，类似的协调更新将需要Commmit控件，以避免您的表脱离步骤。