සෑම විටම ස්වයංක්‍රීයව සම්පුර්ණ කරන ලද ප්‍රාථමික යතුරක් තිබීම හොඳ පුරුද්දක් ද?

මගේ දත්ත සමුදායන් තුළ, මම idසාදන සෑම වගුවකටම නම සහිත ස්වයංක්‍රීයව වැඩි කරන පූර්ණ සංඛ්‍යා ප්‍රාථමික යතුරක් ලබා ගැනීමේ පුරුද්දට මම නැඹුරු වෙමි .

මෙය නරක අදහසක් ලෙස සලකන්නේද? එය මේ ආකාරයෙන් කිරීමට යම් අඩුපාඩු තිබේද? සමහර වෙලාවට මට වැනි විවිධ දර්ශක වෙනවා id, profile_id, subscriptionsඑහිදී idඑම අනුපම අනන්යකාරකය වන අතර, profile_idවිදේශ සබැඳි idඅ Profileමේසය, ආදිය

එසේත් නැතිනම් ඔබට එවැනි ක්ෂේත්‍රයක් එක් කිරීමට අවශ්‍ය නොවන අවස්ථා තිබේද?

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

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

මම මීට පෙර සියලු පිළිතුරු සමඟ එකඟ නොවෙමි. සියලුම වගු වල ස්වයංක්‍රීය වර්ධක ක්ෂේත්‍රයක් එක් කිරීම නරක අදහසක් වීමට බොහෝ හේතු තිබේ.

ඔබට පැහැදිලි යතුරු නොමැති වගුවක් තිබේ නම්, ස්වයංක්‍රීය වර්ධක ක්ෂේත්‍රයක් හොඳ අදහසක් සේ පෙනේ. සියල්ලට පසු, ඔබට අවශ්‍ය නැත select * from blog where body = '[10000 character string]'. ඔයා කැමතියි select * from blog where id = 42. මෙම අවස්ථා බොහොමයකදී ඔබට සැබවින්ම අවශ්‍ය වන්නේ අද්විතීය හඳුනාගැනීමක් බව මම තර්ක කරමි; අනුක්‍රමික අද්විතීය හඳුනාගැනීමක් නොවේ. ඒ වෙනුවට විශ්වීය අද්විතීය හඳුනාගැනීමක් භාවිතා කිරීමට ඔබට අවශ්‍ය විය හැකිය.

අහඹු අද්විතීය හඳුනාගැනීම් ජනනය කිරීම සඳහා බොහෝ දත්ත සමුදායන්හි කාර්යයන් ඇත ( uuidmysql, postgres. newidMssql හි). විවිධ යන්ත්‍රවල, ඕනෑම වේලාවක, ඒවා අතර ජාල සම්බන්ධතාවයක් නොමැතිව, දත්ත සමුදායන් තුළට දත්ත ජනනය කිරීමට මේවා ඔබට ඉඩ සලසයි, සහ තවමත් ශුන්‍ය ගැටුම් සමඟ දත්ත ඒකාබද්ධ කරයි. මයික්‍රෝ සර්විසස් සමඟ බහු සේවාදායක සහ දත්ත මධ්‍යස්ථාන පවා පහසුවෙන් සැකසීමට මෙය ඔබට ඉඩ දෙයි.

ප්‍රහාරකයන්ට තමන්ට ප්‍රවේශ විය නොහැකි පිටු වෙත යූආර්එල් අනුමාන කිරීම ද මෙය වළක්වයි. එහි https://example.com/user/1263තිබේ නම් බොහෝ විට https://example.com/user/1262ද තිබේ. පරිශීලක පැතිකඩ පිටුවේ ආරක්ෂක සූරාකෑම ස්වයංක්‍රීය කිරීමට මෙය ඉඩ දෙයි.

Uuid තීරුවක් නිෂ් less ල හෝ හානිකර වන අවස්ථා ද තිබේ. ඔබට සමාජ ජාලයක් ඇති බව කියමු. ඒ නිසා එය usersමේසය සහ friendsමේසය. මිතුරන්ගේ වගුවේ පරිශීලක තීරු දෙකක් සහ ස්වයංක්‍රීය වර්ධක ක්ෂේත්‍රයක් අඩංගු වේ. ඔබට 3මිතුරන් වීමට අවශ්‍ය 5නිසා ඔබ 3,5දත්ත සමුදායට ඇතුළු කරන්න . දත්ත සමුදාය ස්වයංක්‍රීය වර්ධක හැඳුනුම්පතක් එක් කර ගබඩා 1,3,5කරයි. කෙසේ හෝ පරිශීලකයා 3නැවත "මිතුරා එක් කරන්න" බොත්තම ක්ලික් කරයි. ඔබ 3,5නැවත දත්ත සමුදායට ඇතුළු කරන්න , දත්ත සමුදාය ස්වයංක්‍රීයව වර්ධක හැඳුනුම්පතක් එක් කර ඇතුළු කරයි 2,3,5. නමුත් දැන් 3සහ 5දෙවරක් එකිනෙකා සමඟ මිතුරු වන්න! එය අවකාශය නාස්තියක් වන අතර, ඔබ ඒ ගැන සිතන්නේ නම්, ස්වයංක්‍රීය වර්ධක තීරුව ද එසේමය. ඔබ දැකීමට අවශ්‍ය සියල්ල aසහbමිතුරන් යනු එම අගයන් දෙක සමඟ පේළිය තෝරා ගැනීමයි. ඒවා එකට එක්ව අද්විතීය පේළි හඳුනාගැනීමක් වේ. (ඔබට බොහෝ විට තර්කනය ලිවීමට අවශ්‍ය වනු ඇති 3,5අතර 5,3ඒවා අනුපිටපත් කර තිබේ.)

Url-shortener එකක් තැනීමේදී මෙන් අනුක්‍රමික හැඳුනුම්පත් ප්‍රයෝජනවත් විය හැකි අවස්ථා තවමත් පවතී, නමුත් බොහෝ විට (සහ url shortener සමඟ වුවද) අහඹු ලෙස ජනනය කරන ලද අද්විතීය හැඳුනුම්පතක් යනු ඒ වෙනුවට ඔබට සැබවින්ම භාවිතා කිරීමට අවශ්‍ය දෙයයි.

TL; DR: එක් එක් පේළිය හඳුනා ගැනීමේ අද්විතීය ක්‍රමයක් ඔබට දැනටමත් නොමැති නම්, ස්වයංක්‍රීය වර්ධක වෙනුවට UUID භාවිතා කරන්න.

ස්වයංක්‍රීය යතුරු බොහෝ දුරට වාසි ඇත.

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

• ඔබට ව්‍යාපාර යතුරක් තිබේ නම්, ව්‍යාපාර නීති බලාත්මක කිරීම සඳහා එම තීරුවේ (න්) අද්විතීය දර්ශකයක් එක් කළ යුතුය.
• දත්ත සමුදායන් දෙකක් අතර දත්ත මාරු කිරීමේදී, විශේෂයෙන් දත්ත එකකට වඩා වැඩි ගණනක (එනම් ප්‍රධාන / විස්තර) ඇති විට, දත්ත සමුදායන් අතර අනුක්‍රමයන් සමමුහුර්ත නොවන බැවින් එය කෙළින්ම ඉදිරියට නොයනු ඇත, තවද ඔබට පළමුව සමානතා වගුවක් සෑදිය යුතුය. ව්‍යාපාර දත්ත යතුර ඉලක්ක දත්ත ගබඩාවේ ඇති හැඳුනුම්පත සමඟ අනුරූප වන මූල දත්ත ගබඩාවේ කුමන හැඳුනුම්පත දැන ගැනීමට ගැලපේ. හුදකලා වගු වලින් දත්ත මාරු කිරීමේදී එය ගැටළුවක් නොවිය යුතුය.
• බොහෝ ව්‍යවසායන් තුළ තාවකාලික, චිත්‍රක, ලක්ෂ්‍ය-ක්ලික්, ඇදගෙන යාම සහ වාර්තා කිරීමේ මෙවලම් ඇත. ස්වයංක්‍රීයව හැඳුනුම්පත් අර්ථ විරහිත බැවින්, මෙම වර්ගයේ පරිශීලකයින්ට "යෙදුමට" පිටතින් ඇති දත්ත පිළිබඳ අවබෝධයක් ලබා ගැනීම දුෂ්කර වනු ඇත.
• ඔබ ව්‍යාපාරික යතුර අහම්බෙන් වෙනස් කළහොත්, ඔබට එම පේළිය කිසි විටෙකත් යථා තත්වයට පත් නොවීමට ඉඩ තිබේ. එය වරක් බිට්කොයින් වේදිකාවේ දෝෂයක් ඇති කළේය .
• සමහර නිර්මාණකරුවන් වගු දෙකක් අතර සම්බන්ධක වගුවකට හැඳුනුම්පතක් එක් කරයි, PK හුදෙක් විදේශීය හැඳුනුම්පත් දෙකෙන් සමන්විත විය යුතුය. නිසැකවම සම්බන්ධ වීමේ වගුව වගු තුනක් හෝ වැඩි ගණනක් අතර තිබේ නම්, ස්වයංක්‍රීයව හැඳුනුම්පතක් අර්ථවත් කරයි, නමුත් ව්‍යාපාර නීති ක්‍රියාත්මක කිරීම සඳහා FKs සංයෝජනයට අදාළ වන විට ඔබට අද්විතීය යතුරක් එක් කළ යුතුය.

අන්වාදේශ යතුරු වල අවාසි පිළිබඳ විකිපීඩියා ලිපි කොටස මෙන්න .

ඊට පටහැනිව, නැත, ඔබට සැමවිටම සංඛ්‍යාත්මක ස්වයංක්‍රීය ඉන්ක් පීකේ අවශ්‍ය නොවේ.

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

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

ගනුදෙනුකරුට අර්ථවත් වටිනාකමක් ජනනය කිරීම සඳහා සමහර විට ඔබට AutoInc PK භාවිතා කළ හැකිය. උදා. ප්‍රතිපත්ති අංක. ආරම්භක අගය සංවේදී දෙයකට සැකසීම සහ ප්‍රමුඛ ශුන්‍යයන් පිළිබඳ ව්‍යාපාරික නීති රීති යෙදීම යනාදිය මෙය බොහෝ විට “ලෝක දෙකෙහිම හොඳම” ප්‍රවේශයකි.

ඔබට සාපේක්ෂව ස්ථිතික අගයන් කුඩා සංඛ්‍යාවක් ඇති විට, පද්ධති පරිශීලකයාට අර්ථවත් වන අගයන් භාවිතා කරන්න. ඔබට රක්ෂණ "ප්‍රතිපත්ති වර්ගය" සන්දර්භය තුළ ජීවිතය, මෝටර් රථය සහ නිවස නියෝජනය කරන L, C, H භාවිතා කළ හැකි විට 1,2,3 භාවිතා කරන්නේ ඇයි, හෝ VIN උදාහරණය වෙත ආපසු යාම, "TO" භාවිතා කරන්නේ කෙසේද? "ටොයොටා සඳහා? සියලුම ටොයාටා මෝටර් රථවල VIN එකක් ඇති අතර එය "TO" ලෙස ආරම්භ වන අතර එය පරිශීලකයින්ට මතක තබා ගත යුතු එක් අඩු දෙයක් වන අතර, ක්‍රමලේඛන සහ පරිශීලක දෝෂ හඳුන්වා දීමට ඔවුන්ට ඇති ඉඩකඩ අඩු කරයි. කළමනාකරණ වාර්තා වල සම්පූර්ණ විස්තරයක් සඳහා භාවිතා කළ හැකි අන්‍යාගමිකයෙකු විය හැකිය. ලිවීමට සහ සමහර විට ඉක්මනින් ජනනය කිරීමට.

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

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

