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

精选留言(4)

• 

  BigSpinach

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

  作者回复: 可以这样理解，不过，如果 BOOK_ID 和 CATEGORY_ID 组成联合主键，那么这个 BOOK_NAME 依赖于另外的那半个“部分主键” BOOK_ID

  2019-11-17

  

  
• 

  Mandalorian

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

  作者回复: 就是通过这两级联合起来构成主键。例子的话，你可以看一下 https://aws.amazon.com/blogs/database/using-sort-keys-to-organize-data-in-amazon-dynamodb/ 这里面有几个例子，比如 deviceId 是 partitionKey，而 timestamp 是 sortKey，可以存在 partitionKey 相同而 sortKey 不同的数据。

  2019-11-13

  

  
• 

  Middleware

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

  作者回复: 👍，如果没有特殊原因，借阅表和归还表可以合并。

  2019-11-07

   1

  
• 

  leslie

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

  作者回复: 👍，不过关于其中的 2) 拆分得不完整：把 borrow_date、return_date 可以拆到另外一张借书关系表里面去，因为对于同一本书，book_name 这样的信息不应该出现超过一次：
  
  图书信息表：
  book_id / book_name
  
  借书关系表：
  book_id / borrower_id / borrow_date / return_date

  2019-11-06

  

  