වගු නම් කිරීමේ උභතෝකෝටිකය: ඒකීය එදිරිව බහු වචන [සංවෘත]

ඇකඩමිය සතුව ඇත්තේ වගු නාමයන් ඔවුන් සතු ගුණාංග ගබඩා කරන ඒකකයේ ඒකකය විය යුතු බවයි.

නම් වටා හතරැස් වරහන් අවශ්‍ය වන ඕනෑම ටී-එස්කියුඑල් එකකට මම අකමැතියි, නමුත් මම Usersමේසයක් ඒකීය ලෙස නම් කර ඇති අතර, වගුව භාවිතා කරන්නන්ට සමහර විට වරහන් භාවිතා කිරීමට සදාකාලිකවම ද en ුවම් කරමි.

මගේ බඩවැල් හැඟීම නම් ඒකීය භාවය සමඟ සිටීම වඩාත් නිවැරදියි, නමුත් මගේ බඩවැල් හැඟීම වන්නේ වරහන් මඟින් අවකාශයේ ඇති තීරු නම් වැනි අනවශ්‍ය දේ දක්වයි.

මම නැවතී සිටිය යුතුද, නැත්නම් යා යුතුද?

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

මට එකම ප්‍රශ්නයක් ඇති අතර, මෙහි ඇති සියලුම පිළිතුරු කියවීමෙන් පසු මම අනිවාර්යයෙන්ම තනි, හේතු සමඟ සිටිමි.

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

හේතුව 2 . (පහසුව). බහු වචන වලට වඩා ඒකීය නම් වලින් එළියට පැමිණීම පහසුය. වස්තූන් අක්‍රමවත් බහුවිධ හෝ බහු වචන නොවිය හැකි නමුත් සෑම විටම ඒකීය එකක් ඇත (ප්‍රවෘත්ති වැනි ව්‍යතිරේක කිහිපයක් සහිතව).

• පාරිභෝගික
• නියෝග
• පරිශීලක
• තත්ත්වය
• පුවත්

හේතුව 3 . (සෞන්දර්යාත්මක හා පිළිවෙල). විශේෂයෙන් මාස්ටර්-සවිස්තරාත්මක අවස්ථා වලදී, මෙය වඩා හොඳින් කියවයි, නමට වඩා හොඳින් පෙළගස්වයි, සහ වඩාත් තාර්කික අනුපිළිවෙලක් ඇත (මාස්ටර් පළමුව, විස්තර දෙවන):

• 1. ඕඩර්
• 2. ඕර්ඩර් ඩෙටේල්

සසඳන විට:

• 1. ඕර්ඩර් ඩෙටේල්ස්
• 2. ඕඩර්ස්

හේතුව 4 (සරල බව). සියල්ල එකට ගත් විට, වගු නම්, ප්‍රාථමික යතුරු, සම්බන්ධතා, ආයතන පන්ති ... දෙකක් වෙනුවට තනි නමක් (ඒකීය) පමණක් දැන සිටීම වඩා හොඳය (ඒකීය පන්තිය, බහු වගුව, ඒකීය ක්ෂේත්‍රය, ඒකීය-බහු වචන මාස්ටර්-විස්තර ..). .)

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

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

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

හේතුව 6 . (ඇයි නැත්තේ?). එමඟින් ඔබට ලිවීමේ කාලය ඉතිරි කර ගත හැකි අතර, තැටියේ ඉඩ ඉතිරි කර ගත හැකි අතර ඔබේ පරිගණක යතුරුපුවරුව දිගු කල් පවතිනු ඇත!

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

ඔබ අකුරු 3 ක්, බයිට් 3 ක්, අමතර යතුරුපුවරු පහර 3 ක් ඉතිරි කර ඇත :)

අවසාන වශයෙන්, වෙන් කර ඇති නම් සමඟ අවුල් කරන අය නම් කළ හැකිය:

• පරිශීලක> පිවිසුම් පරිශීලක, AppUser, SystemUser, CMSUser, ...

නැතහොත් කුප්‍රකට වර්ග වරහන් භාවිතා කරන්න [පරිශීලක]

ඔබ වස්තු සම්බන්ධතා සිතියම්කරණ මෙවලම් භාවිතා කරන්නේ නම් හෝ අනාගතයේ දී මම යෝජනා කරන්නේ ඒකීය ය .

