Il team in cui mi trovo si sta muovendo per utilizzare couchbase anziché elasticsearch DB. Ora questo è solo un esempio, ma la mia domanda è più generale. In elasticsearch hai la nozione di relazioni genitore-figlio . Quando passiamo a un negozio di valori chiave standard non ne abbiamo. La mia domanda:
Supponendo che voglio imporre relazioni come:
- Una volta eliminato il genitore, tutti i bambini dovrebbero essere cancellati.
- Quando viene cancellato un figlio, i genitori che avevano un puntatore a questo bambino devono essere aggiornati.
- Child è un documento piuttosto grande, quindi abbiamo un puntatore da padre a figlio.
Con quale design andresti?
Opzione 1 : crea un livello generale sopra l'archivio KV che sa gestire le relazioni parent parent, in modo tale che i tuoi programmatori debbano solo specificare le relazioni e il tuo strato generico sofisticato-dao saprà per gestire queste relazioni.
Opzione 2 : le relazioni non devono essere gestite dal livello DAO, quindi il livello logico di cui sopra dovrebbe gestirlo. Nessuna soluzione generica, ogni entità di dominio che ha questa relazione dovrebbe scrivere il proprio codice nel livello logico per gestire questo livello.
Opzione 3 : i genitori tengono i figli nello stesso doc - un doc (sia genitore che bambino) - non lo faranno, i bambini sono troppo grandi e ci sono anche altri tipi di bambini. (altri motivi che posso specificare se necessario).
Opzione 4 : usa specifiche funzionalità di database - Voglio evitarlo così la prossima volta che eseguiremo la migrazione in un db diverso non avrò più bisogno di affrontare questo problema. Una soluzione che funzionerà per qualsiasi KV.
Opzione 5 : non passare all'archivio KV - passare a un database relazionale o mantenere il db corrente (aggiornato dal commento Thimothy), questo è fuori dal mio controllo, passeremo a KV, quindi questa opzione è fuori discussione. La massima preferenza è per la velocità al di sopra di qualsiasi funzionalità di db.
Opzione 6 : ha un processo asincrono che gestisce le relazioni, quindi se elimino un figlio (nell'esempio figlio-genitore), se un client ottiene il genitore, recupera ciascun figlio dal suo id vedrebbe che un bambino non esiste, solo 30 minuti dopo un processo asincrono vedrà questa incoerenza e la risolverà, nel nostro caso il cliente dovrebbe decidere se questa incoerenza è un errore reale o un'incoerenza temporale. Questa è una soluzione possibile chiamata così come opzione 6, ma temo che ogni sviluppatore possa ottenere chissà dove gli errori e avrebbe bisogno di decidere se questo è uno stato ok e ignorarlo o meno.
Opzione 7 : approvvigionamento degli eventi, in modo che continui a riprodurre e rieseguire almeno o compensare in caso di un errore in cui il genitore è aggiornato e figlio non lo è, ma penso che questo non risolva l'intero cosa figlio / genitore, avrei ancora più comandi ed eventi e non è come una transazione, in questo momento anche se sarei felice di utilizzare il sourcing di eventi, non sono a questo punto, forse in futuro su un refactoring totale di codebase, nessuna immediata rimedio questo mi può dare.
So che questo tipo di domande tendono a non avere una risposta precisa Vorrei sapere se qualcuno ha affrontato questa domanda generale prima, e se è meglio elaborare un quadro generale un DAO generale che sappia gestire queste relazioni o lascia che uno sviluppatore gestisca le sue relazioni.
Tieni presente che dare ad ogni sviluppatore la responsabilità di gestire le proprie relazioni è dubbio perché più sviluppatori hai più desideri avere alcune infrastrutture di base e non reinventare la ruota o essere incoerenti tra i team (pensa impresa) . Tuttavia nel mio caso non sono sicuro di voler costruire tutta questa architettura e livelli al di sopra di un KV, la mia tendenza è attualmente, se ho un KV, consentire agli sviluppatori degli utenti finali di gestire le dipendenze, tuttavia questo lascia troppo stanza per ciascuno di venire con la sua soluzione, quale opzione sceglieresti?
AGGIORNAMENTO: Penso che per me la via migliore per andare sia sotto l'assunzione di un negozio KV senza relazioni:
- Non implementare il livello delle relazioni generiche sopra l'archivio KV.
- Livello DAO leggero.
- Ogni livello logico / servizio che utilizza il livello DAO light dovrebbe implementare le relazioni nella sua logica di business.
Come appendice a questo: se un programmatore affronta un'incoerenza (il genitore punta a un bambino ma il bambino non esiste) allora avrebbe bisogno di gestirlo con il suo codice personalizzato + Considera un processo asincrono per ripulire queste incoerenze.
Grazie.