Quale schema della tabella del database è più efficiente?

Question

Quale schema della tabella del database è più efficiente e perché?

"Users (UserID, UserName, CompamyId)"
"Companies (CompamyId, CompanyName)"

O

"Users (UserID, UserName)"
"Companies (CompamyId, CompanyName)"
"UserCompanies (UserID, CompamyId)"

Dato che utente e azienda hanno una relazione uno a uno.

Answer 1

Di sicuro, quello precedente è più efficiente dato questo vincolo.Per ottenere le stesse informazioni, avrai meno numero di join nelle tue query.

Answer 2

beh, questa è una domanda a risposta aperta e dipende dalle regole della tua attività.La prima opzione disponibile consente di mappare solo un'azienda su un utente.stai definendo una relazione molti-a-uno.

Il secondo schema definisce una relazione molti-a-molti che consente di associare più utenti a più aziende.

Risolvono diversi problemi e, a seconda di ciò che stai cercando di risolvere, determinerà quale schema dovresti utilizzare.

In senso stretto dal punto di vista delle "transazioni", il primo schema sarà più veloce perché devi solo impegnare una riga affinché un oggetto utente venga associato a un'azienda e per recuperare l'azienda per cui lavora il tuo utente richiede solo un join, tuttavia, la seconda soluzione sarà più scalabile se i requisiti aziendali cambiano e richiedono l'assegnazione di più aziende a un utente.

Answer 3

Come sempre dipende.Personalmente sceglierei la risposta numero uno poiché avrebbe meno join e sarebbe più facile da mantenere.Meno join dovrebbero significare che richiedono meno scansioni di tabelle e indici.

SELECT userid, username, companyid, companyname
FROM companies c, users u
WHERE userid = companyid

È molto meglio di...

SELECT userid, username, companyid, companyname
FROM companies c, users u, usercompanies uc
WHERE u.userid = uc.userid
AND c.companyid = uc.companyid

Answer 4

I due schemi non possono essere confrontati, poiché hanno relazioni diverse, dovresti probabilmente guardare quali sono le specifiche per le tabelle e poi capire quale si adatta alla relazione necessaria.

Il primo implica che un Utente può essere solo membro di uno azienda (una relazione di appartenenza).Mentre il secondo schema implica che un Utente possa essere membro di molte aziende (una relazione has_many)

Se stai cercando uno schema che possa (o supporterà in seguito) una relazione has_many, allora scegli il secondo.Per il motivo confrontare:

//select all users in company x with schema 1
select username, companyname from companies
inner join users on users.companyid = companies.companyid
where companies.companyid = __some_id__;

E

//select all users in company x with schema 2
select username, companyname from companies
inner join usercompanies on usercompanies.companyid = companies.companyid
inner join users on usercompanies.userid = users.userid
where companies.companyid = __some_id__;

Hai un join extra sulla tabella selezionata.Se desideri solo la relazione appartiene_a, la seconda query svolge più lavoro di quanto dovrebbe e quindi la rende meno efficiente.

Answer 5

Penso che tu intenda "molti a uno" quando si tratta di utenti e aziende, a meno che tu non preveda di avere un'azienda unica per ciascun utente.

Per rispondere alla tua domanda, segui il primo approccio.Una tabella in meno da archiviare riduce lo spazio e farà sì che le tue query utilizzino meno comandi JOIN.Inoltre, e cosa ancora più importante, corrisponde correttamente all'input desiderato.Lo schema del database dovrebbe descrivere il formato per tutti i dati validi: se si adatta al formato dovrebbe essere considerato valido.Poiché un utente può avere solo un'azienda, è possibile che nel database siano presenti dati errati se si utilizza il secondo schema.

Answer 6

Se Utente e Azienda hanno davvero un file uno a uno relazione, allora hai solo bisogno di una tabella:

(ID, UserName, CompanyName)

Ma sospetto che tu intendessi davvero che esiste un uno a molti rapporto tra utente e azienda: uno o più utenti per azienda ma solo un'azienda per utente.In tal caso la soluzione a due tabelle è corretta.

Se c'è un molti-a-molti relazione (un'azienda può avere più utenti e un utente può essere collegato a più aziende), la soluzione a tre tabelle è corretta.

Notare che efficienza non è proprio questo il problema qui.È la natura dei dati che determina quale soluzione utilizzare.