Qui, consideriamo un'architettura server-client. Supponiamo di mantenere i dettagli flessibili, ma esiste più di un livello di server che supporta il nostro servizio ipotetico. La domanda generale è "Quando e quanto convalido i dati del cliente?" .
Da altre domande e risposte che ho letto, la risposta può essere riassunta come una delle seguenti strategie (o una loro combinazione).
- Convalida tutti i dati non appena arrivano dal client. Altri server si fidano l'un l'altro.
- Convalida tutti i dati su ogni server nel sistema. (questo non è molto favorito)
- Convalida tutti i dati rigorosamente quando raggiunge il database e, facoltativamente, altrove come richiesto dall'applicazione.
- A tutti i livelli, convalidare esattamente tutti i dati necessari a quel particolare server per svolgere il proprio lavoro.
Il numero 3 sembra particolarmente popolare .
Nelle risposte che ho visto, tuttavia, sembra esserci un'assunzione implicita dell'archiviazione dei dati centralizzata RDBMS classica ("OldSql"). Questi sono i MySQL e Postgres del mondo. Prendendo spunto dal teorema CAP , chiamiamo questi database CP , poiché tendono a fornire strumenti per coerenza a scapito di alcune classi di disponibilità: in genere, solo un master delegato può scrivere su una particolare partizione.
Le alternative recenti al classico RDBMS (in particolare Voldemort, Riak e Cassandra, che sono modellate sul sistema di storage Dynamo) sono meglio classificate come database AP . Questi strumenti consentono di comparire incoerenze naturali al momento del recupero dei dati (ad esempio più valori di dati con clock vettoriali) in cambio della disponibilità "sempre scrivibile". Dato che questi archivi di dati hanno piuttosto proprietà uniche , pongo la domanda:
La storia di convalida dei dati del client cambia quando utilizziamo i datastore AP? Quanti dei miei dati cliente dovrei convalidare prima e dopo l'inserimento in un database AP?