සංස්කරණය කරන්න ඔබට ස්වයංක්‍රීය PK අවශ්‍ය නොවන තවත් තීරණාත්මක අවස්ථාවක් වන්නේ වෙනත් වගු දෙකක ඡේදනය නිරූපණය කරන වගු ය. කාර් ප්‍රතිසමයට අනුකූල වීම සඳහා, මෝටර් රථයක උපාංග 0..n ඇත, සෑම උපාංගයක්ම බොහෝ මෝටර් රථවල සොයාගත හැකිය. එබැවින් මෙය නිරූපණය කිරීම සඳහා ඔබ කාර් සහ උපාංග වලින් PKs අඩංගු වන කාර්_ඇක්සරි වගුවක් සාදයි.

ඔබට (සාමාන්‍යයෙන්) අවශ්‍ය නොවන දෙය මේසය මත ඇති ස්වයංක්‍රීය ඉන්ක් පීකේ ය - එය ප්‍රවේශ විය හැක්කේ මෝටර් රථය හරහා පමණි "මෙම මෝටර් රථයේ ඇති උපාංග මොනවාදැයි මට කියන්න" හෝ උපාංගයෙන් "මෙම උපාංග ඇති මෝටර් රථ මොනවාදැයි ඔවුන්ට කියන්න"

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

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

විශාල පද්ධති වල, හැඳුනුම්පත අනුකූලතා බූස්ටරයකි, එය ඕනෑම තැනක පාහේ භාවිතා කරන්න . මෙම සන්දර්භය තුළ, තනි ප්‍රාථමික යතුරු නිර්දේශ නොකරයි, ඒවා පහළම මාලයේ මිල අධිකය (ඇයි කියවන්න).

සෑම රීතියකටම ව්‍යතිරේකයක් ඇත, එබැවින් අපනයන / ආනයනය සඳහා භාවිතා කරන වේදිකා වගු සහ ඒ හා සමාන එක්-මාර්ග වගු හෝ තාවකාලික වගු මත ඔබට පූර්ණ සංඛ්‍යා ස්වයංක්‍රීය හැඳුනුම්පතක් අවශ්‍ය නොවනු ඇත. බෙදා හරින ලද පද්ධතිවල හැඳුනුම්පත් වෙනුවට GUID වලටද ඔබ කැමති වනු ඇත.

මෙහි ඇති බොහෝ පිළිතුරු වලින් පෙනී යන්නේ පවතින අද්විතීය යතුර ගත යුතු බවයි. හොඳයි, එහි අක්ෂර 150 ක් තිබුණත්? මම හිතන්නේ නැහැ.

දැන් මගේ ප්‍රධාන කරුණ:

ස්වයංක්‍රීය සංයුක්ත පූර්ණ හැඳුනුම්පතේ විරුද්ධවාදීන් වගු 20 ක් දක්වා කුඩා දත්ත සමුදායන් ගැන කතා කරන බව පෙනේ. එහිදී ඔවුන්ට එක් එක් මේසයට තනි ප්‍රවේශයක් ලබා ගත හැකිය.

නමුත් ඔබට 400+ වගු සහිත ඊආර්පී ඇති විට, ඕනෑම තැනක පූර්ණ සංඛ්‍යා ස්වයංක්‍රීය හැඳුනුම්පතක් තිබීම (ඉහත සඳහන් කළ අවස්ථා හැර) විශාල අර්ථයක් ඇත. වෙනත් සුවිශේෂී ක්‍ෂේත්‍රයන් අද්විතීයව තබාගෙන සිටියත් ඒවා මත රඳා නොසිටින්න.

• විශ්වීය කාලය ඉතිරි කිරීම, උත්සාහය ඉතිරි කිරීම, පහසුවෙන් මතක තබා ගත හැකි සමුළුවෙන් ඔබට ප්‍රතිලාභ ලැබේ.
• බොහෝ අවස්ථාවන්හිදී JOINයතුරු මොනවාදැයි පරීක්ෂා කිරීමකින් තොරව ඔබ වගු කරයි.
• ඔබේ පූර්ණ සංඛ්‍යා ස්වයංක්‍රීය තීරු තීරුව සමඟ වැඩ කරන විශ්වීය කේත චර්යාවන් ඔබට තිබිය හැකිය.
• දැනට පවතින වගු වල හැඳුනුම්පත් වෙත යොමු කිරීමෙන් ඔබට පෙර නොදුටු නව වගු හෝ පරිශීලක ප්ලගීන සමඟ ඔබේ පද්ධතිය දීර් extend කළ හැකිය. ඔවුන් මුල සිටම එහි සිට ඇත, ඒවා අතිරේකව එකතු කිරීමට කිසිදු පිරිවැයක් නොමැත.

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

ඕනෑවට වඩා මෝස්තර කිරීම හොඳ පුරුද්දක් නොවේ. එනම් - අවශ්‍ය නොවන විට සෑම විටම ස්වයංක්‍රීය වර්ධක int ප්‍රාථමික යතුරක් තිබීම හොඳ පුරුද්දක් නොවේ.

එකක් අවශ්‍ය නොවන උදාහරණයක් බලමු.

