cde*_*zaq 38 database key-value relational-database
何时可以在关系数据库上选择键值数据存储？决定一方或另一方需要考虑哪些因素？什么时候混合最好的路线？如果可以,请提供示例.
Jef*_*vis 24
键值,层次,地图缩减或图形数据库系统更接近实施策略,它们与物理表示密切相关.选择其中之一的主要原因是,如果存在令人信服的性能参数,并且它非常符合您的数据处理策略.请注意,即席查询通常对这些系统不实用,您最好提前决定查询.
关系数据库系统试图将逻辑的,面向业务的模型与底层物理表示和处理策略分开.这种分离是不完美的,但仍然很好.关系系统非常适合处理事实并从事实集合中提取可靠信息.关系系统在ad-hoc查询方面也很出色,而其他系统则非常糟糕.这非常适合商业世界和许多其他地方.这就是关系系统如此普遍的原因.
如果它是一个商业应用程序,关系系统几乎总是答案.对于其他系统,它可能就是答案.如果您有更多的数据处理问题,例如需要发生的一些事情,并且您拥有大量数据,并且您事先知道所有查询,则另一个系统可能适合您.
小智 6
如果您的数据只是一个事物列表,并且您可以为每个项目派生唯一标识符,那么KVS是一个很好的匹配.它们是我们在新生计算机科学中学到的简单数据结构的紧密实现,不允许复杂的关系.
一个简单的测试:您能将您的数据及其所有关系表示为链表或哈希表吗？如果是,KVS可能有效.如果不是,则需要RDB.
您仍然需要找到适合您环境的KVS.对KVSes的支持,即使是主要的KVS,也远不及它的用途,比如PostgreSQL和MySQL/MariaDB.
Ale*_*lis -5
根据我的经验，如果您甚至问是否使用传统做法还是深奥做法的问题，那就选择传统做法。虽然深奥的实践很性感、具有挑战性且有趣，但 99.999% 的应用程序都需要传统方法。
关于关系与 KV，您应该问的问题是：
为什么我不想在这种情况下使用关系模型：...
由于您没有描述该场景，因此任何人都不可能告诉您为什么不应该使用它。KV 的“包罗万象”的原因是可扩展性，现在这不是问题。你知道优化的规则吗？
KV 是一种高度优化的可扩展性解决方案，对于您的应用程序来说很可能完全不需要。