请教数据库设计

kevin2005

想做一个系统，大概是这样的：

一个多用户系统，用户是动态，自己注册生成的。针对每个用户，都有一套相同的数据表格，用户可以自己添加修改内容。

目前想到两种方法：

第一种：所有的用户和用户数据都放在一个数据库中，对不同的表数据，通过用户的id区分

第二种：在动态生成用户时，针对这个用户，动态生成一个数据库和相应的表格。当然，还需要一个中心数据库，管理这些用户的信息。

比较倾向于第二种，感觉将来扩展性更好一些，就是不知道有没有什么缺陷？

oldboy

用淘宝的数据库吧，不是开源了么

flyspirit

第二种不成， 如果有10万个用户， 难道生成10万个数据库？

kevin2005

原帖由 flyspirit 于 2011-10-11 10:27 发表
第二种不成， 如果有10万个用户， 难道生成10万个数据库？

可是如果是第一种，数据库也会变得很庞大

第二种的话，如果用多个数据库服务器，很容易就划分流量了，而第一种还要做数据库同步

不知道系统中数据库很多的话，是不是系统开销会很大？

jungle

LZ的需求是典型的Multitenancy 系统——据我所知大多数方案都是使用第二种设计。

第一种设计维护非常困难。

北风

我的理解要不要用第二种multi tenant取决于你们的预算，还有每个用户有多少与众不同的东西。
你这里的“用户可以自己添加修改内容”具体是指什么？

psaux

个人认为，现在全球大约65亿人口，就算每人在你系统里注册一次，你说的第一种方案也足够处理了。数据库庞大有什么关系呢？做好normalization, indexing, optimization,replication,synchronization, performance不会差的。我看了一下我公司的数据库，最小的一个size是132G，共有943,682,112 rows，做了一个简单的3 left join search，0.0348s。如果想再优化一下，就做数据库同步好了，读写分开，分别访问不同的 replication server，这样很简单的就达到了分流的目的。你说的第二种方案，看上去很美，我就想这需要多牛B的应用才配得上它阿。

kevin2005

原帖由 psaux 于 2011-10-11 11:40 发表
个人认为，现在全球大约65亿人口，就算每人在你系统里注册一次，你说的第一种方案也足够处理了。数据库庞大有什么关系呢？做好normalization, indexing, optimization,replication,synchronization, performance不会差的。我 ...

看了下相关的文章，性能可能不是关键，从设计、维护、扩展、安全性上需要考虑的更多一些

kevin2005

原帖由 jungle 于 2011-10-11 11:01 发表
LZ的需求是典型的Multitenancy 系统——据我所知大多数方案都是使用第二种设计。

第一种设计维护非常困难。

谢谢，正是我想找的

psaux

good luck  ^_-

atransformer

coolioo

第二种才难维护呢，实战经验

greed

看不出第二种的扩展性和维护性更好。如果要在所有用户表里加一个字段，第二种方案得多连接多少次数据库啊？如果要定期根据用户数据做报表，做数据采集，这动静得多大啊。

Fernando

要多大的才需要拆分db呢?
多数package软件都是第一种，用户定制自己，只要能把需求都定义到元数据里就可以算成功。更适合传统方式
第二种，感觉可以放到云里面。设计有难度啊，维护也难

混不到坑的萝卜

原帖由 jungle 于 2011-10-11 10:01 发表
LZ的需求是典型的Multitenancy 系统——据我所知大多数方案都是使用第二种设计。
第一种设计维护非常困难。

LS典型的DBA言论。作为一个Developer我不得不认为这纯属忽悠。

一个多用户系统，用户是动态，自己注册生成的。针对每个用户，都有一套相同的数据表格，用户可以自己添加修改内容。

如果每个用户都是一样的表格形式，只是内容不同。那么完全可以共享同一张表或者同一个数据库，用不同的User ID区别。

典

Search NoSQL or MongoDB, or documentDB. Rational DB is good for something but not good for your scenario.

kevin2005

http://msdn.microsoft.com/en-us/library/aa479086.aspx

找到的这篇文章，我觉得讲的挺好的

不过刚才上面有位同学提到后期修改数据库结构的问题，好像对这个问题，第二种实在没什么好办法

kevin2005

谢谢各位的回复

交易人生

看你的项目需求：

1）目标是针对多少个用户
2）目标用户要不要求数据独立性，独立备份或者什么
3）性能要求是什么？ 如果每个用户访问，都需要一个应用程序的connection，而connection pool是有限的。

如果用户是个人用户，要求系统支持10万个单用户，还是用前者；如果用户是organization ，也可以用后者，以便于独立备份和维护，也安全。

yangwulong1978

我们现在就是用的第二种，，， 这要根据你做的APPLICATION 类型来定的，，如果只是功能一般的，一摸一样，不需要定制的APPLICATION 第一种就OK，，，

但是如果对 不同的公司，，，有些公司会有一些不同的业务逻辑，或者，需要定制的是必须要用第二种的。。

第一种不行，，数据不安全，，，性能也不行，，，

有些公司会要求自己的公司数据库放在自己规定的服务器上，，如果是第一种，你根本就没办法分开给他特殊放。。

选哪种主要是根据你的APPLICATION 类型来定的。。。。。。。各有长短，

coolioo

第一种有数据安全的隐患，不过如果前端软件控制的好，就没啥大问题
第二种方案数据安全有保障，但维护和改动会非常非常麻烦.....

stevenbian

第一种吧，用户视图很好用的。

老衲

楼上说的都有道理，
不过从实现和维护的难易程度上说， 当然是第一种有优势。
数据安全和performance两种各有利弊，很难比较。

kevin2005

谢谢各位，足迹高手很多啊

综合大家所说，应该是两种方案各有利弊，也都有人在用。

我想做的项目是一个在线的产品，客户主要是企业或者商业用户。结合项目情况，初步决定采用第二种方案。

主要是几个考虑：

1。数据安全性更好
2。面向用户的扩展性更好，比如可以为收费用户提供更好的或附加的服务，如备份、更好的服务器性能等等，或者独立出来做单独的系统
3。数据库数量的问题，因为是面向商业用户，数量应该不会很大，如果能有1000个用户，估计我都乐翻了，所以暂时不用考虑太多。本来我的直觉感觉这种方式很“傻”，不过既然很多人在用，说明应该是一个常见的解决方案，不会有太大的问题。

但有一个问题就是，如果系统升级涉及到数据库结构的变化，估计工作量就大了，不过可以考虑采用脚本对所有的数据库依次升级。

北风

我觉得你可能还不太了解multi tenant数据库
如果需要商业级的应用实现，你应该找专业的有经验的看一看
在这里问，大多只会给你一个启发，真正的实现还是要靠自己
这是我个人的一点建议

原帖由 kevin2005 于 14/10/2011 08:56 发表
谢谢各位，足迹高手很多啊

综合大家所说，应该是两种方案各有利弊，也都有人在用。

我想做的项目是一个在线的产品，客户主要是企业或者商业用户。结合项目情况，初步决定采用第二种方案。

主要是几个考虑：

1。数据安全性更 ...