ඔබට ලිපි සඳහා වගුවක් ඇත - මෙයට ප්‍රාථමික ප්‍රාථමික යතුරක් ඇත id, සහ වර්චාර් තීරුවක් නම් කර titleඇත.

ඔබට ලිපි කාණ්ඩ වලින් පිරුණු වගුවක් ද ඇත - idint ප්‍රාථමික යතුර, varchar name.

ලිපි වගුවේ එක් පේළියක id5 ක් ඇති අතර title “බටර් සමග පාත්තයා පිසින ආකාරය” ඇත. ඔබේ කාණ්ඩ වගුවේ පහත දැක්වෙන පේළි සමඟ එම ලිපිය සම්බන්ධ කිරීමට ඔබට අවශ්‍යය: "කුකුළා" ( id : 20), "පාත්තයා" ( id : 12), "ඉවුම් පිහුම්" ( id : 2), "බටර්" (id: 9) .

දැන්, ඔබට වගු 2 ක් ඇත: ලිපි සහ කාණ්ඩ. ඔබ දෙදෙනා අතර සම්බන්ධතාවය ඇති කරන්නේ කෙසේද?

ඔබට තීරු 3 ක් සහිත වගුවක් තිබිය හැකිය: id (ප්‍රාථමික යතුර), article_id (විදේශීය යතුර), category_id (විදේශීය යතුර). නමුත් දැන් ඔබට එවැනි දෙයක් තිබේ:

| id | a_id | c_id |
| 1 | 5 | 20 |
| 2 | 5 | 12 |
| 3 | 5 | 2 |

වඩා හොඳ විසඳුමක් වන්නේ තීරු 2 කින් සමන්විත ප්‍රාථමික යතුරක් තිබීමයි.

| a_id | c_id |
| 5 | 20 |
| 5 | 12 |
| 5 | 2 |

මෙය කිරීමෙන් මෙය කළ හැකිය:

create table articles_categories (
  article_id bigint,
  category_id bigint,
  primary key (article_id, category_id)
) engine=InnoDB;

ස්වයංක්‍රීය වර්ධක සංඛ්‍යාවක් භාවිතා නොකිරීමට තවත් හේතුවක් වන්නේ ඔබ ඔබේ ප්‍රාථමික යතුර සඳහා UUID භාවිතා කරන්නේ නම්.

UUIDs යනු ඔවුන්ගේ අර්ථ දැක්වීම අනුව අද්විතීය වන අතර එමඟින් අද්විතීය නිඛිල භාවිතා කිරීම සිදු කරයි. පූර්ණ සංඛ්‍යා වලට වඩා ඔවුන්ට ඔවුන්ගේම අමතර ප්‍රතිලාභ (සහ අවාසි) ඇත. උදාහරණයක් ලෙස, UUID සමඟ, ඔබ සඳහන් කරන අද්විතීය නූල විශේෂිත දත්ත වාර්තාවකට යොමු කරන බව ඔබ දන්නවා; ඔබට කේන්ද්‍රීය දත්ත සමුදායන් 1 ක් නොමැති අවස්ථාවන්හිදී හෝ නොබැඳි ලෙස දත්ත වාර්තා නිර්මාණය කිරීමට යෙදුම් වලට හැකියාවක් ඇති අවස්ථාවලදී මෙය ප්‍රයෝජනවත් වේ (පසුව ඒවා පසු දිනකදී දත්ත සමුදායට උඩුගත කරන්න).

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

එසේත් නැතිනම් ඔබට එවැනි ක්ෂේත්‍රයක් එක් කිරීමට අවශ්‍ය නොවන අවස්ථා තිබේද?

ෂුවර්.

පළමුවෙන්ම, ස්වයංක්‍රීය සැකසුම් නොමැති දත්ත සමුදායන් ඇත (උදා: ඔරකල්, නිසැකවම අවට ඇති කුඩාම තරඟකරුවන්ගෙන් එකක් නොවේ). මෙය සෑම කෙනෙකුටම කැමති හෝ අවශ්‍ය නොවන බවට පළමු ඇඟවීම විය යුතුය.

වඩා වැදගත්, මෙම හැඳුනුම්පත ඇත්තටම දේ ගැන හිතන්න වේ - එය ඔබගේ දත්ත සඳහා ප්රාථමික යතුර වේ. ඔබට වෙනත් ප්‍රාථමික යතුරක් සහිත වගුවක් තිබේ නම්, ඔබට හැඳුනුම්පතක් අවශ්‍ය නොවන අතර එකක් නොතිබිය යුතුය. උදාහරණයක් ලෙස, වගුවක (EMPLOYEE_ID, TEAM_ID)(එක් එක් සේවකයාට සමගාමීව කණ්ඩායම් කිහිපයක සිටිය හැකි) එම හැඳුනුම්පත් දෙකෙන් සමන්විත පැහැදිලිව අර්ථ දක්වා ඇති ප්‍රාථමික යතුරක් ඇත. IDමෙම වගුවේ මූලික යතුරක් වන ස්වයංක්‍රීය තීරු තීරුවක් එක් කිරීම කිසිසේත්ම තේරුමක් නැත. දැන් ඔබ ප්‍රාථමික යතුරු 2 ක් වටා ගමන් කරමින් සිටින අතර, "ප්‍රාථමික යතුර" හි පළමු වචනය ඔබට සැබවින්ම තිබිය යුතු බවට ඉඟියක් ලබා දිය යුතුය.

“දීර්-කාලීන” දත්ත සඳහා නව වගු නිර්වචනය කිරීමේදී මම සාමාන්‍යයෙන් “අනන්‍යතා” තීරුවක් (ස්වයංක්‍රීයව වැඩි කරන පූර්ණ සංඛ්‍යාවක්) භාවිතා කරමි (වාර්තා එක් වරක් ඇතුල් කිරීමට බලාපොරොත්තු වන වාර්තා සහ ඒවා තරමක් තර්කානුකූලව මකාදැමීම අවසන් වුව ද දින නියමයක් නොමැතිව තබා ගන්න. ).

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

