Studiez această întrebare. există o astfel de expresie în răspuns
Testele primare compuse apar de obicei atunci când se face maparea din bazele de date vechi când cheia bazei de date este compusă din mai multe coloane.
Înțeleg corect că moștenirea este aproape sinonimă cu cuvântul "depășită"?
Dacă da, merită să faceți, atunci când dezvoltați o nouă aplicație și o nouă bază de date, chei compuse? Sau adăugați încă o coloană, care de fapt nu va face nimic, deoarece toată munca cu bd este de obicei efectuată de cadre?
a fost văzută ultima dată 5 Mar la ora 15:00
De obicei, folosesc următoarea regulă: dacă alte tabele nu se referă la tabel, atunci în acest tabel puteți utiliza o cheie compusă. Acest lucru nu este întotdeauna adevărat (de exemplu, este posibil ca cheia rezultată să nu fie unică sau să utilizați câmpuri voluminoase în cheie etc.), dar funcționează frecvent. Apoi, economisim memoria pe un indice suplimentar (sau, mai degrabă, în absența acestuia) și, prin urmare, mărim eficiența indicilor. - BOPOH 6 Mar 15 la 6:08 am
Aceasta este o întrebare destul de holivă și singurul răspuns adevărat nu este aici. Dar, de cele mai multe ori, opiniile sunt de acord că cheile nu ar trebui să fie compuse și nu ar trebui să conțină nici o informație despre entitate. Adică, trebuie să existe un câmp (de obicei, întreg-automat incrementat), care asigură unicitatea înregistrării
Cred că traducerea este semnificativă: "Cheile primare compuse apar de obicei când sunt mapate la tabelele de baze de date existente atunci când cheia tabelului este compusă din mai multe coloane".
Moștenirea aici este practic un sinonim pentru cuvântul "existent".
La elaborarea unei noi tabele, nu ar trebui să creați teoretic redundanță de informații cu un nou câmp cheie dacă combinația existentă de taste străine (sau alte câmpuri) este deja o cheie unică.
Dar, în practică, căutarea unui câmp suplimentar al unei chei unice poate fi mai rapid sau subiectiv mai ușor pentru dezvoltator și astfel are sens pentru obținerea rezultatului dorit :)
răspuns primit 20 Oct 15 la 5:17 am
Există o abordare oarecum depășită a designului bazei de date, numită uneori în mod greșit "academică", unde cheia primară a relației este selectată ca una dintre cheile naturale ale relației. De obicei, o astfel de cheie devine numele înregistrării.
Aceasta este abordarea pe care o utilizați. Dar această abordare este depășită din mai multe motive. Primul: cheia primară a înregistrării este ceea ce se utilizează pentru a se referi la înregistrare atât în baza de date cât și în afara acesteia. Este de dorit să o faceți cât mai puțin posibil - toate cheile cele mai naturale sunt șir.
Al doilea motiv este că multe lucruri care privesc la prima vedere ca chei naturale nu sunt într-adevăr așa. De exemplu, printre oameni există numiri complete (și chiar și aceia care s-au născut în aceeași zi). Magazinul poate avea două produse cu același nume în diferite departamente.
Al treilea motiv este că cheia naturală se poate schimba, de asemenea, ceea ce duce și la probleme. Deci, pentru o persoană, o cheie naturală ar putea fi un număr de pașaport sau un certificat de naștere - dar aceste documente pot fi înlocuite la o anumită vârstă sau în caz de pierdere.
Prin urmare, este o bună practică introducerea unei chei surogat - acesta este un domeniu nou care nu are nimic de-a face cu domeniul în cauză. De obicei, tipul său este un număr întreg de 32 de biți cu creștere automată, mai puțin de 64 de biți. Poate fi și un UUID.
Ca regulă, în prezența unui astfel de câmp, nu există nici un sens în cheile compuse.
Cu toate acestea, uneori cheile combinate sunt utile. Acestea sunt cazurile:
Tabele de legare pentru relații multe-la-multe. În mod obișnuit, astfel de tabele sunt create și gestionate de bibliotecile ORM - însă uneori trebuie să le creați separat. În astfel de tabele, întreaga cheie este cheia naturală - și nu există niciun motiv pentru a crea o cheie separată de surogat.
Unele sub-obiecte ale copilului care nu au nici un înțeles separat de părinte. Dacă facem un sistem de testare a elevilor, atunci uneori are sens să răspundem la răspunsul la întrebarea cu privire la cel de-al cincilea răspuns la întrebarea 147 și nu la răspunsul 3423. Și uneori opusul.
Utilizați relațiile din baza de date pentru verificări suplimentare de integritate. Există o așa-numită formă normală de domeniu-cheie în care toate restricțiile privind datele sunt implementate în format de chei străine. În acest caz, este uneori logic să includeți câmpuri suplimentare în cheia primară.
Trimiteți-le prietenilor: