求教数据库设计

丫头片子

想做一个零碎，大略是这样的：

一个多用户零碎，用户是静态，本人注册生成的。针对每个用户，都有一套相反的数据表格，用户能够本人添加修正内容。

目前想到两种办法：

第一种：一切的用户和用户数据都放在一个数据库中，对不同的表数据，经过用户的id区别

第二种：在静态生成用户时，针对这个用户，静态生成一个数据库和相应的表格。固然，还需求一个核心数据库，办理这些用户的信息。

对比偏向于第二种，觉得未来扩展性更好一些，就是不知道有无甚么缺点？

不可思议

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

whitecat

第二种不可， 假如有10万个用户， 莫非生成10万个数据库？

modena

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

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

不知道零碎中数据库得多的话，是否零碎开消会很大？

丫头片子

LZ的需要是典型的Multitenancy 零碎——据我所知大少数计划都是使用第二种设计。

第一种设计保护十分难题。

花猪54288

我的了解要不要用第二种multi tenant取决于你们的估算，还有每个用户有多少不同凡响的货色。
你这里的“用户能够本人添加修正内容”详细是指甚么？

xqg555

集体以为，当初寰球大约65亿人口，就算每人在你零碎里注册一次，你说的第一种计划也足够处置了。数据库宏大有甚么瓜葛呢？做好normalization, indexing, optimization,replication,synchronization, performance不会差的。我看了一下我公司的数据库，最小的一个size是132G，共有943,682,十一2 rows，做了一个简略的3 left join search，0.0348s。假如想再优化一下，就做数据库同步好了，读写离开，分别拜候不同的 replication server，这样很简略的就达到了分流的目的。你说的第二种计划，看下来很美，我就想这需求多牛B的运用才配得上它阿。

水中金

看了下相干的文章，机能可能不是症结，从设计、保护、扩展、平安性上需求斟酌的更多一些

kkkkk221119

谢谢，恰是我想找的

lnn

good luck  ^_-

ligangang

第二种才难保护呢，实战教训

necely

看不出第二种的扩展性和保护性更好。假如要在一切用户内外加一个字段，第二种计划很多衔接多少次数据库啊？假如要按期按照用户数据做报表，做数据收集，这消息很多大啊。

真空科学技术

要多大的才需求拆分db呢?
少数package软件都是第一种，用户定制本人，只有能把需要都定义到元数据里就能算胜利。更合适传统形式
第二种，觉得能够放到云外面。设计有难度啊，保护也难

虫子

LS典型的DBA舆论。作为一个Developer我不能不以为这纯属忽悠。


假如每个用户都是同样的表格方式，只是内容不同。那末彻底能够同享同一张表或者同一个数据库，用不同的User ID区分。

smff125

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

lqs518

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

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

不外方才下面有位同窗提到前期修正数据库构造的问题，好像对这个问题，第二种真实没甚么好方法

shuha

谢谢各位的回复

anyany

看你的名目需要：

1）指标是针对多少个用户
2）指标用户要不要求数据独立性，独立备份或者甚么
3）机能要求是甚么？ 假如每个用户拜候，都需求一个运用顺序的connection，而connection pool是无限的。

假如用户是集体用户，要求零碎反对10万个单用户，仍是用前者；假如用户是organization ，也能够用后者，以便于独立备份和保护，也平安。

kyg071007

咱们当初就是用的第二种，，， 这要按照你做的APPLICATION 类型来定的，，假如只是功用个别的，一摸同样，不需求定制的APPLICATION 第一种就OK，，，

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

第一种不行，，数据不平安，，，机能也不行，，，

有些公司会要求本人的公司数据库放在本人规则的办事器上，，假如是第一种，你基本就没方法离开给他特殊放。。

选哪一种次要是按照你的APPLICATION 类型来定的。。。。。。。各有长短，

hxy8802

第一种无数据平安的隐患，不外假如前端软件管制的好，就没啥大问题
第二种计划数据平安有保障，但保护和改变会十分十分费事.....

lovewulong

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

lqs518

楼上说的都有情理，
不外从完成和保护的难易水平上说， 固然是第一种有劣势。
数据平安和performance两种各无利弊，很难对比。

mgw-hello

谢谢各位，高手得多啊

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

我想做的名目是一个在线的产品，客户次要是企业或者商业用户。结合名目状况，初步抉择采取第二种计划。

次要是几个斟酌：

1。数据平安性更好
2。面向用户的扩展性更好，好比能够为免费用户提供更好的或附加的办事，如备份、更好的办事器机能等等，或者独立出来做独自的零碎
3。数据库数量的问题，由于是面向商业用户，数量应该不会很大，假如能有1000个用户，估量我都乐翻了，所以临时不必斟酌太多。原本我的直觉觉得这类形式很“傻”，不外既然得多人在用，阐明应该是一个常见的解决计划，不会有太大的问题。

但有一个问题就是，假如零碎降级波及到数据库构造的变动，估量任务量就大了，不外能够斟酌采取脚本对一切的数据库挨次降级。

hechun

我感觉你可能还不太理解multi tenant数据库
假如需求商业级的运用完成，你应该找专业的有教训的看一看
在这里问，大多只会给你一个启示，真实的完成仍是要靠本人
这是我集体的一点倡议