• වර්ධක හැඳුනුම්පත් විභව ප්‍රහාරකයෙකුට ඕනෑවට වඩා තොරතුරු වන විට. "මහජන මුහුණැති" දත්ත සේවාවන් සඳහා අනන්‍යතා තීරුවක් භාවිතා කිරීම ඔබව "ජර්මානු ටැංකි ගැටළුවට" ගොදුරු කරයි; රෙකෝඩ් හැඳුනුම්පත 10234 තිබේ නම්, එය වාර්තාගත 10233, 10232 යනාදිය අවම වශයෙන් වාර්තා 10001 ක් දක්වා පවතින බවට තර්ක කරයි, ඉන්පසු ඔබේ අනන්‍යතා තීරුව ආරම්භ වූයේ කොතැනින්දැයි සොයා ගැනීමට 1001, 101 සහ 1 වාර්තා පරීක්ෂා කිරීම පහසුය. ප්‍රධාන වශයෙන් අහඹු දත්ත වලින් සමන්විත V4 GUIDs මෙම වර්ධක හැසිරීම සැලසුම අනුව බිඳ දමයි, එවිට එක් GUID එකක් පවතින නිසා, GUID හි බයිට් එකක් වැඩි කිරීම හෝ අඩු කිරීම මගින් නිර්මාණය කරන ලද GUID එකක් අනිවාර්යයෙන්ම නොපවතින අතර, ප්‍රහාරකයාට සේවාවක් භාවිතා කිරීම දුෂ්කර කරයි. ඩම්ප් මෙවලමක් ලෙස තනි වාර්තා ලබා ගැනීම සඳහා. ප්‍රවේශය වඩා හොඳින් සීමා කළ හැකි වෙනත් ආරක්ෂක පියවරයන් ඇත, නමුත් මෙය උපකාරී වේ.
• M: M හරස් යොමු වගු වල. මෙය එක්තරා ආකාරයක ව්‍යායාමයක් නමුත් මම එය කලින් දැක ඇත්තෙමි. ඔබේ දත්ත ගබඩාවේ වගු දෙකක් අතර ඔබට බොහෝ සිට බොහෝ සම්බන්ධතාවයක් තිබේ නම්, යන්න විසඳුම යනු එක් එක් වගුවේ PK ගැන සඳහන් කරන විදේශීය යතුරු තීරු අඩංගු හරස් යොමු වගුවකි. මෙම වගුවේ PK සෑම විටම පාහේ විදේශීය යතුරු දෙකේ සංයුක්ත යතුරක් විය යුතුය, ගොඩනඟන ලද දර්ශක හැසිරීම ලබා ගැනීමට සහ යොමු කිරීම්වල සුවිශේෂත්වය සහතික කිරීමට.
• මෙම වගුව මත තොග වශයෙන් ඇතුළත් කිරීමට සහ මකා දැමීමට ඔබ සැලසුම් කරන විට. අනන්‍යතා තීරු වලට ඇති ලොකුම අවාසිය නම් මුල් වගුවේ ප්‍රධාන අගයන් පවත්වා ගැනීමට ඔබට අවශ්‍ය වෙනත් වගුවකින් හෝ විමසුමකින් පේළි ඇතුළත් කිරීමේදී ඔබට යා යුතු අමතර හූප්ලා ය. ඔබ "අනන්‍යතා ඇතුළු කිරීම" සක්‍රිය කළ යුතුය (කෙසේ වෙතත් එය ඔබගේ ඩීබීඑම්එස් හි සිදු කර ඇත), ඉන්පසු ඔබ ඇතුළු කරන යතුරු අද්විතීය බව අතින් තහවුරු කරගන්න, ඉන්පසු ඔබ ආනයනය කළ පසු අනන්‍යතා කවුන්ටරය සැකසිය යුතුය. වගුවේ පාර-දත්ත උපරිම අගය දක්වා. මෙම මෙහෙයුම මෙම වගුවේ බොහෝ දේ සිදුවුවහොත්, වෙනත් PK යෝජනා ක්‍රමයක් සලකා බලන්න.
• බෙදා හරින ලද වගු සඳහා.තනි දත්ත සමුදායන්, අසාර්ථක යුගල සහ වෙනත් අවස්ථා සඳහා අනන්‍යතා තීරු ඉතා හොඳින් ක්‍රියා කරයි. කෙසේ වෙතත්, ඔබට යා හැකි තරම් විශාල ප්‍රමාණයක් ඇති අතර තවමත් එක් පරිගණකයක් ප්‍රමාණවත් තරම් වේගවත් විය යුතුය. අනුරූකරණය හෝ ගනුදෙනු ලොග් නැව්ගත කිරීම මඟින් ඔබට කියවීමට පමණක් අමතර පිටපත් ලබා ගත හැකි නමුත් එම විසඳුමේ පරිමාණයට සීමාවක් ද ඇත. වැඩි කල් යන්නට මත්තෙන් ඔබට දත්ත ඇතුළත් කිරීම් හැසිරවීමට හා එකිනෙකා සමඟ සමමුහුර්ත කිරීමට සේවාදායක අවස්ථා දෙකක් හෝ වැඩි ගණනක් අවශ්‍ය වේ. එම තත්වය පැමිණි විට, ඔබට වර්ධක එකක් වෙනුවට GUID ක්ෂේත්‍රයක් අවශ්‍ය වනු ඇත, මන්ද බොහෝ DBMSs කලින් සැකසූ ඒවා GUID වලින් කොටසක් නිදර්ශන-විශේෂිත හඳුනාගැනීමක් ලෙස භාවිතා කරන අතර පසුව අනන්‍යතාවය අහඹු ලෙස ජනනය කරයි. හෝ වර්ධක ලෙස. කෙසේ වෙතත්,
• ඩීබී හි බහු වගු හරහා ඔබට සුවිශේෂත්වය බලාත්මක කිරීමට සිදු වූ විට.නිදසුනක් ලෙස, ගිණුම්කරණ පද්ධති වල සාමාන්‍ය දෙයක් වන්නේ, සාමාන්‍ය ලෙජරය කළමනාකරණය කිරීමයි (මෙතෙක් සිදු වී ඇති සෑම ගිණුමකම එක් එක් ණය හෝ හර සඳහා පේළියක් ඇත, එබැවින් එය ඉතා ඉක්මණින් විශාල වේ) එක් එක් දින දර්ශන මාසයක් නියෝජනය කරන වගු අනුක්‍රමයක් ලෙස / අවුරුදු. වාර්තා කිරීම සඳහා ඒවා එකට සම්බන්ධ කිරීම සඳහා දර්ශන නිර්මාණය කළ හැකිය. තර්කානුකූලව, මේ සියල්ල ඉතා විශාල වගුවක් වන නමුත් එය කපා හැරීම ඩීබී හි නඩත්තු කටයුතු පහසු කරයි. කෙසේ වෙතත්, අනුපිටපත් යතුරු සමඟ අවසන් නොවී බහුවිධ වගු වලට ඇතුළත් කිරීම් කළමනාකරණය කරන්නේ කෙසේද යන්න පිළිබඳ ගැටළුව (ඊළඟ මාසයේදී වසා දැමීමේදී ඉදිරි මාසයේදී ගනුදෙනු ආරම්භ කිරීමට ඔබට ඉඩ සලසයි). නැවතත්, අනන්‍යතා නිඛිල තීරු වෙනුවට GUID යනු යන්නට විසඳුමයි, ඩීබීඑම්එස් නිර්මාණය කර ඇත්තේ මේවා සැබවින්ම අද්විතීය ආකාරයකින් ජනනය කිරීමට ය,

