වගුවක ප්‍රාථමික යතුරු තීරුව “අයිඩී” ලෙස නම් කිරීම නරක පුරුද්දක් ලෙස සලකන්නේ ඇයි? [වසා ඇත]

217

එය දැනට පවතින පරිදි, මෙම ප්‍රශ්නය අපගේ ප්‍රශ්නෝත්තර ආකෘතියට සුදුසු නොවේ. කරුණු, යොමු කිරීම් හෝ විශේෂ ise තාවයන්ගෙන් පිළිතුරු ලැබෙනු ඇතැයි අපි අපේක්ෂා කරමු, නමුත් මෙම ප්‍රශ්නය විවාදය, තර්ක, ඡන්ද විමසීම හෝ දීර් discussion සාකච්ඡාවක් ඉල්ලා සිටිනු ඇත. මෙම ප්‍රශ්නය වැඩිදියුණු කර නැවත විවෘත කළ හැකි යැයි ඔබට හැඟේ නම්, මඟ පෙන්වීම සඳහා උපකාරක මධ්‍යස්ථානය වෙත යන්න.

වසර 7 කට පෙර වසා ඇත.

මගේ ටී-එස්එල්එල් ගුරුවරයා අපට පැවසුවේ අපගේ පීකේ තීරුව "අයිඩී" ලෙස නම් කිරීම වැඩිදුර පැහැදිලි කිරීමකින් තොරව නරක පුරුද්දක් ලෙස සලකන බවයි.

PK තීරුව "Id" ලෙස නම් කිරීම නරක පුරුද්දක් ලෙස සලකන්නේ ඇයි?

sql naming tsql

— ජීන්-පිලිප් ලෙක්ලර්ක්
source

27

හොඳයි, එය ඇත්ත වශයෙන්ම විස්තරයක් නොවන අතර අයිඩී යන්නෙහි අර්ථය “අනන්‍යතාවය” යන්නයි. එය මගේ මතයයි.

— ජීන්-පිලිප් ලෙක්ලර්ක්

49

PK නමක් ලෙස Id භාවිතා කරන සාප්පු ඕනෑ තරම් ඇති බව මට විශ්වාසයි. මගේ නම් කිරීමේ සම්මුතිය ලෙස මම පෞද්ගලිකව TableId භාවිතා කරමි, නමුත් මම එහි සත්‍ය මාර්ගය කිසිවෙකුට නොකියමි. ඔබේ ගුරුවරයා ඇගේ මතය පුළුල් ලෙස පිළිගත් හොඳම භාවිතයක් ලෙස ඉදිරිපත් කිරීමට උත්සාහ කරන බවක් පෙනේ.

22

නිසැකවම එතරම් නරක නොවන නරක පුරුදු වර්ගය. කාරණය වන්නේ ස්ථාවර වීමයි. ඔබ හැඳුනුම්පත භාවිතා කරන්නේ නම්, එය සෑම තැනකම භාවිතා කරන්න හෝ භාවිතා නොකරන්න.

— deadalnix

58

ඔබට මේසයක් තිබේ ... එය මිනිසුන් ලෙස හැඳින්වේ, එයට තීරුවක් ඇත, අයිඩී යනුවෙන් හැඳින්වේ, ඔබ සිතන්නේ අයිඩී යනු කුමක්ද? කාර් එකක්? බෝට්ටුවක්? ... නෑ ඒ පීපල් අයිඩී, එච්චරයි. මම හිතන්නේ නැහැ එය නරක පුරුද්දක් නොවන අතර අයිඩී හැර වෙනත් කිසිවක් පීකේ තීරුවට නම් කිරීම අවශ්‍ය නොවේ.

— ජිම්

38

ඉතින් ගුරුවරයා පන්තිය ඉදිරිපිටට පැමිණ ඔබට කියන්නේ එක හේතුවක් නොමැතිව මෙය නරක පුරුද්දක් කියාද? එය ගුරුවරයෙකුට වඩා නරක පුරුද්දකි.

— ජෙෆෝ

251

ඒක ඇත්තටම නරක පුරුදු (සහ පවා එය, එහි නොමැති නම් නොවේ: මම ඇවිත් ඒක කියන්න යන්නේ ඒ නරක).

පහත දැක්වෙන විමසුමේදී මෙන් දෝෂ වසං කළ හැකි බවට ( චැඩ් පෙන්වා දුන් පරිදි) ඔබට තර්කය ඉදිරිපත් කළ හැකිය:

SELECT * 
    FROM cars car
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

නමුත් ඔබේ වගු නාම සඳහා කුඩා අන්වර්ථ නාම භාවිතා නොකිරීමෙන් මෙය පහසුවෙන් අවම කර ගත හැකිය:

SELECT * 
    FROM cars
    JOIN manufacturer
        ON manufacturer.Id = cars.ManufacturerId
    JOIN models
        ON models.Id = cars.ModelId
    JOIN colors
        ON manufacturer.Id = cars.ColorId

තීරු නම භාවිතා කිරීමට වඩා සෑම විටම අකුරු 3 ක් භාවිතා කිරීම පුරුද්දක් ලෙස මට පෙනේ id. (උදාහරණ ලෙස: වගුවේ නම carsකෙටියෙන් කෙටියෙන් හඳුන්වන්නේ carකවුද? එය සේවය කරන්නේ කුමන අවසානයටද?)

කාරණය වන්නේ: අනුකූල වන්න. ඔබේ සමාගම හැඳුනුම්පත භාවිතා කරන්නේ නම් සහ ඔබ සාමාන්‍යයෙන් ඉහත වැරැද්ද කරන්නේ නම්, සම්පූර්ණ වගු නම් භාවිතා කිරීමේ පුරුද්ද ඇති කරගන්න. ඔබේ සමාගම හැඳුනුම් තීරුව තහනම් කරන්නේ නම්, එය වේගයෙන් ගෙන ඔවුන් කැමති ඕනෑම නම් කිරීමේ සම්මුතියක් භාවිතා කරන්න.

මේ වගේ කාරණා ගැන කතා කරනවාට වඩා ඇත්ත වශයෙන්ම නරක පුරුදු (බහු කැදැලි සහසම්බන්ධිත උප විමසුම් වැනි) ඉගෙනීමට අවධානය යොමු කරන්න. ඔබේ තීරු "හැඳුනුම්පත" ලෙස නම් කිරීමේ ගැටළුව නරක පුරුද්දකට වඩා රසයට වඩා සමීප වේ.

සංස්කාරකවරුන්ට සටහනක්: මෙම විමසුමේ දෝෂය හිතාමතාම වන අතර එය කරුණු දැක්වීමට භාවිතා කරයි. සංස්කරණය කිරීමට පෙර කරුණාකර සම්පූර්ණ පිළිතුර කියවන්න.

— riwalk
source

1

H චැඩ්, එය විශේෂිත විමසුමේදී ඔබ අන්වර්ථ නාම සඳහා වගු නාම සඳහා අකුරු 3 ක් භාවිතා කර ඇති අතර, එය තේරුමක් නැති විට පවා ( cars-> car. දෙවියන්ට ස්තූතියි - ඔබ මගේ ඇඟිලි බේරා ගත්තා). ඒ ගැන ඕනෑවට වඩා කියවන්න එපා.

— රිවාක්

3

මගේ අන්වර්ථ නාමයන්ට වඩා නරක නම්, මම බහුත්ව මිශ්‍ර වීම carsසහ manufacturer. එකක් බහු වචන, අනෙක එසේ නොවේ. මිනිසුන්ට ඩීබී එකෙන් තෝරා ගැනීමට අවශ්‍ය නම්, එය තෝරා ගත යුතු නරක පුරුද්ද එයයි.

— CaffGeek

3

මම හිතන්නේ එය නරක පුරුද්දක්. නිසැකවම, නරක පුහුණුවීම් වලට අනුව එය භයානක නොවේ .. නමුත් එය වළක්වා ගැනීම එතරම් පහසුය, එසේ නොකරන්නේ මන්ද? දැන්, මම එකඟ වෙමි, හඳුන්වාදීමේ පන්තියක් සඳහා, අවධානය යොමු කළ යුතු කාරණය මෙයද? බොහෝ විට නැත ....

— user606723

2

