主从表设计和编程

主从表操作是数据库相关编程中绕不过去的技术之一。为了减少数据冗余、满足数据库的范式要求，必需考虑建立主表和从表，从以外键关联。主从表可以看做是对母表进行纵向切割而得到的。

    由于表个数的增加，和外键关系的存在（“关系型数据库”的名称就是从这里来的吧？），使操作主从表比操作单表复杂了很多。编程的复杂度和工作量也成倍增加 - 至少增加了3倍。

    主从表从表设计和编程角度一般可以这么做：

 

    1，主表和从表分离，以外键关联(dedecms)。

    这是最常见和典型的做法，数据库理论的教科书上一般就是这么讲的。这样做的好处是，充分利用关系型数据库的优点，从表可以有多个字段，可以保存大量的数据和记录个数。而且由于客观上实现了表的纵向切割，使数据存储结构得到了优化。但由于牵扯到2个表，所以编程时，对表的编辑（增、删、改、查）总是涉及到二个步骤，还会引起主表和从表操作的原子性问题，即：主表数据操作完成后，同一个事务里，从表的关联数据操作是否也全部完成了？在一些关键行业的关键业务里，主从表操作必需以事务的方式来操作，主表和从表操作，要么全部完成，要么一个都不完成，只要其中一个出错，事务必需回滚到未操作前的状态（这一般是“事务”机制自动完成的）。所以编码考虑的因素很多。

 

    2，另一种变通的方法是，从表的数据存贮在主表同一条记录的另一个字段里，用分隔符连接起来。

    这样以来，不用建立主从表之间的外键关联 - 命存一线，本身就“关联”起来了。好处是编码简单。但会引起以下问题：
    （1）分隔符可能与保存的数据中的字符串重复，引起混淆；
    （2）当子表中的记录过多和/或过长的时候，显得愚笨，并会有存储上的问题；
    （3）不适合记录是二进制数据的从表。
    （4）从表的字段多于一个时，基本很难实现。

    既然是变通的方法，这种方法仅适合部分情况：从表数据类型一般是字符串型，且数据很短；从表记录很少，不需要通过建立索引来提高检索效率。从表的字段也必需较少，最好就一个字段，多于2个，编程的某些细节就反而复杂了。

    所以，无果有十足的把握，或确信从表不会再重构的情况下，才采用第二种办法。否则还是乖乖按照数据库理论来做，以减少可能发生的风险，保证项目进度。