postgresql 与 mysql 在易于扩展以及对于高度相关（大量外键）数据库的实用性方面比较

Question

好的，我已经阅读了很多关于 PostgresSQL 的内容，它似乎有一些看起来非常棒的功能，我真的很喜欢能够更新表并添加列/索引而无需等待数据库的想法并将其锁定。而且就性能而言，它似乎与 MySQL 一样快。但我最担心的是与我的系统一样相关的扩展它的难易程度。

现在，我的表都具有外键并且相互关联以便于使用，并且我经常使用外键。举个例子，我有一个“玩家”表，其中有许多与之相关的表。我有以下从中分支出来的表格。

1. players_mailplayers_mail_attachmentsplayers_bankplayers_inventoryplayers_effectsplayers_effects_tempplayers_questsplayers_quests_tasks
2. ​
3. 列表
4. 继续
5. 。
6. 还在
7. ...
8. ​
9. ​

​我还有其他一些表，它们都使用players表的id作为索引之一，并与players.id列相关联。邮件也有一个邮件的外键，其他的也有关系。 PostgreSQL 能否很好地适应数据库的关系？我在大多数表上也有一些索引。所有不是“根”表的表（例如玩家表）都有两个索引，即主键索引和外键索引。

我已经读到 postgres 不会自动在外键上创建索引，所以我知道我可能必须手动创建这些索引。正如我所说，Postgres 处理此类数据集的效果如何？我确信其他人已经在我之前在 RDBMS 中创建了高度关系数据库，我很想听听他们的经验。

编辑添加：

我主要关注它是因为它如何处理写入期间的锁定，也因为我不知道我对 Oracle 的感觉如何，以及依赖 xtradb 作为数据库格式。尽管我知道 MariaDB 正在开发自己的数据库格式，但我仍然不喜欢我最喜欢的数据库格式受到一家可能会扼杀它的公司的控制，或者更糟糕的是使其完全闭源。在我浏览完 postgresql 并了解如何轻松地将数据库移至其中并查看其工具后，我将选择最好的答案，我还会将其保留 24 小时，以便人们可以修改任何内容他们希望。

编辑2：

我终于真正开始研究数据库格式本身，虽然我真的很喜欢一些我无法忍受面向对象的东西，但它让我发疯。我已经完全准备好去 postgres 了，直到我意识到它是在面向对象的一半之后建模的，我想我最后的问题之一是，它不会强迫我正确使用类和对象？维基百科说它是 OOP 和 RDMB 之间的一座“桥梁”，因此我认为它是因为我仍然可以按照我喜欢的方式做所有事情。如果这就是它的工作原理，那么我可能会喜欢这个数据库，如果不能，那么我会讨厌它。我不想讨厌一个对于这件事的成功至关重要的工具。

Answer 1

300 个具有大量外键和索引的表，大约 150 个具有超过 1000 条记录的表，大约 20 个具有超过 100000 条记录的表对您来说足够大吗？

从未遇到过由 PostgreSQl 本身引起的性能问题。大约 15 个子选择的 400 多行查询在一秒钟内运行。

总结一下：PostgreSQL 的扩展性非常好。当然无法与 Oracle 相媲美，但它可以完成任务。唯一的提示：如果您非常关心性能 - 用规则替换触发器，并在可能的情况下使用视图而不是存储过程

Answer 2

如果您真的担心扩展，那么最终您应该停止依赖数据库中的外键并在应用程序级别处理它。

就扩展 MySQL 与 Postgres 而言，您大多会遇到相同的障碍，因为它们都是非常快速且稳定的 RDBMS。

话虽如此，Postgres 比 MySQL 更符合 ACID，它可以根据您的需要处理 FK，我通常会根据您在帖子中表达的内容推荐它。

Answer 3

你用什么并不重要。一切都取决于应用程序和架构。例如，如果你做一点冗余，外键并不会造成太大影响。
示例：

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;

如果读取次数多于写入次数，这是有意义的。