如何搭建数据库平台管理多用户

我们最近在开发一个网页版的进销存系统，，，用户注册、登录我们的系统，进行在线操作。
可是现在有这个问题，，，我们大概有2万客户，如果他们使用这个 网页。
如何 搭建他们的数据库呢？

是在一个数据库里面保存用户的注册信息，，，用户注册后，直接建立一个该客户的数据库，这样行么？2万多。数据库太多了吧？

请问如何解决？

17 个解决方案

#1

你得先评估一下数据量、同时在线客户数。
什么都没有就决定2万客户共用一个服务器了？

#2

引用 1 楼 Tiger_Zhao 的回复:

你得先评估一下数据量、同时在线客户数。
什么都没有就决定2万客户共用一个服务器了？

刚提出这个 想法，，，就想查询一下相关信息。
首先可以确定，有至少2万用户使用，，，那么是不是 就要随着用户注册使用，要建立2万个数据库啊？？这太多了吧。
同时在线客户数，还没确定。需要问一下。

#3

网页版的进销存系统，前几年我就考虑过自己写，只是感觉特别麻烦就没写了。
查了一下，一台服务器可以支持3万多数据库，所以2万个数据库应该没问题，平均一个数据库10M，那总共就要200G容量。

一个主数据库，存放各个用户的资料，另一个模板数据库，每新增一个用户，就复制这个模板数据库（备份、还原方式）。如果有新增、修改，就改这个模板数据库。

当时考虑到几个问题：
1、如果数据库有修改，那已有的库怎么办？
2、代码可能会根据用户不同，有一些差异，这些差异怎么处理？是一个用户一套代码？还是大家共用代码，代码中判断是哪个用户？
3、怎么保证数据的安全？我担心用户会觉得数据不安全，会被他人进入，盗取一些机密信息（进货厂商、进货价格），甚至会担心上税的问题。

#4

2亿用户也可以在一个数据库中。这是完全由你的设计自己决定的。

#5

建议一个客户(即一家公司)使用一个独立的数据库.
大部分客户之间的数据应该是不共享的,
所以,可以把20000个数据库分别放在N个服务器上,
再建一个客户-服务器名-数据库名关系映射表,登录时自动拼接产生数据库连接串.

#6

建立N个数据库，如果有多人 并行访问 不同数据库，会不会导致  影响运行啊？

#7

引用 3 楼 zbdzjx 的回复:

网页版的进销存系统，前几年我就考虑过自己写，只是感觉特别麻烦就没写了。
查了一下，一台服务器可以支持3万多数据库，所以2万个数据库应该没问题，平均一个数据库10M，那总共就要200G容量。

一个主数据库，存放各个用户的资料，另一个模板数据库，每新增一个用户，就复制这个模板数据库（备份、还原方式）。如果有新增、修改，就改这个模板数据库。

当时考虑到几个问题：
1、如果数据库有修改，那已有的库怎么办？
2、代码可能会根据用户不同，有一些差异，这些差异怎么处理？是一个用户一套代码？还是大家共用代码，代码中判断是哪个用户？
3、怎么保证数据的安全？我担心用户会觉得数据不安全，会被他人进入，盗取一些机密信息（进货厂商、进货价格），甚至会担心上税的问题。

1.有数据库修改，的问题 是不是可以用 用户登录名 当做数据库名，然后用户名不可修改。
2.网页版的代码 为什么 会根据用户不同有差异呢？无外乎是 用户使用不同的模块吧。。。
3.数据安全，，，这确实是个问题，需要做好防护 和 断网恢复以及 备份还原问题。

#8

上班顶一个，还有人 解答没》》》

#9

安全性上一个库和2万个库没有区别。

#10

数据库分开的话，如果数据结构要修改，那会很麻烦的，
公司的集团ERP，下面有10多家子公司，也是用一个数据库的，

#11

引用 4 楼 Tiger_Zhao 的回复:

2亿用户也可以在一个数据库中。这是完全由你的设计自己决定的。

现在就是出于设计阶段，所以 就来 问问 如何设计这个 结构。

#12

我认为最好是一个数据库，集中的方式，易于管理，如果数据量大了，可以再考虑做分区表，如果数据量还大，再考虑分表，如果还大，那在考虑分库。

随着数据用户越来越多，数据量也会越来越大，到时候 我想 不仅仅是数据库设计会变化，应用程序，估计也要做大量的修改。

#13

现在数据库的设计，最关键的还是要考虑现阶段的实际需求，如果稍微考虑长远一点，那么在近1-2年内的用户量会到多少。

再以后的事情，就先可以不考虑，等以后数据量大了，再想办法，那就不是数据库一个了，还要考虑缓存、分布式等问题，一步一步来。

#14

引用 7 楼 u013759319 的回复:

Quote: 引用 3 楼 zbdzjx 的回复:

网页版的进销存系统，前几年我就考虑过自己写，只是感觉特别麻烦就没写了。
查了一下，一台服务器可以支持3万多数据库，所以2万个数据库应该没问题，平均一个数据库10M，那总共就要200G容量。

一个主数据库，存放各个用户的资料，另一个模板数据库，每新增一个用户，就复制这个模板数据库（备份、还原方式）。如果有新增、修改，就改这个模板数据库。

当时考虑到几个问题：
1、如果数据库有修改，那已有的库怎么办？
2、代码可能会根据用户不同，有一些差异，这些差异怎么处理？是一个用户一套代码？还是大家共用代码，代码中判断是哪个用户？
3、怎么保证数据的安全？我担心用户会觉得数据不安全，会被他人进入，盗取一些机密信息（进货厂商、进货价格），甚至会担心上税的问题。

1.有数据库修改，的问题 是不是可以用 用户登录名 当做数据库名，然后用户名不可修改。
2.网页版的代码 为什么 会根据用户不同有差异呢？无外乎是 用户使用不同的模块吧。。。
3.数据安全，，，这确实是个问题，需要做好防护 和 断网恢复以及 备份还原问题。

1、我说的是指，系统已经跑了一段时间了，有一些用户在使用了。其中一个用户提出，我要在入库单上增加一个备注栏位。那你就要将此用户的数据库入库表增加一个备注字段，但其他用户的入库表是不是也要增加这个备注字段？如果多个用户都放在一个数据库中，没有此问题；如果每个用户一个数据库，就会有此问题。如果因此导致有些基础的视图或语句要改，多个库，那就都要改。
2、除非你强制用户就按你的系统规定去操作，否则，多数用户都会有一些定制的功能，这就导致代码上会有差异。像我们公司用的TIPTOP，全集团用的一套，但源代码中，会判断：如果是华东厂，要怎么怎么操作；如果是华南厂，要怎么怎么操作；如果是台北厂，又要怎么怎么操作……甚至界面都有可能会分成：入库单(For 华东厂)、入库单(For 华南厂)、入库单(For 台北厂)……
3、这基本上就是纯技术上的问题了，软硬件方面都要注意了。

分多个库，针对每个用户的客制化，更灵活；如果合并到一个库，管理、修改及代码方面，更省事。程序代码也是类似情况。这需要仔细衡量。

#15

好吧，更进一步了，，，还没想到这里呢，，，不过确实要 考虑进去。
谢谢！

#16

我要开支琢磨琢磨怎么 设计 数据库结构了。。。。。结了啊

#17

我认为像这样大的用户量，首先考虑分库，用户库，业务库，基础信息库，为了未来数据量的逐渐增大，楼上有位哥们提到分区表也是必须考虑的，因为分区表可以方便数据库大数据归档。