Prefissi tabella database

Sicuramente non nominare ogni tabella con un prefisso. L'ho provato una volta ed è fastidioso mantenere e continuare dritti, soprattutto perché alcune tabelle si applicano a più sezioni.

Attualmente lavoro con un sistema che non ha un prefisso di denominazione per la maggior parte delle tabelle, ma esiste un prefisso di denominazione per le tabelle specifiche dei moduli

Ad esempio, abbiamo le solite Users , Customers , Products tabelle per la maggior parte degli oggetti, tuttavia un modulo che è specificamente progettato per funzionare con la gestione delle relazioni con i clienti potrebbe prefigurare le sue tabelle specifiche del modulo con CRM_

Vorrei utilizzare schemi separati per sezioni completamente separate l'una dall'altra, tuttavia se ci sono collegamenti tra i due (come il modulo CRM_ che collega alla tabella Customers principale), probabilmente sarei solo aggiungi le tabelle specifiche del modulo allo schema esistente e anteponali con qualcosa

Creare tutto in schemi separati è ciò che ha più senso, IMO. Fornisce una separazione logica e ti consente anche di organizzare facilmente ciò che stai facendo.

Se la tua applicazione cresce, sarà più facile replicare i dati su server di lettura separati, dato che potresti dividere per avere uno o più server di lettura per schema. Sarà molto più facile tracciare in questo modo.

A mio parere, i prefissi non sembrano avere valore fisico o logico, tranne in casi come questo:

• Per distinguere le tabelle normali dalle tabelle di riepilogo aggregate. Questo serve a rimuovere la confusione dalle tabelle di riepilogo vendite e vendite senza utilizzare la parola sommario .

• Per distinguere le viste dalle tabelle attuali

• Quando gestisci database demoralizzati in cui una singola tabella deve apparire due volte per distinguere tra dati dell'area di sosta e dati transazionali.

Le tabelle di prefisso non possono essere eseguite correttamente perché è comune trovare tabelle condivise tra le funzioni aziendali. Ad esempio, una tabella come Paese, può essere parte delle aree funzionali: Payroll, Vendite, Conti, Sicurezza, ecc.

La metodologia dell'Information Engineering promuove la categorizzazione logica delle tabelle in quelle che vengono definite Aree tematiche aziendali. Tuttavia, nell'implementazione fisica, non esiste tale divisione e non è richiesto il prefisso del nome.

Gli strumenti avanzati di modellazione dei dati consentono di raggruppare tabelle in gruppi separati da un modello principale e consentire l'amministrazione. del modello principale per fornire i diritti di accesso in modo che ogni sottomodello possa essere visualizzato e modificato in modo controllato.

Un altro problema con i prefissi, è che rendono i nomi più lunghi senza fornire valore a sviluppatore, dba o utente finale.

Devo menzionare qui che Microsoft Dynamics ha un approccio diverso a questo. Le tabelle in MS Dynamics hanno come prefisso un prefisso, ad esempio:

• CustBankAccount
• BankAccountStatement
• BankAccountTrans

Ancora una volta, personalmente, non vedo il valore dei prefissi tranne dove citato sopra.

Ho usato gli schemi perché rendono anche facile gestire la sicurezza sulle tabelle: puoi definire quale tipo di accesso ogni utente o gruppo di utenti sullo schema generale.

Ho anche tabelle come Users o Currencies che sono usate per ogni dipartimento e ho creato uno schema Common per esso.

Penso che abbia molto senso ed è sicuramente il più facile da mantenere.

1. I prefissi sono i migliori se:

a) Vuoi essere in grado di installare più copie della stessa applicazione all'interno di un singolo schema o database

b) Devono fornire protezione contro l'iniezione SQL soprattutto per le piattaforme CMS comuni

1. Tuttavia li trovo un problema e un problema. Le tabelle dovrebbero essere denominate in modo che i loro nomi definiscano i loro contenuti, proprio come @Emmad Kareen ha descritto da Microsoft Dynamics sopra.

2. Vengo dal mondo MySQL in cui le applicazioni che utilizzano più database non sono così comuni, sebbene siano in Oracle e in altri database.

3. Inoltre, ciò che è comune è l'utilizzo di un utente dell'applicazione per connettere l'applicazione al database, quindi utilizzare la sicurezza delle applicazioni per controllare ciò che un utente può vedere o accedere.

Il mio consiglio, stai lontano da loro mentre rendono lo sviluppo e la mappatura ORM più complessi

Non lo farei Inoltre, se puoi dividere chiaramente la tua applicazione in diverse sezioni gestendo ciascuna una diversa funzionalità, potresti semplicemente orientare il messaggio in modo completo e renderle completamente separate, ognuna con dati in uno schema separato (o anche server) ) tutti i messaggi che passano attraverso un bus condiviso sotto un meccanismo di pubblicazione / sottoscrizione.

Quindi, per mantenere la risposta breve, non farlo. Se provate a indovinare dove verrà usata la tabella in questo momento, probabilmente vi sbagliate e sarete infastiditi per sempre perché la tabella crm_users verrà inevitabilmente utilizzata nel gestore delle identità. La tua domanda mi fa sospettare che la tua organizzazione stia provando un approccio BDUF. Qualunque cosa pensi di sapere sul sistema ora, fidati di me, davvero no. ; -)