මෙම තත්වයන් තුළ අනන්‍යතා තීරු භාවිතා කිරීමට ඉඩ සලසන ක්‍රියාමාර්ග තිබේ, මම බලාපොරොත්තු වූ පරිදි, නමුත් මේවායින් බොහොමයක් තුළ, අනන්‍යතා නිඛිල තීරුවේ සිට GUID දක්වා යාවත්කාලීන කිරීම සරල වන අතර ගැටළුව වඩාත් හොඳින් විසඳයි.

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

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

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

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

අනෙක් අය වැඩි කරන ප්‍රාථමික යතුරක් සඳහා නඩුව සකස් කර ඇති බැවින් මම GUID එකක් සඳහා එකක් සාදමි:

• එය අද්විතීය බව සහතික කර ඇත
• ඔබගේ යෙදුමේ දත්ත සඳහා දත්ත සමුදායට එක් අඩු සංචාරයක් කළ හැකිය. (උදාහරණයක් ලෙස වර්ග වගුවක් සඳහා ඔබට GUID යෙදුම තුළ ගබඩා කර වාර්තාව ලබා ගැනීමට භාවිතා කළ හැකිය. ඔබ අනන්‍යතාවයක් භාවිතා කරන්නේ නම් දත්ත සමුදාය නාමයෙන් විමසීමට අවශ්‍ය වන අතර PK ලබා ගැනීම සඳහා මෙය කරන බොහෝ යෙදුමක් මම දැක ඇත්තෙමි. පසුව සම්පූර්ණ තොරතුරු ලබා ගැනීම සඳහා එය නැවත විමසයි).
• දත්ත සැඟවීමට එය ප්‍රයෝජනවත් වේ. www.domain.com/Article/2 ඔබට ඇත්තේ ලිපි දෙකක් පමණක් බව මට දන්වන්න. www.domain.com/article/b08a91c5-67fc-449f-8a50-ffdf2403444a මට කිසිවක් නොකියයි.
• ඔබට විවිධ දත්ත සමුදායන්ගෙන් වාර්තා පහසුවෙන් ඒකාබද්ධ කළ හැකිය.
• MSFT අනන්‍යතාවය සඳහා GUIDS භාවිතා කරයි.

සංස්කරණය කරන්න: අනුපිටපත

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

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

මූලික මූලධර්මයක් ලෙස (සමහර විට දැඩි රීතියක්), ප්‍රාථමික යතුරක වටිනාකම එහි පේළියේ ජීවිත කාලය පුරාම වෙනස් නොවිය යුතුය. පේළියක ඇති ඕනෑම ව්‍යාපාර දත්තයක් එහි ජීවිත කාලය පුරාවටම වෙනස් වේ යැයි උපකල්පනය කිරීම නුවණට හුරුය, එබැවින් ඕනෑම ව්‍යාපාර දත්තයක් ප්‍රාථමික යතුරක් සඳහා දුර්වල අපේක්ෂකයෙකු වනු ඇත. ස්වයංක්‍රීයව වැඩි කරන ලද පූර්ණ සංඛ්‍යාවක් වැනි වියුක්ත දෙයක් බොහෝ විට හොඳ අදහසක් වන්නේ මේ නිසා ය. කෙසේ වෙතත්, ස්වයංක්‍රීයව වැඩි කරන ලද පූර්ණ සංඛ්‍යා වලට ඒවායේ සීමාවන් ඇත.