LLBLGen වැනි සමහර මෙවලම් මඟින් වගු නාමය වෙනස් නොකර ස්වයංක්‍රීයව පරිශීලකයින්ට පරිශීලකයා වැනි බහු නාමයන් නිවැරදි කළ හැකිය. මෙය වැදගත් වන්නේ ඇයි? මන්ද එය සිතියම් ගත කළ විට එය පරිශීලකයින් වෙනුවට පරිශීලක.නාමයක් ලෙස පෙනීමට අවශ්‍යය. මගේ පැරණි දත්ත සමුදා වගු වලින් tblUsers.strName නම් කරන සමහර පැරණි දත්ත සමුදා වගු වලින් එය නරක ය.

මගේ නව නියමය නම් එය වස්තුවක් බවට පරිවර්තනය වූ පසු එය පෙනෙන්නේ කෙසේද යන්න විනිශ්චය කිරීමයි.

මා භාවිතා කරන නව නාමකරණයට නොගැලපෙන එක් වගුවක් වන්නේ UsersInRoles ය. නමුත් සෑම විටම එම ව්‍යතිරේකයන් ස්වල්පයක් ඇති අතර මේ අවස්ථාවේ දී පවා එය UsersInRoles.Username ලෙස පෙනේ.

ඉංග්‍රීසියෙන් ඒකීය ලෙස තෝරා නොගත් නාම පදයක් භාවිතා කිරීමට මම කැමැත්තෙමි .

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

අපි සාමාන්‍යයෙන් පේළි සමඟ යමක් කරන බැවින්, නම චෝදනාවට ලක් නොකරන්නේ ඇයි? අප කියවන ප්‍රමාණයට වඩා අප ලියන වගුවක් තිබේ නම්, නම ද්වෛතයට ඇතුළත් නොකරන්නේ මන්ද? එය මේසය තියෙන්නේ ක ද genitive භාවිතා නොකළ ඇයි, යමක්? අපි මෙය නොකරන්නෙමු, මන්ද වගුව එහි තත්වය හෝ භාවිතය නොසලකා පවතින වියුක්ත බහාලුමක් ලෙස අර්ථ දක්වා ඇත. නිරවද්‍ය හා නිරපේක්ෂ අර්ථකථන හේතුවක් නොමැතිව නාම පදයට බලපෑම් කිරීම බබල් කිරීමකි.

තෝරා නොගත් නාම පදයක් භාවිතා කිරීම සරල, තාර්කික, නිත්‍ය සහ භාෂාවෙන් ස්වාධීන ය.

වගු වලට තනි නම් තිබිය යුතු සම්මුතියට අවශ්‍ය කුමක්ද? මම නිතරම සිතුවේ එය බහුවිධ නම් බවයි.

පරිශීලක වගුවට පරිශීලකයෙකු එකතු කරනු ලැබේ.

මෙම වෙබ් අඩවිය එකඟ වේ:
http://vyaskn.tripod.com/object_naming.htm#Tables

මෙම වෙබ් අඩවිය එකඟ නොවේ (නමුත් මම එයට එකඟ නොවෙමි):
http://justinsomnia.org/writings/naming_conventions.html

අනෙක් අය සඳහන් කර ඇති පරිදි: මේවා හුදෙක් මාර්ගෝපදේශ පමණි. ඔබ සහ ඔබේ සමාගම / ව්‍යාපෘතිය සඳහා වැඩ කරන සමුළුවක් තෝරාගෙන ඒ සමඟම රැඳී සිටින්න. ඒකීය හා බහු වචන හෝ සමහර විට කෙටි යෙදුම් අතර මාරුවීම හා සමහර විට එසේ නොවීම වඩාත් උග්‍ර වේ.

සරල උදාහරණයක් ලෙස මෙය කරන්නේ කෙසේද:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

එදිරිව.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

දෙවැන්නෙහි ඇති SQL කලින් තිබූ ඒවාට වඩා ආගන්තුක ශබ්දයකි.

මම තනි ඡන්දය ප්‍රකාශ කරමි .

