如何将相关的业务模型对象存储在键值存储中？答案

【问题标题】：How to store related business model objects in a key value store?如何将相关的业务模型对象存储在键值存储中？
【发布时间】：2018-03-12 16:36:03
【问题描述】：

假设这个模型和一个支持获取整个对象而不仅仅是标量类型的键值存储：

class Country
{
    public string Name { get; set; }
}

class Company
{
    public string Key { get; set; }
    public string Name { get; set; }
    public Country Country { get; set; }
}

var bmw = new Company
{
    Key = "bmw",
    Name = "Bayerische Motoren Werke",
    Country = new Country { Name = "Germany" }
};
var vw = new Company
{
    Key = "vw",
    Name = "Volkswagen",
    Country = new Country { Name = "Germany" }
};

myStore.Put(bmw.Key, bmw);
myStore.Put(vw.Key, vw);

问题：

如何在没有冗余数据的情况下处理 Company 和 Country 之间的关系？
Company.Key：将键存储在值中是个好主意吗？从技术上讲，它是多余的，因此是“坏的”。但在多层应用程序中传递“公司”后，我可能需要记住相关键。

【问题讨论】：

嗨。您的大胆问题很清楚-尽管很笼统。但细节尚不清楚，也不清楚它们如何提供“一种方法”NFs 而不是实现 FKs。您可以给出示例关系 DDL 和数据以及相应的 KV 设计并清楚地解释——给出与minimal reproducible example 相关的尽可能多的内容。但这仍然不会显示如何处理关系和 NF 解决的设计问题。规范化本身不会添加 FK——它在表之间共享列，而每个共享在 all 表中具有相同的子行值。一些共享对在 1 个或两个方向上都有 FK。阅读我们为什么要规范化。
What is Normalisation (or Normalization)?的可能重复
规范化是删除重复数据的过程，但键值不是这样的..
我没有问“什么是规范化”，而是“它甚至存在于键值存储中”。但我担心，键值存储并不是为了规范化，而是为了快速。
请注意，尽管回答了这个问题，但我并不认为它特别适合 StackOverflow。 Software Engineering StackExchange 更欢迎那些倾向于理论而不是具体和实际的问题（如果你问的是键/值存储作为一个类，而不是任何特定的实现——这可能会或可能不会允许服务器端约束执行——你在世界的“理论”与“实践”方面非常遥远）。

标签： database-normalization key-value-store

【解决方案1】：

考虑以下键/值对示例——使用不是数字标识符而是有意义的、标准主体分配的主键：

Country.de.Name=Germany
Company.1.Name=BMW
Company.1.Country=de
Company.2.Name=VW
Company.2.Country=de

这在尊重国家的情况下有意义地标准化：架构设计使得国家名称只存储一次，只能存储一次（防止任何潜在的数据冲突）。

“完整性检查”和“外键”是与规范化无关的概念；也就是说，我会注意到 some 元组存储（其中键/值存储实际上是退化子集）确实支持约束执行；例如，在 Datomic 中，这是通过事务函数实现的。

同样，Redis 可以让任意 Lua 代码在服务器端运行，这是应用程序可以用来执行约束的功能。 简而言之：有可能对键/值存储中的内容进行有意义的规范化。

【讨论】：

所以，您的建议基本上是仅使用标量类型并在将域模型对象放入商店时将其分解，并在我想检索它时将其组装回来？在我的业务模型中，我宁愿使用对象而不是键值对。我看到的键值存储支持对象作为键和值。这就是样本将整个公司视为“价值”的原因。