我已经研究过这个没有尽头。我并不是唯一一个提出这个问题的人......但我希望你对最佳实践有所了解。
我试图设计一个跟踪金融交易的数据库。为简单起见，每个事务只能有一个类别，每个类别只能有一个子类别。
我有一个自引用表，如下所示：
Table: Categories
ID, int, primary key
parentID, int, foreign key
description, text
长话短说，你最终会得到这样的数据：
1 Auto [null]
2 Bills [null]
3 Healthcare [null]
4 Maintenance 1
5 Gasoline 1
6 Cell Phone 2
7 Rent 2
8 Prescriptions 3
9 Dentist 3
到目前为止，这么好。 这是我的问题：
我不知道我应该将这一切全部反馈到我的交易表中的正确方法。 ＆＃39;交易＆＃39;有一个列＆＃39;类别＆＃39;和＆＃39;子类别＆＃39;。 Transaction.ID将是PK，而Categories.ID将是FK。
对于以上述方式与类别相关的交易，这意味着类别中的任何值都可以写入类别或子类别......
作为程序员，我是否有责任通过表单控制对表的访问？换句话说，我唯一的选择是以编程方式控制＆＃39;什么进入Category和Subcategory列？
请记住，每个类别只能有一个子类别。所选类别应仅允许该类别的孩子......
我有道理吗？
好的：自动维护 坏：医疗保健 - 汽油
答案 0 :(得分：1)
您提出的案例是在关系表中编码分层数据，树结构的更一般问题的子集。自从关系数据库在20世纪70年代末首次出现以来，这个案例已经进行了非常详细的研究。
特别是在簿记系统中，每次都会出现子类别和类别的概念。较大规模的工业系统往往具有四级系统，具有整体帐户类型（费用），类别（运输），子类别（汽车）和子子类别（汽油）。
如果您使用以下搜索词，您的研究可能会更有成效：“关系设计中的树结构”。该搜索产生了以下维基百科摘要：
http://en.wikipedia.org/wiki/Hierarchical_database_model
您可以在此处找到许多相关问题和答案。在“嵌套集”或“邻近列表”下搜索几种技术。
您的问题将是简化您将找到的答案，只有两个级别：类别和子类别。
我认为您选择的任何设计都需要明确规定以下规则：子类别确定类别。 IMO，您希望DBMS强制执行此规则，以便任何事务都不会以与其类别不一致的子类别结束。
答案 1 :(得分：0)
因此，您的分类不是正交和独立的（例如性别和城市），而是等级的（例如州和县）。
为了强制执行分层分类，请使用单个分类表，其中ID列作为主键，在数据表中作为外键引用，以及两个描述性字段Category和Subcategory。
为方便数据输入，您可以提供一个组合框类别，用于过滤可用的子类别。但是，实际的外键引用由子类别组合框中的选择提供，该组件框必须列出字段，类别和子类别。通常将这两个字段与分隔符（如短划线（ - ）或管道（|））连接起来。