60 user606723, ඇත්ත වශයෙන්ම, හඳුන්වාදීමේ පන්තියක් සඳහා එය වැදගත් කරුණක් බව මම සිතමි. හොඳම පුරුදු ඉගැන්වීම මූලික විය යුතුය. එහි ප්‍රතිවිපාක සහ වෙළඳාම් සහ ඔබ හොඳ පුරුදු වලින් බැහැර විය යුත්තේ කවදාදැයි ඔබ අත්විඳින තෙක් නොවේ.

— CaffGeek

5

H චැඩ්, එකඟ නොවීමට එකඟ වන්න. හොඳම භාවිතයන් වන්නේ ඇයි දැයි තේරුම් ගැනීමට ඉඩ නොදී සිසුන්ට “හොඳම භාවිතයන්” ඉගැන්වීමට උත්සාහ කිරීම නිෂ් uti ල උත්සාහයකි. ඔබට සෑම දෙයක්ම ආවරණය කළ නොහැකි බැවින්, මෙම කරුණ "ඔබ එය නොකළ යුතුය, පසුව ඔබ තේරුම් ගනීවි" යන්න මහාචාර්යවරයෙකුගේ දෘෂ්ටි කෝණයෙන් බැලූ බැල්මට පෙනේ. කුතුහලය දනවන සිසුන්ට මෙහි පළ කිරීමට හෝ දැනටමත් පිළිතුරු දී ඇති මෙම ප්‍රශ්නයට බලාපොරොත්තු විය හැකිය. (නැතහොත් පංතියෙන් පසුව විමසන්න)

— user606723

125

ඔබ සතුව විදේශීය යතුරක් ඇති වගුවක් ඇති විට ඔබට එම විදේශීය යතුර "අයිඩී" ලෙස නම් කළ නොහැක. ඔබට මේස නාමය ඇත TableId

එවිට ඔබේ බැඳීම පෙනේ

SELECT * FROM cars c JOIN manufacturer m ON m.Id = c.ManufacturerId

ඔබේ තත්වය සෑම පැත්තකින්ම එකම ක්ෂේත්‍ර නාමයක් තිබිය යුතුය

SELECT * FROM cars c JOIN manufacturer m ON m.ManufacturerId = c.ManufacturerId

එබැවින් නිෂ්පාදකයා ලෙස හැඳුනුම්පත නම් කිරීම අතිරික්තයක් ලෙස පෙනුනද, එමඟින් වැරදි සම්බන්ධ වන විට ඔබේ සම්බන්ධ වීමේ කොන්දේසි වල දෝෂ ඇති බව අඩු වේ.

මෙය සරල බව පෙනේ, නමුත් ඔබ වගු කිහිපයකට සම්බන්ධ වූ විට, ඔබ වැරැද්දක් කිරීමට වැඩි ඉඩක් ඇත, පහත එක සොයා ගන්න ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

නිසි නම් කිරීම සමඟ, දෝෂය කැපී පෙනේ ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.ManufacturerId = car.ManufacturerId
    JOIN models mod
        ON mod.ModelId = car.ModelId
    JOIN colors col
        ON mfg.ManufacturerId = car.ColorId

අයිඩී "නරක" ලෙස නම් කිරීමට තවත් හේතුවක් නම්, ඔබ වගු කිහිපයකින් තොරතුරු විමසන විට ඔබට අයිඩී තීරු නම් කිරීමට අවශ්‍ය වන අතර එමඟින් ඔබට ඒවා වෙන්කර හඳුනාගත හැකිය.

SELECT   manufacturer.Id as 'ManufacturerId'
        ,cars.Id as 'CarId'
        --etc
    FROM cars 
    JOIN manufacturer
        ON manufacturer.Id = cars.Id

නිවැරදි නම් සහිතව මෙය ගැටළුවක් අඩුය

— revs CaffGeek
source

177

මෙය මට හොඳ පැහැදිලි කිරීමක් බව විශ්වාස නැත. කීමේ වරදක් නැත SELECT * FROM cars c JOIN manufacturer m ON manufacturer.Id = c.ManufacturerId. මම idවසර ගණනාවක් තිස්සේ භාවිතා කර ඇති අතර ඔබ විස්තර කළ දේ සැබෑ ගැටලුවක් ලෙස කිසි විටෙකත් සොයාගෙන නැත.

— රිවොක්

61

මෙහි නරක පුරුද්ද වන්නේ mfg හෝ mod වැනි නම සහිත අන්වර්ථ වගු බව මම කියමි. manufacture.id = cars.manufacturer_id ඉතා කියවිය හැකි අතර දෝෂය ද කැපී පෙනේ.

— deadalnix

5

@ චැඩ්> ගොළු විචල්‍ය නම් සමඟ මට දැනටමත් ගැටළු තිබේ. බොහෝ වාරයක්. රෙකෝඩ් කිරීම සඳහා, මෙන්න මම මගේ කණ්ඩායමේ මෙය කරන දේවරයෙකුට පවසන දෙය «mfg යන්නෙන් නිෂ්පාදකයා අදහස් නොවේ, එයින් අදහස් වන්නේ ඔබ නිෂ්පාදකයා ටයිප් කිරීමට කම්මැලි විය යුතු බවයි».

— deadalnix

9

@ Stargazer712: වගු 2 කින් SELECT * කිරීමෙන් 2 x ID තීරු ලැබේ. හැඳුනුම්පත දැන් අපැහැදිලි ය: ඔබ යොමු කරන්නේ සාමාන්‍ය හෝ නම අනුව ද? SELECT * හොඳ පුහුණුවක් ද නොවේ. දුර්වල තර්ක. බිඳෙන සුළු කේතය. චැඩ් නිවැරදි ය: ආරක්ෂක කේතීකරණය මූලික වශයෙන්

— gbn

6

@gbn, නැවතත්, ඔබ සරලවම කළහොත් සියලු අපැහැදිලි බව නැති වී යයි SELECT manufacturer.id FROM .... එහි ප්‍රති ing ලයක් ලෙස ඇති වන සෑම දුෂ්කරතාවයක්ම idඉතා පහසුවෙන් ජය ගත හැකි අතර එය හුදෙක් රසයේ කාරණයක් බවට පත් කරයි.

— රිවොක්

68

රූබීගේ ඇක්ටිව් රෙකෝඩ් පුස්තකාලය සහ ග්‍රෝවිගේ GORM පෙරනිමියෙන් අන්‍යාගමික යතුර සඳහා "හැඳුනුම්පත" භාවිතා කරයි. මම මේ පුරුද්දට කැමතියි. එක් එක් තීරුවේ නමෙහි වගුවේ නම අනුපිටපත් කිරීම අතිරික්තය, ලිවීමට වෙහෙසකාරී සහ කියවීමට වඩා වෙහෙසකාරී ය.

— kevin cline
source

30

+1 සඳහා "සහ කියවීමට වඩා වෙහෙසකරයි." - නම් කිරීමේ සම්මුතීන් අලස කේත සඳහා කලාප ආධාරකයක් ලෙස නොසිතිය යුතුය, ඒවා මූලික අවධානයක් ලෙස කියවීමේ හැකියාව වැඩි දියුණු කළ යුතුය.

— ocodo

12

හැඳුනුම්පත කියවීමට වඩා

— වෙහෙසකරයි

6

LHLGEM: යමෙකුට සෑම විටම තීරුවේ නම වගු නාමය සමඟ සුදුසුකම් ලැබිය හැකිය.

— kevin cline

2

කියවීමට වඩා වෙහෙසකාරී බව හැරෙන්නට මම එකඟ වෙමි. මම වඩාත් කැමති වඩාත් විස්තරාත්මක තීරු නම් කියවීමට සහ එම තීරුව ඇත්ත වශයෙන්ම කුමක් දැයි හදුනා ගැනීමට අඩු කාලයක් ගත කිරීමට ය.

— ඩෙවින් ඩික්සන්

2

+1, Post.postID, Posts.postName වැනි තීරු සහිත වගු දැකීම පිළිකුල් කරන්න, එහිදී හුදෙක් post.id සහ post.name භාවිතා කිරීම වඩා ලස්සනයි.

— ඩග්

40

"නම" හෝ "හැඳුනුම්පත" වැනි පොදු හෝ යතුරු තීරු නම් වගු නාමය සමඟ උපසර්ග ගත යුතුය.

එය අපැහැදිලි බව ඉවත් කරයි, සෙවීමට පහසුය, එයින් අදහස් කරන්නේ "අයිඩී" අගයන් දෙකම අවශ්‍ය වූ විට තීරු අන්වර්ථයන් වඩා අඩු බවයි.

