开发者学堂课程【Java面试疑难点串讲2：Java数据库开发：数据库设计】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/25/detail/543
数据库设计
一张基础表 dept，100 张单据表用到了 dept 中的 deptno，对于 100 单据表都去设置外键参照 dept 表，对于中小型系统来讲，在数据库中表结构设置这种关联关系，对开发有益；
如果数据量不大，那么所有正确的涉及思想都是可以正常发挥的。所有可以使用的
查询，所有可以不进行费劲的操作。
例如:最坑的设计:“编程语言+存储过程”。
对大型系统 ERP 系统(比如用友、金蝶)，每张表引入这种关联关系，实在是太恐怖了，我的想法是在更新的时候，在前台和业务层校验它 deptno 代号的合法性之后，存入表中，这样是不是会更好？
那么此时最大的问题在于系统的可控性上。假如以一个商城为例:初期发展，每天只
有三个订单，这个时候的系统吞吐量不大，那么怎么设计都可以
后来随着推广的力度加强，我要组织一个“1313活动”，突然一天的订单量爆
满:10000000单
但是不管怎么折腾，单数据库根本折腾不了多久。
也就是说单数据库的开发只能够给我们提供一种基础的锻炼，相当于你开发经历
第一层。
随后你需要考虑到数据表的性能，以及系统的拆分问题。
如果要进行数据变得拆分，那么这些所谓的关联关系、事务处理，而这种拆库拆表的操作就成为库表分离，又有两种拆分的模式:水平拆分、垂直拆分、垂直水平拆分。
假如说订单表的数据量很大，于是将这些订单表拆分为十个数据库的表，那么每个数据库的表只保存10%的数据
另外一个是进行垂直拆分操作，那么就将数据表有一张表拆分为多张表；
如果两者的结合，那么就变为了:商城系统。
l 用户数据库；
l 订单数据库；
l 水平拆分10个数据库；
l 库存数据库。
这个时候看起来这些问题都可以很好的解决。但是同时也需要知道另外一个问题:如果将系统分库了，实际上是将系统拆分为若干个子系统的过程，那么这若干个子系统之间的沟通以及控制的问题也就出现了。
图书管理的思想＝性能的调整思想。
