在运行时创建表与在运行时创建数据库
我正在为一家公司构建一个客户销售和发票应用程序。该应用程序使用 PHP MYSQL，但我想这应该不重要。
应用程序结构如下：
网站文件：.php、.htm、图像和 css
数据库：包含 20 多个表格
该应用程序目前由公司使用，其他 2 个姐妹问题（主要是 beta 测试）。由于用户群很小，我手动复制网站文件和数据库来设置应用程序以供新公司使用。 我正在寻找一种方法使应用程序更具“可扩展性”，而无需手动进行“扩展”。（这意味着我不想手动管理三个不同的文件集和数据库） 由于代码是公司中立的，并且数据库包含公司信息，因此当用户请求设置新公司时，我只需重新创建数据库。我可以通过多种方式为新公司创建数据库。
在运行时，我可以使用 CREATE DATABASE 创建一个包含 20 多个表的新数据库
在运行时，我可以创建额外的 20 多个表，并使用 CREATE TABLES 将公司名称作为表的前缀
我可以添加公司列到我的所有表中，然后像以前一样继续添加信息。
新的数据库方法对我很有吸引力，因为备份和维护很容易，它可能会更安全，因为黑客只能访问一家公司的详细信息（可能......）。此选项不适用于数据库数量有限的共享主机。
第二个选项意味着我可以在一个数据库中创建所有内容。但这个选项更加“共享”。
由于 MySQL 中的表级锁定问题，我不会选择第三个选项（我没有对所有表使用 InnoDb）。
所以我的选择是在选项1和2之间。管理过金融应用程序的开发人员请提供建议，因为一旦完成beta测试阶段，使用基数就会增加，我不希望手动更改相同的内容10 个数据库和文件集。最好的做法是什么？
I am building a customer sales and invoicing app for a company.The app is in PHP MYSQL, but I guess that shouldn't matter much.
The app structure is as follows:
website files: .php, ,.htm, images and css
database: containing 20+ tables
The app is currently being used by the company and 2 other sister concerns(beta testing mostly). Since the user base is small, I manually copy the website files and the database to set the app up for usage by a new compnay.
I am looking for a way to make the app more 'scalable' without having to manually do the 'scaling'.(meaning I don't want to manage three different filesets and dbs manually)
Since the code is company neutral and the databases contain the company info, I will only have to recreate the database when a user requests a new company to be setup. There are multiple ways that I can create the database for a new compnay.
At runtime I can create a new databse with the 20+ tables using CREATE DATABASE
At runtime I can create additional 20+ tables with the company name as prefix for the tables using CREATE TABLES
I can add a company column to all of my tables and then continue adding info as before.
The new database method appeals to me because backup and maintenance would be easy, it would probably be a bit more secure since a hacker will only be able to access the details of one company(probably...). This option wont work on a shared hosting with a limit on number of databases.
The second option would mean I can create everything in one database. But this option is a bit more 'shared'.
I wouldn't go for the third option due to table level locking issues in MySQL (I am not using InnoDb for all my tables).
So my choices are between option 1 and 2. Developers who've managed financial apps , please advice, as once the beta testing phase is done with, the usage base will increase, and I don't wish to manually change the same thing in 10 databases and filesets. What will be the best thing to do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从安全角度来看，客户应该拥有独立的数据库，这限制了MySQL用户的访问。
该用户应该只具有应用程序所需的权限（通常是 SELECT、INSERT、DELETE 和 UPDATE），而不是管理权限（DROP、CREATE、GRANT，...）。这样，您就可以清楚地了解数据库和表。
当您需要更改表结构时，只需在数据库上执行（经过彻底测试的）SQL 查询即可。
CSS、图像和其他静态内容可以放在子域中，或者 <代码>别名 (Apache)
库和中性类也应该放在一个目录中，使用
include_path来包含这样一个文件，这样您就只有一个文件集需要更改。From the security point of view, customers should have separate databases, which restricted access from MySQL users.
That user should only have the permissions needed by the application (often SELECT, INSERT, DELETE and UPDATE), and not administrative permissions (DROP, CREATE, GRANT, ...). In this way, you've a clear overview on databases and tables.
When you need to alter a table structure, you just executes the (thoroughly tested) SQL query on your database.
CSS, images and other static content could be put in a subdomain, or
Alias(Apache)Libraries and neutral classes should be put in one directory too, using
include_pathto include such a file, so you have only one fileset that needs to be changed.