අඩුවෙන් භාවිතා කළ හෝ විගණන තීරුවක් හෝ යතුරක් (LastUpdatedDateTime කියන්න) වැදගත් නොවේ

— gbn
source

57

ඔබ මෙය කරන්නේ නම්, මට අමතර ටයිප් කිරීමක් කිරීම ගැන මම ඔබට වෛර කරමි !!!! මේසයේ නම පුද්ගලයා, ඔබ සිතන්නේ හැඳුනුම්පත කුමක් වනු ඇත්ද? මෝටර් රථ? නැහැ, ඒ පුද්ගලයා.

— ජිම්

16

im ජිම්, මම ඔබ ගැන නොදනිමි, නමුත් අමතර අක්ෂර 6 ක් ටයිප් කිරීමෙන් මට දළ වශයෙන් තත්පර භාගයක් ගතවේ. මම එක් වගුවකින් කලාතුරකින් තෝරාගෙන ඇති අතර, ඒ අනුව 'අයිඩී' නම් තීරු දෙකකින් අවසන් වන අතර කෙසේ හෝ වගුව / අන්වර්ථ නාමය ඇතුළත් කිරීමට අවශ්‍ය වනු ඇත, යතුරු ලියනය කළ අක්ෂර සංඛ්‍යාවේ ඉතිරියක් නොමැත.

— CaffGeek

22

H චැඩ් මට එය ඕනෑවට වඩා පෙනේ. මම සම්බන්ධ වීමක් කරන්නේ නම්, c.id = m.manufacturerid, මා සමඟ හොඳින්. මෙම තීරු සාමාන්‍යයෙන් කෙසේ හෝ පන්තියකට "සිතියම් ගත" කර ඇති අතර පුද්ගලයා සමඟ පන්තියක් පැවැත්විය යුතුය. පර්සන් අයිඩ් මට වමනය කිරීමට අවශ්‍ය කරයි ... ඔව්, මට ගැටළු ඇති බව මම හොඳින් දනිමි.

— ජිම්

20

මමත් මේකට එකඟ නැහැ. ඇයි නතර nameහා id? සෑම තීරුවක්ම එහි වගු නාමය සමඟ උපසර්ග කර නොගන්නේ මන්ද? උපසර්ගයක් නියම කිරීම සඳහා එම නම් දෙක තෝරා ගැනීම අත්තනෝමතික ලෙස පෙනේ. සංකල්පමය වශයෙන්, කෙසේ හෝ තීරුවක සන්දර්භය ලබා ගැනීම සඳහා ඔබට වගුව තිබිය යුතුය. විමසුම පැහැදිලි කිරීම සඳහා එම වගුවේ නම පමණක් භාවිතා නොකරන්නේ ඇයි: Person.Name, Animal.Name, Part.Name, ...

— Thomas

11

Ill බිල් ලීපර්, දත්ත සමුදාය සංවර්ධනය කිරීමේදී ඩ්‍රයි සැමවිටම සුදුසු නොවේ. දත්ත සමුදායන්හි වැදගත් වන්නේ කාර්ය සාධනය සහ දත්ත සමුදාය ඩ්‍රයි මූලධර්ම පූර්ණ ලෙස පිරවීම සඳහා වැඩිපුර වැඩ කිරීම ය. (පරිමාණ ශ්‍රිත හෝ දර්ශන භාවිතා කරන අදහස් හෝ විමසුම් විමසීම් හෝ තීරු වැඩි ප්‍රමාණයක් ලබා දීම හෝ කර්සරයක් භාවිතා කරමින් දැනට පවතින ප්‍රොක් එකක් භාවිතා කිරීම සඳහා වාර්තා 1000000 එකතු කිරීම) බොහෝ විට contraindicated. වස්තු-නැඹුරු ලෝකයේ යමක් හොඳ නිසා දත්ත සමුදා සැලසුම් කිරීමේදී එය සුදුසු යැයි නොසිතන්න. ඔබගේ පහත් අගය නුසුදුසු විය. හැඳුනුම්පත භාවිතා කිරීම දන්නා SQL ප්‍රති-රටාවකි.

— HLGEM

32

මෙම නූල මියගොස් ඇත, නමුත් IMO භාවිතා නොකිරීමId නරක පුරුද්දක් බව එක් කිරීමට මම කැමැත්තෙමි . මෙම Idතීරුව විශේෂ ය; එය මෙම ප්රාථමික යතුර. ඕනෑම වගුවකට විදේශීය යතුරු ගණනක් තිබිය හැකි නමුත් එයට තිබිය හැක්කේ ප්‍රාථමික යතුරක් පමණි. සියලුම ප්‍රාථමික යතුරු කැඳවා ඇති දත්ත ගබඩාවක Id, ඔබ මේසය දෙස බැලූ විගසම ප්‍රාථමික යතුර කුමක්දැයි ඔබ හරියටම දනී.

මාව විශ්වාස කරන්න, දැන් මාස ගණනක් තිස්සේ මම සෑම දිනකම විශාල දත්ත සමුදායන් (විකුණුම් බලකාය) තුළ වැඩ කර ඇති අතර, ක්‍රමෝපායන් ගැන මට පැවසිය හැකි හොඳම දෙය නම් සෑම වගුවකටම ප්‍රාථමික යතුරක් Idතිබීමයි. PK ලෙස හැඳින්වෙන නිසා විදේශීය යතුරකට ප්‍රාථමික යතුරක් සම්බන්ධ කිරීම ගැන මම කිසි විටෙකත් ව්‍යාකූල නොවන බව මට සහතික විය හැකිය Id. මිනිසුන් සඳහන් නොකළ තවත් දෙයක් නම්, වගු වලට දිගු මෝඩ නම් තිබිය හැකි ය Table_ThatDoesGood_stuff__c; ගෘහ නිර්මාණ ශිල්පියා උදේ වරුවේ හැන්ගෝවර් එකක් තිබූ නිසා එම නම නරක ය, නමුත් දැන් ඔබ මට කියන්නේ ප්‍රාථමික යතුර ඇමතීම නරක පුරුද්දක් බවයි Table_ThatDoesGood_stuff__cId (SQL තීරු නම් සාමාන්‍යයෙන් සංවේදී නොවන බව මතක තබා ගැනීම).

ඇත්තම කිව්වොත්, පරිගණක ක්‍රමලේඛනය උගන්වන බොහෝ පුද්ගලයින්ගේ ගැටළු නම්, ඔවුන් වසර ගණනාවක සිට නිෂ්පාදන කේතයක් ලියා නොමැති අතර, වැඩ කරන මෘදුකාංග ඉංජිනේරුවෙකු ඇත්ත වශයෙන්ම කරන්නේ කුමක්ද යන්න පිළිබඳව ඔවුන්ට අවබෝධයක් නැත. ඔබ වැඩ කිරීමට පටන් ගන්නා තෙක් රැඳී සිට හොඳ අදහසක් හෝ නැතැයි ඔබ සිතන දේ ඔබේ මනසෙහි තබා ගන්න.

— revs user23157
source

2

ඔබගේ ප්‍රාථමික යතුරු කිසිවක් සංයුක්ත යතුරක් නොවේ නම් එය එසේ වන්නේ අවාසනාවකට මෙන් බොහෝ විට එසේ නොවේ. යමෙකු සැබවින්ම භාවිතා කළ යුත්තේ විශේෂිත අවස්ථාවන්හිදී පමණි.

— nicodemus13

6

සංවර්ධකයින් සිතන්නේ නැතිව ඔවුන් සාදන සෑම වගුවකටම මූලික යතුරු හැඳුනුම්පත එකතු කරන තත්වයක් සමඟ අයිඩී භාවිතා කිරීම. සබැඳි දත්ත සමුදායන්හි එක් පදනමක් වන්නේ අර්ථවත් හා සමස්ත ප්‍රාථමික යතුරු භාවිතා කිරීම සහ හැඳුනුම්පත භාවිතා කිරීම උපකාරී නොවේ.

— පීටර් බී

