有问题。更好有更多的分贝或更多的表？
我的问题之前，我想添加标签像DB-优化，但标签不存在。
我实际上有很多表的我的分贝，即时通讯编写一个程序，对企业解决方案做一些工作，我有一个可以被程序员看到的“alpha”系统，程序员看到的“beta”系统和一些用户和生产系统。现在
，我已经得到了很多表的（不是全部），如那些：
我知道我可以代替把所有的beta和alpha表格在他们自己的数据库（我可以创建一个我需要的），并改变所有关系需求。
我已经知道在单表的大小MySQL数据库的限制，并最终对数据库文件本身（如果不分裂）。我也知道把它们分开可以帮助一点操作的表现。
您认为如何？哪种解决方案更好？实际的一个或数据库分离一个？
至于一些参考的应用程序是一个网络游戏，将存储，让我们从120MB说为200MB的游戏系统和近5MB最低为每个玩家。
在此先感谢您的答复。
这太长了评论。
如果您在兆字节计数，你没有在附近现代系统或数据库的限制。这些与您的解决方案无关。
您应该将应用程序封装在单个数据库中，面向生产系统。然后，您应该拥有此数据库的副本以用于开发，测试，性能调整和其他应用程序。您不应该将来自在线应用程序的数据混合到其他系统中 - 除非您有意使用复制机制或其他有意识的系统复制它。
我很难想象将测试表放入您的生产系统的好处。
然后在你的代码，当你打开一个表，你必须说
if environment = "alpha" then
table="foobar_alpha"
elseif environment = "beta" then
table="foobar_beta"
else
table=foobar"
endif
或者稍好
table="foobar" & environment
（我用VB的例子。小的区别，如果另一语言）。
或者更糟糕的是，你有更多更复杂的东西。
这看起来好像只是向您提供程序错误的可能性，导致将测试数据写入生产表的可能性，仅仅因为在指定表名的数百或数千个地方之一中，有人忘记了编写代码以获取正确的表名。
这也意味着您的所有查询都必须与表格名称“动态组合”，而不是仅仅具有静态查询字符串。如果您使用存储过程，则必须拥有存储过程的多个副本。
还有更可怕的是，无论何时你更新一个表格定义，你都必须进行更新3次。如果你犯了一个错误，并且它不完全相同，那么你可以发现在测试中运行的代码在生产时不起作用。
这似乎造成了很多问题，我只是没有看到任何优势。
因此不，创建一个生产数据库，只需要生产所需的表格。然后复制这个数据库用于开发和测试。
我没有使用复制系统，我允许编辑在alpha系统上创建编辑线，之后该线进入beta版，经过批准（并经过测试）后将返回到生产系统。每个系统得到它的配置和数据库自动操作将只在系统处于状态“维护”时完成 –
这只是为了没有重复的系统并使用较小的资源可能，我试图在创建它之前这样想。 –