ආයතන සම්බන්ධතා රූප සටහනක, ඒකකය තනි නමකින් පිළිබිඹු විය යුතු යැයි මම තරයේ විශ්වාස කරමි. ක්ෂණික වූ පසු, නම එහි උදාහරණය පිළිබිඹු කරයි. එබැවින් දත්ත සමුදායන් සමඟ, වගුවක් බවට පත් කරන විට (වස්තු හෝ වාර්තා එකතුවක්) බහු වේ. ආයතනය, පරිශීලකයා වගු පරිශීලකයින් බවට පත් කර ඇත. පරිශීලකයාගේ නම සේවකයා ලෙස වැඩිදියුණු කළ හැකි යැයි යෝජනා කළ අනෙක් අය සමඟ මම එකඟ වෙමි.

SQL ප්‍රකාශයකින් මෙය වඩාත් අර්ථවත් වන්නේ ඔබ වාර්තා සමූහයකින් තෝරාගෙන ඇති නිසා සහ වගුවේ නම ඒකීය නම් එය හොඳින් කියවන්නේ නැති බැවිනි.

මම සමඟ දැනට ඒක වචන වගුව නම් සහ කිසිදු ක්රමලේඛ ස්ථිතියක් හෝ සඳහා.

හේතුව? මූසික ⇒ මීයන් සහ බැටළුවන් ⇒ බැටළුවන් වැනි අක්‍රමවත් බහුවිධ ඉංග්‍රීසි භාෂාවෙන් තිබීම . එවිට, මම අවශ්ය නම් එකතු , මම එය භාවිතා ස්ටික් හෝ sheeps , සහ යනවා.

එය සැබවින්ම බහුත්වයට කැපී පෙනීමට උපකාරී වන අතර, දේවල් එකතු කිරීම කෙබඳු වේදැයි මට පහසුවෙන් සහ ක්‍රමලේඛිකව තීරණය කළ හැකිය.

ඒ නිසා, මගේ නීතිය: සෑම දෙයක්ම දේවල් සෑම එකතුව සමග ඒක වචන වන අතර, ඒක වචන වේ ගේ ඇත්තා වූ ද,. ORM වලටද උදව් කරයි.

IMHO, වගු නම් ගනුදෙනුකරුවන් මෙන් බහු වචන විය යුතුය .

ගනුදෙනුකරුවන්ගේ වගුවේ පේළියකට සිතියම් ගත කරන්නේ නම් පන්ති නාම පාරිභෝගිකයා මෙන් ඒකීය විය යුතුය .

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

මගේ ප්‍රධාන තර්කය නම් මම වගු කට්ටලයක් ලෙස නොව සබඳතා ලෙස නොසිතන බවයි.

ඉතින්, AppUserසම්බන්ධතාවය පවසන්නේ කුමන ආයතනද AppUsersයන්නයි.

මෙම AppUserGroupසම්බන්ධයෙන් මට කියනවා ආයතන වනAppUserGroups

මෙම AppUser_AppUserGroupසම්බන්ධයෙන් මට කියනවා AppUsersහා AppUserGroupsසම්බන්ධ කර ඇත.

මෙම AppUserGroup_AppUserGroupආකාරය සම්බන්ධයෙන් මට කියනවා AppUserGroupsහා AppUserGroupsසම්බන්ධ, (කණ්ඩායම් එනම් කණ්ඩායම් සාමාජික).

වෙනත් වචන වලින් කිවහොත්, මම ආයතන ගැන සිතන විට සහ ඒවා සම්බන්ධ වන්නේ කෙසේද යන්න ගැන මම සිතන්නේ ඒකීය සම්බන්ධතා ගැන ය, නමුත් ඇත්ත වශයෙන්ම, එකතු කිරීම් හෝ කට්ටලවල ඇති ආයතන ගැන සිතන විට, එකතු කිරීම් හෝ කට්ටල බහු වේ.

මගේ කේතයේ, පසුව, සහ දත්ත සමුදායේ, මම ඒකීය භාවිතා කරමි. පා description මය විස්තර වලදී, මම කියවීමේ හැකියාව වැඩි කිරීම සඳහා බහු වචන භාවිතා කරමි - ඉන්පසු අකුරු ආදිය භාවිතා කර වගුවේ / සම්බන්ධතාවයේ නම බහු වචන වලින් වෙන්කර හඳුනා ගනිමි.

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

මමත් බහු වචන සමඟ යන්නෙමි , සහ ඉහත සඳහන් කළ පරිශීලකයින්ගේ උභතෝකෝටිකය සමඟ, අපි වර්ග වරහන් ප්‍රවේශය ගනිමු.