මෙම පිළිතුර ඔබ අදහස් කරන තර්ක සමඟ "මම අයිඩීට කැමතියි" යැයි පවසන බවක් පෙනේ. ඔබේ තර්කය නම් අයිඩී යනුවෙන් හැඳින්වෙන යතුර සොයා ගැනීමෙන් මූලික යතුර කුමක්දැයි ඔබට ක්ෂණිකව දැකගත හැකිය. හොඳයි, එය හරියටම TableId සමඟ සමාන වේ. ප්‍රාථමික යතුර කුමක්දැයි මම කිසි විටෙකත් ව්‍යාකූල නොවෙමි. මම හැඳුනුම්පතට පෙර මේසයේ නම ඇති එක සොයමි. එපමණක් නොව, පළමු තීරුවේ ප්‍රාථමික යතුර නොමැති තැන ඔබ වැඩ කරන්නේ කුමන ආකාරයේ විජාතික වගු සමඟද? මෙම පිළිතුරෙහි ඔබගේ සියලු තර්ක තනිකරම මනාප පදනම් වූ ඒවා වන අතර "tableId මට වැරදියි" යනුවෙන් මට හැඟේ.

— ඩලින්

all ඩලින් සියලු පිළිතුරු දරනු ලැබේ, එසේ නොමැතිනම් යමෙකු නිල ප්‍රමිතියට සම්බන්ධ වනු ඇත, එකක්වත් නැත!

— ජේම්ස්

Ame ජේම්ස් මට දැනෙන්නේ ස්ටැක්එක්ස්චේන්ජ් අඩවි වල පරමාර්ථය වන්නේ අදහස් දැක්වීම් අඩු කිරීමයි. ඕනෑවට වඩා අදහස් ඇති බැවින් ප්‍රශ්න වැසෙන්නේ එබැවිනි. ඇත්ත වශයෙන්ම, මෙම ප්‍රශ්නය වසා දැමීමට හේතුව එය යැයි මම සිතමි - එය මතවාදී පිළිතුරු ඉස්මතු කරන හෙයින්, නමුත් මෙම නිශ්චිත පිළිතුර සත්‍ය ආධාරක කරුණු හෝ කරුණු මත පදනම් වූ තර්ක නොමැතිව ඕනෑවට වඩා අදහස් දැක්වූ බව මට හැඟේ. සම්පූර්ණ පිළිතුර සාරාංශගත කළ හැකිය, “In මගේ මතය නම්, ඔබ අයිඩී භාවිතා කළ යුතුය, එය මා කැමති නිසා ය ”. එය වටිනා පිළිතුරක් නොවේ.

— ඩලින්

25

Data.stackexchange.com වෙතින්

තනතුරු වල හැඳුනුම්පත

BOOM, ප්‍රශ්නයට පිළිතුරු.
දැන් ගොස් ඔබේ ගුරුවරයාට කියන්න SO නරක දත්ත සමුදායක් සැලසුම් කරන බව.

— සිරිල් ගන්ඩන්
source

8

නම් මත පදනම්ව, FKs හි මගේ අනුමානය : PostTypeId -> PostTypes.Id; AcceptedAnswerId -> Answers.Id; OwnerUserId -> Users.Id. එතරම් පහසු පුරුද්දක් 'නරක' ලෙස සැලකිය යුත්තේ ඇයි?

— Sjoerd

4

හොඳම භාවිතයන් පිළිබඳව මෙය හරියටම ඔප්පු කරන්නේ කෙසේද?

— GBa

6

යමක් තොගයේ භාවිතා කළත් නැතත් එය හොඳ හෝ නරක පුරුද්දක් දැයි ඔප්පු නොවේ.

— පීටර් බී

2

එය සනාථ කරන දෙය නම්, මෙම භාවිතයෙන් යෙදුමක පරිමාණය සහ ප්‍රයෝජනය කිසිසේත් තහනම් නොවන බවයි.

— සයිෆර්

1

ඇත්ත වශයෙන්ම SO පුහුණුව පරිපූර්ණ නොවේ. මම මෙම නම් කිරීම භාවිතා කරමි: PostType -> PostType.Id; පිළිගත් පිළිතුරු -> පිළිතුර.ඉඩ්; OwnerUser -> User.Id

— alpav

24

මම එය නරක පුරුද්දක් ලෙස සලකන්නේ නැහැ. සුපුරුදු පරිදි අනුකූලතාව රජ වේ.

මම හිතන්නේ ඒ සියල්ල සන්දර්භය ගැන ය. වගුවේ සන්දර්භය තුළ, "හැඳුනුම්පත" යන්නෙන් අදහස් කරන්නේ ඔබ අපේක්ෂා කරන දෙයමයි, වෙනත් ආකාරයකින් සමාන විය හැකි (හෝ පෙනෙන) අනෙක් අයට එරෙහිව එය අද්විතීය ලෙස හඳුනා ගැනීමට උපකාරී වන ලේබලයකි.

සම්බන්ධ වීමේ සන්දර්භය තුළ, ඔබට සහ ඔබේ කණ්ඩායමට කියවිය හැකි වන පරිදි සම්බන්ධතා ගොඩනැගීම ඔබේ වගකීමකි. දුර්වල වාක්‍ය ඛණ්ඩයක් හෝ නම් කිරීමක් සමඟ දේවල් දුෂ්කර කරවීමට හැකි සේම, අන්වර්ථ නාමයන් සහ අදහස් පවා effective ලදායී ලෙස භාවිතා කරමින් අර්ථවත් විමසුමක් තැනීම සමානව කළ හැකිය.

ජාවා පංතියක 'ෆූ' හි ගුණාංග 'ෆූ' මගින් උපසර්ගගත කර නැති ආකාරයටම, ඔබේ වගු හැඳුනුම්පත් වගු නාම සමඟ උපසර්ග කිරීමට බැඳී නොසිටින්න. හැඳුනුම්පත යනු කුමක්ද යන්න සාමාන්‍යයෙන් සන්දර්භය තුළ පැහැදිලි වේ.

— lotsoffreetime
source

5

සාපේක්ෂ දත්ත සමුදා වගු පන්ති නොවේ .

— ඇඩම් රොබින්සන්

1

කෙසේ වෙතත් ඒවා දත්ත ව්‍යුහයන් වන අතර ඒවා PODO පන්ති වලට සමානය. එකම නම් කිරීමේ ගැටළු අදාළ වේ.

— ocodo

4

L ස්ලොමෝජෝ: නැත, ඒවා සරල වස්තූන් හා සමාන නොවේ. වස්තු-නැඹුරු සැලසුම් සහ දත්ත සමුදා සැලසුම් එක හා සමාන නොවන අතර ඒවා පවා සම්බන්ධ නොවේ. සමහර අවස්ථාවල දී ඔවුන්ට සමාන (හෝ එකම) මෝස්තරයක් ලබා දිය හැකි අතර, ඒවා සම්බන්ධ බව අඟවන්නේ නැත. උදාහරණයක් ලෙස, m: m සම්බන්ධතා පන්ති වලදී ඉතා සුළු වන නමුත් තෙවන සංගම් වගුවක් නොමැතිව වගු දෙකක් අතර තිබිය නොහැක.

— ඇඩම් රොබින්සන්

1

මෙය නම් කිරීමේ උපාය මාර්ගයකට සම්බන්ධ වන්නේ කෙසේ ද, මම නොදනිමි. මගේ ප්‍රතිසමය (පැහැදිලිවම?) විෂය පථයට පමණක් සීමා වී ඇත.

— ocodo

2

මට කණගාටුයි මගේ ඇඟවුම් කළ අර්ථය එතරම් පැහැදිලි නැත, මම පැවසිය යුතුව තිබුණේ “ මේ අර්ථයෙන් ඒවා පන්තිවලට සමානය” යනුවෙනි. කෙසේ හෝ වේවා, මම මේ ගැන ඕනෑවට වඩා නොසැලකිලිමත් වීම විශේෂයෙන් .ලදායී යැයි මම නොසිතමි. නම් කිරීම සම්බන්ධයෙන් ගත් කල, වගු සහ පන්ති සැලකිය යුතු සමානකම් ප්‍රමාණයක් බෙදා ගනී. කුල්-ඩි-සැක් තුළ වර්ධනය වන හොඳම භාවිතයන් සංශෝධනය සඳහා සාධාරණ ක්‍රීඩාවකි, නැතහොත් අවම වශයෙන් සාකච්ඡාවට විවෘතය. මෙය effectively ලදායී ලෙස විදහා දක්වන මෙම ප්‍රශ්නෝත්තර තුළ ඕනෑ තරම් තිබේ, එකතු කිරීමට මට වෙනත් කිසිවක් නොමැත.

— ocodo

17

