请教数据库主外键关系表设计问题

Question

数据库中有主外键关系的表一般怎么设计更合理？表建立的越多，分得越细好，还是差不多就行？还是怎么地？例如现在有个服装销售记录表，里面有诸如服装类型、款式、尺寸、颜色、产地等等可分类维护的字段，是否需要一个个建立对应的服装类型表、尺码表、颜色表等，建立多，给用户的自由化程度就高，可以自己定义各种所需的信息，但是表多了，查询起来七八个表联立查询，结果集是各表记录数的笛卡尔积，数据量大的情况下很影响效率的，如果都定义死，用户就不能自定义添加修改，这样的东西一般怎么设计好呢，请各位高手指点，谢谢

Answer 1

建立维表，维护起来更方便,程序应用更灵活。如果是为了解决查询效率，可以建立视图，视图中把你需要的字段返回，不需要select * from 。。

Answer 2

服装类型、款式、尺寸、颜色、产地
放在一个表，那么这个表的数据量肯定会很大，而且一种服装要维护几条记录，分开后，维护基础数据，然后关联就可以了。但是我想最后的关联表的记录和一个表的记录的样式是一样的，只是后者是很多的外键（id）而已。
后者要对很多的表进行关联。但是可以使数据更精确，比如尺寸原来是用A作单位的，现在统一改成B做单位，那么后者只要改基础表（尺寸表）中的记录即可，而前者要修改所有的记录。当然这只是随便举个例子，总的来说，还是分开好点吧！方便维护。

Answer 3

这些服装类型、款式、尺寸、颜色、产地 若非常重要的话还是建议维护在一个表中。若有些内容只是就几种类型，则用LIST维护即可。。比如 男装，女装，童装， 类型无非几种，就没必要进行
建立表进行维护了。
所以总之,类型少且固定的可不需要建立表，经常变更且没规律的则不建表，手工录入。对于必须要求进行管理的服装必要属性，则可进行用表建立。

Answer 4

感谢楼上几位的指点，现实中为了照顾客户的自定义，当然希望都设置成单独的表，自行维护灵活，但是当表服装销售表记录到一定量的时候（一般的服务器几十万数据就有点延时了），七八个表的联立查询，即便建立视图，就是只取需要的字段，也有延迟的（人为能感觉出来那种），看一些设计技巧提到，一般联立表最好不要超过三个，保持效率。建立list是个方法，但对于类似品牌、尺码、颜色、产地等需灵活设置的就不太实用了；如果都放在一张表貌似不好取吧？联立查询的时候，主表（销售记录表中保存的都是外键ID）展示的是各类型的名称，而不是ID哦，通过程序倒是可以实现，但是分开存储的话一条sql语句联立查询就搞定结果了（数据多了虽然慢），现在问题不是功能实现不了，而是，这看似矛盾的两个方面（表多灵活可维护性好，速度慢；表少灵活性不够，速度快）怎么平衡呢？