Php 自动部署多应用程序的数据库结构

我想创建一个类似basecamp或mailchimp的应用程序。客户自行注册，然后自动为自己设置应用程序。该应用程序将使用cakephp开发

我的问题是什么是最好的数据库结构

• 在一个表中由客户id分隔的所有客户
• 每个客户都有自己的DB+DB用户
• 为每个人使用文件夹中的SQLite文件

---

如果你想变得更大（可扩展），那么SQLite可能不是你最好的选择。真正的RDBMS要高效得多。这就是说，如果你真的打算扩大规模，蛋糕可能也不是最有效的选择。这些都是根据您的业务模式做出的决策。有抱负很好，但成为一只10000磅重的大猩猩却很少见……这是双关语

我的公司有一个应用程序，可以为几十个客户实现营销自动化，它使用一个公共数据库实现公共功能，使用一个单独的数据库实现唯一数据。是的，它可以工作，而且实际上非常高效，并且很好地分离了数据，因此数据库不会失控……事实上，共享数据库有包含数百万条记录的表。也就是说，跟踪你的联系很糟糕，而且往往是我们错误的原因。只中断一个会话或实例化错误的内容，然后轰！这是烤面包。我经常发现自己不得不完全限定我的查询以使事情顺利进行，这只会增加压力。我想我不会再这样做了

此外，从数量的角度来看，在数千人中找到一个数据库也不是我心目中的好下午。我不喜欢为了找到故障排除所需的数据而跳过50步

---

对于单个DB，一个连接就可以正常工作。从开发人员的角度来看，这要容易得多。我很难说性能方面的好处是什么，因为我们的应用程序最受效率极低的框架（遗留Symfony）

我们正在创建一个类似的结构应用程序，人们可以注册并创建自己的内部应用程序。我们使用的是MySQL，所有数据都存储在同一个数据库中。我们以这样一种方式构建了这些表，即使用登录凭据，可以轻松地在整个站点中识别所有数据，并在需要时获取这些数据。

可以有不同的实现方法，每种方法都取决于应用程序的性质，例如为每个用户提供了什么功能，涉及哪些用户数据以及这些数据之间的关系，涉及多少用户数据等

方法1：单一应用程序数据库；根据应用程序的功能/结构提供多个表，但这些表包含所有用户的数据。例如，

评论

，

权限

，

类别

等

优点：结构简单，易于快速检索和插入

缺点：如果表太大或涉及复杂的索引，数据库操作可能会变得昂贵

方法2：单一应用程序数据库；根据应用程序的功能/结构提供多个表；每个用户都有自己的表集，可能由用户id标识。例如，对于用户id=1，表可能是

注释\u 1

，

权限\u 1

，

类别\u 1

等

优点：结构简单；易于识别要为特定用户查询的表；由于表将只包含特定用户的数据，因此至少少了一个WHERE子句（WHERE user_id=xx）；较小的表，因此检索更快；在繁忙时间锁冲突的机会更少

缺点：需要更多的维护；添加需要添加新列或表的更新功能，需要对所有用户表集进行模式更改

方法3：每个用户有多个应用程序数据库

优点：用户之间的数据100%隔离；如果每个用户都需要自定义的功能，则可以轻松调整DB模式；易于跨多台服务器拆分数据库，以实现负载平衡

缺点：复杂的架构；需要更多的维护；存储公共或共享数据更为棘手-数据可以复制到每个用户数据库，也可以维护一个公共数据库

我认为，如果模式的有效设计能够在更快的选择/插入和每个表的数据量之间保持平衡，那么第一种方法对于100-10000个用户来说应该可以很好地工作。然而，它需要大量的数据库调优和智能索引

从方法2和3来看，两者都很好，但从我的角度来看，方法3更好，因为它给了您更多的灵活性。实现可能需要一些时间，但不难实现

此外，SQLite似乎不适合这样的实现。我建议使用像MySQL这样的关系数据库

---

希望以上内容能让您对实现有所了解，并帮助您确定哪些最适合您的应用程序。

我建议您研究一些新的创新型数据库。对于巨大的数据集，当数据量超过某一点时，正常的SQL数据库开始不足。这就是谷歌创建BigTable项目（）的原因。这也是NoSQL运动（）背后的原因

我特别推荐使用MongoDB（）。它是一个NoSQL数据库，以面向对象的方式将信息存储在类似JSON的文档集合中。一开始有点让人头疼，但它很有效，而且速度快得离谱。我有一个朋友，他使用MongoDB和Zend框架推出了一个全新的动漫网站，他的网站速度与谷歌提供的任何东西一样快，甚至更快，他在一台专用服务器上运行

您可以在
下面是一个关于将其与CakePHP一起使用的指南：
这个