මේසය මත ස්වාභාවික සම්බන්ධතාවයක් පැවැත්වීම දුෂ්කර (හා ව්‍යාකූල) කරයි, එබැවින් ඔව්, එය නරක නම් ඉතා නරක නොවේ.

ස්වාභාවික බැඳීම යනු SQL ලෝර් (එනම් සම්බන්ධතා වීජ ගණිතය) හි පුරාණ කෞතුක වස්තුවකි, ඔබ මේවායින් එකක් දැක ඇති: a සමහර විට දත්ත සමුදා පොතක. මා අදහස් කළේ නට්රූල් එක්වීම නව විකාර SQL අදහසක් නොවේ, එය ක්‍රියාත්මක කිරීම සඳහා ඩීබීඑම්එස් හි සදහටම ගත වන බවක් පෙනෙන්නට තිබුණද, එබැවින් එය ක්‍රියාත්මක කිරීම සඳහා ඔබට නව විකාර අදහසක් නොවේ, ඔබ නොසලකා හැරීම පවා අසාධාරණ විය හැකිය වර්තමානයේ එහි පැවැත්ම.

හොඳයි, ඔබ ඔබේ සියලුම ප්‍රාථමික යතුරු හැඳුනුම්පත නම් කළහොත්, ස්වාභාවික සම්බන්ධතාවයේ පහසුව සහ සරල බව ඔබට අහිමි වේ. select * from dudes natural join carsලිවීම සඳහා අවශ්ය වනු ඇත select * from dudes inner join cars where cars.dudeid = dudes.idහෝ select * from dudes inner join cars where dudes.carid = cars.id. ඔබට ස්වභාවික සම්බන්ධතාවයක් කිරීමට හැකි නම්, සම්බන්ධතාවය ඇත්ත වශයෙන්ම කුමක්ද යන්න නොසලකා හැරිය යුතුය, එය, නියමයි.

— පීටර් ටර්නර්
source

ඔබ ගබඩා කළ ක්‍රියා පටිපාටියක් ලියන්නේ නැත්නම්, යෙදුම් සංවර්ධකයෙකු ලෙස අවසන් වරට ඔබ සම්පුර්ණයෙන්ම සංයුති කරන ලද SQL තේරීම් කාරකයක් ලියා ඇත්තේ කවදාද? නවීන භාෂා සියල්ලටම මෙම සම්බන්ධතාවය ඔබ වෙනුවෙන් කළමනාකරණය කරන යම් ආකාරයක ORM අංගයක් ඇතුළත් වේ. පිරිසිදු අත්පොත SQL ලිවීමට වඩා තීරුවේ නම වඩා වැදගත් ය.

— බිල් ලීපර්

4

Il මම සෑම විටම කරන්නේ, බොහෝ විට, බොහෝ විට, බොහෝ විට, ඔබ සංවර්ධනය කරන භාෂාවට වඩා ඔබේ කේත පදනම මත රඳා පවතී. රෝග විනිශ්චය සඳහා, ඔබට හොඳ සහ ගැඹුරු සම්බන්ධතා කිහිපයක් කිරීමට අවශ්‍ය නම්, එම ස්වාභාවික බැඳීම් එකට එකතු කර ක්ෂේත්‍ර හැඳුනුම්පත් බැලීම සම්පූර්ණයෙන්ම වළක්වා ගත හැකිය. ශාන්ත ජෙරොම් ප්‍රසිද්ධියේ පැවසූ පරිදි, “SQL නොදැන සිටීම යනු දත්ත සමුදායන් නොදැන සිටීමයි”.

— පීටර් ටර්නර්

ස්වාභාවික බැඳීම් විශ්වීය සහය නොදක්වන කාරණය හැරුණු විට, IMO, ස්වාභාවික බැඳීම් කියවීමට අපහසුය. සම්බන්ධතාවයේ තීරු දෙකක් තිබේද? පැහැදිළිව සිටීම හා ස්වාභාවික බැඳීම් වළක්වා ගැනීම වඩා හොඳය.

— තෝමස්

1

H තෝමස්, මම ස්වාභාවික සම්බන්ධතා කේතයට ඇතුළත් නොකරමි, නමුත් රෝග නිර්ණය සඳහා, දත්ත සමුදාය ආකෘතිගත කර ඇති විට ඒවා සැබවින්ම ක්‍රියාත්මක වන පරිදි ඒවා ඉතා ප්‍රයෝජනවත් බව මට පෙනී ගියේය.

— පීටර් ටර්නර්

16

සෑම මේසයකම "හැඳුනුම්පත" ඇලවීම හොඳම අදහස නොවන තත්වයක් තිබේ :. USING මූල පදය, එයට සහය නම්. අපි එය බොහෝ විට MySQL හි භාවිතා කරමු.

උදාහරණයක් ලෙස, ඔබ සතුව fooTableතීරුව fooTableIdසහ barTableවිදේශීය යතුර තිබේ නම් fooTableId, එවිට ඔබේ විමසීම් මෙසේ සාදා ගත හැකිය:

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

එය යතුරු ලියනය සුරකිනවා පමණක් නොව, විකල්පයට සාපේක්ෂව වඩා කියවිය හැකි ය:

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)

— ඉස්කාටා
source

මෙය මට වඩාත්ම කැපී පෙනෙන පිළිතුරයි. මෙම USINGමූල පදය postgres / mysql / sqlite දත්ත සමුදාය විසින් ආධාර කරනු ලබයි, භාවිතා කිරීම සඳහා හේතුවක් ලෙස අනෙක් පිළිතුරු ලැයිස්තුව සමහර අර්ථය ඇති අඩු ටයිප් id, හා අවසානයේ මගේ ආත්මීය මතය වඩාත් හොඳින් කියවිය හැකි වේ.

— මයිකල් බාටන්

11

ඔබේ ගුරුවරයාගෙන් පමණක් විමසන්නේ නැත්තේ ඇයි?

මේ ගැන සිතා බලන්න, ඔබගේ සියලු වගු PK තීරු නම් කළ IDවිට එය විදේශීය යතුරු ලෙස භාවිතා කිරීම බියකරු සිහිනයක් බවට පත් කරයි.

තීරු නම් අර්ථාන්විතව වැදගත් විය යුතුය. IDයනු සාමාන්‍ය දෙයකි.

— user7519
source

8

කුමක් සඳහා ද සාමාන්‍යයි? මේසයක හැඳුනුම්පත?

— ජිම්

3

කුමන වගුවේ ජිම්? idතනිවම කිසිවක් අදහස් නොකෙරේ, විශේෂයෙන් වෙනත් වගුවකට විදේශීය යතුරක සන්දර්භය තුළ. මෙයට කිසිදු සම්බන්ධයක් නැති classesඅතර හොඳ මූලික මූලික සම්බන්ධතා දත්ත සමුදා සැලසුමක් සමඟ කළ යුතු සියල්ල.

10

තරමක් මාරාන්තික වීමට නම්, එය අයත් මේසය. ක්ෂේත්‍රයක් table.idවෙත යොමු කිරීම සඳහා සම්පූර්ණයෙන්ම පිළිගත හැකි ක්‍රමයකි id. ක්ෂේත්‍ර නාමය වගු නාමය සමඟ උපසර්ගය අතිරික්ත වේ.

— ocodo

2

L ස්ලොමොජ් එය තීරුවේ නම ඇතුළත් කරනවාට වඩා ටයිප් කිරීමක් නොවන අතර රාක්ෂයා එක්වන විට තනි හෝ ද්විත්ව අකුරු කෙටියෙන් වගු නාම අන්වර්ථ කරන විට වඩාත් පැහැදිලි වේ.

6

ඔබ සඳහන් කරන්නේ කුමන බියකරු සිහිනය ගැනද? සේවකයින්ගේ කළමනාකරු නියෝජනය කරන තීරුවක් සහිත ස්වයං යොමු කිරීමේ ව්‍යුහයක් ඔබ සතුව ඇතැයි සිතමු. ඔබ විදේශීය යතුර ලෙස හඳුන්වන්නේ කුමක්ද? ඔබට එය සේවක අයිඩ් ලෙස හැඳින්විය නොහැක. FK හි නම PK හා සැසඳිය යුතු නැත. එය අඩංගු වන ආයතනයට එය නියෝජනය කරන දේ සඳහා එය නම් කළ යුතුය.

— තෝමස්

7

පහත සඳහන් හේතු නිසා හැඳුනුම්පත නරක ය:

