Progettazione del database - Quando una colonna della tabella dovrebbe essere effettivamente una tabella?

Naviga le tue risposte
1

Compare Database #1 and Database #2 below

DATABASE #1

POSTS---------------------------------
|___Id________Category_Id______Body__|
|   1         "For Sale"      "...." |
|   2         "Requests"      "...." |
|   3         "Misc."         "...." |
|   4         "For Sale"      "...." |
|   5         "Misc."         "...." |
--------------------------------------

DATABASE #2

POSTS---------------------------------
|___Id________Category_Id______Body__|
|   1             1           "...." |
|   2             2           "...." |
|   3             3           "...." |
|   4             1           "...." |
|   5             3           "...." |
--------------------------------------


CATEGORIES----------------
|___Id__________Title____|
|   1        "For Sale"  |
|   2        "Requests"  |
|   3        "Misc."     |
--------------------------

Are there any situations where Database #1 is preferred over Database #2?

It think that Database #2 is the better choice, especially in terms of scalability and maintenance, but should you ever opt for the simpler design of Database #1?

Prima di continuare a leggere -

▼ Da non perdere questa parte! ▼

Il resto del post è per niente necessario per rispondere alla mia domanda e, a meno che tu non voglia solo leggere la mia opinione, dovresti probabilmente saltare alla fine .

Ho incluso solo il resto di questo post in modo che se qualcuno volesse, potrebbe vedere una situazione in cui pensavo che il Database # 1 potesse essere migliore del Database # 2.

Se qualcuno vuole prendersi del tempo, mi piacerebbe avere un riscontro sul motivo per cui il Database # 1 non è adatto alla seguente situazione e come / dove il mio processo di pensiero va storto.

▲ Non perdere questa parte! ▲

When/why I think that Database #1 might be acceptable and/or preferred over Database #2 -

  • Se utilizzi il Database n. 1, puoi cercare e ordinare i post per categoria con la stessa facilità con il Database n. 2.

  • L'unico compito che vedo essere più difficile con il Database n. 1 è il recupero di ogni titolo di categoria univoco.

Tuttavia, se il progettista sa che ci sono solo alcune (< 5) categorie e non è previsto che cambino, allora è possibile codificare a macchina il titolo di ogni categoria nella vista.

  • Il Modello può fornire un accesso facile per ogni Categoria di post, pur restando in ordine e svolgendo solo le funzioni di un Modello.

Dettagli di implementazione: Potresti avere una pagina View che ha semplicemente tre link (dal momento che questo database ha solo 3 categorie): 

        ----------------------------------------------------------------
        |                          View Posts!                         |
        |                                                              |
        |         __________       __________       _______            |
        |         |For Sale|       |Requests|       |Misc.|            |
        |         ‾‾‾‾‾‾‾‾‾‾       ‾‾‾‾‾‾‾‾‾‾       ‾‾‾‾‾‾‾            |
        ----------------------------------------------------------------

Ogni link può essere indirizzato a una pagina diversa che verrebbe servita da un diverso metodo di controller, oppure ciascun link potrebbe andare alla stessa pagina e inviare un parametro che specifica la categoria desiderata nella richiesta HTTP.

Nel controller, a seconda del link cliccato dall'utente, viene fatta una chiamata diversa al Modello che richiede Post con qualsiasi Categoria richiesta dall'utente.

Il modello potrebbe implementare queste chiamate in uno dei due modi molto puliti: 

# One way
# post.rb

def by_category(category)
    where("category = ?", category)
end


# OR
# post.rb

def for_sale
    where("category = ?", "For Sale")
end

def requests
    where("category = ?", "Request")
end

def misc
    where("category = ?", "Misc.")
end

Per questi motivi penso che il Database n. 1 possa funzionare meglio in questa situazione.

In conclusion

Are there any situations where Database #1 is preferred over Database #2?

È molto importante rispondere a questa domanda nel modo più generico possibile.

Toccare la mia opinione o la situazione specifica che ho descritto è solo un plus.
Grazie!

    
posta Matthew Cliatt 12.04.2016 - 05:58
fonte

5 risposte

1

DATABASE # 1

Non esiste una tabella principale . Significa che non ci sono repository di categorie. Categoria è un semplice campo di descrizione.

Non importa se otteniamo valori ripetuti (sembra). Può essere perché questi valori sono informati dal cliente o dal cliente ed è fuori dal nostro controllo. Vogliamo solo memorizzarlo.

Non è stato richiesto il suo mantenimento. Quindi non c'è bisogno di CRUD. Sembra che ogni parola sia una Categoria valida. Sembra un tag .

DATABASE # 2

