Questa è una domanda difficile perché entrambi i tipi di persistenza presentano vantaggi e svantaggi. Ma, dato che stiamo prendendo in considerazione un modello di lettura CQRS (userò questo termine per la vista materializzata) (supponendo che l'operazione di autenticazione sia fatta in sola lettura, cioè tramite una query) potremmo pensare alle seguenti considerazioni:
-
per ogni tipo di schema di autenticazione supportato potresti avere un'implementazione diversa; ovvero nome utente / password che utilizza NoSQL e accesso one-time-by-email-link utilizzando SQL
-
alcuni schemi di autenticazione come username / password sono facili da implementare; potresti implementarlo per entrambi i tipi persistenti e utilizzare benchmark o test A / B per decidere quale utilizzare; questo è semplice da fare grazie a CQRS e al sourcing di eventi mediante la sottoscrizione di entrambe le modalità di lettura agli eventi di dominio pertinenti
-
entrambi hanno soluzioni per la disponibilità: SQL e NoSQL hanno una sorta di soluzioni di replica (master / slave o set di repliche) ma grazie a CQRS non si è costretti a utilizzare la replica integrata; si potevano semplicemente avere più istanze dello stesso modello di lettura in esecuzione su nodi diversi; qui dipende più dai costi operativi
-
entrambi hanno soluzioni per la scalabilità orizzontale, come il sharding; ma ancora una volta, grazie a CQRS è possibile implementare il sharding creando una tabella / collezione per ogni regione o paese o qualsiasi dimensione abbia più senso; oppure potresti combinare lo sharding integrato con questa tecnica
-
NoSQL semplifica l'archiviazione / recupero delle entità ma se il modello di lettura è semplice (ovvero ID utente, nome utente e password con hash) anche SQL funziona
Quindi, dipende da ogni schema di autenticazione che sosterrai, dalla quantità di codice che scrivi, dai costi operativi di replica / sharding ecc.
