自组装多应用程序的数据库结构

Question

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

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

• 所有客户在一个表格中按客户ID分隔。
• 每个拥有自己的DB + DB用户的客户。
• 在每个文件夹中使用一个SQLite文件。

Answer 1

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

方法1 ：单一应用数据库;根据应用程序的功能/结构，多个表，但表保存所有用户的数据。例如，comments，permissions，categories等。

专业人员：简单的架构，简单快捷的检索和插入

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

方法2 ：单一应用数据库;根据应用程序的功能/结构的多个表;每个用户都有自己的表集，可能由user_id标识。例如，对于user_id = 1，表格可能是comments_1，permissions_1，categories_1等。

pros ：再次简单的架构;易于识别要查询特定用户的表;因为表只包含特定用户的数据，所以至少有一个WHERE子句（其中user_id = xx）;较小的表格，因此检索速度更快;繁忙时段锁定冲突的可能性更小

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

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

专业人员：用户之间100％的数据隔离;如果每个用户都需要定制功能，那么很容易调整数据库架构;易于跨多个服务器拆分数据库以实现负载平衡;

缺点：复杂的架构;需要更多的维护;更难以存储公共或共享数据 - 可以将数据复制到每个用户数据库，也可以维护公共数据库。

我认为如果架构有效设计，以便在更快的SELECT / INSERT和每个表的数据量之间保持平衡，第一种方法应该适用于100-10000个用户。但是，它需要大量的数据库调优和智能索引。

从方法2和方法3开始，两者都运行良好但从我的角度来看，方法3更好，因为它为您提供了更大的灵活性。实施可能需要一些时间，但

并不困难

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

希望上面提供一些有关实施的见解，并帮助您确定哪种方法最适合您的应用。

Answer 2

如果你要变大（可扩展），那么SQLite可能不是你最好的选择。真正的RDBMS效率更高。话虽这么说，如果你真的要扩展蛋糕可能也不是最有效的选择。这些是您根据自己的商业模式做出的决定。有抱负是好的，但很少成为一个10,000磅的大猩猩......双关语。

我的公司有一个应用程序，可以为数十个客户进行营销自动化，这些客户使用通用数据库执行常用功能，使用单独数据库执行唯一数据。是的，它有效，而且它实际上非常高效，并且可以很好地分离数据，因此数据库不会失控......实际上，共享数据库具有包含数百万条记录的表。话虽这么说，跟踪你的连接STINKS，往往是我们错误的原因。只删除一个会话或实例化错误和BOOM！这是吐司。我经常发现自己必须完全限定我的查询以使事情有效，这只会增加压力。我不认为我会这样做。

另外，从绝对数量的角度来看，不得不在数以千计的数据库中找到数据库，这也不是我下午好时光的想法。我不喜欢跳过50来查找故障排除所需的数据。

使用单个数据库，一个连接就可以正常工作。从Dev的角度来看，它更容易。我很难说性能方面的好处是什么，因为我们的应用程序受制于极其低效的框架（遗留的Symfony）

Answer 3

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

Answer 4

我建议你看看一些新的创新类型的数据库。对于大型数据集，当数据量超过某个点时，正常的SQL DB开始不足。这就是Google创建BigTable项目（http://en.wikipedia.org/wiki/BigTable）的原因。这也是NoSQL运动背后的原因（http://en.wikipedia.org/wiki/NoSQL）。

我特别建议使用MongoDB（http://en.wikipedia.org/wiki/MongoDB）。它是一个NoSQL数据库，以面向对象的方式将信息存储在类似JSON的文档集合中。最初它有点包围你的头，但它工作，它是疯狂的快。我有一个伙伴使用MongoDB和Zend Framework推出了一个全新的动漫网站，他的网站和谷歌提供的任何东西一样快，如果不是更快，他在一个专用服务器上运行。

您可以在http://www.mongodb.org/找到MongoDB 以下是与CakePHP一起使用的指南：http://mark-story.com/posts/view/using-mongodb-with-cakephp
MongoDB网站还提供了更多相关信息：http://www.mongodb.org/display/DOCS/PHP+Libraries,+Frameworks,+and+Tools

Answer 5

我强烈建议您使用NoSQL设计。 NonSQL意味着可伸缩 - 非关系数据存储，没有连接和轻量级语义。 NonSQL方法将通过获取有关数据的新模型和观点来改进您开发应用程序的方式。

NoSQL DB倾向于使用磁盘上的内存作为第一类写入位置：Redis和Memcached仅在内存中，甚至像Cassandra这样的系统也使用memtables进行写入，异步刷新到磁盘，防止I / O性能不一致创造写速度瓶颈。由于NoSQL数据存储通常通过分区强调水平可伸缩性，因此这使它们处于利用云的弹性配置功能的优势地位。 NoSQL和云是天生的选择。

您有哪些选择？

NoSQL可以为某些场景提供更好的性能：

- 经常编写，很少读取网络点击计数器或日志设备数据的数据：Redis | MongoDB的

- 经常读取，很少编写/更新：用于瞬态数据缓存的Memcached，Cassandra |用于搜索的HBase，以及用于数据分析的Hadoop和Hive

- 需要最少停机时间的高可用性应用程序可以很好地处理群集的冗余数据存储：Riak |卡桑德拉

- 跨多个位置的数据同步：CouchDB

- 瞬态数据（网络会话和缓存）在瞬态键值数据存储中表现良好：Memcached

- 可能不遵循任何明显架构的业务或网站分析产生的大数据：Hadoop

组合？

也许您的应用程序更适合不同数据存储的明智组合。请查看此主题并选择。