L'approccio al database per utente di CouchDB è fattibile per gli utenti con molti dati condivisi?

Question

Voglio implementare una webapp - un feed che integra i dati da varie fonti e li visualizza agli utenti. Un utente dovrebbe essere in grado di vedere solo gli elementi del feed che ha le autorizzazioni per leggere (ad esempio perché appartengono a un progetto di cui è membro). Tuttavia, un elemento del feed potrebbe (e lo sarà) essere visibile da molti utenti.

Mi piacerebbe molto usare CouchDB (principalmente a causa del fresco feed _changes e della mappa/riduzione delle viste). Stavo pensando di implementare l'app come un puro couchapp, ma ho problemi con il modello delle autorizzazioni. AFAIK, non ci sono permessi per documento in CouchDB e questo è comunemente implementato usando database e repliche per utente.

Ma quando c'è molta sovrapposizione tra ciò che vedono i vari utenti, questo introdurrebbe un sacco di spese generali ... roba che verrebbe replicata dappertutto e duplicata in molti database. Mi piace l'eleganza di questo approccio, ma l'enorme sovraccarico sembra un rompicapo ... (diciamo che ho 50 utenti e tutti vedono gli stessi dati ...).

Qualche idea su come, per favore? Soluzione alternativa?

Answer 1

È possibile applicare le autorizzazioni di lettura come descritto in CouchDB Authorization on a Per-Database Basis.

Per le autorizzazioni di scrittura è possibile utilizzare le funzioni di convalida come descritto in CouchDB The Definitive Guide - Security.

È possibile creare un database per ciascun progetto e applicare le autorizzazioni lì, quindi tutti i dati vengono condivisi in modo efficiente tra gli utenti. Se un utente condivide un feed da solo e ha bisogno di autorizzazioni anche su questo, puoi trasformare l'utente in un "progetto" in modo che la stessa logica si applichi ovunque.

Utilizzando questo modello è possibile autorizzare un utente o un gruppo di utenti (ruoli) per ciascun progetto.

Answer 2

Altro che (come già suggerito da victorsavu3) che gestisce l'autorizzazione di lettura in un proxy tra l'app e il divano, ci sono solo altre due alternative a cui posso pensare.

primo è quello di non solo la cura, il disco è a buon mercato e avere più copie dei dati può sembrare un sacco di inutili duplicazioni, ma semplifica in maniera massiccia la vostra architettura e si ottiene alcuni benefici automatiche come facile scalabilità per gestire il carico (semplicemente spostando alcuni DB degli utenti su altri server).

Secondo è dividere i dati condivisi in un DB diverso. Questo a volte limita le cose che puoi fare nelle viste (ad esempio, no "Documenti collegati") ma questo non è un grosso problema in molte situazioni.