25 | 设计数据持久层（上）：理论分析

只满足第一范式 可以拆分s三张表 user表 user_id user_name book 表 book_id book_name user_book关联表 user_id book_id borrow_date return_date

老师的扩展阅读确实不错：强化和补充了不少知识，对于进一步学习和提升以及真正掌握知识的这块还是蛮有用的；希望老师能在这个环节更好的分享一些东西，谢谢。 下面来回答今天的问题：其实问题非常典型-两张表的东西放在了一张表里。另外指出老师在提供表时所疏漏的一点，字段名没有注释，实际工作中字段名没有注释一律不让通过-生产系统想都不要想上；DBA会明确告诉开发，注释写好了再发过来。开发手上其实都是DBA给的相关要求，不达要求不要发过来，合规了才给上。 根据字段名只能大致猜测：应当拆分成用户表和用户使用表。具体做法如下： 1）user_id、user_name作为用户基本信息表，当然这张表可能还会有一些其他的基本信息；如：phone 手机号码 address 用户住址之类的等等信息； 2）book_id,book_name,brrow_date,return_date作为用户借书表，这张表追加一个userid与用户基本信息表关联。 这个应当是正确的设计方式：至于范式这块我就不解释了；正确的拆分我是给出了。范式的概念不光在表的设计有，索引的设计同样有；实践中修正久了就成习惯了。 其实键值数据库和文档数据库其中不少思想还是借鉴了关系型数据库，不然不会出现大量的no sql数据库支持类sql。基于sql 的一些缺乏灵活性上的改变而已。

感觉第三范式举得那个例子，也可以这么理解，BOOK_ID和CATEGORY_ID组成联合主键，这样CATEGORY_NAME只依赖于部分主键，这样它也不符合第二范式，不知道这样理解对不对？

索引的数量是有着明确限制的，一种是全局的（相当于 Partition Key + Sort Key），每张表上限 20 个；一种是本地的（相当于 Partition Key 已经确定，只通过 Sort Key 索引），每张表上限 5 个。 Partition Key + Sort Key 上限20个，不太明白，怎么样算一个啊？可以举例说明吗，谢谢。

如果设计的话，可能差分成四张表 1：用户表（用户id、用户名） 2：图书表（图片编号、图书名称） 3：借阅表（图书编号、用户编号、借阅时间） 4：归还表（图书编号、用户编号、归还时间） 当然实际情况字段可能不止这些

答：只满足一范式 拆分成3个表 user_id | user_name book_id | book_name user_id | book_id | borrow_date | return_date