අපි ඒ යටින් පවත්නා අවබෝධය සමග, දත්ත සමුදාය ගෘහ නිර්මාණ ශිල්පය සහ අයදුම් ගෘහ නිර්මාණ ශිල්පය දෙකම අතර ඒකාකාර ලබා මේ පරිශීලකයන් වගුව එකතුවකි පරිශීලක ලෙස බොහෝ ලෙස වටිනාකම් පරිශීලකයන් කේත පුරාවස්තුවක් දී එකතු එකතුවකි පරිශීලක වස්තූන්.

අපගේ දත්ත කණ්ඩායම සහ අපගේ සංවර්ධකයින් එකම සංකල්පීය භාෂාවක් කථා කිරීම (සෑම විටම එකම වස්තු නාම නොවුවද) ඔවුන් අතර අදහස් ගෙන ඒම පහසු කරයි.

කට්ටලයක් නිරූපණය කිරීම සඳහා මම බහු වචන භාවිතා කිරීමට කැමැත්තෙමි, එය මගේ සම්බන්ධතා මනසට වඩා හොඳ යැයි හැඟේ.

මෙම නිශ්චිත මොහොතේදී මම මගේ සමාගම සඳහා දත්ත ආකෘතියක් නිර්වචනය කිරීම සඳහා තනි නම් භාවිතා කරමි, මන්ද රැකියා ස්ථානයේ සිටින බොහෝ දෙනෙකුට එය සමඟ වඩාත් ගැටුම්කාරී බවක් දැනේ. සමහර විට ඔබ ඔබේ පෞද්ගලික මනාපයන් පැනවීම වෙනුවට සෑම කෙනෙකුටම ජීවිතය පහසු කර ගත යුතුය. (වගු නම් කිරීම සඳහා “හොඳම පුහුණුව” කුමක් විය යුතුද යන්න තහවුරු කිරීමක් ලබා ගැනීම සඳහා මම මෙම ත්‍රෙඩ් එකේ අවසන් වූයේ එලෙසිනි)

මෙම ත්‍රෙඩ් එකේ ඇති සියලුම තර්ක කියවීමෙන් පසු මම එක් නිගමනයකට පැමිණියෙමි.

සෑම කෙනෙකුගේම ප්‍රියතම රසය කුමක් වුවත් මම මී පැණි සමඟ මගේ පෑන්කේක් වලට කැමතියි. නමුත් මම වෙනත් පුද්ගලයින් සඳහා ආහාර පිසිනවා නම්, ඔවුන් කැමති දෙයක් ඔවුන්ට සේවය කිරීමට මම උත්සාහ කරමි.

බහුවිධ වගු නම් භාවිතා කිරීම ජනප්‍රිය සම්මුතියක් යැයි මම නිතරම සිතුවෙමි. මේ දක්වා මම සෑම විටම බහු වචන භාවිතා කර ඇත.

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

මෝටර් රථ මේසයක් නම ඇතැයි මෝටර් රථ හා එක් එක් පේළිය කාර් වේ. ක්ෂේත්‍රය සමඟ මේසය සඳහන් කිරීම table.fieldහොඳම ක්‍රමය බවත් ඒකීය වගු නාම තිබීම වඩාත් කියවිය හැකි බවත් මම පිළිගනිමි . කෙසේ වෙතත් පහත දැක්වෙන උදාහරණ දෙකෙන්, කලින් සඳහන් කළ දේ වඩාත් අර්ථවත් කරයි:

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

අවංකවම, මම මේ කාරණය සම්බන්ධයෙන් මගේ ස්ථාවරය ගැන නැවත සිතා බලනු ඇති අතර, මම සංවර්ධනය කරන සංවිධානය විසින් භාවිතා කරනු ලබන සැබෑ සම්මුතීන් මත විශ්වාසය තබමි. කෙසේ වෙතත්, මම හිතන්නේ මගේ පුද්ගලික සම්මුතීන් සඳහා, මම බහු වගු නම් සමඟ රැඳී සිටිමි. මට එය වඩාත් අර්ථවත් කරයි.

ඒක වචන. පරිශීලක පේළි නිරූපණ වස්තු සමූහයක් අඩංගු අරාවකට මම 'පරිශීලකයින්' යැයි කියමි, නමුත් වගුව 'පරිශීලක වගුව' වේ. වගුව එහි ඇති පේළි සමූහය හැර අන් කිසිවක් නොවේ යැයි සිතීම වැරදිය, IMO; වගුව පාර-දත්ත වන අතර පේළි සමූහය ධූරාවලියෙන් මේසය සමඟ අමුණා ඇත, එය වගුවම නොවේ.

