Come progettare un database relazionale per l'utente che segue altri utenti?

Question

Come progettare un database relazionale per l'utente che segue altri utenti?

#1 da (12 voti)
#2 da (-2 voti)

5

Voglio progettare il mio schema relazionale per archiviare informazioni sugli utenti che seguono altri utenti. Quindi se user1 sta seguendo user2 lo schema sarà come sotto

user_follow
------------
|user1|user2| -> Column names
------------
|U_Nm1|U_Nm2| -> tuple
------------

Quindi in questo modo se user1 sta seguendo 100 altri utenti avrò 100 righe solo per un singolo utente. Se ho molti utenti che seguono molti altri utenti, le dimensioni del mio tavolo cresceranno enormemente. C'è un altro modo in cui posso progettare questo? So che è meglio usare NoSQL per tali requisiti, ma io sono limitato a utilizzare il DB relazionale.

database-design

posta karan ratnaparkhi 11.07.2015 - 20:23

fonte

2 risposte

Leggi altre domande sui tag database-design

È possibile sviluppare un'applicazione web interamente in Javascript oggi (client e server) includendo un'API RESTful che espone i dati PostgreSQL? Aggiunta di un nuovo file a un progetto GPL - come posso portare avanti / modificare le informazioni sul copyright?

score 12 · Answer 1

I know it is better to use NoSQL for such requirements

Non sono sicuro del perché lo pensi. Dopo tutto, i dati delle domande sono di natura molto relazionale.

Ecco cosa dovrei fare:

Tabella utente

ID utente (chiave primaria)
UserName
... ecc.

Tabella seguente (tabella join)

FollowingUserId (chiave esterna a UserTable.UserId)
FollowedUserId (chiave esterna a UserTable.UserId)

Utilizzando questa tabella di join sarai in grado di creare una relazione "seguente" tra gli utenti. E certo, se un utente segue 100 utenti, allora sì ci saranno 100 righe nella tabella di join per quel singolo utente. Questo è piccolo in realtà, però, e con ottimizzazioni ci sarebbe un impatto trascurabile.

score -2 · Answer 2

Per quanto riguarda il buon design, suggerirei di utilizzare due sottoclassi per gli utenti; Seguaci e seguiti. Se si disegna un diagramma ER, questo approccio è più semanticamente più ricco.

Quindi gli schemi sarebbero:

Utente (UserName, Email, ecc.)
FollowerUser (FollowerName, FollowerEmail, ecc.)
FollowedUser (FollowedName, FollowedEmail, ecc.)
Seguendo (FollowerEmail, FollowedEmail)

Uno dei vantaggi di tale design è che gli utenti che non seguono o sono seguiti da chiunque sono ora più facilmente accessibili.

Inoltre, la normalizzazione o l'ottimizzazione del database è necessaria quando si desidera rimuovere la ridondanza. In questo caso:

Utente1 segue Utente2 è diverso da Utente1 segue Utente3 , poiché ogni riga rappresenta una nuova relazione. Quindi i dati non sono ridondanti e la normalizzazione non è richiesta.