001*_*001 14 database sql-server
Think Design:我有许多共享相同用户数据库的应用程序!其他表也是共享的,例如用户活动日志,购买等
1)无论如何我的问题是,如果我要使所有应用程序只使用1个数据库的一切!我可以在扩展性方面遇到任何问题吗？或者这样做的任何其他问题？拥有1个数据库更好吗？？还是最差的？
2)或者我应该让每个应用程序都有自己的数据库,然后使用Web服务来共享应用程序之间的公共表？
Erw*_*out 30
"或者我应该让每个应用程序都拥有自己的数据库,"
在20世纪50年代,每个应用程序都有自己的私有文件集.大约十年后,一些聪明人开始观察到那些"appliation-private files"中的某些数据元素实际上是重复信息.客户名称遍布各地,销售点信息在各处重复,等等.
数据库技术是由更聪明的人发明来解决这个问题的.
而现在,通过使数据库"应用程序私有",互联网程序员的生成正在复活已经在1960年代解决的同样问题.
只是想到我的,没什么重要的.
"那些忘记历史的人注定要重蹈覆辙".(这不是一个思想雷)
Rob*_*ner 16
访问共享资源的进程越多,就越有可能进入扩展/性能和计时问题.
即使您的应用程序很小,我也会建议不要这样做.
整个项目中最糟糕的部分可能是您将添加到应用程序集中的不必要的复杂性.毕竟,编程不是线性的,只需添加一个表进行交互,就会使整体复杂度增加一倍以上.
至少,创建一个服务以与常用表进行交互,并让您的应用程序通过该服务发出请求.
我同情你将资源合并到一个共同位置的愿望,但我认为在这种情况下,你将为自己设置更多的艰辛.我觉得这不值得.
为了回应你的编辑...我会选择(2).
不要创建单独的数据库.那么你将有一个噩梦来维持,事情将会失去同步.人们在不同的系统中会有不同的名字和ID,这将是你见过的最糟糕的噩梦.一个系统中的Dups将与其他人中的一个人匹配,从而产生报告问题.只是在试图让不同的系统匹配时编写报告将是令人讨厌的.相反,计划可扩展性.了解如何分区数据.
如果您有多个应用程序命中同一个数据库,请确保数据库维护数据完整性而不是任何应用程序!这是至关重要的,否则某些应用程序可能不知道维护其他人需要的某些事情,并且您将需要清理数据完整性灾难.使用真正的PK和Fk约束,定义默认值,使用正确的数据类型,以便无法输入无效日期等.
不允许开发人员在未经数据库专家批准的情况下更改数据库结构,数据库专家知道其他应用程序可能会受到更改的影响.确保第一次学习如何编写高性能代码,因为您将使用代码影响其他应用程序.