sql >> Databáze >  >> NoSQL >> MongoDB

Doporučené postupy NoSQL

Myslím, že v současné době je celá myšlenka datových úložišť NoSQL a koncept databází dokumentů tak nový a odlišný od zavedených myšlenek, které řídí relační úložiště, že v současnosti existuje jen velmi málo (pokud vůbec nějaké) osvědčených postupů.

V tuto chvíli víme, že pravidla pro ukládání vašich dat v rámci řekněme CouchDB (nebo jakékoli jiné databáze dokumentů) se poněkud liší od pravidel pro relační databázi. Například je do značné míry faktem, že normalizace a směřování k 3NF není něco, o co by člověk měl usilovat. Jedním z běžných příkladů by byl jednoduchý blog.

V relačním obchodě byste měli tabulku pro „Příspěvky“, „Komentáře“ a „Autoři“. Každý autor by měl mnoho příspěvků a každý příspěvek by měl mnoho komentářů. Toto je model, který funguje dostatečně dobře a dobře mapuje jakoukoli relační DB. Ukládání stejných dat v docDB by však s největší pravděpodobností bylo poněkud odlišné. Pravděpodobně byste měli něco jako sbírku dokumentů Post, z nichž každý by měl svého vlastního autora a sbírku komentářů přímo v sobě. Samozřejmě to pravděpodobně není jediný způsob, jak to udělat, a je to určitý kompromis (nyní dotazování na jeden příspěvek je rychlé – uděláte pouze jednu operaci a dostanete vše zpět, ale nemáte žádný způsob, jak udržet vztah mezi autory a příspěvky (protože se to všechno stává součástí dokumentu příspěvku).

Také jsem viděl příklady využívající atribut "type" (v příkladu CouchDB). Jistě, to zní jako životaschopný přístup. Je to nejlepší? Nemám tušení. V MongoDB byste určitě použili samostatné kolekce v rámci databáze, takže atribut type je naprostý nesmysl. I když v CouchDB... možná to je nejlepší. Ostatní alternativy? Samostatné databáze pro každý typ dokumentu? Zdá se to trochu zamotané, takže bych se sám přiklonil k "typovému" řešení. Ale to jsem jen já. Možná existuje něco lepšího.

Uvědomuji si, že jsem se tu toho dost rozepsal a řekl velmi málo, pravděpodobně nic, co byste už nevěděli. Jde mi však o toto – myslím, že je na nás, abychom experimentovali s nástroji, které máme, a s daty, se kterými pracujeme, a časem se dobré nápady rozšíří a stanou osvědčených postupů. Jen si myslím, že se ptáte příliš brzy ve hře.



  1. MongoDB agregujte skupinu na vnitřní podřízené kolekci a získejte kompletní dokument s počtem

  2. Údržba sad replik MongoDB v cloudu pomocí Ansible

  3. Kompozitní klíč MongoDB

  4. Ember-data a MongoDB, jak zacházet s _id