就是 比方一个系统吧，有很多公司用户，每个公司用户也要填写专门属于他自己的表单吧，假设报税啊，记账啊啥的单据，
那就是所有的公司用户是一个表，然后账单表那边也是一个总表吗？就是带有公司id的账单总表？
如果业务量大的话可以分开 一个公司 一个账单表吗？
还是要怎么着的，我就是担心 账单业务量大的问题？
13 个解决方案
#1
可以还是不可以，这个跟初学者其实很难回答得“令你满意”。
你的系统上的数据库有几T大吗？如果只有几个G，那为什么要分开成不同的数据库呢？但是另一方面来说，你会设置并且利用好索引吗？如果用不好索引，那么就算是极小量的数据，也会让程序很慢。另外就是数据迁移、备份等等要求，这可能影响到是否要针对不同客户是否需要拆分为不同数据库的问题。
你的系统上的数据库有几T大吗？如果只有几个G，那为什么要分开成不同的数据库呢？但是另一方面来说，你会设置并且利用好索引吗？如果用不好索引，那么就算是极小量的数据，也会让程序很慢。另外就是数据迁移、备份等等要求，这可能影响到是否要针对不同客户是否需要拆分为不同数据库的问题。
#2
某一个数据库表要根据公司来分表的说法其实也是如此。比如说一个表有1000万数据，你把它拆为100个表，最大的那个单位数据表可能有50万数据，这在索引查询某个键值记录时也只是能提高不到千分之一秒的数据，基本上是可以说是无意义的。
但是分表在某些情况下又绝对是有意义的，就是将来你需要分库存放数据，或者你需要强迫自己的程序少写一些大的查询语句时，那么物理上的低级隔离，其实就可以倒逼程序员去费点心思去重构代码、从而避免写出滥用数据库事务的语句。
但是分表在某些情况下又绝对是有意义的，就是将来你需要分库存放数据，或者你需要强迫自己的程序少写一些大的查询语句时，那么物理上的低级隔离，其实就可以倒逼程序员去费点心思去重构代码、从而避免写出滥用数据库事务的语句。
#3
也只是能提高不到千分之一秒的数据 --> 也只是能提高不到千分之一秒的速度
简单说，对于初学者，这些基本上都还不需要纠结。如果你用一个数据库管理100个企业的帐表，与你分别部署100个数据库相比，你做好程序设计、搞清楚自己的程序代码有什么区别就行了。在不复杂的情况下你就不要论是非，而在你真的有超过 T 级别的数据量的时候则要允许接受任何重构而不要规定某个是非结论。
简单说，对于初学者，这些基本上都还不需要纠结。如果你用一个数据库管理100个企业的帐表，与你分别部署100个数据库相比，你做好程序设计、搞清楚自己的程序代码有什么区别就行了。在不复杂的情况下你就不要论是非，而在你真的有超过 T 级别的数据量的时候则要允许接受任何重构而不要规定某个是非结论。
#4
根据你自已业务的实际来决定吧，真要数据量巨大，分表，分库都是可以的。（当然你如果查询统计要相对麻烦些）,如果你数据量没大到那种地步，一个表也完全可以，做好索引。一段时间停机维护的时候清除一下索引碎片，就可以了。对于查询，报税啊，记账啊啥的单据，这些东西总有一个时间段查询吧？比如说一年内的数据，对于一年外的数据，还有没有必要保留？没有的话，可以移走，查历史数据可以在别的地方查。总之，要看你实际业务来决定的。
#5
传统的（20几年前的）按照年度来分库的，其实主要是历史原因，几个大公司（例如用友、安易）的几个程序员的原因，比较容易让用户感觉“满意”的原因（例如声称是软件数据到了年底也要“封帐、关帐”）。现在的商用数据库远非几十年前的 pc 机数据库可比。
但是其实通常都要允许程序员有个性化，是每一个客户一个数据库还是所有客户都用一个数据库，在数据库系统压力和数据迁移的分析模拟时假设没有那么明确的必要性，那就无需纠结。反之你更可以考虑一下如何利用其长处，例如合并在一起容易进行合并报表分析、容易备份和维护.....；分开则容易水平扩展（甚至拆成根本无关联的一些独立系统）。
但是其实通常都要允许程序员有个性化，是每一个客户一个数据库还是所有客户都用一个数据库，在数据库系统压力和数据迁移的分析模拟时假设没有那么明确的必要性，那就无需纠结。反之你更可以考虑一下如何利用其长处，例如合并在一起容易进行合并报表分析、容易备份和维护.....；分开则容易水平扩展（甚至拆成根本无关联的一些独立系统）。
#6
确实，按年度分表我觉得是过时了。
#7
看情况吧，我们倒有过按年度来分的，比如说，对一些充值记录，我们只关心最近几周的充值情况统计，适用于推广做决策。再久远的数据是不太关心的，最多是账务对一下而已，一些比较长时间内总量的统计。还有些游戏记录数据，太久远的也是没有多少意义的，用户来反映问题，一般也就是最近一两天内的问题，不会查到一年前，就是一个星期前都很少见。这样比较久的一些数据移走是没问题的，顶多自已作数据分析用得着，或都应付偶尔的上面审核会用得着（基本也有明确的时间段）
#8
有些表数据，如果增长速度非常快,不清理，迟早有那么一天表数据量你受不了的，哪怕你再分库，分表，看看能不能在业务来重新来设计,不要一条道上走到黑，死抗上了。说个很简单的例子:
你在充值的时候，有可能会根据用户充值历史总充值的钱来升级用户的VIP等级，比如说用户历史充值满1000元，VIP等级从vip1升级到vip2,如果你是直接从充值订单表里直接count()出来的，那这个订单表的数据你就没法清理。不如你新建一个表来处理这种情况，每次充值累计用户的钱，和加虚拟货币的地方用事务控制一下。
又比如，对于用户表来说，对于象游戏行业来说，有些极度不活跃用户是不是可以移到另一张表上去，比如说注册后1年都没登陆过，没玩游戏过，也没充值过，属于僵尸用户，可能是刷注册的数据（要不要保留都要好好想想）
你在充值的时候，有可能会根据用户充值历史总充值的钱来升级用户的VIP等级，比如说用户历史充值满1000元，VIP等级从vip1升级到vip2,如果你是直接从充值订单表里直接count()出来的，那这个订单表的数据你就没法清理。不如你新建一个表来处理这种情况，每次充值累计用户的钱，和加虚拟货币的地方用事务控制一下。
又比如，对于用户表来说，对于象游戏行业来说，有些极度不活跃用户是不是可以移到另一张表上去，比如说注册后1年都没登陆过，没玩游戏过，也没充值过，属于僵尸用户，可能是刷注册的数据（要不要保留都要好好想想）
#9
突然想起来我搜狐的邮箱好几年没登录了，刚上去试了一下，不让上了，
，可见他们对于这样极度不活跃的账号也是作了处理的。
，可见他们对于这样极度不活跃的账号也是作了处理的。
#10
楼主应该是个新人，你的表结构符合 第三范式足够，不用考虑太多。
#11
数据量很庞大吗？千万或者上亿级别吗？没有的话，尽量不要这样做。
#12
之前公司利用分库分表确实也解决了一些问题，那时候只是应付设计的时候出现的弊端而已，如果设计好了完全没必要分表分库，反而维护起来麻烦。
#13
该回复于2018-01-17 11:05:59被管理员删除
#1
可以还是不可以，这个跟初学者其实很难回答得“令你满意”。
你的系统上的数据库有几T大吗？如果只有几个G，那为什么要分开成不同的数据库呢？但是另一方面来说，你会设置并且利用好索引吗？如果用不好索引，那么就算是极小量的数据，也会让程序很慢。另外就是数据迁移、备份等等要求，这可能影响到是否要针对不同客户是否需要拆分为不同数据库的问题。
你的系统上的数据库有几T大吗？如果只有几个G，那为什么要分开成不同的数据库呢？但是另一方面来说，你会设置并且利用好索引吗？如果用不好索引，那么就算是极小量的数据，也会让程序很慢。另外就是数据迁移、备份等等要求，这可能影响到是否要针对不同客户是否需要拆分为不同数据库的问题。
#2
某一个数据库表要根据公司来分表的说法其实也是如此。比如说一个表有1000万数据，你把它拆为100个表，最大的那个单位数据表可能有50万数据，这在索引查询某个键值记录时也只是能提高不到千分之一秒的数据，基本上是可以说是无意义的。
但是分表在某些情况下又绝对是有意义的，就是将来你需要分库存放数据，或者你需要强迫自己的程序少写一些大的查询语句时，那么物理上的低级隔离，其实就可以倒逼程序员去费点心思去重构代码、从而避免写出滥用数据库事务的语句。
但是分表在某些情况下又绝对是有意义的，就是将来你需要分库存放数据，或者你需要强迫自己的程序少写一些大的查询语句时，那么物理上的低级隔离，其实就可以倒逼程序员去费点心思去重构代码、从而避免写出滥用数据库事务的语句。
#3
也只是能提高不到千分之一秒的数据 --> 也只是能提高不到千分之一秒的速度
简单说，对于初学者，这些基本上都还不需要纠结。如果你用一个数据库管理100个企业的帐表，与你分别部署100个数据库相比，你做好程序设计、搞清楚自己的程序代码有什么区别就行了。在不复杂的情况下你就不要论是非，而在你真的有超过 T 级别的数据量的时候则要允许接受任何重构而不要规定某个是非结论。
简单说，对于初学者，这些基本上都还不需要纠结。如果你用一个数据库管理100个企业的帐表，与你分别部署100个数据库相比，你做好程序设计、搞清楚自己的程序代码有什么区别就行了。在不复杂的情况下你就不要论是非，而在你真的有超过 T 级别的数据量的时候则要允许接受任何重构而不要规定某个是非结论。
#4
根据你自已业务的实际来决定吧，真要数据量巨大，分表，分库都是可以的。（当然你如果查询统计要相对麻烦些）,如果你数据量没大到那种地步，一个表也完全可以，做好索引。一段时间停机维护的时候清除一下索引碎片，就可以了。对于查询，报税啊，记账啊啥的单据，这些东西总有一个时间段查询吧？比如说一年内的数据，对于一年外的数据，还有没有必要保留？没有的话，可以移走，查历史数据可以在别的地方查。总之，要看你实际业务来决定的。
#5
传统的（20几年前的）按照年度来分库的，其实主要是历史原因，几个大公司（例如用友、安易）的几个程序员的原因，比较容易让用户感觉“满意”的原因（例如声称是软件数据到了年底也要“封帐、关帐”）。现在的商用数据库远非几十年前的 pc 机数据库可比。
但是其实通常都要允许程序员有个性化，是每一个客户一个数据库还是所有客户都用一个数据库，在数据库系统压力和数据迁移的分析模拟时假设没有那么明确的必要性，那就无需纠结。反之你更可以考虑一下如何利用其长处，例如合并在一起容易进行合并报表分析、容易备份和维护.....；分开则容易水平扩展（甚至拆成根本无关联的一些独立系统）。
但是其实通常都要允许程序员有个性化，是每一个客户一个数据库还是所有客户都用一个数据库，在数据库系统压力和数据迁移的分析模拟时假设没有那么明确的必要性，那就无需纠结。反之你更可以考虑一下如何利用其长处，例如合并在一起容易进行合并报表分析、容易备份和维护.....；分开则容易水平扩展（甚至拆成根本无关联的一些独立系统）。
#6
确实，按年度分表我觉得是过时了。
#7
看情况吧，我们倒有过按年度来分的，比如说，对一些充值记录，我们只关心最近几周的充值情况统计，适用于推广做决策。再久远的数据是不太关心的，最多是账务对一下而已，一些比较长时间内总量的统计。还有些游戏记录数据，太久远的也是没有多少意义的，用户来反映问题，一般也就是最近一两天内的问题，不会查到一年前，就是一个星期前都很少见。这样比较久的一些数据移走是没问题的，顶多自已作数据分析用得着，或都应付偶尔的上面审核会用得着（基本也有明确的时间段）
#8
有些表数据，如果增长速度非常快,不清理，迟早有那么一天表数据量你受不了的，哪怕你再分库，分表，看看能不能在业务来重新来设计,不要一条道上走到黑，死抗上了。说个很简单的例子:
你在充值的时候，有可能会根据用户充值历史总充值的钱来升级用户的VIP等级，比如说用户历史充值满1000元，VIP等级从vip1升级到vip2,如果你是直接从充值订单表里直接count()出来的，那这个订单表的数据你就没法清理。不如你新建一个表来处理这种情况，每次充值累计用户的钱，和加虚拟货币的地方用事务控制一下。
又比如，对于用户表来说，对于象游戏行业来说，有些极度不活跃用户是不是可以移到另一张表上去，比如说注册后1年都没登陆过，没玩游戏过，也没充值过，属于僵尸用户，可能是刷注册的数据（要不要保留都要好好想想）
你在充值的时候，有可能会根据用户充值历史总充值的钱来升级用户的VIP等级，比如说用户历史充值满1000元，VIP等级从vip1升级到vip2,如果你是直接从充值订单表里直接count()出来的，那这个订单表的数据你就没法清理。不如你新建一个表来处理这种情况，每次充值累计用户的钱，和加虚拟货币的地方用事务控制一下。
又比如，对于用户表来说，对于象游戏行业来说，有些极度不活跃用户是不是可以移到另一张表上去，比如说注册后1年都没登陆过，没玩游戏过，也没充值过，属于僵尸用户，可能是刷注册的数据（要不要保留都要好好想想）
#9
突然想起来我搜狐的邮箱好几年没登录了，刚上去试了一下，不让上了，
，可见他们对于这样极度不活跃的账号也是作了处理的。
，可见他们对于这样极度不活跃的账号也是作了处理的。
#10
楼主应该是个新人，你的表结构符合 第三范式足够，不用考虑太多。
#11
数据量很庞大吗？千万或者上亿级别吗？没有的话，尽量不要这样做。
#12
之前公司利用分库分表确实也解决了一些问题，那时候只是应付设计的时候出现的弊端而已，如果设计好了完全没必要分表分库，反而维护起来麻烦。
#13
该回复于2018-01-17 11:05:59被管理员删除