ඔබ වාර්තාකරණ විමසීම් රාශියක් කරන්නේ නම්, ඔබට ඒ දෙකම දැකීමට අවශ්‍ය නම් සෑම විටම තීරු අන්වර්ථ කළ යුතුය. එබැවින් ආරම්භ කිරීම සඳහා ඔබට එය නිසි ලෙස නම් කළ හැකි කාලය නාස්තියක් බවට පත්වේ. අනවශ්‍ය වැඩ කිරීමේ අමතර බරක් නොමැතිව මෙම සංකීර්ණ විමසුම් ප්‍රමාණවත් නොවේ (මම පේළි සිය ගණනක් දිග විය හැකි විමසුම් ලියමි).

එය කේත දෝෂ ඇති කිරීමට යටත් වේ. ඔබ ස්වාභාවික බැඳීම භාවිතා කිරීමට ඉඩ දෙන දත්ත සමුදායක් භාවිතා කරන්නේ නම් (ඔබ එය කවදා හෝ භාවිතා කළ යුතු යැයි මම නොසිතමි, නමුත් විශේෂාංග ඇති විට කවුරුහරි ඒවා භාවිතා කරනු ඇත), ඔබ එය භාවිතා කරන සංවර්ධකයෙකු ලබා ගන්නේ නම් ඔබ වැරදි දෙයට සම්බන්ධ වනු ඇත.

ඔබ සංකීර්ණ විමසුමක් නිර්මාණය කිරීම සඳහා බැඳීම් පිටපත් කරන්නේ නම්, අන්වර්ථය ඔබට අවශ්‍ය පරිදි වෙනස් කර වැරදි සම්බන්ධතාවයක් ලබා ගැනීම අමතක කිරීම පහසුය. සෑම හැඳුනුම්පතක්ම එහි ඇති වගුවට නම් කර ඇත්නම්, එවිට ඔබට සාමාන්‍යයෙන් සින්ටැක්ස් දෝෂයක් ලැබෙනු ඇත. පීපීකේ නම සහ එෆ්කේ නම ගැලපෙන්නේ නම් එක්වන ඉනා සංකීර්ණ විමසුම වැරදියි නම් හඳුනා ගැනීම පහසුය.

— revs HLGEM
source

+1: මේවා මගේ මතය අනුව බලවත් හේතු වන අතර විරුද්ධ වන අනෙක් පිළිතුරු IDමට කිසිසේත් ඒත්තු ගැන්වෙන්නේ නැත.

— phoog

Re: "ඔබ පිටපත් කරන්නේ නම් සංකීර්ණ විමසුමක් නිර්මාණය කරයි" - එබැවින් ඔබේ ගැටළුව පිටපත් කර අලවන්න. පිටපත් කිරීම හා ඇලවීම නවත්වන්න, car.id නම් කිරීම කොතරම් පහසුදැයි ඔබට පෙනෙනු ඇත. FK සම්බන්ධ වීම සඳහා car.mfg = mfg.id, car.color = color.id, car.model = model.id - ඉතා සරල වන අතර ඔබ LINQ හි ලියන දේට ගැලපේ.

— alpav

බැඳීම් 30 ක් සමඟ යමක් ලිවීමට උත්සාහ කරන්න, එය ප්‍රති-රටාවක් වන්නේ මන්දැයි ඔබට පෙනෙනු ඇත.

— HLGEM

අන්වර්ථකරණය පළමු හා ප්‍රධානතම හේතුවයි - විශාල සංකීර්ණ වාර්තා කරන විට එය එවැනි හිසරදයකි. ස්වාභාවික බැඳීම් මිහිරි ප්‍රසාද දීමනාවක් පමණි. වෙනත් පිළිතුරු මෙම කරුණු නොසලකා හරින ආකාරය පුදුම සහගතය. මම හිතන්නේ උදාහරණ කිහිපයක් එකතු කිරීමෙන් කාරණය වඩාත් පැහැදිලි වන අතර මෙම පිළිතුර තිබිය යුතු තැනට ඉහළට පනින්න.

— ලූලු

5

වගුවක ඇති ප්‍රාථමික යතුර සඳහා තීරු නාමය ලෙස "හැඳුනුම්පත" භාවිතා නොකිරීමට වඩාත්ම වැදගත් හේතුව ලෙස මා සලකන දෙයට ප්‍රවේශ වන පිළිතුරු කිහිපයක් ඇත: එනම් අනුකූලතාව සහ අඩු අපැහැදිලි බව.

කෙසේ වෙතත්, මට ප්‍රධාන වාසිය වන්නේ නඩත්තු ක්‍රමලේඛකයා, විශේෂයෙන් මුල් සංවර්ධනය සමඟ සම්බන්ධ නොවූ අයෙකි. පුද්ගල වගුවේ ඇති හැඳුනුම්පත සඳහා ඔබ "PersonID" යන නම භාවිතා කර එම නම විදේශීය යතුරක් ලෙස නිරන්තරයෙන් භාවිතා කළේ නම්, එම "PersonID" යන්න අනුමාන නොකොට PersonID සතුව ඇති වගු මොනවාදැයි සොයා ගැනීමට ක්‍රමයට එරෙහිව විමසුමක් ලිවීම සුළුපටු ය. එය විදේශීය යතුරක් වන විට භාවිතා කරන නමයි. මතක තබා ගන්න, හරි හෝ වැරදි, විදේශීය ප්‍රධාන සම්බන්ධතා සෑම ව්‍යාපෘතියකම සෑම විටම ක්‍රියාත්මක නොවේ.

එක් වගුවකට එකම වගුවකට විදේශීය යතුරු දෙකක් තිබිය යුතු දාර නඩුවක් ඇත, නමුත් එවැනි අවස්ථාවලදී මම මුල් යතුරු නාමය තීරුවේ උපසර්ග නාමය ලෙස තබමි, එබැවින් ආදේශක කාඩ් ගැලපීමක් වන% PersonID පහසුවෙන් සොයාගත හැකිය එම අවස්ථා ද වේ.

ඔව්, මෙයින් බොහෝමයක් ඉටු කළ හැක්කේ "හැඳුනුම්පත" සහ සෑම විටම එය "tableNameID" ලෙස භාවිතා කිරීමට දැන සිටීමෙනි, නමුත් ඒ සඳහා පුහුණුවීම් පවතින බව දැන ගැනීම සහ මුල් සංවර්ධකයින් මත පදනම්ව අනුගමනය කළ යුතුය. ප්‍රත්‍යක්ෂ සම්මත පුහුණුව.

දිගු තීරු නම් ලිවීමට අමතර යතුරු පහරවල් කිහිපයක් අවශ්‍ය බව සමහර අය පෙන්වා දී ඇති නමුත්, කේතය ලිවීම වැඩසටහනේ ක්‍රියාකාරී ජීවිතයේ සුළු කොටසක් පමණක් බව මම ප්‍රකාශ කරමි. සංවර්ධක යතුරු එබීම සුරැකීම ඉලක්කය නම්, අදහස් කිසි විටෙකත් ලිවිය යුතු නොවේ.

වගු සිය ගණනක් සහිත විශාල ව්‍යාපෘති නඩත්තු කිරීමට වසර ගණනාවක් ගත කර ඇති අයෙකු ලෙස, වගු හරහා යතුරක් සඳහා ස්ථාවර නම් වලට මම තදින්ම කැමැත්තෙමි.

— මලාකි
source

Companiesවගුවකට මේසයකට විදේශීය යතුරු 2 ක් ඇතැයි සිතමු Persons. එක් අයෙකු සමාගමේ සභාපති නියෝජනය කරයි; අනෙක සමාගමේ භාණ්ඩාගාරික නියෝජනය කරයි. ඔබ ඇත්තටම තීරු කතා කරනවාද PersonID1හා PersonID2? එය වඩා විස්තරාත්මක ඔවුන් අමතන්න වනු ඇත PresidentIDහා TreasurerID. මට කියවීමට inner join Person AS Presidents ON Company.PresidentID = Presidents.IDවඩා පහසු බව පෙනේinner join Person AS Person1 ON Company.PersonID1 = Person1.PersonID

— phoog

1

