数据表设计深入浅出

我不是女神ヾ 2022-09-09 14:53 159阅读 0赞

### 数据库表到底该怎么设计 ###

*  前言
 *  一、数据库表？
 *  总结

--------------------

# 前言 #

我这里提到的数据库表的设计，涉及到你的业务表该怎么组织，该怎么设计，该怎么冗余字段等等，但是这些都是我个人的观点，欢迎有不同的观点在留言区和我讨论

--------------------

# 一、数据库表？ #

数据库表，按我理解大体上分为基础信息表，业务表。基础信息表是一些基础的信息服务表，业务表或多或少都会用到，业务表其实就是在基础信息基础上抽象出来的一种业务形式，是在基础信息上的一种抽象。  
基础信息表：商品表：

CREATE TABLE `sku_tab` (
      `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
      `sku_id` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
      `category_id` int(10) unsigned NOT NULL,
      `name` varbinary(1024) NOT NULL DEFAULT '',
      `is_sn_mgt` tinyint(3) unsigned NOT NULL DEFAULT '0',
      `description` blob,
      `images` varchar(1024) COLLATE utf8mb4_unicode_ci NOT NULL,
      `country` char(4) COLLATE utf8mb4_unicode_ci NOT NULL,
      PRIMARY KEY (`id`),
      UNIQUE KEY `sku_id` (`sku_id`),
      KEY `idx_country` (`country`),
      KEY `idx_sku_name` (`name`(767)),
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

业务表: 某明细表：

CREATE TABLE `order_item_tab` (
      `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `cc_order_id` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
      `sku_id` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
      `sku_name` varchar(1024) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
      `location_id` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
      `is_sn_mgt` tinyint(3) unsigned NOT NULL DEFAULT '0',
      `qty` int(10) unsigned NOT NULL DEFAULT '0',
      `ctime` int(10) unsigned NOT NULL DEFAULT '0',
      `mtime` int(10) unsigned NOT NULL DEFAULT '0',
      PRIMARY KEY (`id`),
      KEY `idx_cc_order_id` (`cc_order_id`),
      KEY `idx_location_id` (`location_id`),
      KEY `idx_sku_id` (`sku_id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

这里是个很典型的反面例子，这里冗余了基础信息服务的sku信息：sku\_id、sku\_name、is\_sn\_mgt。  
优势：在页面上搜索sku\_id、sku\_name、is\_sn\_mgt这些信息时不用再去基础信息表查询了。  
劣势：一旦基础信息服务更改sku\_name、is\_sn\_mgt这些信息，由于不会来更新这些业务表，就会出现页面搜索不到的情况。  
这里：  
因为sku\_id 是有唯一键的，所以注定不会再被更改，所以这个业务表冗余sku\_id是没有问题的，  
但是sku\_name 和 is\_sn\_mgt没有唯一键是可以被更改的，这里冗余了，那么一旦基础信息服务sku那边更改了sku\_name 或者 is\_sn\_mgt，那么业务这里就会出现搜索不到的情况出现。  
可能你会说，这里冗余也没问题啊，当基础信息服务更改时同步这些业务表一起更改相应的信息啊。这样更不可行，首先业务表有那么多，是不是基础信息一更改就同步修改所有的业务表信息啊，而且业务表和基础信息是属于上层对下层的关系，下层的更改不可以直接调用上层跟着去修改的。  
那么问题来了到底该怎么选择设计表？  
当业务表搜索框有些基础信息要搜索时，比如sku\_id 比如sku\_name，如果要搜索的这个基础信息在原表中这里是sku表里属于唯一的，那么可以大胆放心的冗余，但是如果要搜索的这个基础信息比如sku\_name在原表中不是唯一的，可以更改，那么我觉得就不适合冗余了。  
这是个设计问题，也是哲学问题，到底选择冗余还是不冗余要根据自己的业务来的。

# 总结 #

数据表的设计是很重要的，因为数据库设计不好，你写代码就会写的不是很舒服，这里需要你好好思考该怎么设计数据库表。