目前我正在开发一款在线建筑材料Web应用程序。公司可以登录我们的网站，然后使用这个Web应用程序。
从一开始的想法就是为每个客户创建一个数据库。但现在随着客户数量的增加（100+），我们需要管理100个以上的数据库。
我们需要大约每半年运行一次更新脚本进行数据库维护。
我认为的优点是，当客户要退出时，我们可以删除他们的数据库，然后就完成了。
当我想添加新客户时，我必须为该特定客户填充大约1,000,000个唯一记录，因为每个客户都有不同的价格/材料。
备份方面，我使用一个MySQL Dump脚本，它会为每个数据库创建一个*.sql文件，我每天下载一次。
您的意见是什么？您认为应该使用一个大型数据库还是为每个客户使用一个数据库？
我使用的是ASP.NET/C#和MySQL...
但现在它越来越大（100+），所以我们现在有100个数据库需要管理。
我认为你已经得到了答案。
必须同意@Hogan的观点-管理那么多数据库的开销可能远非理想-特别是如果您将来需要进行模式更改等。
话虽如此，如果您使用单个数据库，您是否有可能需要将给定客户的数据分离到独立的数据库/站点中？如果可能，执行此分离需要多长时间？
实质上，如果编写一组工具来处理上述情况需要的工作量较小，则我会倾向于采用单个数据库方法。但是，您还需要考虑为每个客户处理数据集的统一版本的数据库模式的预计时间表。
此外，现有的100多个数据库的架构是否完全相同？如果不是，如果您决定将现有数据迁移到单个数据库，则可能会遇到很多问题。
更新-顺便说一句，以上所有内容都有些概括，但是如果不了解正在使用的数据量和流量等信息，很难具体说明。（例如：如果您曾经为客户提供高需求的站点，则使用每个客户数据库将其轻松放入其自己的DB服务器上。）
我同意@Hogan和@middaparke的观点...如果模式相同，您应该将其放在一个实例中。
不幸的是，从这里无法确定您的模式是否会从重用大部分那一百万行中受益，如果规范化得好，那么肯定会有好处。
基于此更改，很难确定对应用程序进行任何更改的难度。
不幸的是，听起来您拥有庞大的客户群体，并且已经有了运作良好的应用程序，因此保持这个方向的动力非常强烈 - 这将使您自动化管理如此多的数据库...虽然这不是从头开始做事的方式，但可能是最便宜的选择，因为您已经在这个位置上了。
