Zend 的多个数据库
我正在构建一个应用程序（使用 zend 框架），其中我们将有多个客户端登录并使用该应用程序，并且每个客户端都将存储有关其用户的大量数据（顺便说一句，我正在使用 MySQL）。
基本上我想知道两件事：
拥有多个数据库，每个客户端一个（即 ipd_client_CLIENTNAME）并具有相同的表是一个愚蠢的想法吗？或者，如果我们有 50 个客户，“他们的”数据库中有 20,000 个用户的数据，那么它实际上会更快响应（比将所有内容都放入一个数据库中）吗？ 我已经成功地构建了相同的系统，但全部在一个数据库上，我的模型类只是获取登录的客户端的名称（在模型类的 init() 方法中），然后动态更改它们获取的表的名称数据来自，这会好吗？
如果“系统上的每个客户端都有自己的数据库”有意义，那么我到底如何动态更改我的数据库模型连接到的数据库（基于登录的客户端）？
如果这没有意义，下面是数据库在两种不同情况下的示例（假设系统上注册了 2 个客户端）：
多个数据库：
ClientA 有一个名为“ipd_clients_ClientA”的数据库与表“用户”，“列表”。
ClientB 有一个名为“ipd_clients_ClientB”的数据库，其中包含表“users”、“lists”。
单个数据库：
ClientA 具有名为“users_ClientA”、“lists_ClientA”的表。
ClientB 具有名为“users_ClientB”、“lists_ClientB”的表。
希望这是有道理的。
任何帮助将不胜感激，谢谢！
I'm building an application (using the zend framework) where we will have multiple clients who login and use the application, and each of these clients will be storing lots of data about their users (I'm using MySQL btw).
Basically I'm wondering 2 things:
Is having multiple databases, one for each client (ie. ipd_client_CLIENTNAME) with identical tables a stupid idea? Or will it actually be more responsive (than putting everything in one database) if we have 50 clients with 20,000 users' data in 'their' database?
I've already managed to build the same system but all on one database, my model classes simply grab the name of the client logged in (in the model classes' init() method) and then dynamically change the name of the table they grab data from, is this going to be just fine?If the "every client on the system gets their own database" makes sense, how exactly would I dynamically change what database my db models connect to (based on which client is logged in)?
In case this made no sense, here's an example of what the databases would look like in the two different scenarios (given 2 clients registered on the system):
Multiple Databases:
ClientA has a database called "ipd_clients_ClientA" with tables "users", "lists".
ClientB has a database called "ipd_clients_ClientB" with tables "users","lists".
Single Database:
ClientA has tables called "users_ClientA", "lists_ClientA".
ClientB has tables called "users_ClientB", "lists_ClientB".
Hopefully that makes sense.
Any help would be GREATLY appreciated, thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我将使用解决方案 2，为您的客户提供多个表，并结合 MySQL 主/从复制。
MySQL Master Slave
如果你想使用不同的数据库，你可以使用 Zend Framework 的原生函数：
多数据库教程
然后为客户端选择一个通过某种前缀。
i would use Solution 2, with multiple Tables for your clients in combination mit MySQL Master / Slave Replication.
MySQL Master Slave
If you want to use different Databases, you can use native functions of Zend Framework:
Tutorial multipe dbs
And than select the one for the client by some kind of prefix.
尽管您接受了这个答案，但我不敢苟同。我认为拥有多个数据库会更容易管理。
该教程使用多个数据库的方式比实际需要的要复杂得多。我的方法是简单地在根文件（index.php？）中定义客户端名称，然后我的引导程序使用此常量加载到正确的 ini 文件中。
如果您从分离开始，那么您可以继续使用相同的原理更轻松地在单独的结构中缓存数据。
使用单独的数据库将使管理单个客户变得更加容易。
Although you accepted that answer, I beg to differ. I think having multiple database would be much easier to manage.
The way that tutorial uses multiple databases is far more complicated than it needs to be. The way I do it is by simply defining the client name in a root file (index.php?) and then my bootstrap uses this constant to load in the correct ini file.
If you start with the separation, you can then go on to using the same principles for caching data in separate structures far more easily.
Using separate databases would make it much easier to manage individual clients.
虽然 ZF 确实支持多个数据库连接，但我不会在这种特殊情况下使用它们。
对我来说，在每个数据表中存储 client_id （或 site_id）并使用它进行过滤更有意义。重复使得在应用程序范围内进行更改变得非常困难。每当我看到这样的动态命名表时，我通常认为这是糟糕的设计。
对于缓存，只需在任何缓存键前面加上客户端标识符即可。
While ZF does have support for multiple database connections, I would not use them in this particular case.
It makes more sense to me to store a client_id (or site_id) in each of your data tables and use that to filter. Duplication makes it very hard to make application-wide changes. Whenever I see dynamically named tables like that, I usually think it's poor design.
For caching, just prefix any cache keys with the client identifier.