Changement cardinalité attribut de schéma basé sur un autre attribut

Question

j'ai les schémas pseudo suivants:

A)

-- Cost-schedule: FRE494 
    -- Periodic: false 
    -- Type: Fixed 
    -- Value: 70.00 
    -- CCY GBP 

B)

-- Cost-schedule: GHK999 
    -- Periodic: true 
    -- Period start: 01/04/2015 
    -- Period end: 30/04/2015 
    -- Type: Promise 
    -- Filled: false 
    -- Value: 0.00 
    -- CCY: GBP 

Je suis en train d'éviter toute sorte de hiérarchie méchant avec une super classe "Cost-Schedule" avec des sous-classes "Periodic" et "One-off". Premièrement, j'utilise clojure qui n'est pas OO. Aussi ne veulent pas tomber dans le piège de substitution Liskov. Donc, en tant que novice de Datomic, existe-t-il un moyen de modifier dynamiquement le schéma afin qu'une cardinalité d'attributs soit modifiée en fonction d'une autre valeur d'attribut. Dans ce cas, si Periodic est "false", nous n'avons pas besoin d'avoir Period-Start, Period-End. Si Periodic est "true", nous devons appliquer des valeurs pour ces attributs. Mon instinct dit, ce n'est pas possible. Si non, comment puis-je l'appliquer dans la base de données? Il me semble que si je dois valider explicitement la transaction avant de la soumettre à l'opérateur, alors je ne fais que définir un schéma en dehors des contraintes de Datomic qui ne semble pas sage, étant donné que beaucoup de micro-systèmes seront écrire/lire à partir de la BD et coordonner les humains pour écrire du code «correct» est difficile!

Toute aide sur la façon de surmonter ce défi très apprécié.

Answer 1

Je vois deux sous-réponses à votre question.

La première est que Datomic ne définit pas "objets". C'est vraiment plus proche d'une carte simple. Votre entité B a 3 champs que l'entité A n'a pas. C'est très bien et ce n'est pas contrôlé par Datomic. Chaque paire attribut-valeur peut être ajoutée à n'importe quelle entité indépendamment de toute autre entité. Juste parce qu'une carte a 4 entrées, elle n'a pas de relation avec une autre carte ayant 7 entrées, même si toutes les clés de la carte A sont également dans la carte B.

La 2ème sous-réponse est que votre application doit faire tout validation & vérification de l'intégrité - Datomic ne sera pas. Il n'y a pas d'analogue à "UNIQUE NOT NULL" dans SQL, etc. Cependant, Datomic supporte Database Functions qui ont une chance d'annuler toute transaction qui échoue à un test fourni par l'utilisateur. Donc, c'est une façon de faire respecter les contrôles d'intégrité des données.

Veuillez également consulter Tupelo Datomic, une bibliothèque que j'ai écrite pour rendre l'utilisation de Datomic plus facile.