ඔබේ දත්ත වලට ඇත්තේ ඔබේ දත්ත ගබඩාව තුළ පමණක් ආයු කාලයක් නම්, ස්වයංක්‍රීයව වැඩි කළ පූර්ණ සංඛ්‍යා හොඳයි. එහෙත්, වෙනත් පිළිතුරු වල සඳහන් කර ඇති පරිදි, ඔබේ දත්ත බෙදා ගැනීමට, සමමුහුර්ත කිරීමට හෝ වෙනත් ආකාරයකින් ඔබේ දත්ත ගබඩාවෙන් පිටත ජීවිතයක් ගත කිරීමට ඔබට අවශ්‍ය නම්, ස්වයංක්‍රීයව වැඩි කරන ලද පූර්ණ සංඛ්‍යා දුර්වල ප්‍රාථමික යතුරු සාදයි. වඩා හොඳ තේරීමක් මාර්ගෝපදේශයක් වනු ඇත (aka uuid "විශ්වීය අද්විතීය හැඳුනුම්පත").

සෑම වගුවක් සඳහාම ස්වාභාවික යතුරු දත්ත සමුදාය සඳහා වන තාර්කික ක්‍රමෝපාය තුළ පමණක් පවතින බවට වැදගත් කාරණය ප්‍රශ්නය සහ බොහෝ පිළිතුරු මග හැරී ඇති අතර, එක් එක් වගුව සඳහා වන සියලු ආදේශක යතුරු දත්ත ගබඩාව සඳහා වන භෞතික ක්‍රමවේදය තුළ පමණක් පවතී . වෙනත් පිළිතුරු මගින් අන්‍යාගමික යතුරු නිසියාකාරව භාවිතා කිරීමට හේතු සහ කවදාද යන්න සාකච්ඡා නොකර පූර්ණ සංඛ්‍යා හා GUID ආදේශක යතුරු වල සාපේක්ෂ ප්‍රතිලාභ ගැන සාකච්ඡා කරයි.

BTW: ප්‍රාථමික යතුර වැරදි ලෙස අර්ථ දක්වා ඇති සහ නිරවද්‍ය නොවන යෙදුම භාවිතා කිරීමෙන් වැළකී සිටිමු . එය පූර්ව සම්බන්ධතා දත්ත ආකෘතිවල පුරාවස්තුවක් වන අතර එය මුලින්ම සම්බන්ධිත ආකෘතියට (නොදැනුවත්ව) සම්බන්ධ වූ අතර පසුව විවිධ RDBMS වෙළෙන්දන් විසින් භෞතික වසමට නැවත සම්බන්ධ විය. එහි භාවිතය සේවය කරන්නේ අර්ථ නිරූපණය අවුල් කිරීමට පමණි.

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

ඊට හාත්පසින්ම වෙනස්ව , වගුවක ඇති ඕනෑම ආදේශක යතුරක් දත්ත සමුදාය සඳහා වන භෞතික ක්‍රමවේදය තුළ පමණක් වාසය කරයි (එබැවින් සෑම විටම, ආරක්ෂක හේතූන් මත සහ දත්ත සමුදායේ අඛණ්ඩතාව පවත්වා ගැනීම සඳහා, දත්ත සමුදාය භාවිතා කරන්නන්ට සම්පූර්ණයෙන්ම නොපෙනෙන විය යුතුය). අන්‍යාගමික යතුරක් හඳුන්වාදීමට ඇති එකම හේතුව වන්නේ ඩීබී හි භෞතික නඩත්තුව සහ භාවිතය පිළිබඳ කාර්ය සාධන ගැටළු විසඳීමයි; ඒවා සම්බන්ධ වීම, ප්‍රතිවර්තනය කිරීම, දත්ත සඳහා බහු දෘඩාංග ප්‍රභවයන් හෝ වෙනත් වේවා.

අන්වාදේශ යතුරක් හඳුන්වාදීමට ඇති එකම හේතුව කාර්ය සාධනය බැවින්, එය ක්‍රියාකාරී වීමට අපි ප්‍රාර්ථනා කරමු. අතෙහි ඇති කාර්යසාධන ගැටළුව සම්බන්ධ වන්නේ නම්, අපි අනිවාර්යයෙන්ම අපේ අන්‍යාගමික යතුර හැකි තරම් පටු බවට පත් කිරීමට කැමැත්තෙමු (දෘඩාංගයට සම්බන්ධ නොවී, කෙටි සංඛ්‍යා හා බයිට් සාමාන්‍යයෙන් ඉවතට). සම්බන්ධ වීමේ කාර්ය සාධනය අවම දර්ශක උස මත රඳා පවතී, එබැවින් බයිට් 4 ක පූර්ණ සංඛ්‍යාවක් ස්වාභාවික විසඳුමකි. ඔබගේ කාර්ය සාධන ගැටළුව ඇතුළත් කිරීමේ අනුපාතය නම්, බයිට් 4 ක පූර්ණ සංඛ්‍යාවක් ස්වාභාවික විසඳුමක් විය හැකිය (ඔබේ RDBMS හි අභ්‍යන්තරය අනුව). වගුවක් සඳහා ඔබගේ කාර්ය සාධන ගැටළුව වෙනත් ආදේශක යතුරු තාක්‍ෂණයට වඩා අනුරූකරණයක් හෝ බහු දත්ත ප්‍රභවයක් නම් , එය GUID හෝ කොටස් දෙකක යතුරක් (ධාරක ID + නිඛිලය) වඩා සුදුසු විය හැකිය. මම පෞද්ගලිකව GUIDs වලට කැමති නැති නමුත් ඒවා පහසුය.

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

විශේෂ අවස්ථා

