Post e statistiche: è necessario normalizzarlo o mantenerlo insieme?

Question

Post e statistiche: è necessario normalizzarlo o mantenerlo insieme?

#1 da (3 voti)

3

Ho tabella posts :

id (int) index
uid (int)
text (text)
created (int)
is_deleted (tinyint)

e una tabella per memorizzare post stats :

post_id (int) index
comments (int)
shares (int)
views (int)

Ora quando prendo post, la maggior parte delle volte recupero le statistiche. Il motivo per cui ho creato un altro tavolo era perché queste statistiche aggiornano frequentemente viste speciali . Aggiorno queste colonne nella transazione (commenti, condivisioni, viste) così le righe vengono bloccate e volevo mantenere la tabella dei post veloce da leggere, così ho creato un'altra tabella per le statistiche.

Ma ora penso che se li unisco in 1 tavolo, mi salverà un join extra che devo fare quasi l'80% delle volte.

Domanda 1: dovrei unire la tabella e mantenerle entrambe in una tabella?

Domanda 2: l'aggiornamento in una transazione blocca davvero la riga e impedisce di recuperarla? o recupera l'ultima riga aggiornata? (confuso su di esso)

performance database-design normalization transaction

posta Shaharyar 17.06.2017 - 11:16

fonte

1 risposta

Leggi altre domande sui tag performance database-design normalization transaction

Il mio caso d'uso per Redis è appropriato? Come e cosa esporre una classe Tree AVL per un corretto test?

score 3 · Accepted Answer

Question 2: Updating in a transaction really locks row and prevents fetching it? or does it fetch the last time updated row? (bit confused about it)

Questo non è esattamente ciò che è una transazione.

Qualsiasi vero ACID database assicurerà che quando si avvia l'aggiornamento non venga sovrascritto con un altro aggiornamento a metà. Questo non richiede che il recupero venga prevenuto. Richiede che il caricamento attenda fino a quando la transazione ha avuto esito positivo o fallito. In questo modo, se cambio il mio nome completo, non è possibile che termini il mio nuovo nome con il mio vecchio cognome con un recupero scaduto.

Question 1: Should I merge the table and keep both of them in 1 table?

Puoi semplificare l'SQL in questo modo. L'alternativa è lasciarla come una relazione 1 a 1 tra i tavoli. Non vi è alcun motivo logico per avere relazioni 1 a 1, ma ci sono delle prestazioni e, soprattutto, delle ragioni concettuali. Vedi C'è sempre un momento in cui l'uso di una relazione database 1: 1 ha senso?