Je me suis penché sur Datomic , et ça a l'air vraiment intéressant. Cependant, alors qu'il semble y avoir de très bonnes informations sur le fonctionnement technique de Datomic , je n'ai pas vu grand-chose sur la manière de penser à la modélisation des données.
Quelles sont les meilleures pratiques pour la modélisation de données dans Datomic? Existe-t-il de bonnes ressources sur le sujet?
Comme Datomic est nouveau et mon expérience est limitée, cette réponse ne devrait pas être considérées comme des pratiques exemplaires en aucune façon. Prendre cette place comme une intro à Datomic pour ceux avec un arrière-plan relationnel et un penchant pour une plus productif magasin de données.
Dans Datomic, le modèle de votre domaine de données comme des Entités qui possèdent des Valeurs pour les Attributs. Car une référence à une autre Entité peut être la Valeur d'un Attribut, vous pouvez modéliser les Relations entre les Entités , tout simplement.
Au premier coup d'oeil, ce n'est pas différent de la façon dont les données sont modélisées dans un cadre traditionnel de base de données relationnelle. En SQL, les lignes de la table sont les Entités et les colonnes nom des Attributs qui ont des Valeurs. Une Relation est représentée par une clé étrangère de la Valeur dans une table en ligne qui référence la clé primaire de la Valeur d'une autre ligne de la table.
Cette similitude est agréable car vous pouvez simplement dessiner votre traditionnel ER diagrammes lors de la modélisation de votre domaine. Vous pouvez compter sur des relations tout comme vous le feriez dans une base de données SQL, mais n'ont pas besoin de se compliquer la vie avec des clés étrangères puisque c'est fait pour vous. Écrit dans Datomic sont transactionnelles et vos lectures sont cohérentes. De sorte que vous pouvez séparer vos données en entités, quelle que soit la granularité se sent le droit, en s'appuyant sur les jointures pour fournir l'image plus grande. C'est un confort que vous perdez avec de nombreux NoSQL magasins, où il est courant d'avoir de GROS dénormalisés entités pour atteindre un certain niveau utile de l'atomicité lors des mises à jour.
À ce stade, vous êtes hors d'un bon début. Mais Datomic est beaucoup plus souple qu'une base de données SQL.
Le temps est intrinsèquement partie de tous les Datomic de données, donc il n'est pas nécessaire d'inclure spécifiquement l'histoire de vos données dans le cadre de votre modèle de données. C'est probablement le plus parlé de l'aspect de Datomic.
Dans Datomic, votre schéma n'est pas rigidement définis dans la "forme rectangulaire" requis par SQL. C'est, d'une entité[1] pouvez avoir tout ce que les attributs il a besoin pour satisfaire votre modèle. Une entité n'ont pas besoin d' NULL ou de valeurs par défaut pour les attributs qui ne le concernent pas. Et vous pouvez ajouter des attributs à un particulier, chaque entité que vous voyez l'ajustement.
Ainsi, vous pouvez modifier la forme des entités individuelles au cours du temps à être sensible aux changements dans votre domaine (ou des changements à votre compréhension du domaine). Et alors? Ce n'est pas à la différence de Document Magasins comme MongoDB et CouchDB.
La différence est que, avec Datomic vous pouvez adopter les modifications de schéma atomiquement sur toutes les entités concernées. Ce qui signifie que vous pouvez émettre une transaction de mise à jour de la forme de toutes les entités, fondée sur l'arbitraire du domaine de la logique, écrit dans votre langue[2], qui va l'exécuter sans affecter les lecteurs jusqu'à ce commis. Je ne suis pas au courant de quoi que ce soit à proximité de cette sorte de puissance dans le relationnel ou d'un document les espaces de stockage.
Votre entités ne sont pas rigoureusement défini comme le fait de vivre dans une seule table". Vous décidez ce qui définit le "type" d'une entité dans Datomic. Vous pouvez choisir d'être explicite et le mandat que chaque entité de votre modèle aura un :table attribut qui évoque ce "type" il est. Ou votre les entités peuvent se conformer à un certain nombre de "types" tout simplement par la satisfaction de l'attribut exigences de chaque type.
Par exemple, votre modèle de mandat:
:name, :ssn, :dob
:name, :title, :salary
:name, :address
:id, :plan, :expiration
Ce qui signifie qu'une entité comme moi:
{:name "Brian" :ssn 123-45-6789 :dob 1976-09-15
:address "400 South State St, Chicago, IL 60605"
:id 42 :plan "Basic" :expiration 2012-05-01}
peut être déduit d'un Person, Resident et un Member mais PAS un Employee.
Datomic les requêtes sont exprimées en Datalog et peut incorporer des règles exprimées dans votre propre langue, la référence à des données et des ressources qui ne sont pas stockés dans Datomic. Vous pouvez stocker des Fonctions de Base de données en tant que valeurs de première classe à l'intérieur de Datomic. Ils ressemblent aux Procédures Stockées dans SQL, mais peuvent être manipulés comme des valeurs à l'intérieur d'une transaction et sont également écrits dans votre langue. Ces deux fonctionnalités vous permettent d'exprimer des requêtes et mises à jour dans un plus centré sur le domaine.
Enfin, la différence d'impédance entre les OO et les univers relationnels a toujours frustré moi. À l'aide d'une fonctionnelle, centrée sur les données de la langue (Clojure) vous aide à cela, mais Datomic semble durable fournir une banque de données qui ne nécessite pas de gymnastique mentale à pont de code pour le stockage.
Comme un exemple, une entité extraite de l'Datomic ressemble et agit comme un Clojure (ou Java) de la carte. Il peut être transmis à des niveaux plus élevés d'une application sans traduction dans une instance de l'objet ou des données générales de la structure. La traversée de cette entité relations ira chercher les entités liées de Datomic paresseusement. Mais, avec la garantie qu'ils seront compatible avec la requête d'origine, même dans le visage de mises à jour simultanées. Et ces entités apparaissent à la plaine de vieilles cartes imbriquée à l'intérieur de la première entité.
Cela rend la modélisation de données de plus naturel et de beaucoup, beaucoup moins d'un combat, à mon avis.
Des attributs conflictuels
L'exemple ci-dessus illustre un écueil potentiel de votre modèle. Si vous décidez plus tard que :id est également un attribut de l' Employee? La solution est d'organiser vos attributs dans des espaces de noms. Donc, vous avez à la fois :member/id et :employee/id. Faire de cette avance permet d'éviter les conflits plus tard.
Un attribut définition ne peut pas être changé (encore)
Une fois que vous avez défini un attribut dans votre Datomic comme un type particulier, indexé ou pas, unique, etc. vous ne pouvez pas changer cela plus tard. Nous parlons ALTER TABLE ALTER COLUMN dans SQL le langage ici. Pour l'instant, vous pouvez créer un remplacement de l'attribut avec le bouton droit de la définition et de déplacer vos données existantes.
Cela peut sembler terrible, mais il ne l'est pas. Parce que les transactions sont sérialisées, vous pouvez soumettre un qui crée un nouvel attribut, des copies de vos données, résout les conflits et supprime l'ancien attribut. Il sera exécuté sans interférence avec d'autres transactions et peut profiter d'un domaine spécifique de la logique dans votre langue maternelle à le faire. C'est essentiellement ce qu'un SGBDR est fait en arrière-plan lorsque vous émettez un ALTER TABLE, mais vous nom les règles.
Ne pas être "un gamin dans un magasin de bonbons"
Flexible schéma ne veut pas dire pas de modèle de données. Je vous conseille une petite planification initiale pour modèle les choses d'une façon saine, même comme vous le feriez pour n'importe quel autre magasin de données. L'effet de levier Datomic de souplesse en bas de la route lorsque vous devez, non seulement parce que vous le pouvez.
Éviter de stocker de gros, en changeant constamment de données
Datomic n'est pas une bonne banque de données pour les objets Blob ou de données très volumineux qui change constamment. Parce qu'il conserve un historique des valeurs précédentes et il n'y a pas une méthode pour purger les anciennes versions (encore). Ce genre de chose est presque toujours un meilleur ajustement pour un magasin d'objets comme le S3.
Une très belle réponse de bkirkbri. Je veux faire quelques ajouts:
Si vous stockez un grand nombre d'entités similaires, mais pas égal à "types" ou des schémas, l'utilisation d'un type de mot-clé dans le schéma, comme
[:db/add #db/id[:db.part/user] :db/ident :article.type/animal]
[:db/add #db/id[:db.part/user] :db/ident :article.type/weapon]
[:db/add #db/id[:db.part/user] :db/ident :article.type/candy]{:db/id #db/id[:db.partie/db] :db/ident :article/type de :db/valueType :db.type/mot-clé :db/cardinalité :db.cardinalité/un :db/doc "Le type d'article" :db.installer/_attribute :db.partie/db}
Lorsque vous les lisez, obtenir de l'entité-id à partir d'une requête et d'utiliser datomic.api/entity et de la eid et les analyser par multimethods envoi sur le type si nescessary, car il est difficile de faire une bonne requête pour tous les attributs dans certains plus complexes schéma.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