La categoria conta. Fa parte del modello di dati e ha il suo scopo, oltre a catalogare POST.

CATEGORIE è la tabella principale . Probabilmente sarà la manutenzione di queste categorie. È necessaria una sorta di CRUD per gestire la tabella.

Questo è importante perché ora abbiamo il controllo su Categoria e decidiamo cos'è una categoria e come viene denominata.

Come abbiamo sottolineato, Categroy ora è un'entità, quindi avrà la sua classe. Il resto del modello di dati non fa più riferimento a categorie con tag . È richiesto composizione .

Abbiamo bisogno di rivedere i nostri script e mappature SQL. Ora categroy viene recuperato da join e c'è integrità referenziamento da convalidare.

Are there any situations where Database #1 is preferred over Database #2?

Sì . La situazione è requisiti dipendenti . Se non è necessario il mantenimento della categoria, quindi il database n. 1.

Altrimenti, il Database # 2 sembra più flessibile per ulteriori sviluppi. Permette anche di riutilizzare le informazioni perché è stato catalogato come tabella master . Quindi non più tag scattati attorno al modello dati e nessun codice spagetti che confronta le stringhe.

DATABASE # 2 scala meglio di DATABASE # 1 .

Guarda l'esempio. Come pensi di mantenere la vista con soli 3 link se in 1 mese diventa una vista con 200 diverse categorie?

Con DATABASE # 1 

SELECT DISTINCT CATEGORY FROM POST;

Devi assicurare che DISTINCT è CASE SENSITIVE e non ci sono valori ripetuti per errore di digitazione. Anche per tenere conto delle puntate e dei segni ortografici.

Nel tempo, i POST finiranno per contenere molte più voci di quelle di CATEGORIE. O ti aspetti 1 categoria per post?

Questo design potrebbe finire per penalizzare le prestazioni durante la stampa della vista.

Con DATABASE # 2 

SELECT TITLE FROM CATEGORIES;

Questa tabella avrà meno voci del POST. Le prestazioni nella stampa della vista saranno molto migliori.

    
risposta data 12.04.2016 - 15:49
fonte
5

Consiglio strongmente contro DATABASE # 1, per i seguenti motivi:

  • Non esiste un vincolo di integrità. Possono essere creati valori non validi.
  • La modifica di una descrizione richiede la modifica di tutte le righe con quella descrizione. E anche tutti i programmi che usano quel valore (ad esempio potresti avere una dichiarazione if)
  • Non puoi supportare applicazioni multilingua

Non vedo alcun vantaggio di DATABASE # 1, a parte il tempo necessario per la creazione di alcuni minuti. Le tue domande possono essere semplici anche nella # 2 se crei una vista che unisce le due tabelle.

    
risposta data 12.04.2016 - 07:45
fonte
2

Dipende molto da ciò che l'applicazione richiede. Se l'applicazione richiede un elenco di categorie a cui è possibile fare riferimento una o più volte (una relazione uno a molti), utilizzerei DB # 2. Altrimenti, # 1 dovrebbe essere sufficiente e mantenere le query più semplici.

Riguarda la normalizzazione dei dati. Non dovresti semplicemente assumere che devi "normalizzare" i dati in base al testo che stai memorizzando. Ciò che conta è il contesto di quel po 'di dati. Le parole "In vendita" sono davvero una cosa a sé stante o è davvero un attributo della tabella Post?

    
risposta data 12.04.2016 - 07:21
fonte
1

In un data warehouse, il Database # 1 potrebbe essere il data warehouse del Database # 2 (dove le tabelle sono "appiattite" per le prestazioni)

    
risposta data 12.04.2016 - 15:57
fonte
1

But, if you/the designer knows there are only a few ( <5 ) Categories, and they aren't expected to change, then you could hard-code each Category's title in the View.

Ma se si utilizza il secondo approccio, è possibile anche solo eseguire l'hardcode della fk della categoria nella vista. Anche un dettaglio importante nella descrizione è la parola "mi aspettavo", non ti "aspetti" che cambino, ma se cambiano comunque devi cambiare la vista. Con l'approccio del database n. 2 non è necessario modificare nulla nella vista

def for_sale where("category = ?", "For Sale") end

def requests where("category = ?", "Request") end

def misc where("category = ?", "Misc.") end

qui potresti anche scrivere, a cui non importa se il modello di dati cambia:

def for_sale where("category = ?", "1") end

def requests where("category = ?", "2") end

def misc where("category = ?", "3") end

    
risposta data 12.04.2016 - 16:49
fonte

Leggi altre domande sui tag

Come ottimizzare le prestazioni dei controlli delle condizioni sequenziali in Java? È possibile interrompere deliberatamente la RAM usando i puntatori?