设置多个mysql数据库
我有一个 Mysql/PHP 应用程序。 我想把它卖给SAS。 我正在考虑一家拥有多个可用数据库的托管公司。 我想要一个他们登录的页面，然后我将他们带到他们的数据库。 我将拥有许多具有相同结构的数据库。 我需要一种方法将它们切换到该文件夹（我可以为它们修改一些代码，例如css）并操作它们的数据库。 我可以使用主表进行登录，但如何连接到他们的数据库？ 我担心安全问题。 示例：假设我有 3 个客户。 ABC 我在 apache 服务器上设置了 3 个文件夹，在其中复制代码，设置唯一的数据库名称，如 new_db_a、new_db_b、new_db_c。 现在，如果我在内存变量中执行此操作，当登录时，它将把他带到他的位置。 他可以看到该网址，并且可以轻松地替换另一个字母并运行另一个公司的数据库。
我愿意使用 Perl、PHP 或其他任何东西来做到这一点。 最好的方法是什么？
I have a Mysql/ PHP application. I want to sell it SAS. I am thinking of a hosting company that has multiple databases available. I want a page were they login and I take them to their database. I will have many databases with identical structure. I need a way to switch them into that folder( I may modify some code for them like css) and operate their database.
I could use a master table for the logins but how to connect to their database? I am concerned about security.
Example: Lets say I have 3 customers. A B C
I set up 3 folders on an apache server, copy code there, set unique database names like new_db_a, new_db_b, new_db_c.
Now if I do it in a memory variable when a logs in it will take him to his spot. He can see the url and could easily substitute another letter and run another companies database.
I am willing to use Perl, PHP or whatever to do this.
Whats the best way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个经典的抽象问题。 基本上，您不仅需要从应用程序中抽象数据库选择过程，还需要从选择屏幕中抽象出来。
将其视为“问题空间”。 每个应用程序都有自己的（即他们的数据库），然后您还有一个，即客户登录系统。 为此使用另一个不同的数据库并没有什么问题。 与每个登录相关联的是数据库连接信息。 这意味着您可以将数据库信息与用户登录的事实（以及他们登录的身份）一起存储在 PHP 会话中。
现在，您的其他应用程序需要其数据库层 [1] 来学习如何在会话中查找数据库信息。 事实上，如果您不仅存储数据库名称，还存储服务器名称、登录名和密码，您可以自由地将一些客户放在同一数据库服务器上，将一些客户放在另一台数据库服务器上，等等。您只需获得 MySQL 权限正确（不难）。
不过，最大的美中不足可能是，如果选择的应用程序决定控制 PHP 会话信息本身。 有几种方法可以解决这个问题。 一种是将连接到正确数据库所需的内容复制到自己的会话中。 第二种是选择会话单独并可能手动进行会话管理。 但不要将数据库信息存储在 cookie 中。 这不仅可以由坚定的用户更改，而且您将安全性交给了不安全的位置 - 浏览器。
[1] 你确实有一个合适的数据库层，不是吗？ 我的意思是，您的所有
mysql_query()调用都位于处理程序后面，无论是定制的还是 PDO 之类的。This is a classic abstraction problem. Basically, you need to abstract the database selection process from not only the application, but also the selection screen.
Think of it terms of 'problem space'. Each application has their own (i.e. their database) and then you have one more, which is the customer login system. There is nothing wrong with using another, different database for this. Associated with each login will be database connection information. This means you can store the database information in the PHP session alongside the fact that the user is logged in (and who they are logged in as).
Now, your other application needs its database layer[1] to be taught how to look for the database information in the session. In fact, if you store just not just the database name, but the server name, a login and password, you have freedom to put some customers on the same database server, some together on another, etc. You just have get the MySQL permissions correct (not hard).
Probably the biggest fly in this ointment, though, is that if the application being selected decides to take control of the PHP session information itself. There are several ways to solve this. One is for it to copy across to its own session what it needs to connect to the correct database. A second is for the selection session to do its session management separately and possibly manually. But don't store the database information in a cookie. Not only can this can be changed by a determined user but you are ceding security to an insecure location - the browser.
[1] You do have a proper database layer, don't you? And by that I mean you have all your
mysql_query()calls behind a handler, either bespoke or something like PDO.