1. ඔබේ ව්යාපාරික අවශ්යතා බව ක්ෂේත්ර වඩා විගණන (හෝ වෙනත්) කටයුතු සඳහා ගනුදෙනු අනුක්රමික අංක ජනවරම නම් නොවේ යෙන් අන්වාදේශ ප්රධාන; එය ස්වාභාවික යතුරකි (අමතර අවශ්‍යතා සහිතව). ප්‍රලේඛනයෙන් ස්වයංක්‍රීයව වැඩි කරන පූර්ණ සංඛ්‍යාවක් මඟින් ආදේශක යතුරු පමණක් ජනනය කරයි , එබැවින් එය ජනනය කිරීමට වෙනත් යාන්ත්‍රණයක් සොයා ගන්න. නිසැකවම යම් ආකාරයක මොනිටරයක් ​​අවශ්‍ය වනු ඇති අතර, ඔබ ඔබේ ගනුදෙනු බහුවිධ වෙබ් අඩවි වලින් ලබා ගන්නේ නම්, එක් වෙබ් අඩවියක් විශේෂිත වනු ඇත , මොනිටරය සඳහා නම් කරන ලද සත්කාරක වෙබ් අඩවිය වීම නිසා.

2. ඔබේ වගුව කිසි විටෙක පේළි සියයකට වඩා වැඩි නොවන්නේ නම් දර්ශක උස අදාල නොවේ. සෑම ප්‍රවේශයක්ම මේස පරිලෝකනයකින් සිදු වේ. කෙසේ වෙතත්, දිගු නූල්වල නූල් සැසඳීම් තවමත් බයිට් 4 ක නිඛිලයක සංසන්දනයට වඩා මිල අධික වන අතර GUID සංසන්දනය කිරීමට වඩා මිල අධික වනු ඇත.

3. වර්‍ග (4) කේත ක්ෂේත්‍රයක් මඟින් යතුරු කළ කේත අගයන් වගුවක් බයිට් 4 ක පූර්ණ සංඛ්‍යාවක් සහිත එකක් මෙන් ක්‍රියාකාරී විය යුතුය. මේ පිළිබඳව මා සතුව කිසිදු සාක්ෂියක් නොතිබුණද මම උපකල්පනය නිතර භාවිතා කරන අතර එය කිසි විටෙකත් රළු කිරීමට හේතුවක් නොතිබුණි.

එය හොඳ පුහුණුවක් පමණක් නොව, ඇත්ත වශයෙන්ම එය බිල් කාර්වින්ගේ SQL Antipatterns පොතේ ප්‍රති-රටාවක් ලෙස විස්තර කර ඇත.

සෑම වගුවකටම ව්‍යාජ කතාවක් අවශ්‍ය නොවේ - අත්තනෝමතික වටිනාකමක් ඇති ප්‍රාථමික යතුරක්, ආකෘතියට අර්ථකථන වටිනාකමක් ඇති දෙයක් නොවේ - සහ එය සැමවිටම හැඳින්වීමට හේතුවක් නැත id.

මෙය විශ්වීය ය - එසේ නොමැතිනම් යතුර සැබවින්ම අද්විතීය බව ඔබට තහවුරු කිරීමට අවශ්‍ය වනු ඇත. මෙය සිදු කරනු ලබන්නේ අනෙක් සියලුම යතුරු දෙස බැලීමෙනි ... එය කාලය ගතවනු ඇත. ඔබගේ වාර්තා අංකය යතුරු පිටාර ගැලීමේ අගයට ආසන්න වන විට වර්ධක යතුරක් තිබීම මිල අධික වේ.

මම සාමාන්‍යයෙන් දර්ශකයන් වඩාත් පැහැදිලි ක්ෂේත්‍ර නාම ref_{table}හෝ සමාන අදහසක් බවට පත් කරමි.

වාර්තාවක් වෙත බාහිරව යොමු කිරීම අවශ්‍ය නොවන්නේ නම් ඔබට හැඳුනුම්පතක් අවශ්‍ය නොවේ.

එය සැමවිටම කළ යුතු යැයි මම නොකියමි. මට මෙහි අද්විතීය යතුරක් නොමැති මේසයක් තිබේ - එයට එකක් අවශ්‍ය නොවේ. එය විගණන ලොගයකි. කිසි විටෙක යාවත්කාලීනයක් සිදු නොවනු ඇත, විමසීම් මඟින් සියලු වෙනස්කම් ලොග් වී ඇති දෙයට නැවත ලබා දෙනු ඇත, නමුත් එය සාධාරණ ලෙස කළ හැකි හොඳම දේ වන්නේ වැරදි වෙනසක් නිර්වචනය කිරීමට මිනිසෙකු අවශ්‍ය වේ. (කේතයට හැකි නම් එය මුලින්ම එය තහනම් කරනු ඇත!)

ප්‍රාථමික යතුරක් සඳහා ස්වයංක්‍රීය වර්ධක කවුන්ටරය හොඳ අදහසක් නොවේ. එයට හේතුව ඔබේ දත්ත ඇතුළත් කිරීමට පෙර ඊළඟ යතුර සොයා ගැනීමට සහ එකකින් වර්ධක කිරීමට දත්ත ගබඩාවට ආපසු යා යුතු බැවිනි.

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

දත්ත සමුදාය ඔබට එය ලබා දීමට ඉඩ දීමෙන් එයට අවශ්‍ය දේ සඳහා යතුර අද්විතීය බව සහතික කළ හැකිය.

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

UUIDs මම ප්‍රාථමික යතුරු ලෙස භාවිතා නොකරමි, මන්ද ඒවා තැනීමට හා ගබඩා කිරීමට යන වියදම දිගු අගයක් එකකින් වැඩි කිරීමට වඩා වැඩි ය. UUIDs තවමත් උපන් දින විරුද්ධාභාසය සමඟ කටයුතු කරන්නේ අනුපිටපතක් න්‍යායාත්මකව පැන නැගිය හැකි බැවිනි.