我最近为处理近200张桌子的大学构建了一个相当复杂的数据库应用程序。一些表可以（例如出版物）保存30个或更多字段并存储10个一对一FK关系和多达2或3个多对多FK关系（使用交叉引用参考表）。我始终使用整数ID，并且规范化是每一步的关键。 AJAX很小，大多数页面都是标准的CRUD表单/流程。
我使用了Symfony 1.4和Doctrine ORM 1.2，MySQL，PHP。
虽然开发时间和易维护性的好处是巨大的（使用MVC和ORM），但我们一直遇到速度问题。也就是说，当我们有多个用户登录并且在任何时候都处于活动状态时，应用程序会慢慢减速（保存或编辑记录最多可达20秒）。
我们目前正在与我们的SysAdmin进行讨论，但他们说我们应该拥有足够的力量。有6个或更多用户参与活动，我们最终在虚拟服务器环境中排队4个CPU，而内存使用率很低（没有出血）。
当然，我们正在考虑对我们的mySQL应用程序进行多线程处理（如果这会有所帮助），改进我们的代码（虽然其中大部分是由MVC生成的）并改进我们的缓存使用（这可能会更好，尽管大多数使用的屏幕是特定于用户登录和动态的）;我们已经安装了APC，额外的内存，对我们的数据库进行了分解，我已经尝试取消设置所有记录集（虽然我知道这现在在ORM中是自动的），煽动手动垃圾回收......
但我问的问题是，mySQL，PHP和Symfony MVC实际上是否真的是开发这种大小的应用程序的不良选择？如果是这样，那么人们通常会使用/推荐这种大小/复杂度的基于Web的数据库接口应用程序？
答案 0 :(得分：3)
我对Symfony或Doctrine没有任何经验。但是，在这些项目上建立的网站肯定比您的网站大。例如，DailyMotion使用两者，并且它比几个同时用户服务更多。
同样，PHP和MySQL用于与维基百科一样大的站点，因此可扩展性应该不是问题。 （顺便说一下，默认情况下MySQL应该是多线程的 - 每个连接一个线程。）
当然，合理的表现是相对的。如果你试图在一个坐在壁橱里的米色盒子上运行一个提供200个并发请求的站点，那么你可能需要比拥有自己数据中心的财富500强公司更优化你的代码。
显而易见的事情实际上是对应用程序进行概要分析并查看瓶颈所在。对MySQL查询进行分析非常简单，并且还有PHP profiling tools类Xdebug。从那里你可以弄清楚你是应该切换框架，ORM（或者完全放弃ORM），数据库，还是重构一些代码，或者只是投入更多的处理能力。
答案 1 :(得分：1)
加速复杂数据库操作的最佳方法是不调用它们：）。
因此，请分析您可以缓存的应用程序的哪些部分 Symfony有一个非常好的缓存系统（在symfony2中甚至更好），可以非常精确地使用。
在数据库方面，另一种方法是使用视图或嵌套集来存储聚合数据 尝试找到合适的部分。