n: m come l'unico modo per memorizzare le notifiche?

2

Ho un utente e una tabella delle notifiche. Voglio assicurarmi che ogni utente veda una nuova notifica una volta sola. Non di più, non di meno. L'idea intuitiva è di avere una tabella delle relazioni n: m con userId: notificationId. Ma non è un po 'troppo overhead per creare un nuovo tavolo solo per quello?

E i database NoSQL? Sarebbe una buona idea aggiungere semplicemente una serie di ID di notifica al singolo utente nella tabella utente?

    
posta Amberlamps 25.07.2014 - 09:44
fonte

1 risposta

2

@Amberlamps la tua domanda è molto generica e da una prospettiva, AakashM ha già risposto in un commento.

Tuttavia diamo un'occhiata alle nozioni di base per illustrare alcune idee e tecniche e le loro considerazioni di progettazione ..

Per un singolo utente, qual è la quantità minima di record (di dimensioni ridotte) che soddisferà le tue necessità. In superficie (m) record per utente. Tuttavia, con maggiore attenzione, puoi vedere che è probabile che sia un set sparse o il contrario di esso, ovvero un set per lo più pieno.

Puoi, in base ai tuoi dati, generare rappresentazioni più complesse se lo spazio è la tua preoccupazione .. cioè per ogni utente rappresentano tutti i record "visti" in intervalli, cioè (utente1, lowid1, highid1), (utente1, lowid2 , highid2), (user2, lowid1, highid1) e così via. Separatamente a livello di sistema avresti un sistema lowid e system highid per dare dei limiti alle tue query. Essenzialmente questo è un modo per rappresentare un set sparse (non ho visto questa struttura esatta da nessun'altra parte ma se qualcuno l'ha visto formalmente rappresentato altrove, per favore commenta) ..

Puoi trovare altri modi per rappresentare anche i set sparse.

OTOH, se la velocità di ricerca è più importante di una scala n: m richiede spazio extra rispetto ad altre rappresentazioni, ma ti dà una velocità molto alta per quasi tutte le operazioni che puoi immaginare.

Ora passa agli argomenti .. Nei DB relazionali avere una tabella separata non è in realtà molto più sovraccarico, perché lo storage è efficiente. Nel DB NoSQL, l'aggiunta di un array a ciascun utente richiede meno spazio, tuttavia, quando si cercano tutti gli utenti che hanno "letto" una particolare notifica, si costringe a una query costosa, a meno che non si disponga di indici (che possono essere stesso overhead di averli in una tabella separata). In questo caso, se passi la query e cerchi tutti gli utenti che hanno "non" letto una notifica, potrebbe essere ancora più costoso.

Scrivi un commento o aggiorna la tua domanda e io amplierò di più se necessario.

    
risposta data 02.08.2014 - 05:47
fonte

Leggi altre domande sui tag