le tabelle di MySQL e le strategie di eliminazione

Question

sto lavorando su un social network, come un sottoinsieme di Facebook. Credo Ciò significa che l'applicazione sarà più lettura pesante che write-pesante (cioè più SELECTS degli inserti, aggiorna o elimina)

Sto pensando di utilizzare MySQL per il database, utilizzando MyISAM. Ogni tabella nel database conterrà i seguenti tre campi:

• CREATED - un campo data che contiene l'ora il record è stato creato
• UPDATED - un campo data che contiene l'ora il record è stato modificato
• ROWSTATUS -. CHAR (1) campo contenente un singolo carattere bandiera per mostrare se il record è attiva, inattiva o soppresso (usando 'A' valori, I e D, rispettivamente)

Con una classe PHP involucro, ci assicuriamo che tutte le query SELECT includono il RowStatus e query di aggiornamento aggiorna anche la colonna aggiornata e le query INSERISCI aggiornare la colonna creata.

Sto pensando di non effettivamente eliminare tutti i record, optando invece per l'aggiornamento che registra campo RowStatus per D per dimostrare di essere eliminato (vale a dire una morbida di eliminazione).

Abbiamo una procedura di SQL che cancella fisicamente i dati cancellati dopo 10 giorni.

Tuttavia, mi stava attraversando questo articolo , che sostiene che non v'è alcuna necessità di eliminare fisicamente a causa di spese di chiusura. Piuttosto, l'autore ha suggerito di utilizzare questo schema:

SELECT e.eventid,e.title
    FROM events e
   WHERE NOT EXISTS
    (SELECT * FROM event_deletes ed WHERE ed.eventid = e.eventid);

Mi chiedo come il mio schema confronta con questo meccanismo proposto, e che uno è meglio? Non ho potuto raggiungere a qualsiasi risposta definitiva da solo.

Answer 1

Come @ Pentium10 dice, non c'è nulla di intrinsecamente sbagliato con il vostro piano. In realtà è un approccio abbastanza standard.

Il problema è solo che se si sta utilizzando MyISAM tuoi aggiornamenti saranno causare l'intera tabella di blocco durante l'esecuzione di query. Che presenta un collo di bottiglia, perché si può solo aggiornare o eliminare un singolo record alla volta.

Se non avete una ragione per usare MyISAM, io consiglierei di commutazione per InnoDB come motore di database. InnoDB utilizza il blocco a livello di riga, in modo che le query UPDATE non bloccherà altri aggiornamenti. Ha anche qualche altra bella caratteristiche come il supporto per le transazioni ei vincoli di integrità referenziale.

Answer 2

L'unico problema che vedo qui, rispetto a tale articolo, che si gestisce solo blocca la chiamata DELETE.

Si deve sapere che UPDATE e DELETE ha sempre bisogno di rilasciare un blocco esclusivo su una tabella MyISAM.

Questo è il motivo per cui l'articolo consiglia di utilizzare un INSERT invece di un RowStatus UPDATE. Si dovrebbe andare come dice l'articolo. Creare una tabella dedicato per memorizzare i ids cancellati, e utilizzare il raccomandato unirsi sulle seleziona per recuperare non cancellare i record. In questo modo su azione di eliminazione di utente finale, si sarà solo inserire nella tabella, e non causerà blocco di aggiornamento sul tavolo. Se si aggiungono le chiavi adeguate per entrambe le tabelle, il join verrà fatto solo sugli indici, Si sarà veloce sulla SELECT.

Si sta anche introducendo in testa se si memorizza il tempo di aggiornamento. Si dovrebbe abbandonare l'idea, come ha alcuna utilità, e non utilizzerà per dire quando un record è stato aggiornato.