sql的纸牌游戏引擎

Question

我计划用sql创建一个卡片游戏引擎，游戏由4个人类玩家组成，卡片在sql表中，现在每件事都是关于游戏逻辑和点数，每个游戏都由一个单独的sql表管理，玩家可以创建房间

每个房间都应有一个游戏桌，其中包含卡片数据，每个玩家都会在一个列中进行重新排列和一个单独的聊天表

1. 如果有1000个游戏在同一个游戏中运行 时间和每次卡片播放然后对服务器进行请求 从玩家牌组记录员得分中移除一张牌 总游戏分数，可以在单个sql数据库中处理 没有延迟和性能问题？

2. 我可以为每个游戏室使用全局临时表## sometable吗？     我必须手动创建表并在之后删除它们     游戏结束了吗？

3. 我还想知道是否在单个sql中存储聊天数据     表会产生问题，我想到的一件事就是保存聊天数据     对于具有游戏ID列的单个数据表中的所有开放房间，但是     如果存在问题，这会给出一些性能问题吗？     聊天数据线？

4. 对于每个游戏的数据库怎么样，那将是结束 杀？

5. 如何正常管理此类应用程序？

6. 我是否必须使用多台服务器并分发正在运行的游戏     在他们身上？

7. 关于优化此类事情的任何想法

Answer 1

您应该考虑使用基于内存的缓存系统（如Velocity或Memcached）来解决性能问题。

Answer 2

1. 是。关于如何扩展这样的任务的讨论很长。
2. 你可以。但你应该考虑一个更智能的模型，即在一个表格中出现多个游戏。
3. 我会使用SQL Server Service Broker进行聊天
4. 是

我建议您将问题分解为多个问题，以便专门针对问题域的某个方面的贡献者可以做出相应的贡献。

我不知道PHP是如何运作的;但我相当肯定，很多游戏逻辑在客户端发生会更有效率。对每个游戏动作进行服务器调用都会起作用，我的意见只是它是次优的。

Answer 3

1. 是的，我希望现场球员在进行动作之前至少有1秒钟的延迟，并且每场比赛只有一场比赛正在进行。因此，1000场比赛每秒大约有1000笔交易达到峰值。对现代架构的负担不是很大。
2. 大多数DBMS中存在更多用于创建和销毁表的开销。把它们放在同一张桌子上。
3. 在单个表格中聊天会很好。您可以通过归档以前的非活动游戏中的聊天并从主要实时数据库中删除来提高性能。
4. 是的，非常低效。增加了复杂性，没有收获。
5. 不确定你在问什么。
6. 只有在你扩展的时候。我想你会从一个数据库服务器开始，直到你需要更多的容量。
7. 良好的设计数据库设计从一开始就有经验的人会有很长的路要走。不要浪费太多时间在开始时进行微观优化，否则你将永远不会离开地面。在扩展时根据需要进行优化。

Answer 4

简短版本是关系数据库（如SQL Server）对游戏不是很有用，因为它们无法有效存储结构严重的分层数据

我仍然主张避免使用SQL，但NoSQL中有更多选项，对于实际性能，您应该考虑使用快速临时存储，例如Redis或Memcache

您可以快速查看Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris comparison

优化是一个完全不同的主题..广泛和项目特定。