Sono relativamente appena uscito dal college, quindi la maggior parte della mia familiarità con i database relazionali proviene dal mio corso di database in cui tutto ciò che non è in BCNF o 3NF è una parodia. Certamente questa è un'estremità dell'estremo, ma la mia squadra al lavoro sembra davvero portarla all'estremità opposta.
Nei nostri schemi di microservizi db, le entità raramente hanno più di una singola tabella. Tutto ciò che normalmente si dovrebbe normalizzare in un'altra tabella viene archiviato in una colonna JSON. Se in seguito viene scoperto che è necessario eseguire una query su una delle proprietà di questo json, viene aggiunta una nuova colonna e i dati vengono archiviati in entrambe le posizioni (sì, in due colonne diverse nella stessa tabella).
In molti casi queste colonne JSON hanno sicuramente un vantaggio. Se non hai mai bisogno di fare una query su quei dati e se non devi mai apportare una modifica unilaterale a quei dati (che è qualcosa che ovviamente non puoi prevedere), non è una cattiva idea. Inoltre molti dei nostri servizi non vedono il server o sono ospitati su macchine con una quantità oscena di spazio su disco per ciò di cui avevano bisogno, quindi la duplicazione dei dati non è un grosso problema. (Anche se qualcosa che in genere vorrei evitare per filosofia)
Attualmente stiamo creando un servizio che corrisponda alle regole in base a una serie di condizioni di loro proprietà e quindi eseguirà una serie di azioni associate a tali regole quando le regole sono vere (ad es. Tutte le condizioni sono vere). Il mio team secondario che sta costruendo questo servizio più immediatamente ritiene che ci sia un sostanziale vantaggio nel normalizzare azioni e condizioni lontano dalle regole nello schema. Ovviamente queste tabelle mantengono relazioni di chiave esterna con l'id regola. Dal nostro punto di vista possiamo evitare la duplicazione dei dati sulle condizioni che ci consentono di assicurarci che vengano valutati una sola volta ed è facile trovare le condizioni e le regole di cui abbiamo bisogno quando ne abbiamo bisogno senza dover estrarre ogni singola regola ed eseguire le ricerche in memoria.
Parlando con uno dei nostri principali ingegneri oggi ha tentato di spingermi lontano da questo schema. Cercare di discutere in tutti i modi in cui non ne abbiamo realmente bisogno causerà problemi di prestazioni in futuro, facendo riferimento a un vecchio monolito che possediamo che è una parodia del design. Si riferiva a quello che stiamo facendo come "alla vecchia maniera" e ai tavoli piatti con json come "alla nuova maniera". Ha sostenuto che nei luoghi in cui voglio l'atomicità non ne abbiamo bisogno e che invece di interrogazioni dovremmo fare più cose in memoria. Questo è un principio progettuale che molti dei nostri servizi seguono ora. Non prevediamo che il volume dei nostri dati aumenterà in modo sostanziale, il che dovrebbe mantenere le nostre query rapide. Ciò che anticipiamo è molto tempo speso nella valutazione delle regole e nell'esecuzione di azioni.
Capisco che i database non relazionali siano diventati più popolari negli ultimi anni ma anche quando cerco attivamente informazioni sulle implicazioni in termini di prestazioni delle relazioni con le chiavi esterne, non vedo molte informazioni nel suo caso. Suppongo che potrebbero tendere a introdurre transazioni di grandi dimensioni che potrebbero causare problemi, ma sembra un problema indipendente dalla chiave esterna stessa.
È questa la mia ingenuità? O c'è davvero qualcosa che manca a me e al mio sotto-team? Non ho esplicitamente fornito informazioni dettagliate sul nostro problema perché non sto necessariamente cercando una soluzione a questo. Dato che questa è una tendenza comune nel nostro team più grande, sono davvero curioso di sapere se ci sono.