好的，我已经阅读了很多关于PostgresSQL的内容，它似乎有一些看似非常棒的功能，我真的很喜欢能够更新表并添加列/索引而无需等待的想法对于数据库并将其锁定。当谈到性能时，它似乎也和MySQL一样快。但我最担心的是通过与我的系统关系来扩展它的容易程度。
现在我的表都有外键并且相互关联以便于使用，我使用外键很多。举个例子，我有一个“玩家”表，然后有许多表格与之相关。我有以下表格分支出来。
并继续列表。我有一些其他的表，他们都使用player表的id作为他们的索引之一，并回到players.id列。邮件也有邮件的外键，其他邮件也是关系密钥。 PostgreSQL是否可以很好地适应数据库的关系？我在大多数表上也有一些索引。所有不是“根”表的表（如播放器一个）都有两个索引作为主键，然后是外键的索引。
我已经读过postgres不会自动在外键上创建索引，所以我知道我可能不得不手动创建这些索引。据我所说，Postgres处理这种数据集的效果如何？我确信那里的其他人已经在我之前在RDBMS中创建了一个高度关系数据库，我很想听听他们的经历。
编辑添加：
我主要是看它，因为它在写入期间如何处理锁定，还因为我不知道我对oracle的感觉，并且依赖于xtradb作为数据库格式。虽然我知道MariaDB正在研究它自己的数据库格式，但我仍然不喜欢我最喜欢的数据库格式在一家可能会杀死它的公司的控制之下，或者更糟糕的是让它完全封闭。在我浏览postgresql之后，看看我如何轻松地将数据库移动到它并查看它的工具，我会选择哪个答案最好，我也会将它打开24小时以便人们可以修改任何他们希望。
编辑2：
我终于真正开始关注数据库格式本身，虽然我真的很喜欢一些我无法忍受面向对象的事情，但它让我感到疯狂。我已经完全准备好去postgres，直到我意识到它是在面向对象的一半之后建模的，我想我最后一点问题是，它不会强迫我使用类和对象正确吗？维基百科说它是OOP和RDMB之间的“桥梁”，因此我接受它，因为我仍然可以按照我喜欢的方式做所有事情。如果它是如何工作的，那么我可能会喜欢这个数据库，如果我不能，那么我会讨厌它。而且我宁愿不讨厌对这件事的成功至关重要的工具。
答案 0 :(得分：4)
包含大量外键和索引的300个表，大约150个记录超过1000条记录的表，大约20个记录超过100000条记录的表对您来说足够大了吗？
从未遇到PostgreSQl本身导致的性能问题。超过400个行的查询，大约15个子选择在一秒钟内运行。
总结一下：PostgreSQL可以很好地扩展。当然，甲骨文不匹配，但它完成了工作。唯一的提示：如果您非常关注性能 - 用规则替换触发器并使用视图而不是存储过程（如果可能）
答案 1 :(得分：1)
如果您真的担心扩展，那么最终您应该停止依赖数据库中的外键并在应用程序级别处理它。
就扩展MySQL与Postgres而言，由于它们都是非常快速且稳定的RDBMS，因此你们大多会遇到相同的障碍。
所有这一切，Postgres比MySQL更符合ACID，它会根据您的需要处理FK，我通常会根据您在帖子中表达的内容推荐它。
答案 2 :(得分：0)
使用什么并不重要。一切都取决于应用程序和架构。例如，如果你做一点冗余，外键不会受到太大伤害。 例如：
players(id, ....)
players_quests(id, player_id, ....)
players_quests_tasks(id,player_quest_id, ...)
要查找players_quests_tasks属于某些玩家，您需要加入。 解决方案：将player_id添加到players_quests_tasks表。 它是中断规范化但没有连接：
players_quests_tasks(id,player_quest_id, player_id,...)
SELECT * FROM players_quests_tasks WHERE player_id=:player_id_to_find;
如果你有更多的读数而不是写作，那就没有意义。