我是否过度设计（可以这么说）这个应用程序？答案

【问题标题】：Am I over-engineering (jumping the shark, so to speak) this app?我是否过度设计（可以这么说）这个应用程序？
【发布时间】：2010-10-14 13:30:37
【问题描述】：

我的任务是从头开始为我工作的公司开发 CMS/引擎和网站管理员/后端。

我们所做的将被归类为“非常独特”（不过，不是每个人的情况都如此吗？）我正在寻找可以从使用起来非常痛苦的东西转向更好的系统的方法。

我们当前的系统以结构化格式提供文章、画廊、自定义数据（每天更新）和来自提要的数据（如天气信息），还为我们的会员提供论坛等。

我希望将一些内容从我们的核心应用程序中移出，其中一个是论坛，但其他大部分内容都将从头开始重建。目前一切都存储在 MySQL 数据库中，它的历史很差（当我接手项目时，加载时间约为 60 秒每页，在进行愚蠢的数据库调用和模型设计之后，已经减少到可接受的每页 0.2/0.3 秒）。

该网站本身是在 Rails 中构建的，无意改变它，但我现在正在看的是它是否适合查看其他数据库解决方案，而不是像 MySQL 这样的传统 RDBMS。

考虑到我们的大部分内容都是结构化的新闻项目（例如，具有多个属性的新闻项目，然后是我称之为不同内容的“块” - 文本、视频嵌入、图像、引用等）、画廊（文本和图像）我想知道使用 MongoDB 等面向文档的数据库是否理想。

就性能而言，我觉得它可以与设计良好的 MySQL 系统相媲美，并且考虑到该站点将被大量缓存（页面中的动态块使用 ESI 清漆），DB 时间并不是一个重要因素。

这个项目的另一件事是我们希望它是多租户的，因为我们可以托管不同的网站（例如，相同的类型（基本数据格式等）但不同的主题） - 它需要灵活地用于网站管理员/所有者自己设置新事物（即，当创建一个新站点时，我不应该设置一个全新的站点/服务器并进行代码更改等）。

我想知道我是不是想太多了，或者我对我需要为这一切做的事情的“预期”变得瘫痪了。

我的问题归结为：对于似乎真的不适合标准数据库表格式的东西，我应该考虑使用 MongoDB 或类似的东西，还是我在追求新的和闪亮的东西？

对不起，如果这有点乱七八糟...

【问题讨论】：

我无法回答这个问题，因为您误用了“跳跃鲨鱼”这个短语。

标签： content-management-system

【解决方案1】：

是的，你是。

我现在正在做一个类似的 CMS 类型的网站，我对使用哪个数据库有相同的决定。

我的结论基本上是坚持我所知道的：PHP 和 mySQL/Postgres。是的，Mongo 或其他 noSQL 可能更适合数据，但我需要时间来学习如何安装和使用它们，坦率地说，除非你有大量的流量，否则 mySQL/Postgres 不会导致性能问题。如果你保持你的数据库代码抽象，那么如果你需要的话，你可以在以后很多加入 Mongo/whatever。

正如 BarsMonster 所说，前端良好的 HTML 缓存方案将大大减少您的数据库使用量。如果需要，请使用 memcached。

保持简单，使用您熟悉的工具并发布。

【讨论】：

【解决方案2】：

您的绩效目标是什么？使用适当的缓存，快速前端 + MySQL 可以毫无问题地每秒处理 200-400 个请求（每个请求

如果你使用繁重的框架和垃圾代码，无论底层存储有多快，你每秒都会收到 5 个请求。

所以我的建议 - 使用 EASIER 并编写适当的代码，避免使用繁重的框架。

【讨论】：