මම නිතරම ORM භාවිතා කරමි, ඇත්ත වශයෙන්ම එය බහු වගු නම් වලින් ලියා ඇති ORM කේතය මෝඩ පෙනුමක් ලබා ගැනීමට උපකාරී වේ.

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

උත්ප්රාසාත්මකව, සමහරවිට මම Userව්යතිරේකයක් හා එය අමතන්න Usersනිසා USER (Transac-SQL) නෑ මම නොමැති නම් මම ද වගු පමණ වරහන් භාවිතා කැමති නැති නිසා.

සියලුම හැඳුනුම්පත් තීරු ලෙස නම් කිරීමට මම කැමතියි Id, නැත ( ChickenIdහෝ ChickensIdබහු පුද්ගලයින් මේ ගැන කරන්නේ කුමක්ද?).

මේ සියල්ලට හේතුව මට දත්ත සමුදායන් කෙරෙහි නිසි ගෞරවයක් නොමැති නිසා, මම ජාවා වැනි පුරුදු හා කම්මැලිකම වැනි OO නම් කිරීමේ සම්මුතීන්ගෙන් එක් උපක්‍රමයක් පිළිබඳ දැනුම නැවත භාවිතා කරමි . සංකීර්ණ SQL සඳහා වඩා හොඳ IDE සහය ලැබෙනු ඇතැයි මම ප්‍රාර්ථනා කරමි.

ස්ක්‍රිප්ටින් කිරීමේදී අපි නම් වටා []] සමාන ප්‍රමිතීන් ක්‍රියාත්මක කරන අතර සුදුසු ක්‍රමෝපායන් සුදුසුකම් ඇති අය - මූලික වශයෙන් එය SQL සින්ටැක්ස් මගින් අනාගත නාම ග්‍රහණයට එරෙහිව ඔබේ ඔට්ටු ඇල්ලීම වළක්වයි.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

මෙය අතීතයේ දී අපගේ ආත්මයන් සුරකින ලදි - අපගේ සමහර දත්ත සමුදා පද්ධති SQL 6.0 සිට SQL 2005 දක්වා අවුරුදු 10+ ක් ධාවනය කර ඇත - ඔවුන් අපේක්ෂිත ආයු කාලය ඉක්මවා යයි.

වගු: බහු

පරිශීලකයින් වගුවේ බහු පරිශීලකයින් ලැයිස්තුගත කර ඇත.

ආකෘති: ඒකීය

පරිශීලක වගුවෙන් තනි පරිශීලකයෙකු තෝරා ගත හැකිය.

පාලකයන්: බහු

http://myapp.com/users විසින් බහු පරිශීලකයින් ලැයිස්තුගත කරනු ඇත.

එය කෙසේ හෝ වේවා.

CASE සින්ටැක්ස් භාවිතයෙන් මගේ ඊආර් රූප සටහන් කියවීම පහසු කරවන බැවින් මම තනි වගු නාමවල රසිකයෙක් වෙමි, නමුත් මෙම ප්‍රතිචාර කියවීමෙන් මට එය කිසි විටෙකත් හොඳින් හසු නොවන බවක් දැනේ? මම පෞද්ගලිකව එයට කැමතියි. ඔබ තනි වගු නම් භාවිතා කරන විට, ඔබේ සම්බන්ධතාවලට ක්‍රියාකාරී ක්‍රියා පද එකතු කරන විට සහ සෑම සම්බන්ධතාවකටම හොඳ වාක්‍ය සැකසීමේදී ඔබේ ආකෘති කෙතරම් කියවිය හැකිද යන්න පිළිබඳ උදාහරණ සමඟ හොඳ දළ විශ්ලේෂණයක් ඇත. මේස 20 ක දත්ත සමුදායක් සඳහා මේ සියල්ල මඳක් වැඩි ය. එහෙත් ඔබට මේස සිය ගණනක් සහිත ඩීබී සහ සංකීර්ණ මෝස්තරයක් තිබේ නම් හොඳ කියවිය හැකි රූප සටහනකින් තොරව ඔබේ සංවර්ධකයින් එය තේරුම් ගන්නේ කෙසේද?

