Implementazione di commenti e Mi piace nel database

Sono uno sviluppatore di software. Adoro programmare, ma odio i database ... Attualmente sto creando un sito Web in cui un utente potrà contrassegnare un'entità come piaciuta (come in FB), contrassegnarla e commentarla .

Rimango bloccato nella progettazione di tabelle di database per gestire questa funzionalità. La soluzione è banale, se possiamo farlo solo per un tipo di cosa (es. Foto). Ma devo abilitarlo per 5 cose diverse (per ora, ma presumo anche che questo numero possa crescere, man mano che l'intero servizio cresce).

Ho trovato alcune domande simili qui, ma nessuna di esse ha una risposta soddisfacente, quindi sto ponendo di nuovo questa domanda.

La domanda è: come progettare correttamente, efficientemente ed elasticamente il database, in modo che possa memorizzare commenti per tabelle diverse , like per tabelle diverse e tag per loro. Alcuni modelli di design come risposta saranno i migliori;)

Descrizione dettagliata : ho una tabella User con alcuni dati utente e altre 3 tabelle : Photocon fotografie , Articlescon articoli , Placescon luoghi . Voglio abilitare qualsiasi utente registrato a:

• commentare una di quelle 3 tabelle

• contrassegnare uno di loro come piace

• contrassegnare uno di essi con qualche tag

• Voglio anche contare il numero di Mi piace per ogni elemento e il numero di volte in cui quel particolare tag è stato usato.
  
  

1 ^° metodo :

a) Per i tag , creerò un tavolo Tag [TagId, tagName, tagCounter] , poi creerò molti-a-molti rapporti tabelle per: Photo_has_tags, Place_has_tag, Article_has_tag.

b) Lo stesso vale per i commenti.

c) Creerò un tavolo LikedPhotos [idUser, idPhoto] , LikedArticles[idUser, idArticle], LikedPlace [idUser, idPlace]. Il numero di Mi piace verrà calcolato dalle query (che, presumo sia negativo). E...

Davvero non mi piace questo disegno per l'ultima parte, ha un cattivo odore per me;)

2 ^° approccio :

Creerò una tabella ElementType [idType, TypeName == some table name]che verrà popolata dall'amministratore (me) con i nomi delle tabelle che possono essere apprezzate , commentate o taggate . Quindi creerò tabelle :

a) LikedElement [idLike, idUser, idElementType, idLikedElement]e lo stesso per commenti e tag con le colonne appropriate per ciascuno. Ora, quando voglio fare una foto piaciuta inserirò:

typeId = SELECT id FROM ElementType WHERE TypeName == 'Photo'
INSERT (user id, typeId, photoId)

e per i luoghi:

typeId = SELECT id FROM ElementType WHERE TypeName == 'Place'
INSERT (user id, typeId, placeId)

e così via ... Penso che il secondo approccio sia migliore, ma penso anche che manchi qualcosa in questo design ...

Alla fine, mi chiedo anche quale sia il posto migliore dove riporre un contatore per quante volte è stato apprezzato l'elemento. Mi vengono in mente solo due modi:

1. nella Photo/Article/Placetabella element ( )
2. selezionando count ().

Spero che la mia spiegazione del problema sia ora più approfondita.

La soluzione più estensibile è avere solo una tabella "base" (collegata a "Mi piace", tag e commenti) e "ereditare" tutte le altre tabelle da essa. L'aggiunta di un nuovo tipo di entità implica semplicemente l'aggiunta di una nuova tabella "ereditata", che si inserisce automaticamente in tutto il macchinario like / tag / comment.

Il termine entità-relazione per questo è "categoria" (consultare la Guida ai metodi ERwin , sezione: "Relazioni del sottotipo"). Il simbolo della categoria è:

Supponendo che un utente possa apprezzare più entità, uno stesso tag può essere utilizzato per più di un'entità ma un commento è specifico dell'entità, il modello potrebbe essere simile al seguente:

A proposito, ci sono circa 3 modi per implementare la "categoria ER":

• Tutti i tipi in una tabella.
• Tutti i tipi di calcestruzzo in tabelle separate.
• Tutti i tipi concreti e astratti in tabelle separate.

A meno che tu non abbia requisiti di prestazione molto severi, il terzo approccio è probabilmente il migliore (ovvero le tabelle fisiche corrispondono 1: 1 alle entità nel diagramma sopra).

Dato che "odi" i database, perché stai cercando di implementarne uno? Invece, chiedi aiuto a qualcuno che ama e respira queste cose.

