我正在考虑为客户编写一个快速聊天应用程序，以帮助他们解决一些通信需求。显然，编写一个简单的聊天内容并不简单，但该公司有严重的扩展需求，因此从一开始就在 noSQL 存储上构建服务可能是一个好主意。
除了明显缺乏事务（这不是我们关心的问题之一）之外，使用 noSQL 存储进行聊天是否是个好主意？
问问题
1712 次
3 回答
2
如果您追求可伸缩性和性能，MongoDB 应该足够好。大多数 SQL 引擎对于这些东西来说都是矫枉过正的。我怀疑您是否需要复杂的数据聚合和其他聊天数据查询。即使这样，MongoDB 也有 map-reduce 功能来帮助您。
于 2010-11-12T11:43:14.980 回答
1
如果您没有固定的数据模型，则使用NoSQL，这适用于面向文档的应用程序，您必须存储对象和文档，其中每个对象和文档可能具有不同的结构。
我认为您的情况并非如此，因为聊天日志具有定义明确的固定数据模型，例如（用户、时间、文本）。我认为传统的 SQL 数据库可能适合您。如果仅在客户端使用，SQLite将是最合适的，因为不需要安装或配置，只需重新分发 SQLite dll。占地面积也非常小。
于 2010-11-12T11:47:58.153 回答
0
我会说不。SQLite 包含在 PHP 中......为什么不直接使用它呢？或者更好的是，为什么不使用已经存在的数百个聊天应用程序之一，并为自己节省大量的开发时间。
于 2010-11-12T11:36:34.483 回答