http://www.aisintl.com/case/method.html

වගු සහ අදහස් උපසර්ග කිරීම සම්බන්ධයෙන් මම එම පුරුද්දට වෛර කරමි. නරක තොරතුරු ලබා දීමට පෙර පුද්ගලයෙකුට කිසිදු තොරතුරක් ලබා නොදෙන්න. වස්තූන් සඳහා ඩීබී බ්‍රවුස් කරන ඕනෑම කෙනෙකුට දර්ශනයකින් මේසයක් ඉතා පහසුවෙන් පැවසිය හැකිය, නමුත් මා සතුව ටීබීඑල් යූසර්ස් නම් වගුවක් තිබේ නම්, යම් හේතුවක් නිසා අනාගතයේ දී වගු දෙකකට ප්‍රතිව්‍යුහගත කිරීමට මම තීරණය කරමි. මට දැන් tblUsers නමින් දර්ශනයක් තිබේ. මෙම අවස්ථාවෙහිදී මට නොපෙනෙන විකල්ප දෙකක් ඉතිරිව ඇත, සමහර සංවර්ධකයින් ව්‍යාකූල කළ හැකි tbl උපසර්ගයක් සහිත දර්ශනයක් තබන්න, නැතහොත් මගේ නව ව්‍යුහය හෝ නම නරඹන්නන් යොමු කිරීම සඳහා නැවත ලියන ලෙස මධ්‍යම ස්ථරයට හෝ යෙදුමට වෙනත් ස්ථරයකට බල කරන්න. එය IMHO හි අදහස්වල වටිනාකමෙන් විශාල කොටසක් ප්‍රතික්ෂේප කරයි.

පද්ධතිය tables/viewsසේවාදායකය ම ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, ආදිය) සෑම විටම පාහේ, බහු වචන වේ. මම හිතන්නේ මම ඔවුන්ගේ නායකත්වය අනුගමනය කරනවා.

අපි MS SQL Server'sපද්ධති වගු දෙස බැලුවහොත් , මයික්‍රොසොෆ්ට් විසින් පවරා ඇති පරිදි ඒවායේ නම් ඇත plural.

ඔරකල් හි පද්ධති වගු නම් කර ඇත singular. ඒවායින් කිහිපයක් බහු වචන වුවද. පරිශීලක අර්ථ දක්වන වගු නාම සඳහා ඔරකල් බහු වචන නිර්දේශ කරයි. ඔවුන් එක් දෙයක් නිර්දේශ කර තවත් දෙයක් අනුගමනය කරන බව එයින් එතරම් තේරුමක් නැත. මෙම මෘදුකාංග දැවැන්තයන් දෙදෙනාගේ ගෘහ නිර්මාණ ශිල්පීන් විවිධ සම්මුතීන් භාවිතා කරමින් ඔවුන්ගේ වගු නම් කර තිබීම එතරම් තේරුමක් නැති දෙයකි ... සියල්ලට පසු, මේ අය කවුද ... ආචාර්ය උපාධිය?

මට මතකයි ශාස්ත්‍රීය, නිර්දේශය ඒකීයයි.

උදාහරණයක් ලෙස, අප පවසන විට:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

සමහර විට b / c එක් එක් IDවිශේෂිත පේළියකින් තෝරාගෙන තිබේද ...?

මෙය ටිකක් අතිරික්තයක් විය හැකි නමුත් ප්‍රවේශම් වීමට මම යෝජනා කරමි. වගු නැවත නම් කිරීම නරක දෙයක් බව අනිවාර්යයෙන්ම නොවේ, නමුත් ප්‍රමිතිකරණය එය පමණි; ප්‍රමිතියක් - මෙම දත්ත සමුදාය දැනටමත් "ප්‍රමිතිගත" විය හැකි නමුත් කොතරම් නරකද :) - මෙම දත්ත සමුදාය දැනටමත් පවතින අතර අනුමාන වශයෙන් එය වගු 2 කට වඩා වැඩි ගණනකින් සමන්විත වන බැවින් වඩා හොඳ ඉලක්කයක් වීමට අනුකූලතාව යෝජනා කරමි.

