Database 数据库设计-系统默认项和自定义用户项

此问题适用于任何数据库表设计，在这种设计中，系统默认项和自定义用户默认项的类型相同（即用户可以添加自己的自定义项/设置）

这是一个发票和付款类型的示例，默认情况下，发票可以有DueonReceive、NET10、NET15、NET30等付款条件（这是所有用户的默认设置！），因此您将有两个表“发票”和“付款条件”

现在，允许用户存储自己的自定义“PaymentTerms”的最佳方式是什么？为什么？（即用户可以使用系统默认付款条件或用户自己创建/添加的自定义付款条件）

选项1）将UserId添加到PaymentTerm，为添加自定义项的用户设置UserId，并将系统默认UserId设置为null

INVOICE
Id
...
PaymentTermId



PaymentTerm
Id
Name
UserId (System Default, UserId=null)

选项2）向发票“IsPaymentTermCustom”添加一个标志，并创建一个自定义表“PAYMENT\u TERM\u custom”

现在通过SQL查询检查用户是否使用自定义付款条件，如果IsPaymentTermCustom=True，则表示用户正在使用自定义付款条件，否则为false

选项3）

…作为一般规则：

• 与添加表相比，更喜欢添加列
• 与添加列相比，更喜欢添加行

一般来说，考虑因素包括：

添加表的效果

• 需要对应用程序进行最多更改：您正在支持一种新的“东西”
• 需要更复杂的SQL：您必须以某种方式加入它
• 可能需要更改其他表以添加引用新表的外键列
• 影响性能，因为需要更多的I/O连接到新表并从中读取

请注意，我不是说“从不添加表”。只要知道成本

添加列的效果

• 如果表很大，则添加列的成本可能会很高（完成

  altertableaddcolumn

  可能需要数小时，在这段时间内，表将被锁定，从而有效地“关闭”站点），但这是一次性的
• 项目成本低：易于编码/维护
• 通常需要对应用程序进行最小的更改-这是一个事物的新方面，而不是一个新事物
• 性能差异可以忽略不计。不会变得更糟，但可能会更快，这取决于具体情况（如果使用新列可以避免连接或昂贵的计算）

添加行的效果

• 零：如果您的数据模型可以通过添加更多行来处理您的新业务想法，那么这是最好的选择

（学究们请避免发表评论，如“没有‘零’影响”或“但仍将有更多磁盘用于更多行”等-我指的是对DB/项目/代码的重大影响）

回答以下问题：选项1最好（即在付款选项表中添加一列）。
推理基于上述指南，这种情况非常适合这些指南

此外，
我还将“标准”支付选项存储在同一个表中，但使用

NULL

userid；这样，您只需在真正拥有付款选项时添加新的付款选项，而不是为每个客户添加新的付款选项，即使他们使用标准的付款选项

---

这还意味着您的发票表不需要更改，这是一件好事-这意味着对应用程序的这一部分影响最小。

在我看来，只有“付款条件”和“用户”。决定什么是“默认”付款条件是一个业务规则，因此最好在应用程序的业务层中进行表示

假设您希望从一开始就在应用程序中存在一组预定义的“默认”付款条件，那么这些付款条件表中已经存在了。但是，我会在用户和付款条件之间放置一个参考表：

USERS:
    user-id
    user_namde

USER_PAYMENT_TERMS:
    userID
    payment_term_id

PAYMENT_TERMS:
    payment_term_id
    payment_term

您的业务层应通过GUI向用户（或更可能是管理员）提供以下功能：

将0分配给特定用户（某些用户）的多个付款条件选项 例如，用户可能不希望其中一个默认值可用 例如

添加自定义付款条件，然后可将其分配给一个或多个用户（但可避免不同用户创建重复的付款条件）

允许将自定义付款期限的定义分配给多个用户（例如用户的公司）一个唯一的付款流程，该流程要求所有用户使用默认付款期限以外的付款期限？创建自定义期限一次，然后分配给所有用户

您的应用程序业务层将建立规则来管理对付款条件的访问，然后您的用户界面可以访问这些规则

然后，您的UI（同样，可能通过管理员功能）允许在您描述的标准之外设置一个或多个付款条件，然后通过复选框（例如）使一个或多个用户可以使用这些付款条件。

---

在我看来，问题的一部分是，不同的付款条件也会导致不同的计算。如果我仍然从事焊接供应业务，我想加上“2%10净价30”，如果在10天内全额付款，这意味着2%的折扣，否则，净价30。”

撇开这个问题不谈，我认为支付条款的所有权是有意义的。假设用户表（未显示）包括用户“系统”，例如用户id 0

create table payment_terms (
  payment_term_id integer primary key,
  payment_term_owner_id integer not null references users (user_id),
  payment_term_desc varchar(30) not null unique,
);

insert into payment_terms values (1, 0, 'Net 10');
insert into payment_terms values (2, 0, 'Net 15');
...
insert into payment_terms values (5, 1, '2% 10, Net 30');

这使得外键保持简单，并且可以很容易地在运行时选择付款条件，以便在用户界面中显示

在这里要非常小心。您可能希望在发票中存储描述，而不是ID号。（它是唯一的；您可以设置对它的外键引用。）如果您只存储ID号，更新用户的自定义描述可能会微妙地损坏所有数据

USERS:
    user-id
    user_namde

USER_PAYMENT_TERMS:
    userID
    payment_term_id

PAYMENT_TERMS:
    payment_term_id
    payment_term

create table payment_terms (
  payment_term_id integer primary key,
  payment_term_owner_id integer not null references users (user_id),
  payment_term_desc varchar(30) not null unique,
);

insert into payment_terms values (1, 0, 'Net 10');
insert into payment_terms values (2, 0, 'Net 15');
...
insert into payment_terms values (5, 1, '2% 10, Net 30');