Quando si nomina un modello, il nome deve essere il più generico possibile, anche se questo non sarà il nome visualizzato agli utenti?
Ad esempio, immaginiamo un modello Django per il piacere dei post di un altro utente.
Ha senso nominare il modello "Mi piace" anche se ho intenzione di visualizzarlo come Kudos, Approvazioni, Ups, ecc.?
Ha senso rendere il nome il più generico possibile, anche se il nome non sarà quello visualizzato all'utente?
A mio modesto parere, la denominazione dovrebbe essere specifica il più possibile. Seguendo il principio della responsabilità unica, i nomi delle tabelle / campi dovrebbero descrivere esattamente per cosa sono stati creati. Questo può aiutare molto in pista.
Prendendo il tuo esempio, chiamerei il modello "Kudos" (se è quello che chiamerai i tuoi mi piace) come puoi, in fondo alla traccia c'è un altro campo chiamato "Mi piace". Aiuterà inoltre i tuoi sviluppatori a comunicare internamente sui concetti. Se, per esempio, ti viene detto dalla direzione di "aggiungere 15 kudos all'account di tutti", questo viene mappato direttamente al tuo database. Non è richiesta alcuna traduzione.
L'unica eccezione a questa regola è se non hai ancora deciso il nome che verrà mostrato all'utente (cosa che potrebbe accadere per un numero qualsiasi di ragioni), nel qual caso sarebbe meglio usare il "migliore" indovina "al nome più specifico. Puoi sempre cambiarlo in un secondo momento (anche se, come tutte le modifiche ai requisiti, questo diventa più costoso lungo la traccia).
I nomi di tabelle e campi devono essere descrittivi dell'entità di dominio che acquisiscono. Se l'entità di dominio è un cliente, dovresti chiamare la tabella "Clienti". Come le classi in un programma orientato agli oggetti, le tabelle seguono il Principio di Responsabilità Unica: ogni tabella dovrebbe memorizzare istanze di una cosa (con tutti i suoi attributi), e solo una cosa.
Per capire perché è così, immagina l'esatto contrario. Immagina un sistema così generico da archiviarlo in sole tre tabelle:
TableID Primary Key
Name Text
FieldID Primary Key
TableID Foreign Key
Name Text
Type Enum (Text, Number, etc.)
ValueID Primary Key
FieldID Foreign Key
Value Text
Si noti che non ci sono informazioni identificative nelle tabelle stesse. Devi eseguire una query per trovare la tabella che desideri. Quindi, è necessario eseguire un'altra query per ottenere il campo desiderato e un terzo per ottenere il valore del campo.
Se questo sembra familiare, dovrebbe: le prime due tabelle sono fondamentalmente le tabelle "di sistema" in un DBMS ordinario, che ora abbiamo reinventato. In effetti, abbiamo reinventato l'intero DBMS. Se dubiti che questo possa mai accadere, leggi qui:
Leggi altre domande sui tag database coding-standards database-design django