1

Assume this model and a key-value store that supports to take whole objects and not only scalar types:

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);

Questions:

  1. How would I deal with the relation between Company and Country without having redundant data?
  2. Company.Key: Is it a good idea to store the key inside the value? Technically it is redundant and therefore 'bad'. But after passing a 'Company' around in a multi layer application, I might need to remember the related key.
sa.he
  • 1,391
  • 12
  • 25
  • 2
    Hi. Your bold question is clear--though general. But details are not clear & it's not clear how they give "an approach to" *NFs* rather than implementing *FKs*. You could give example relational DDL & data & a corresponding KV design & clearly explain--give as much as is relevant of a [mcve]. But that still won't show how to deal with the design problems relations & NFs solve. Normalization doesn't add FKs per se--it shares columns among tables while *every* sharing has *the same* subrow values in *all* tables. *Some* sharing pairs have a FK in 1 or both directions. Read re why we normalize. – philipxy Mar 12 '18 at 21:36
  • Possible duplicate of [What is Normalisation (or Normalization)?](https://stackoverflow.com/questions/246701/what-is-normalisation-or-normalization) – philipxy Mar 12 '18 at 21:48
  • Normalization is process of removing duplication of data but key value is not the case .. – sandeep rawat Mar 13 '18 at 07:02
  • I did not ask "what is normalization", but "does it even exist for key-value-stores". But I fear, that key-value-stores are not intended to be normalized, but just to be fast. – sa.he Mar 13 '18 at 23:17
  • Note that despite answering this question, I do not consider it a particularly good fit for StackOverflow. [softwareengineering.se] StackExchange is much more welcoming to questions that lean towards the theoretical and away from the concrete and practical (and if you're asking about key/value stores *as a class*, as opposed to any specific implementation -- which may or may not permit server-side constraint enforcement -- you're very far on the "theoretical" vs "practical" side of the world). – Charles Duffy Mar 13 '18 at 23:41

1 Answers1

0

Consider the following example of key/value pairs -- using not a numeric identifier but a meaningful, standards-body-assigned primary key:

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

This is meaningfully normalized as respecting countries: The schema design is such that country name is only stored once, and can only be stored once (preventing any potential for conflicting data).

"Integrity checks" and "foreign keys" are unrelated concepts to normalization; that said, I will note that some tuple stores (of which key/value stores are effectively a degenerate subset) do support constraint enforcement; in Datomic, for example, this is implemented via transaction functions.

Redis, likewise, can have arbitrary Lua code run server-side, a capability which applications could use for constraint enforcement. In short: It is possible to have meaningful normalization for content in key/value stores.

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
  • So, your suggestion is basically to only use scalar types and disassemble my domain model object at the time of putting it to the store and assemble it back once i'd like to retrieve it? In my business model, I'd rather work with objects than key-value-pairs. The key-value-stores that I looked at support objects as key and value. That is why the sample puts the whole Company as 'value'. – sa.he Mar 14 '18 at 07:07