අංක ඔබේ ආදර්ශය මම බොහෝ විට සමන්විත වනු ඇත CompanyOfficerහෝ CompanyPersonඅතර සමග බොහෝ-බහු සම්බන්ධතාව ඉඩ සලසා දෙයි මේසය Companyහා Personසම්බන්ධය ස්වභාවය ගැන අතිරේක තොරතුරු සමඟ. මම තුළ එය ක්රියාත්මක කිරීමට නම් Companyමේසය, මම තීරුව නම් භාවිතා කරන PresidentPersonIDහා TreasurerPersonIDඅතිරේක descriptor එකතු වන අතර නම * PersonID කොටසක් ආරක්ෂා කිරීමට. inner join Person as Presidents on Company.PresidentPersonID = Presidents.PersonID

— මලාකී

5

මූලික යතුරු ක්ෂේත්‍රය ලෙස හැඳුනුම්පත භාවිතා කිරීමේ පුරුද්ද සෑම වගුවකටම හැඳුනුම්පත එකතු වන භාවිතයට මඟ පාදයි. බොහෝ වගු වල දැනටමත් අද්විතීය තොරතුරු ඇත, එය වාර්තාවක් අද්විතීය ලෙස හඳුනා ගනී. එය සෑම යතුරකටම එකතු කරන හැඳුනුම් ක්ෂේත්‍රයක් නොව ප්‍රාථමික යතුරක් ලෙස භාවිතා කරන්න. එය සම්බන්ධතා දත්ත සමුදායන්ගේ පදනම් වලින් එකකි.

හැඳුනුම්පත භාවිතා කිරීම නරක පුරුද්දක් වන්නේ එබැවිනි: හැඳුනුම්පත බොහෝ විට ස්වයංක්‍රීය ස්වයංක්‍රීය තොරතුරු නොවේ.

පහත වගු සලකා බලන්න:

PK id | Countryid   | Countryname
    1 |         840 | United States
    2 |         528 | the Netherlands

මෙම වගුවේ ඇති වැරැද්ද නම්, එය පරිශීලකයාට තවත් පේළියක් එක් කිරීමට ඉඩ සලසයි: එක්සත් ජනපදය, රට කේත 840 සමඟ. එය සම්බන්ධතා අඛණ්ඩතාව බිඳ දැමීය. ඔබට තනි තීරුවල සුවිශේෂත්වය බලාත්මක කළ හැකිය, නැතහොත් ඔබට දැනටමත් ලබා ගත හැකි ප්‍රාථමික යතුරක් භාවිතා කළ හැකිය:

PK Countryid   | Countryname
           840 | United States
           528 | the Netherlands

මේ ආකාරයට ඔබ දැනටමත් ඇති තොරතුරු ප්‍රාථමික යතුරක් ලෙස භාවිතා කරයි, එය සම්බන්ධතා දත්ත සමුදායේ හදවතේ ඇත.

— පීටර් බී
source

1

ඔබට විවිධ පද්ධති අතර දත්ත සමුදායන් සංක්‍රමණය කිරීමට සිදු වූ විට හෝ දත්ත සමුදායන් එකට ඒකාබද්ධ කිරීමේ සතුට ඇති විට මිනිසුන් සෑම වගුවකටම පොදු යතුරු තීරුවක් එක් කරන්නේ මන්දැයි ඔබට වැටහෙනු ඇත.

— සයිෆර්

1

මෙය ඉඳහිට සිදු වේ, නමුත් මගේ අත්දැකීම් අනුව ලස්සන අද්විතීය වෙනස් කළ නොහැකි යතුරක් තිබීම සාමාන්‍ය දෙයකි. නමුත් ඔබේ උදාහරණයේ දී පවා රටවල් හඳුනා ගැනීම සඳහා ඔබට අර්ථ විරහිත අද්විතීය අංකයක් ඇත, අයිඑස්ඕ විසින් වෙන් කර ඇත්තේ ඔබේ දත්ත ගබඩාවෙන් නොවේ.

— CodesInChaos

දැන් රටේ නම වෙනස් වූ විට, එය නිවැරදි කිරීම සඳහා ඔබේ මුළු දත්ත ගබඩාව පුරාම එය යාවත්කාලීන කළ යුතුය. ඔබ හුදෙක් අන්වාදේශ යතුරක් භාවිතා කර ඇත්නම් (වැනි ... "id" වැනි), යාවත්කාලීන කිරීම සුළුපටු නොවේ. ස්වාභාවික යතුරු විශිෂ්ටයි - ඒවා සම්පූර්ණයෙන්ම වෙනස් නොවන විට සහ කිසි විටෙකත් වෙනස් නොවේ. මෙය සත්‍යයක් වන අවස්ථා ඉතා අල්පය.

— ජෙරාට්

Er ජෙරාට්: රටක නමක් වෙනස් වුවහොත්, ISO 3166-1 සංඛ්‍යා කේතය එලෙසම පවතී, වෙනස් වන්නේ ISO 3166-1 ඇල්ෆා -2 සහ ඇල්ෆා -3 කේත පමණි. උදාහරණයක් ලෙස බුරුමය / මියන්මාරය සමඟ මෙය සිදුවිය. ඒ හා සමානව, යම් රටක් තම භූමිය වෙනස් කළත් එහි නම තබා ගන්නේ නම්, අයිඑස්ඕ 3166-1 සංඛ්‍යාත්මක කේතය වෙනස් වේ, නමුත් අයිඑස්ඕ 3166-1 ඇල්ෆා -2 සහ ඇල්ෆා -3 කේත පවතී. මෙය සිදු වූයේ දකුණු සුඩානය සුඩානයෙන් ද එරිත්‍රියාව ඉතියෝපියාවෙන් ද වෙන් වූ විට ය. නැගෙනහිර සහ බටහිර ජර්මනිය නැවත එක් වූ විට, ඔවුන් බටහිර ජර්මනියේ ඇල්ෆා -2 සහ ඇල්ෆා -3 කේත තබා ගත් නමුත් නව සංඛ්‍යා කේතයක් ලැබුණි. රටවල් මුළුමනින්ම විසුරුවා හරින විට හෝ පරිණාමනය වන විට (සිතන්න…

— J Wrg W Mittag

… 90 දශකයේ බෝල්කන් යුද්ධවල ප්‍රති come ල), ඔවුන්ට නව සංඛ්‍යාත්මක හා ඇල්ෆා -2 සහ ඇල්ෆා -3 කේත දෙකම ලැබේ.

— ජෝග් ඩබ් මිට්ටාග්

4

සෑම වගුවකම මූලික තීරු නාමය ලෙස මම සෑම විටම 'අයිඩී' භාවිතා කරන්නේ එය මා භාවිතා කරන රාමු වල සම්මුතිය නිසාය (රූබි ඔන් රේල්ස්, කේක් පීඑච්පී), එබැවින් මට එය සෑම විටම ඉක්මවා යා යුතු නැත.

එය මට ශාස්ත්‍රීය හේතු පරාජය නොකරනු ඇත.

— Sfynx
source

2

එය නිසි ලෙස භාවිතා කරන්නේ නම් එය නරක පුරුද්දක් යැයි මම නොසිතමි. ඔබට කිසි විටෙකත් ස්පර්ශ නොකළ යුතු "හැඳුනුම්පත" නමින් ස්වයංක්‍රීයව වැඩෙන හැඳුනුම් ක්ෂේත්‍රයක් තිබීම සාමාන්‍ය දෙයක් වන අතර යෙදුම සඳහා මිත්‍රශීලී හඳුනාගැනීමක් භාවිතා කරන්න. වැනි කේත ලිවීම ටිකක් කරදරකාරී විය හැකියfrom tableA a inner join tableB b on a.id = b.a_id හැකි නමුත් එම කේතය ඉවතට ගත හැකිය.

පුද්ගලික මනාපයක් ලෙස මම හැඳුනුම්පතෙහි නම සමඟ උපසර්ගය යෙදීමට නැඹුරු වෙමි, නමුත් Idඑය සම්පූර්ණයෙන්ම දත්ත සමුදායෙන් හසුරුවන්නේ නම් භාවිතා කිරීම පිළිබඳ සැබෑ ගැටළුවක් මා දකින්නේ නැත .

— වේන් එම්
source

ප්‍රාථමික යතුරක් මඟින් ස්වයංක්‍රීය වර්ධක හැඳුනුම්පතක් මඟින් ඔබ කිසි විටෙකත් වගු දෙකකට සම්බන්ධ නොවනු ඇත. ඉහත නියැදිය a.id = b.table_a_id හි අභ්‍යන්තර සම්බන්ධතා වගුව b වගුවෙන් ලබා ගත හැකිය.

— බිල් ලීපර්