ඔබට සම්පූර්ණ දත්ත සමුදාය ප්‍රමිතිකරණය කළ නොහැකි නම් හෝ අවම වශයෙන් ඒ සඳහා වැඩ කිරීමට අදහස් කරන්නේ නම්, වගු නම් අයිස් කුට්ටියේ අගයක් පමණක් බවත්, දුර්වල ලෙස නම් කරන ලද වස්තූන්ගේ වේදනාව විඳදරාගෙන අත ළඟ ඇති කර්තව්‍යය කෙරෙහි අවධානය යොමු කළ හැකි බවත් මම සැක කරමි. ඔබේ හොඳම උනන්දුව -

ප්‍රායෝගික අනුකූලතාව සමහර විට හොඳම ප්‍රමිතිය වේ ... :)

my2cents ---

හැකි විකල්ප:

• SystemUser වගුව නැවත නම් කරන්න
• වරහන් භාවිතා කරන්න
• බහුවිධ වගු නම් තබා ගන්න.

IMO වරහන් භාවිතා කිරීම තාක්ෂණික වශයෙන් ආරක්ෂිතම ප්‍රවේශය වන අතර එය ටිකක් කරදරකාරී ය. IMO එය එකක් 6 න් 6 ක්, අනෙක දුසිම් භාගයක් වන අතර ඔබේ විසඳුම පුද්ගලික / කණ්ඩායම් මනාපයන් දක්වාම තම්බා ගනී.

ඔබ ඔබේ බහාලුම නිර්වචනය කරන ආකාරය මත පදනම්ව මගේ තේරීම අර්ථ නිරූපණයන්හි ඇත. උදාහරණයක් ලෙස, “ඇපල් මල්ලක්” හෝ “ඇපල්” හෝ “ඇපල් බෑගයක්” හෝ “ඇපල්”.

උදාහරණය: “විද්‍යාල” වගුවකට විද්‍යාල 0 ක් හෝ වැඩි ගණනක් අඩංගු විය හැකිය “විද්‍යාල” වගුවක සගයන් 0 ක් හෝ වැඩි ගණනක් අඩංගු විය හැකිය

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

මගේ නිගමනය නම් එක්කෝ හොඳයි, නමුත් වගු ගැන සඳහන් කිරීමේදී ඔබ (හෝ ඒ සමඟ අන්තර් ක්‍රියා කරන පුද්ගලයින්) ප්‍රවේශ වන්නේ කෙසේද යන්න නිර්වචනය කළ යුතුය; "අක්ෂ වගුව" හෝ "xs වගුවක්"

අනෙක් අය මෙහි සඳහන් කර ඇති පරිදි, සම්මුතීන් භාවිතයේ පහසුව සහ කියවීමේ හැකියාව වැඩි කිරීම සඳහා මෙවලමක් විය යුතුය. සංවර්ධකයින්ට වධ හිංසා කිරීම සඳහා විලංගුවක් හෝ සමාජ ශාලාවක් ලෙස නොවේ.

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

මෙම පරිචය මගේ වස්තූන් අතර බොහෝ සිට බොහෝ සම්බන්ධතා ගබඩා කරන අය සඳහා බහු වගු නම් වෙන් කරවා ගැනීමට ද මට ඉඩ සලසයි.

මගේ වගුවේ සහ තීරු නාමවල වෙන් කර ඇති වචන වළක්වා ගැනීමට මම උත්සාහ කරමි. මෙහි දී ප්‍රශ්නයක් ඇති විට, පරිශීලකයාගේ වෙන් කළ වචනය භාවිතා කරන වගුවක් සංයුක්ත කිරීමේ අවශ්‍යතාව මඟහරවා ගැනීම සඳහා පරිශීලකයින් සඳහා වන ඒකීය සම්මුතියට විරුද්ධ වීම වඩාත් අර්ථවත් කරයි.

සීමිත ආකාරයකින් උපසර්ග භාවිතා කිරීමට මම කැමතියි (වගු නම් සඳහා tbl, proc නම් සඳහා sp_, ආදිය), නමුත් බොහෝ දෙනා විශ්වාස කරන්නේ මෙය අවුල් සහගත බවයි. මම කැමල්බැක් නම් අවධාරනය කිරීමට වඩා කැමැත්තක් දක්වන්නේ නම ටයිප් කිරීමේදී මම සැමවිටම _ වෙනුවට + වෙනුවට පහර දීමයි. තවත් බොහෝ අය ඊට එකඟ නොවෙති.

