Guida alla configurazione di un database

Question

Il mio sito avrà molti prodotti disponibili, ma saranno classificati in siti (domini) completamente diversi.

La mia domanda è: sto meglio raggruppando tutti i prodotti in un database e usando un ID per distinguere tra i siti, o dovrei impostare una tabella e / o DB per sito?

Ecco i miei pensieri

DATABAS SEPARATI

• Più facile da leggere da un backend
• Classificato meglio
• Rende i backup più difficili
• Se devo apportare una modifica allo schema, dovrà essere inviato a tutti i database

STESSI DATABASI

• Tutto in un unico posto
• Potrebbe diventare ingombrante
• Un database avrà dimensioni di file enormi e le ricerche potrebbero risentirne

Qualcuno può offrirmi qualche consiglio su quale sia il modo migliore e perché?

Answer 1

Non hai fornito troppi dettagli (il che rende difficile fornire una buona risposta), anche se le parole che hai scelto di usare nella tua domanda mi portano a credere che questa sia una singola applicazione con differenti "skin".

  

Il mio sito avrà molti prodotti disponibili, ma saranno classificati in siti (domini) completamente diversi.

La mia ipotesi è che avrai un singolo negozio web con diversi fronti del negozio: cool-widgets.com, awesome-sprockets.com, neato-things.com, ecc. Questi saranno tutti uguali, salvo forse una skin CSS o qualcosa di simile. Le cose dell'amministratore del negozio verranno eseguite in un sistema centrale e il nome di dominio agirà semplicemente come nome di categoria.

In quanto tale, suddividere gli stessi dati in due contenitori diversi usando un criterio arbitrario (nome_categoria == 'cool-widges.com') è partizionamento dei dati , che è un anti-pattern. Proprio come non avresti due diverse tabelle utente basate sul nome utente ([Users $ A-to-M] e [Users $ N-to-Z]), ha poco senso avere due diverse tabelle (o database ) per i nomi delle categorie.

Esistono e saranno molti i codici comuni tra le categorie: gestione utenti, amministrazione, elaborazione ordini, importazione dati, ecc. Sarà molto più difficile aggregare i multipli archivi dati nel codice comune di quanto non lo sarà per separare le categorie nel codice di visualizzazione del negozio. Non solo, i bug di segregazione saranno molto più evidenti: la pagina di confronto dei prezzi mostra gli articoli di tutti e tre i negozi. I bug di aggregazione saranno molto inferiori: solo tre dei quattro negozi sono stati aggiornati. Questo è il motivo per cui è un anti-pattern.

Nota a margine: sì, prima di dire che il porzionamento dei dati ha i suoi usi (cosa che fa), quegli usi arrivano molto dopo si verificano problemi di prestazioni. Molte piattaforme di database serie consentono il partizionamento dietro le quinte per non creare un modello di dati sciocco.

Answer 2

Se i dati devono essere condivisi tra tutti i siti, si consiglia di condividere lo stesso database poiché il trasferimento dei dati viene eliminato. Inoltre i dati sono più centralizzati.

Se non è necessario condividere i dati tra tutti i siti, sarà opportuno suddividere un database per sito. Per quanto riguarda la difficoltà di aggiornare le strutture delle tabelle, è sufficiente registrare le modifiche al database (salvando le query ALTER, UPDATE, DELETE in un file SQL) create per uno e aggiornare gli altri database con lo stesso file SQL.

Anche l'archiviazione in diversi database potrebbe aiutare con la sicurezza. È possibile impostare autorizzazioni utente diverse per ciascuno del sito. e se uno viene compromesso, proteggi gli altri siti.

Inoltre, è possibile gestire e tracciare facilmente il database quando i database sono chiaramente suddivisi.

Answer 3

Come hai già detto, entrambe le opzioni hanno i loro pro e contro. Dato che stai parlando di due negozi, probabilmente non importa molto.

Tuttavia, alcune domande che potresti porti:

• Saranno davvero due negozi, o forse più? Se più, un database potrebbe essere più intelligente.
• I prodotti sono davvero gli stessi? Se devi comprimere i prodotti in un database generale, perché sono di un tipo diverso (ad es. Auto vs. cibo; la quantità e la natura dei dettagli che desideri conservare sono completamente diverse), quindi non farlo; utilizzare invece due database / tabelle.

La domanda centrale è: cosa è più probabile che diventerà più elaborato in futuro: i negozi o i prodotti?

Answer 4

Penso che database separati saranno più facili. È possibile disporre di un database modello di avvio rapido dal quale è possibile creare un nuovo database del negozio. È anche possibile creare un database comune e contenere tabelle e un elenco comuni di negozi e relativi database. Dopo tutto, puoi accedere a qualsiasi database all'interno dello stesso server usando un nome qualificato, osserva:

SELECT value FROM CommonDB.currencies WHERE type='euro';
SELECT price FROM OldTownDB.Products WHERE id=newtownprodid;