Lors de la création d'objets qui utilisent des données stockées dans un SGBDR, il est généralement clair que vous récupérez les données en fonction des tables et des colonnes interrogées. Cependant, lorsque vous traitez avec NoSQL, les systèmes basés sur des documents, il est moins clair ce qui est récupéré.Styles de codage relationnel et NoSQL
Quelles sont les méthodes courantes de suivi de la structure dans laquelle les données sont stockées?
Cela dépend du pilote. Avec le pilote NORM, vous pouvez "sérialiser" et "désérialiser" une instance d'un objet dans et hors de la base de données. Il va lancer une erreur quand il y a un champ supplémentaire dans la base de données qui n'est pas présent dans la définition de la classe. C'est le comportement par défaut de NORM mais ils ajoutent la possibilité de le rendre plus flexible.
Lire ici: http://groups.google.com/group/norm-mongodb/browse_thread/thread/31102ec553a50e19
Non seulement cela dépend de ce que la base de données que vous utilisez, mais cela dépend aussi de la langue/cadre vous codez avec. La plupart des frameworks orientés attendent un ODM de quelque sorte où vous définissez un schéma qui est appliqué dans vos modèles - comme Rails, par exemple - et d'autres frameworks vous permettent de faire ce que vous voulez, ce qui vous met à risque d'avoir des données dans Pour les formats multiples et ne sachant pas quoi en faire ...
Pour MongoDB j'ai joué avec la notion d'un schéma doux, où chaque collection (table) a un document avec un titre de "schéma" et définit le différents éléments et leurs types de données dans un tableau intégré appelé "définition". Cela me permet de générer des échafaudages dynamiques basés sur chaque collection, et peut être très utile lors de l'intégration avec des plates-formes non-ODM - dans mon cas, Joomla.
Une autre approche consiste à stocker ces définitions de schéma dans une collection distincte appelée schémas ou schémas ou autres.
Vous souhaitez certainement verrouiller une sorte de schéma dans votre code pour vous assurer que vos données sont dans un format prévisible; Il est également important d'y répondre chaque fois que vos schémas changent, et ils le feront invariablement.
Il existe également des frameworks dans lesquels votre style de codage ne change pas trop, tel que playOrm, qui vous permet de stocker des données relationnelles dans un magasin noSQL et d'effectuer des jointures. L'astuce consiste à partitionner les données et Scalable SQL de façon à ce que la taille soit correcte et que vous puissiez toujours interroger vos données comme vous l'avez fait dans le passé.