数据库新表名称可以有横岗和竖岗吗

数据库建表有两种方式，横表和竖表。

横表是常用的，比较通用的建表方式。

但是有些场景用横表不太合适。

比如问卷调查，存储用户的回答，就不太方便使用横表。因为每一次问卷调查，题目数量都不相同。

又比如，配置选项，就不太适合横表，因为配置项随时都可能变化。

这个时候，就可以考虑使用竖表来存储。

横标的优点：横标的有点事显示的较为清晰直观，同时在字段的选择上更为科学合理，具体的字段可以根据具体情况划分字段类型。

横标的缺点：不方便扩展和公用，也就是说设计了一张横标，只能在固定的某一种特定的相对不变的场景下使用，比如加字段，或者类似的业务想公用一张横表，都有局限。

竖表的优点：最大的特点是可以灵活扩展存储的内容，同时具有一定的公用性。因为竖表的存储结构不受字段个数的限制，可以存储具有一定共性的业务数据。

竖表的缺点：竖表的字段类型要兼容，比如横标可以根据具体的值设计成varchar，decimal，datetime等，横标为了兼容以上字段类型，只能设计成varchar的，可能会浪费一定的空间。

横表就是普通的建表方式，如一个表结构为：主键、字段1、字段2、字段3。。。 如果变成纵表后，则表结构为： 主键、字段代码、字段值。而字段代码则为字段1、字段2、字段3。 具体为电信行业的例子。以用户帐单表为例一般出账时用户有很多费用客户，其数据一般存储为：时间，客户ID,费用科目，费用。这种存储结构一般称为纵表，其特点是行数多，字段少。纵表在使用时由于行数多，统计用户数或对用户进行分档时还需要进行GROUP BY *** 作，性能低，且 *** 作不便，为提高性能，通常根据需要将纵表进行汇总，形成横表，比如：时间、客户ID,基本通话费、漫游通话费，国内长途费、国际长途费....。通常形成一个客户一行的表，这种表统计用户数或做分档统计时比较方便。另外，数据挖掘时用到的宽表一般也要求是横表结构。纵表对从数据库到内存的映射效率是有影响的，但细一点说也要一分为二：纵表的初始映射要慢一些；纵表的变更的映射可能要快一些，如果只是改变了单个字段时，毕竟横表字段比纵表要多很多

这个问题的核心点在于：不同商品类别差异很大，如何设计通用的存储方案？简单来说，用数据库去存储所有信息，不管横表还是纵表，都有明显的缺陷：横表：同一个字段对不同商品含义不一样，这到了后面开发和维护是很蛋疼的纵表：一个商品的属性分布到很多行记录中，业务处理很麻烦，而且纵表的记录数会非常多，性能会有问题所以不要尝试只用数据库去统一解决这个问题，思路扩散一些其实就简单了：公共表：提炼商品公共的信息放到数据库，例如商品id、名称、发布的商家、发布日期、上架状态扩展表：将变化的信息放到另外一个表，可以是数据库表，例如电脑商品一个表、服装一个表；也可以将信息放到MongoDB或者ElasticSearch这类文档数据库。搜索组件：扩展表在全文搜索的时候不好实现，因此需要独立的组件负责搜索，可以用Elastic Search或者Solr来冗余一份数据，用于搜索。表结构不算复杂，因为项目关系只有SPU，没有涉及到SKU，但是可以做参考，更多的还是要根据项目实际情况设计。重点说明一下产品表的SPU，Keyword字段。本来之前设计了关系表，但是发现在做SQL查询时太痛苦，所以约定了一种数据存储结构（数据结构的重要性）基于上面的基础，可以实现URL规则变化的查询,类似京东的产品查询URL变化c=1,3 指分类层次关系ev=3_1+4_18 指SPU查询 按约定规则转换成字符串再进行查询。

---