Altrimenti, impara ad amare il tuo database. Un database ben progettato semplifica la programmazione, la progettazione del sito e ne semplifica il funzionamento continuo. Anche un designer d / b esperto non avrà una previsione completa e perfetta: alcuni cambiamenti dello schema lungo la strada saranno necessari quando emergono modelli di utilizzo o cambiano i requisiti.

Se si tratta di un progetto individuale, programmare l'interfaccia del database in semplici operazioni usando le procedure memorizzate: add_user, update_user, add_comment, add_like, upload_photo, list_comments, ecc. Non incorporare lo schema in nemmeno una riga di codice. In questo modo, lo schema del database può essere modificato senza influenzare alcun codice: solo le procedure memorizzate dovrebbero conoscere lo schema.

Potrebbe essere necessario riformattare lo schema più volte. E 'normale. Non preoccuparti di renderlo perfetto la prima volta. Renderlo abbastanza funzionale da prototipare un progetto iniziale. Se hai il lusso del tempo, usalo un po ', quindi elimina lo schema e fallo di nuovo. È sempre meglio la seconda volta.

Questa è un'idea generale, per favore non prestare molta attenzione allo stile dei nomi dei campi, ma più alla relazione e alla struttura

Questo pseudocodice riceverà tutti i commenti della foto con ID 5
SELEZIONA * DA azioni
DOVE azioni.id_Stuff = 5
AND actions.typeStuff = "foto"
AND actions.typeAction = "comment"

Questo pseudocodice otterrà tutti i
Mi piace o gli utenti a cui è piaciuta la foto con ID 5 (puoi usare count () per ottenere solo la quantità di Mi piace)

SELECT * FROM actions  
WHERE actions.id_Stuff = 5  
AND actions.typeStuff="photo"  
AND actions.typeAction = "like"  

per quanto ho capito. sono richiesti più tavoli. C'è una relazione da molte a molte tra loro.

• Tabella che memorizza i dati dell'utente come nome, cognome, data di nascita con un campo identità.
• Tabella che memorizza i tipi di dati. questi tipi possono essere foto, condivisioni, collegamenti. ogni tipo deve avere una tabella univoca. pertanto, esiste una relazione tra le loro singole tabelle e questa tabella.
• ogni diverso tipo di dati ha la sua tabella. ad esempio aggiornamenti di stato, foto, collegamenti.
• l'ultima tabella è per molte o molte relazioni che memorizzano un ID, un ID utente, un tipo di dati e un ID dati.

Guarda i modelli di accesso che ti serviranno. Qualcuno di loro sembra aver reso particolarmente difficile o inefficiente la mia scelta progettuale o l'altra?

In caso contrario favorire quello che richiede un minor numero di tabelle

In questo caso:

1. Aggiungi commento: o scegli una particolare tabella molte / molte o inseriscila in una tabella comune con un identificatore specifico noto per ciò che piace, penso che il codice client sarà leggermente più semplice nel tuo secondo caso.
2. Trova commenti per l'elemento: qui sembra che usare una tabella comune sia leggermente più semplice - abbiamo solo una singola query parametrizzata per tipo di entità
3. Trova i commenti di una persona su un tipo di cosa: query semplice in entrambi i casi
4. Trova tutti i commenti di una persona su tutte le cose: questo sembra poco nodoso in entrambi i modi.

Penso che il tuo approccio "discriminato", opzione 2, produca query più semplici in alcuni casi e non sembri molto peggio negli altri, quindi ci andrei.

Sicuramente vai con il secondo approccio in cui hai una tabella e memorizza il tipo di elemento per ogni riga, ti darà molta più flessibilità. Fondamentalmente, quando si può fare logicamente qualcosa con un minor numero di tabelle, è quasi sempre meglio scegliere un numero inferiore di tabelle. Un vantaggio che mi viene in mente in questo momento sul tuo caso particolare, considera che vuoi eliminare tutti gli elementi piaciuti di un determinato utente, con il tuo primo approccio devi emettere una query per ogni tipo di elemento ma con il secondo approccio può essere fatto con una sola query o considera quando vuoi aggiungere un nuovo tipo di elemento, con il primo approccio implica la creazione di una nuova tabella per ogni nuovo tipo ma con il secondo approccio non dovresti fare nulla ...

Prendi in considerazione l'uso della tabella per entità per commenti ed ecc. Altre tabelle: migliore condivisione e ridimensionamento. Non è un problema controllare molte tabelle simili per tutti i framework che conosco.

Un giorno dovrai ottimizzare le letture da tale struttura. Puoi facilmente creare tabelle agragating su quelle di base e perdere un po 'sulle scritture.

Un grande tavolo con dizionario potrebbe diventare incontrollabile un giorno.