සම්මුති මාර්ගෝපදේශ නම් කිරීම සඳහා තවත් හොඳ සබැඳියක් මෙන්න: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

ඔබේ සමුළුවේ වැදගත්ම සාධකය වන්නේ එය සැක සහිත දත්ත සමුදාය සමඟ අන්තර් ක්‍රියා කරන පුද්ගලයින්ට අර්ථවත් වන බවයි. සම්මුති නම් කිරීමේදී "ඒවා සියල්ලම පාලනය කිරීමට එක් මුද්දක්" නොමැත.

මම හිතන්නේ ඒකීයභාවය භාවිතා කිරීම අපට විශ්ව විද්‍යාලයේ උගන්වා ඇති දෙයයි. නමුත් ඒ සමඟම ඔබට හැකි විය තර්ක වස්තු දිශානත ක්‍රමලේඛනය මෙන් නොව, වගුවක් එහි වාර්තා වල උදාහරණයක් නොවන බවයි.

මම හිතන්නේ මම මේ මොහොතේ ඉංග්‍රීසියෙහි බහු අක්‍රමිකතා නිසා ඒක පුද්ගලයාට පක්ෂව කතා කරමි. ස්ථාවර බහුවිධ ස්වරූපයක් නොමැති නිසා ජර්මානු භාෂාවෙන් එය ඊටත් වඩා භයානක ය - සමහර විට වචනයක් බහුවිධද නැද්ද යන්න ඔබට කිව නොහැක. චීන භාෂාවල කෙසේ වෙතත් බහු වචන නොමැත.

මම වරක් පරිශීලක වගුව සඳහා "මචන්" භාවිතා කළෙමි - එකම කෙටි අක්ෂර සංඛ්‍යාවක්, මූල පද සමඟ ගැටුමක් නැත, තවමත් සාමාන්‍ය මිනිසෙකු සඳහා යොමු කිරීමකි. කේතය දැකිය හැකි පිරුණු හිස් ගැන මා සැලකිලිමත් නොවන්නේ නම්, මම එය එලෙසම තබා ගන්නෙමි.

මම නිතරම ඒකීය වචන භාවිතා කර ඇත්තේ එය මට ඉගැන්වූ නිසාය. කෙසේ වෙතත්, මෑතකදී නව ක්‍රමවේදයක් නිර්මාණය කරන අතර, දීර් time කාලයකට පසු පළමු වතාවට, මෙම සමුළුව පවත්වා ගෙන යාමට මම ක්‍රියාකාරීව තීරණය කළෙමි. සෑම වගු නාමයකම අවසානයට 's' එකතු කිරීම සෑම කෙනෙකුටම ඉදිරියෙන් 'tbl_' එකතු කිරීම මට වැඩක් නැති බව පෙනේ.

මම නිතරම සිතුවේ එය ගොළු සමුළුවක් බවයි. මම බහු වගු නම් භාවිතා කරමි.

(එම ප්‍රතිපත්තිය පිටුපස ඇති තාර්කිකත්වය නම්, ORM කේත උත්පාදක යන්ත‍්‍රයන්ට වස්තු සහ එකතු කිරීමේ පන්ති නිෂ්පාදනය කිරීම පහසු කරවන බැවිනි.

මගේ වගු නාම සඳහා මම නාම පද භාවිතා කරන්නේ ඒකීය හෝ බහු වචන වේ.

මූස් මාළු මුවන් ගුවන්යානය ඔබ කලිසම් කොට කලිසම් ඇස් කණ්ණාඩි කතුර විශේෂ දරුවන්

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

ශ්‍රිතයක් කට්ටල දෙකක් අතර හරස් නිෂ්පාදනයේ උප කුලකයක් ලෙස අර්ථ දැක්විය හැකි අතර, යතුරු කට්ටලයේ සෑම අංගයක්ම සිතියම්ගත කිරීමේදී එකවරම සිදු වේ . එබැවින් එම දෘෂ්ටිකෝණයෙන් පැන නගින පාරිභාෂිතය ඒකීය වේ. කාර්යයන් සම්බන්ධ වෙනත් ගණිතමය හා පරිගණක න්‍යායන් හරහා එකම ඒකීය (හෝ අවම වශයෙන් බහු වචන නොවන) සම්මුතියක් යමෙකු දකී (උදාහරණයක් ලෙස වීජ ගණිතය සහ ලැම්බඩා කැල්කියුලස්).