此数据库设计选择违反哪种正常形式或其他正式规则？

Question

我正在开发的项目是一个应用程序，它允许您设计数据输入表单，并在底层PostgreSQL数据库中自动生成模式 坚持使用它们以及浏览和编辑UI。

我遇到的用例是商店后台数据库，但应用程序本身有点普遍。管理员使用给定字段创建以下输入表单：

• 客户
  • 名称（文本框）
• 产品
  • 名称（文本框）
  • stock（数字字段）
• 订单
  • 客户（选择客户的组合框）
  • 订单行（显示订单行的网格）
• 订单行
  • item（选择项目的组合框）
  • count（数字字段）

完成所有这些后，生成的数据库架构将等同于：

create table Customers(id serial primary key,
                       name varchar);
create table Items(id serial primary key,
                   name varchar,
                   stock integer);
create table Orders(id serial primary key);
create table OrderLines(id serial primary key,
                       count integer);
create table Links(id serial primary key,
                   fk1 integer references Customers.id,
                   fk2 integer references Items.id,
                   fk3 integer references Orders.id,
                   fk4 integer references OrderLines.id);

Links是一个存储实体之间所有关系的特殊表;每行（通常）有两个外键设置为一个值，其余的设置为NULL。每当将新的条目表单添加到应用程序实例时，引用此表单的表的新外键将添加到Links。

所以，假设我们的商店有一些小部件， gizmos 和 thingeys 。名为 Adam 的客户订购了两个小部件和三个小玩意儿，而 Betty 订购了四个小玩意儿和五个小玩意儿。该数据库将包含以下数据：

客户

/----+-------\
| ID | NAME  |
| 1  | Adam  |
| 2  | Betty |
\----+-------/

产品

/----+---------+-------\
| ID | NAME    | STOCK |
| 1  | widget  | 123   |
| 2  | gizmo   | 456   |
| 3  | thingey | 789   |
\----+---------+-------/

订单

/----\
| ID |
| 1  |
| 2  |
\----/

OrderLines

/----+-------\
| ID | COUNT |
| 1  | 2     |
| 2  | 3     |
| 3  | 4     |
| 4  | 5     |
\----+-------/

链接

/----+------+------+------+------\
| ID | FK1  | FK2  | FK3  | FK4  |
| 1  | 1    | NULL | 1    | NULL |
| 2  | 2    | NULL | 2    | NULL |
| 3  | NULL | NULL | 1    | 1    |
| 4  | NULL | NULL | 1    | 2    |
| 5  | NULL | NULL | 2    | 3    |
| 6  | NULL | NULL | 2    | 4    |
| 7  | NULL | 1    | NULL | 1    |
| 8  | NULL | 2    | NULL | 2    |
| 9  | NULL | 2    | NULL | 3    |
| 10 | NULL | 3    | NULL | 4    |
\----+------+------+------+------/

（这些表还包含一堆用于审核和软删除的时间戳，但我不认为它们与此相关，它们只是让管理员编写的SQL更加混乱。管理应用程序是还用于实现一堆不同的用例，但它们通常主要是数据输入，主 - 详细视图以及标量字段或选择框。）

当我必须通过这件事写一个联接时，我会向我的同事发牢骚，他回答说＃34;好好为每个关系使用单独的表是一种方法，这个是另一个......＆＃34;撇开上述明显的丑陋和实际问题，我也有一种唠叨的感觉，这 是违反某种正常形式的，但它已经有一段时间了。从大学开始，我就在努力弄清楚这里适用的标准。

是否有更强大的东西＆＃34;那只是你的意见＆＃34;我可以在评论这个设计时使用吗？