ඔව්, ඒකයි මම අදහස් කළේ. දිවා ආහාර වේල පාහේ හා ශක්තිය අවශ්ය වේ.

— වේන් මොලිනා

2

හැඳුනුම්පත ප්‍රමාණවත් තරම් පොදු ය, එය කිසිවෙකු ව්‍යාකූල කරනු ඇතැයි මම නොසිතමි. ඔබට සෑම විටම මේසය දැන ගැනීමට අවශ්‍ය වනු ඇත. වගු / අන්වර්ථයක් ඇතුළත් නොකර ක්ෂේත්‍ර නාම නිෂ්පාදන කේතයට ඇතුළත් කිරීම නරක පුරුද්දකි. තාවකාලික විමසුම් ඉක්මනින් ටයිප් කිරීමට හැකිවීම ගැන ඔබ ඕනෑවට වඩා සැලකිලිමත් වන්නේ නම්, ඔබ තනිවම සිටී.

හැඳුනුම්පත වෙන් කර ඇති වචනයක් වන කිසිවෙකු වර්ග අඩි දත්ත ගබඩාවක් සංවර්ධනය නොකරනු ඇතැයි සිතමු.

CREATE TABLE CAR (ID);

ක්ෂේත්‍රයේ නම, ප්‍රාථමික යතුර සහ ස්වයංක්‍රීය වර්ධක 1 න් 1 කින් ආරම්භ කර එක ලස්සන කුඩා අකුරු 2 කින් සමන්විත වේ. ඔහ්, මම එය CARS ලෙස හඳුන්වනු ඇත, නමුත් අපි යතුරු පහරවල් වලින් ඉතිරි කර ගැනීමට යන්නේ නම් සහ CAR නම් වගුවකට ඇත්තේ එකක් පමණක් යැයි සිතන්නේ කවුද?

— ජෙෆෝ
source

1

විධිමත් සම්බන්ධතා න්‍යාය පිළිබඳ දැනුම වැදගත් වන්නේ මන්දැයි මෙයින් පෙන්නුම් කෙරේ, වගුවේ නම තනි පේළියක් යනු කුමක්ද යන්න නිරූපණය කරයි . වගුව Carනිරූපණය කරන්නේ Tableඑක් එක් Rowතනි නියෝජනය කරන ස්ථානයකි Car. කරන මා ෙවත පවරා ඇති Carsවිධිමත් සමගද න්යාය මූලික විදුහල්පතිවරුන් අවබෝධය සම්පූර්ණ නොමැතිකම අර්ථ විචාර හා දර්ශන වෙනස් වෙනවා. රේල්ස් යනු භයානක වීමට තරම් දැන සිටි කෙනෙකුගේ ප්‍රධාන උදාහරණයකි .

2

මෙම ප්රශ්නය නැවත නැවතත් පහර දී ඇත, නමුත් මම ද මගේ මතය එකතු කරනු ඇතැයි සිතුවෙමි.

මම හැඳුනුම්පත භාවිතා කරන්නේ එය එක් එක් වගුව සඳහා හඳුනාගැනීමේ යන්ත්‍රයයි, එබැවින් මම මේසයකට සම්බන්ධ වූ විට මට ප්‍රාථමික යතුර අවශ්‍ය වූ විට මම ස්වයංක්‍රීයව ප්‍රාථමික යතුරට සම්බන්ධ වෙමි.
හැඳුනුම් ක්ෂේත්‍රය ස්වයංක්‍රීය අත්සන් කිරීමකි, අත්සන් නොකෙරේ (මෙයින් අදහස් කරන්නේ මා කිසි විටෙකත් එහි වටිනාකම සැකසිය යුතු නැති අතර එය negative ණ විය නොහැකි බවයි)
විදේශීය යතුරු සඳහා, මම මේස නාමය භාවිතා කරමි (නැවතත් විලාසිතාවේ කාරණයක්), නමුත් මා සම්බන්ධ වන මූලික යතුර වන්නේ වගුවේ හැඳුනුම් ක්ෂේත්‍රයයි, එබැවින් අනුකූලතාව යනු මට සෑම විටම පහසුවෙන් විමසීම් පරීක්ෂා කළ හැකිය
id ද කෙටි හා මිහිරි ය
අතිරේක සම්මුතිය - සියලුම වගු සහ තීරු නම් සඳහා කුඩා අකුරු භාවිතා කරන්න, එබැවින් නඩුව හේතුවෙන් ගැටළු සොයාගත නොහැක

— ස්ටීවන් සෙන්කොමාගෝ මුසෝක්
source

1

සලකා බැලිය යුතු තවත් දෙයක් නම්, ප්‍රාථමික යතුරු නාමය විදේශීය යතුරු නාමයට වඩා වෙනස් නම්, සමහර තෙවන පාර්ශවීය මෙවලම් භාවිතා කළ නොහැක.

උදාහරණයක් ලෙස, ඔබේ යෝජනා ක්‍රමය විසියෝ වැනි මෙවලමකට පැටවීමට නොහැකි වන අතර එය නිවැරදි ඊආර්ඩී නිපදවයි.

— Martijn Pieters
source

එය තෙවන පාර්ශවීය මෙවලමෙහි වරදක් වුවද. තීරු නම් කිරීමේ සම්මුතීන් සැබෑ විදේශීය යතුරු සඳහා ආදේශකයක් නොවේ, මෙවලම ස්වයං විග්‍රහ කළ යුතුය.

— ජෙරාත්

1

මෙහි සිටින පුද්ගලයින් සෑම අංශයක්ම ආවරණය වන බව මට පෙනේ, නමුත් මට අවශ්‍ය වන්නේ “හැඳුනුම්පත” නොවන අතර එය “අනන්‍යතාවය” ලෙස කියවිය යුතු නොවේ. එය “දර්ශකයක්” වන අතර නිසැකවම එය පේළියේ අනන්‍යතාවය සඳහන් නොකරයි. (මම මෙහි වැරදි වචන භාවිතා කර ඇති අතර, කරුණාකර මා නිවැරදි කළේ නම්)

මිනිසුන් වගු දත්ත කියවන ආකාරය සහ ඔවුන්ගේ කේතය ලියන ආකාරය වැඩි වශයෙන් හෝ අඩුය. මා පෞද්ගලිකව හා බොහෝ විට මෙය වඩාත් නිතර දකින වඩාත් ජනප්‍රියම ක්‍රමය වන්නේ කේත රචකයන් විසින් සම්පුර්ණ සඳහනක් ලිවීමයි table.id, ඔවුන්ට වෘත්තීය සමිති හෝ / හා සම්බන්ධ වීමට අවශ්‍ය නොවුවද. උදාහරණයක් වශයෙන්:

SELECT cars.color, cars.model FROM cars WHERE cars.id = <some_var>

එමඟින් ඔබට එය ඉංග්‍රීසි භාෂාවට පරිවර්තනය කළ හැකිය "අංකනය කර ඇති එම මෝටර් රථයේ වර්ණය හා ආකෘතිය මට දෙන්න." "අංකයක් ලෙස හඳුනාගෙන ඇති එම මෝටර් රථයේ වර්ණය හා ආකෘතිය මට දෙන්න" ලෙස නොවේ. හැඳුනුම්පත කිසිදු ආකාරයකින් මෝටර් රථය නියෝජනය නොකරයි, එය මෝටර් රථයේ දර්ශකය පමණි, ඔබට අවශ්‍ය නම් අනුක්‍රමික අංකය පමණි. ඔබට අරාවකින් තුන්වන අංගය ගැනීමට අවශ්‍ය වූ විට මෙන්.

එබැවින් මට එකතු කිරීමට අවශ්‍ය දේ සාරාංශ කිරීම යනු එය මනාපයක් පමණක් වන අතර විස්තර කර ඇති SQL කියවීමේ ක්‍රමය වඩාත් ජනප්‍රියය.

කෙසේ වෙතත්, මෙය භාවිතා නොකරන සමහර අවස්ථා තිබේ, (වඩා දුර්ලභ උදාහරණයක්) හැඳුනුම්පත යනු සැබවින්ම විස්තර කරන නූලක් වන විට. උදාහරණයක් ලෙස id = "RedFordMustang1970"හෝ ඒ හා සමාන දෙයක්. අවම වශයෙන් අදහස ලබා ගැනීම සඳහා මට මෙය පැහැදිලි කළ හැකි යැයි මම විශ්වාස කරමි.

— සර්ජි ටෙල්ෂෙව්ස්කි
source