key/value (général) et tokyo cabinet (python tc-specific) question

Question

Je suis dans le monde des SGBDR depuis de nombreuses années mais je souhaite explorer l'ensemble du mouvement nosql. alors voici ma première question:

Est-ce une mauvaise pratique d'avoir la possibilité de dupliquer des clés? Par exemple, un carnet d'adresses avec un nom de famille (probablement un élément de recherche?) peut avoir plusieurs entités. Est-ce une mauvaise pratique d'utiliser le nom de famille alors? est la clé supposée être la définition la plus «interrogeable» de l'entité? Existe-t-il des ressources pour les «meilleures pratiques» dans ce nouveau monde (pour moi)?

Je suis intrigué par tokyo cabinet (et en particulier l'interface tc), mais je ne sais pas comment itérer à travers différentes entités qui ont la même clé (voir par exemple ci-dessus). Je peux seulement obtenir la première entité. de toute façon, merci d'avance pour l'aide

Answer 1

Cela dépend de l'implémentation no-sql. Cassandra, par exemple, permet des requêtes de plage, de sorte que vous pouvez modéliser des données pour faire des requêtes sur le nom de famille, ou avec le nom complet (en commençant par le nom, puis le prénom). Au-delà de cela, beaucoup de magasins de valeurs-clés plus simples exigeraient en effet que vous stockiez une structure de liste (ou similaire) pour les entrées à valeurs multiples. Que cela soit faisable ou non dépend du nombre attendu de «doublons» - avec le nom de famille, le nombre pourrait être plutôt élevé, je présume, donc cela ne semble pas être un modèle idéal pour de nombreux cas.

Answer 2

Dans un magasin de valeurs-clés, vous ne pouvez pas avoir des clés en double, il y a une seule valeur derrière une clé. Pour avoir des clés dupliquées, vous pouvez utiliser la base de données B + Tree dans Tokyo Cabinet qui a des valeurs ordonnées et permet la duplication (vous pouvez les accéder en allant au premier élément avec cette clé et en itérant). Tous les problèmes ne sont pas facilement résolus par un magasin de valeurs-clés car vous avez besoin de la clé pour récupérer l'article. Peut-être que quelque chose comme MongoDB est plus approprié que permet des requêtes plus complexes.