MySQL දත්ත වර්ග පැහැදිලි කරයි: කාර්ය සාධනය සහ විස්තාරණය සඳහා නිවැරදි තීරුවේ වර්ග තෝරන්න

1. හැඳින්වීම: MySQL දත්ත වර්ග ලැයිස්තුව ඔබට අවබෝධ කරගත යුතුය ඇයි

MySQL සමඟ වගු නිර්මාණය කරනවාද, යෙදුම් ඒකාබද්ධ කරනවාද යන අවස්ථාවල, සාමාන්‍යයෙන් අසන ප්‍රශ්නයක් මෙසේය: “මෙම තීරුව සඳහා මට කුමන දත්ත වර්ගය භාවිතා කළ යුතුද?”
එය INT විය යුතුද? ඔබට ඇත්තටම BIGINT අවශ්‍යද? ස්ට්‍රින් සඳහා VARCHAR ප්‍රමාණවත්ද, නැත්නම් TEXT වඩා හොඳද? මේ තේරීම් කුඩා වැනි පෙනුමක් දරයි, නමුත් පසුකාලීනව ඔබේ පද්ධතියට බලපාන පදනමක් ලෙස ක්‍රියා කරයි.

දත්ත වර්ග තේරීම අඩු අගයක් ලෙස ගණන් කරන්නේ නම්, ඔබට පහත පරිදි ගැටළු බොහෝවිට මුහුණ දීමට සිදුවේ:

• ඔබේ දත්ත අපේක්ෂා කර තිබූ තරමට වඩා වැඩි වීම නිසා ගබඩා ඉඩ අතුරුදන් වේ
• ඉන්ඩෙක්ස් විශාල වෙයි, විමසුම් කාර්ය සාධනය ක්‍රමයෙන් අඩුවේ
• පරාසය ඉක්මවන අගයන් හෝ අතිරේකය (overflow) අනපේක්ෂිත දෝෂ හෝ අපවාදයන්ට හේතු වේ
• පසුකාලීනව තීරු වර්ග වෙනස් කිරීමට ඔබට බලපෑමක් සිදු වේ, එය විශාල‑පරිමාණ මාරු කිරීමක් ලෙස පෙනේ

අනෙක් වචනයෙන්, MySQL දත්ත වර්ග පද්ධතිමයව අවබෝධ කරගෙන, එක් එක් භාවිතා අවස්ථාව සඳහා නිවැරදි වර්ගය තෝරා ගැනීම යනු කාර්ය සාධනය සහ නඩත්තු හැකියාව වැඩිම කරගැනීමට වේගවත් මාර්ගය.

මෙම පිටුව ප්‍රධාන වශයෙන් පහත පරිදි පාඨකයන් සඳහා යොමු කර ඇත:

• MySQL සමඟ ගැඹුරු පද්ධති සංවර්ධනය ආරම්භ කිරීමට නියමිත ඉංජිනේරුවන්
• පවත්නා වගු සැලසුම් සමාලෝචනය කිරීමට කැමති පසුබැසීම / යටිතල‑ආකෘති ඉංජිනේරුවන්
• “භාවිතා අවස්ථාව අනුව නිර්දේශිත වර්ග” අවශ්‍ය වන වෙබ් සංවර්ධකයින් සහ වැඩසටහන් ලේඛකයින්

අපි ප්‍රධාන MySQL දත්ත වර්ගයන් “ලැයිස්තුව” ලෙස වර්ගීකරණය කරමින් සංවිධානය කිරීමෙන් ආරම්භ කරමු. පසුව, ප්‍රධාන වර්ග—සංඛ්‍යාත්මක, ස්ට්‍රින්, දිනය/කාලය, JSON, ENUM/SET—වෙතින් ඒවායේ ලක්ෂණ, සාමාන්‍ය භාවිතා අවස්ථා, තේරීම් උපදෙස් ආදිය පැහැදිලි කරමු. අවසානයේ, පොදු නිර්මාණ දෝෂ සහ ඒවා වැලැක්වීමේ ක්‍රම, එමෙන්ම FAQ එකක් සමඟ සාරාංශ කරමු.

මෙය “පදනම් ලැයිස්තුව”ක් නොව, තීරු සැලසුම් සැකසීමේදී ඔබට ගැටළුවක් නොවීමට මඟ පෙන්වීමේ තීරණ‑ගැනීමේ මාර්ගෝපදේශයක් ලෙස සැකසෙයි. ඊළඟ කොටසෙහි, දත්ත වර්ග ගැන කෙසේ සිතිය යුතුද, වර්ගීකරණ ලැයිස්තුව සමාලෝචනය කරමු.

2. දත්ත වර්ගයක් කියන්නේ කුමක්ද, “නිවැරදි වර්ගය තෝරා ගැනීම” ඇයි වැදගත්?

දත්ත ගබඩාවක, “දත්ත වර්ගය” යනු තීරුවක් ගබඩා කළ හැකි අගයන්ගේ වර්ගය නියම කරන නීතියකි.
MySQL බොහෝ දත්ත වර්ග—සංඛ්‍යාත්මක, දශම, ස්ට්‍රින්, දිනය, බයිනරි, JSON, ආදිය—පිරිනමයි; ඔබේ අරමුණ අනුව නිවැරදිව තෝරා ගැනීම අවශ්‍ය වේ.

දත්ත වර්ගවල භූමිකාව

දත්ත වර්ගයක් “ආකෘති කාණ්ඩයක්” පමණක් නොවේ. එය එකවර බහු භූමිකා ඉටු කරයි:

• දත්ත වර්ගය සීමා කරයි (සංඛ්‍යාත්මක vs. ස්ට්‍රින්, බූලියන් ආදිය)
• අවසර දෙන පරාසය සහ අංක ගණන නියම කරයි
• අවශ්‍ය මතකය (ගබඩා ප්‍රමාණය) තීරණය කරයි
• ඉන්ඩෙක්ස් ව්‍යුහයන් සහ සෙවීමේ කාර්ය සාධනයට බලපායි
• අනුවාදන පරිවර්තන සහ සංසන්දන නීති (උදා: ස්ට්‍රින් සමානකරණය) මත බලපායි

සාරාංශයෙන්, දත්ත වර්ගයන් “කන්ටේනර්” පමණක් නොව, සම්පූර්ණ දත්ත කළමනාකරණ ජීවිත චක්‍රයම බලපාන මූලික නිර්මාණ තේරීම් වේ.

වැරදි වර්ගයක් තෝරාගත් විට සිදුවන්නේ කුමක්ද?

වැරදි දත්ත වර්ගයක් තෝරාගත් විට, වාස්තුකාර්මිකව පහත ගැටළු බොහෝවිට සිදුවේ:

• ගබඩා ඉඩ අතුරුදන් වීම

උදාහරණයක් ලෙස, BIGINT (8 බයිට්) ප්‍රමාණවත් වන තැන DECIMAL හෝ LONGTEXT භාවිතා කළහොත්, ඔබට අපේක්ෂිතයට වඩා බොහෝ තැටි ඉඩ ගත කරයි.

• විමසුම් මන්දගාමී වීම

විශාල TEXT තීරුවල LIKE සෙවීම් අධික ලෙස භාවිතා කිරීම, හෝ අති විශාල සංඛ්‍යාත්මක වර්ග තෝරා ගැනීම නිසා ඉන්ඩෙක්ස් විශාල වීම, SQL ක්‍රියාත්මක වේගය අඩුවීමට හේතු වේ.

• අසමත් අගයන් හෝ අතිරේකය (Overflow)

INT තුළ නොගැලපෙන අගයන් ගබඩා කිරීමෙන් අනපේක්ෂිත නෙගටීව් අග, වටාකාර කිරීම, හෝ වෙනත් ගැටළු උද्भව වේ.

• වගු වෙනස් කිරීමේ ඉහළ පිරිවැය

විශාල වගු වල වර්ග වෙනස් කිරීම (ALTER TABLE) කරද්දී පහත පරිදි ප්‍රතිඵල ලැබේ:

• දිගු කාලීන ලොක් කිරීම
• සේවා බලපෑම
• දත්ත මාරු කිරීමේ වැඩ සහ අනෙකුත් අවදානම්

ඔබ මුලින්ම අවබෝධ කරගත යුතු ප්‍රධාන කාණ්ඩයන්

MySQL දත්ත වර්ගයන් විශාල වශයෙන් පහත පරිදි වර්ගීකරණය කර ඇත:

• සංඛ්‍යාත්මක වර්ග (ඉන්ටීජර්, දශම)
• ස්ට්‍රින් වර්ග
• දිනය සහ කාල වර්ග
• බයිනරි වර්ග
• JSON වර්ග
• ENUM / SET වර්ග
• ස්පේෂල් දත්ත වර්ග

එක් එක් කාණ්ඩයට විවිධ වෙළඳගත්තු ඇත—ශක්තීන්/අඩුපාඩු, “ලාභ vs. බර,” සහ “සරල vs. අමාරු සෙවීම.” එබැවින් ඔබට අවශ්‍යයි එක් එක් භාවිතා අවස්ථාව සඳහා ඔප්ටිමම වර්ගය තෝරාගැනීම.

3. MySQL දත්ත වර්ග කාණ්ඩ (පිළිවෙල සාරාංශය)

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

3.1 සංඛ්‍යාත්මක වර්ග

සංඛ්‍යාත්මක වර්ග සියලුම සංඛ්‍යාත්මක සැකසුම්වල පදනම වන අතර, ඒවා ඇතුළත් වන්නේ සම්පූර්ණාංක, දශමස්ථ ගුණාංක, සහ ගුණාංක සංඛ්‍යා.
මෙම කාණ්ඩය ID වල, ප්‍රමාණවල, මිල ගණන්වල, සංඥා පරීක්ෂණවල, සහ බොහෝ වෙනත් අරමුණු සඳහා වඩාත් සංඥාකරණය වෙමින් භාවිතා වේ.

සම්පූර්ණාංක වර්ග

සටහන්

• UNSIGNED එකතු කිරීමෙන් ධනාත්මක පරාසය දෙගුණ වේ.
• INT බොහෝ අවස්ථාවල භාවිතා වේ, නමුත් BIGINT සුවිශේෂීව භාවිතා කිරීමෙන් සුචිකරණ වඩාත් බරපතල විය හැක.

දශමස්ථ / ගුණාංක වර්ග

සටහන්

• මුදල් සඳහා, DECIMAL එකම සාධාරණ තේරීම වේ. ගුණාංක වර්ග ( FLOAT / DOUBLE ) දෝෂ ඇතුළත් කළ හැක.
• බොහෝ ගණනය කිරීම් සම්බන්ධ අවස්ථාවල, වේගය/නිරවද්‍යතා වෙළඳගත්තු සඳහා DOUBLE තෝරාගැනීම සමහර විට සිදු වේ.

වෙනත් සංඛ්‍යාත්මක වර්ග

3.2 දිනය සහ වේලාව වර්ග

දිනය/වේලාව සැකසුම් යෙදුම සංවර්ධනයේදී ඉතා සංඥාකරණය වෙමින් භාවිතා වේ.
අරමුණ අනුව, “කාල කලාප හැසිරීම,” “ස්වයංක්‍රීය යාවත්කාලීන කිරීම්,” සහ “දෙවන මට්ටම් නිරවද්‍යතාව” වැනි සාධක වෙනස් වේ, එබැවින් නිවැරදි වර්ගය තෝරාගැනීම වැදගත් වේ.

සටහන්

• “යාවත්කාලීන කළ දිනය” ස්වයංක්‍රීයව කළමනාකරණය කිරීමට අවශ්‍ය නම්, TIMESTAMP පහසුය.
• “ලොග්” හෝ “ඉතිහාසය” සඳහා නිවැරදි කාල ස්ථිරාංක ගබඩා කිරීමට අවශ්‍ය නම්, DATETIME සාමාන්‍යයෙන් භාවිතා වේ.

3.3 සංක්‍රමණ / ද්විමය වර්ග

පරිශීලක නම්, ඊමේල්, මුරපද, විස්තර—සංක්‍රමණ බොහෝ විට වගු සැලසුම්වලදී වඩාත් සංකීර්ණ ප්‍රදේශය වේ.

ස්ථිර-දිග සංක්‍රමණ

විචල්‍ය-දිග සංක්‍රමණ

විශාල පාඨ (TEXT පවුල)

සටහන්

• ලිපි ශරීර හෝ දිගු විස්තර වැනි ඉතා විශාල සංක්‍රමණ ගබඩා කිරීමට අවශ්‍ය නම් TEXT භාවිතා කරන්න.
• සෙවීම සහ සුචිකරණ සැලසුම් සම්බන්ධයෙන් සැලකිලිමත් වන්න.

ද්විමය දත්ත (BINARY / BLOB)

※ සාමාන්‍යයෙන්, විශාල ගොනු දත්ත සමුදායකයේ ගබඩා නොකරනු ලැබේ; ඒවා බාහිර ගබඩාවක ගබඩා කිරීම බහුල සැලසුමකි.

ENUM / SET වර්ග (ගණනයන්)

සටහන්

• පසුව වර්ග නිර්වචනය වෙනස් කිරීමට අවශ්‍ය නම්, නඩත්තුව බරපතල වේ
• කුඩා-පරිමාණ, ස්ථිර අනුමති සඳහා එය ඵලදායී විය හැක

3.4 JSON වර්ග

• ඔබට NoSQL-වැනි නම්‍යශීලතාවක් ලැබෙන අතර JSON-විශේෂිත ශ්‍රියෝජනා භාවිතා කිරීමටද හැකිය.
• කෙසේ වෙතත්, බහුලව සෙවෙන දත්ත JSON තුළ ඇසුරුම් කිරීම නිර්දේශ නොකෙරේ . එය සමත් කළ හැකි නම්, එය ව්‍යුහගත වගු ලෙස ආකෘතිකරණය කළ යුතුය.

3.5 අවකාශ වර්ග

මෙමගින් භූගෝලීය සහ ස්ථාන දත්ත සම්බන්ධයෙන් වැඩ කිරීමේදී භාවිතා වේ.

සාමාන්‍ය වෙබ් යෙදුම්වලදී මෙමගින් බහුලව භාවිතා නොවේ, නමුත් සිතියම් යෙදුම් සහ GPS ඒකාබද්ධකරණ සඳහා ඒවා වැදගත් වේ.

4. එක් එක් දත්ත වර්ගය තෝරාගැනීම සහ භාවිතා කිරීම (ප්‍රධාන තීරණ ලක්ෂ්‍ය)

මෙම කොටසේදී, අපි ඉහත හඳුන්වා දුන් කාණ්ඩවල ගැඹුරට යමු, “ප්‍රායෝගික තත්ත්වයන්හි තෝරාගැනීමේ ක්‍රමය” කෙරෙහි අවධානය යොමු කරමින්.
නම් පමණක් දැනගැනීම ප්‍රමාණවත් නොවේ—වඩාත් ගැලපෙන දත්ත වර්ගය තෝරාගැනීම නඩත්තුකිරීම, කාර්ය සාධනය, සහ අනාගත පරිමාණය සඳහා සැලකිය යුතු බලපෑමක් ඇති කරයි.

4.1 සංඛ්‍යාත්මක වර්ග තෝරාගැනීමේ ක්‍රමය

සම්පූර්ණාංක වර්ග තෝරාගැනීමේ මානදණ්ඩ

සම්පූර්ණාංක වර්ග තෝරාගැනීමේදී, මෙම තුනේ කෙරෙහි අවධානය යොමු කරන්න:

1. අවශ්‍ය උපරිම පරාසය තේරුම් ගන්න

• කුඩා ගණන්කාරක → TINYINT
• නිෂ්පාදන ප්‍රමාණ / සංඥා → SMALLINT / INT
• විශාල-පරිමාණ ID හෝ ලොග් → BIGINT

කිලිඳි ව්‍යාපෘතිවල ප්‍රධාන යතුරු සඳහා BIGINT අධික භාවිතා කිරීම සිදු වේ, නමුත් මෙය සුචිකරණ ප්‍රමාණය වඩාත් විශාල කිරීමට ලේඛනය විය හැකි අතර කාර්ය සාධනයට ඍණාත්මක බලපෑමක් ඇති කළ හැක.

2. UNSIGNED සක්‍රීයව සලකන්න

If you only handle positive values (e.g., numeric IDs, inventory counts)
→ using UNSIGNED doubles the range and may allow you to use a smaller type.

3. මුදල් හෝ නිරවද්‍ය‑අවශ්‍ය අගයන් සඳහා, DECIMAL භාවිතා කරන්න

දෝෂ අනුමත නොවන අගයන් සඳහා, FLOAT/DOUBLE වලින් වැළකිලා සෑමවිටම DECIMAL භාවිතා කරන්න.

4.2 දිනය සහ වේලාව වර්ග තෝරා ගැනීම කෙසේද

සුදුසු වර්ගය ඔබේ භාවිතය මත පදනම් වේ.

DATETIME සහ TIMESTAMP අතර වෙනස්කම්

තෝරා ගැනීම සඳහා සාමාන්‍ය නීති

• යෙදුම් ලොග් හෝ සිදුවීම් වාර්තා → DATETIME (කාල කලාප පරිවර්තන බලපෑම් වලින් වැළකින්න)
• ඔබට ස්වයංක්‍රීයව යාවත්කාලීන කාල සටහන් ලියා ගැනීමට අවශ්‍ය නම් → TIMESTAMP (ආකර්ෂණීය ස්වයං‑යාවත්කාලීන හැසිරීම)

YEAR ප්‍රයෝජනවත් වන ස්ථාන

• මූල්‍ය වර්ෂ කාණ්ඩ, නිකුත් වර්ෂ, ආරම්භ වර්ෂ ආදිය → සංග්‍රහිතව කළමනාකරණය (1 බයිට්)

4.3 ස්ට්‍රින් වර්ග තෝරා ගැනීම කෙසේද

CHAR සහ VARCHAR අතර තීරණය කිරීම කෙසේද

ඔබ CHAR භාවිතා කළ යුතු අවස්ථා

• දිග සෑමවිටම ස්ථාවරයි: පළාත් කේත, රට කේත, ස්ථාවර‑දිග හැඳුනුම්පත් ආදිය.
• වේගවත් ප්‍රවේශය අවශ්‍ය වන සහ අඩුවෙන් යාවත්කාලීන වන දත්ත

ඔබ VARCHAR භාවිතා කළ යුතු අවස්ථා

• දිග වෙනස් වේ: නාම, විද්‍යුත් තැපැල් ලිපින, තේමා, ආදිය.
• බොහෝ අවස්ථා වල හොඳම පෙරනිමි තේරීම

TEXT භාවිතා කළ යුතුද?

TEXT හි වාසි

• විශාල පෙළ (විස්තර, ලිපි අන්තර්ගතය, ආදිය) සහය දක්වයි

TEXT සඳහා අවධානය

• සූචිකරණය සීමිතයි (ප්‍රතිඵල සූචිකරණ අවශ්‍ය වේ)
• JOIN හෝ WHERE වාක්‍යයන්හි භාවිතා කරන විට කාර්ය සාධනය අඩුවිය හැක
• සෙවීම සහ අනුක්‍රමණය බරපතළ විය හැක

උපදෙස්:
TEXT භාවිතා කරන්න “විශාල ස්ට්‍රින්” සඳහා, උදාහරණ ලෙස අන්තර්ගත හෝ සටහන්,
හා ඉතිරි සියලු දේ සඳහා VARCHAR හැකි තරම් භාවිතා කරන්න.

4.4 JSON වර්ග තෝරා ගැනීම කෙසේද

JSON වර්ගය ඉතා ප්‍රයෝජනවත් වේ, නමුත් ඔබ එය “නිවැරදිව” භාවිතා කළ යුතුය.

JSON හොඳින් ක්‍රියා කරන අවස්ථා

• ක්‍රමලේඛ සැකසුම් හෝ ක්ෂේත්‍ර ගණන වෙනස් වන දත්ත
• සීමිත සොයන භාවිතා, හෝ යෙදුම එය විස්තාරණ/විග්‍රහ කරන විට
• ප්‍රධාන වගුවක් අවශ්‍ය නොවන ලාංඡන දත්ත ගබඩා කිරීම

JSON අනුකූල නොවන අවස්ථා

• ඔබ නිතර සෙවීමට යොදා ගන්නා දත්ත
• පෙරහන් සෙවීම්, එකතු කිරීම, හෝ JOIN සඳහා භාවිතා කරන දත්ත
• සාමාන්‍යීකරණය කළ යුතු සංරචිත දත්ත

සාමාන්‍ය නියමය:
ඔබ සෙවීමට අවශ්‍ය දත්ත සාමාන්‍යීකරණය කර සංරචනය ලෙස සැලකිය යුතුය.
JSON “ලච්චිත නමුත් සෙවීමට දුර්වල” බව අමතක නොකරන්න.

4.5 ENUM / SET වර්ග තෝරා ගැනීම කෙසේද

ENUM යෝග්‍ය වන අවස්ථා

• තත්ත්වය ස්ථාවරයි: උදාහරණ ලෙස, තත්ත්වය (draft / published / archived)
• අඩු සංඛ්‍යාවක විකල්ප, අඩුවෙන් වෙනස් වන

ENUM සඳහා අවධානය

• අගයන් එකතු කිරීම හෝ වෙනස් කිරීම සඳහා ALTER TABLE අවශ්‍ය වේ
• යෙදුම්‑පාර්ශ්වයේ නිර්වචන සමඟ සමගාමීතාව අහිමි වීමේ අවදානම

SET යෝග්‍ය වන අවස්ථා

• බහු තේරීම අවශ්‍ය කුඩා පරිමාණ දත්ත (උදා: ලබාගත හැකි සතියේ දින, හෝ ටැග් විකල්ප කීපයක් පමණක් ඇති විට)

SET සඳහා අවධානය

• අගයන්ගේ සංයෝජන සංකීර්ණ විය හැක
• බහු‑අග තත්ත්ව කළමනාකරණය දුෂ්කර විය හැක

4.6 Binary / BLOB වර්ග තෝරා ගැනීම කෙසේද

BINARY / VARBINARY

• ටෝකන, ID, හෑෂ් අගයන්, ආදිය.
• ස්ථාවර‑දිග බයිනරි (උදා: 16‑බයිට් UUIDs)

BLOB වර්ග සඳහා සාමාන්‍ය භාවිතා අවස්ථා

• කුඩා ගොනු, තම්බ්නේල් රූප, සංකේතනය කළ දත්ත

නමුත් සලකන්න

• දත්ත ගබඩාවේ විශාල ගොනු ගබඩා කිරීමෙන් උපස්ථාපන (backup) බර වැඩි වේ
• කියවීම/ලියීමේ පූර්ණභාරයද වැඩි වේ → ප්‍රායෝගික පද්ධතිවල, බාහිර ගබඩා + මාර්ග කළමනාකරණය නිර්දේශිතයි

5. පුහුණුව: වගු නිර්මාණයේ “දත්ත වර්ග යොමු ලැයිස්තුව” භාවිතා කිරීම කෙසේද

මෙම කොටසේ, වගු නිර්මාණයේ MySQL දත්ත වර්ග ලැයිස්තුව ප්‍රායෝගික වැඩපිළිවෙළක් ලෙස භාවිතා කරන ආකාරය පැහැදිලි කරමු. වර්ගයන් මතක තබා ගැනීමට පමණක් නොව, “ඔබ එම වර්ගය තෝරා ගැනීමට හේතුව” තර්ක සහ පියවර මගින් සංවිධානය කිරීම උසස්‑තත්ත්වයේ දත්ත ගබඩා නිර්මාණයට හේතු වේ.

5.1 පියවර 1: තීරුවේ “අරමුණ” සහ “ස්වභාවය” පැහැදිලි කරන්න

පළමුව, තීරුවේ ගබඩා වන දේ පැහැදිලිව නියම කරන්න.

පරීක්ෂා ලැයිස්තුව

• එය සංඛ්‍යාත්මකද, පෙළද, දිනයද, නැතහොත් කොඩියක්ද?
• එය වෙනස්-දිගද නැතහොත් ස්ථිර-දිගද?
• උපරිම අගය හෝ උපරිම දිග කුමක්ද?
• NULL ඉඩ දිය යුතුද?
• ඉදිරියේදී එය වැඩි වීමට ඉඩ තිබේද?

ඔබ මෙහි අස්පෂ්ට අනුමාන සමඟ ඉදිරියට යනවා නම්, වර්ග තේරීම පසුකාලීනව අනිවාර්යයෙන්ම සංකීර්ණ වේ.

5.2 පියවර 2: අවශ්‍ය පරාසය සහ ආකෘතිය අනුමාන කරන්න

ඊළඟට, ඔබ ගබඩා කරන අගයන්ගේ ඉහළ/පහළ සීමා, අක්ෂර දිග, සහ අවශ්‍ය නිරවද්‍යතාව අනුමාන කරන්න.

උදාහරණය: ID තීරුව

• උපරිම රෙකෝඩ් ගණන දහස් මිලියන? සිය ගණන? → මෙය ඔබට INT ප්‍රමාණවත්ද, නැතහොත් BIGINT අවශ්‍යද යන්න තීරණය කිරීමට උපකාරී වේ.

උදාහරණය: නිෂ්පාදන නාමය

• සාමාන්‍යයෙන් 15–25 අක්ෂර, උපරිමය සुमාරූප 50? → VARCHAR(50) ප්‍රමාණවත් වේ. TEXT අවශ්‍ය නැත.

උදාහරණය: මිල

• නිරවද්‍යතාව අවශ්‍යද? → ඔබ DECIMAL(10,2) වැනි වර්ගයක් තෝරාගත යුතුය.

5.3 පියවර 3: දත්ත ප්‍රමාණය සහ කාර්ය සාධනය සලකා බලන්න

MySQL දත්ත වර්ග තේරීම සෘජුවම කාර්ය සාධනයට බලපායි.

ප්‍රධාන සලකුණු

• ඉතා විශාල වර්ග → ගබඩා භාවිතය වැඩි කරයි, සහ ඉන්ඩෙක්ස් බර වැඩි කරයි
• TEXT / BLOB → සෙවීමේ කාර්ය සාධනය අඩු කරයි
• JSON → සවිස්තරාත්මක නමුත් සෙවීමට දුර්වලයි
• TIMESTAMP → ස්වයංක්‍රීය යාවත්කාලීන සහ සංසන්දනය සඳහා කාර්යක්ෂමයි

විශේෂයෙන්, ඉන්ඩෙක්ස් ඇති තීරුවල ලාභදායී වර්ගය භාවිතා කළ යුතුය.

5.4 පියවර 4: නියැදි දත්ත සමඟ වර්ග වල සත්‍යාපනය කරන්න

වගුව නිර්මාණය කිරීමෙන් පසු, දස ගණනක සිට සිය ගණනක පරීක්ෂණ පේළි ඇතුළත් කර හැසිරීම තහවුරු කරන්න.

පරීක්ෂා කළ යුතු දේ

• අනිච්චිත වටාපිටු හෝ කප්පාදු ගැටළු තිබේද?
• VARCHAR ප්‍රමාණවත්ද, නැතහොත් TEXT විය යුතුද?
• දිනය-කාල සකස් කිරීම සහ සෙවීම අපේක්ෂිත ලෙස ක්‍රියා කරන්නේද?
• JSON කියවීම/ලියීමේ කාර්ය සාධනය

යථාර්ථ දත්ත සමඟ පරීක්ෂා කිරීම “තත්ත්වමය වැරදි” අඩු කරයි.

5.5 පියවර 5: විස්තාරණය සහ නඩත්තු හැකියාව සලකා බලන්න

වගුවේ අවසාන සැලසුම් අදියරේ, අනාගත වෙනස්කම් පහසුද යන්න පරීක්ෂා කරන්න.

බර වර්ග වෙනස්කම් උදාහරණ

• ENUM (අගයන් එකතු කිරීමේදී ALTER TABLE අවශ්‍ය වේ)
• TEXT → VARCHAR (විස්තාරණය පහසු, කුඩා කිරීම අවදානම්)
• FLOAT → DECIMAL (අර්ථය වෙනස් විය හැක)

අනාගත විස්තාරණය සිදුවීමට ඉඩ ඇතිද යන අධාරයෙන් වර්ග තෝරන්න.

5.6 පියවර 6: CREATE TABLE උදාහරණය (ප්‍රායෝගික නියැදි)

පහත දැක්වෙන්නේ සාමාන්‍ය වෙබ් යෙදුමක පොදු දත්ත වර්ග තේරීමේ ප්‍රමිතීන් පෙන්වන උදාහරණ වගුවකි.

CREATE TABLE products (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name         VARCHAR(100) NOT NULL,
    price        DECIMAL(10,2) NOT NULL,
    stock        INT UNSIGNED NOT NULL DEFAULT 0,
    status       ENUM('draft', 'published', 'archived') NOT NULL DEFAULT 'draft',
    description  TEXT,
    created_at   DATETIME NOT NULL,
    updated_at   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

මෙම උදාහරණයේ ප්‍රධාන කරුණු

• id : අනාගත පරිමාණය සලකා BIGINT UNSIGNED භාවිතා කරයි
• name : මධ්‍යම-දිග වෙනස්-පෙළ → VARCHAR
• price : මුදල් අගය → නිරවද්‍ය DECIMAL
• stock : තොග ගණන → INT UNSIGNED
• status : ස්ථිර අගයන් සමුහය → ENUM
• description : දිගු පෙළ විය හැක → TEXT
• updated_at : පහසු ස්වයංක්‍රීය යාවත්කාලීන TIMESTAMP

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

6. පොදු වැරදි සහ ඒවා වැලැක්වීමේ ක්‍රම

MySQL බොහෝ දත්ත වර්ග ලබා දෙන බැවින්, වාස්තුක ව්‍යාපෘතිවල බොහෝ පොදු වැරදි පෙනේ. මෙම කොටස සාමාන්‍ය ගැටළු පෙන්වා දී ප්‍රායෝගික විසඳුම් ලබා දෙයි.

6.1 අති විශාල දත්ත වර්ග භාවිතය

සාමාන්‍ය උදාහරණ

• සියලු ID BIGINT ලෙස සකස් කිරීම
• සෑම පෙළක්ම VARCHAR(255) ලෙස සකස් කිරීම
• නො-පෙළ අන්තර්ගතයට TEXT භාවිතා කිරීම

ගැටළු

• අතුරුදන් ගබඩා
• ඉන්ඩෙක්ස් විශාල වීමෙන් විමසුම් කාර්ය සාධනයට අඩුපාඩු
• ජාල පටිපාටිය අතුරුදන් වීම (විශාල දත්ත මාරු)

වැලැක්වීමේ ක්‍රම

• ඉදිරියේදී උපරිම සහ අවම වලංගු ප්‍රමාණයන් ඇස්තමේන්තු කරන්න
• සාක්ෂි මත පදනම්ව VARCHAR දිග සකසන්න
• ඇත්තටම අවශ්‍ය වන විට පමණක් TEXT භාවිතා කරන්න

6.2 දශම තුලනාත්මක වලංගු සඳහා FLOAT/DOUBLE භාවිතා කිරීම (නිරවද්‍යතා ගැටලු)

සුලබ උදාහරණ

• මිල ගණන් FLOAT ලෙස ගබඩා කිරීම
• වටාරුණු දෝෂ හේතුවෙන් සංඛ්‍යාත්මක සංසන්දන අසාර්ථක වීම

වළක්වා ගන්නේ කෙසේද

• මුදල් සහ නිරවද්‍යතා-මූලික වලංගු සඳහා DECIMAL භාවිතා කරන්න
• විද්‍යාත්මක හෝ තාවකාලික ගණනය කිරීම් හැර FLOAT / DOUBLE වළක්වන්න

6.3 අනවශ්‍ය වශයෙන් විශාල VARCHAR වර්ග

සුලබ උදාහරණ

• පෙරනිමි VARCHAR(255) භාවිතා කිරීම
• ආසන්න වශයෙන් 30 අක්ෂර පමණක් ගබඩා කරන වර්ග සඳහා විශාල දිග සකස් කිරීම

ගැටලු

• මතකය සහ ගබඩාව නාස්ති වීම
• සුචිකඩ බරපතල වීම

වළක්වා ගන්නේ කෙසේද

• සැබෑ දත්ත වලින් සාමාන්‍ය සහ උපරිම දිග ඇස්තමේන්තු කරන්න
• අනවශ්‍ය වශයෙන් විශාල ප්‍රමාණයන් වළක්වන්න (උදා: ඊමේල් ලිපින → VARCHAR(100) )

6.4 TEXT වර්ග අධික ලෙස භාවිතා කිරීම

සුලබ උදාහරණ

• “සංගුණක = TEXT” යන උපකල්පනය
• සෙවීම් හෝ පෙරාලීම් අවශ්‍ය දත්ත සඳහා TEXT භාවිතා කිරීම

ගැටලු

• බොහෝ සුචිකඩ සීමාවන්
• බරපතල LIKE සෙවීම්
• JOINs හි සැකසුම මන්දගාමී වීම

වළක්වා ගන්නේ කෙසේද

• විස්තරාත්මක අන්තර්ගතයන් වන විස්තර හෝ ශරීර සඳහා පමණක් TEXT භාවිතා කරන්න
• සෙවිය හැකි සංගුණක VARCHAR හි ගබඩා කරන්න ඕනෑම විට

6.5 ඒවායේ ගුණාංග නොදැනුවත්ව දින/කාල වර්ග තෝරා ගැනීම

සුලබ උදාහරණ

• සියල්ල සඳහා DATETIME භාවිතා කිරීම
• “අප්ඩේට් කළ” සඳහා DATETIME භාවිතා කිරීම, එය ස්වයංක්‍රීයව අප්ඩේට් නොවේ
• කාල කලාප වෙනස්කම් හේතුවෙන් කාල සීල් වෙනස් වීම

වළක්වා ගන්නේ කෙසේද

• ස්වයංක්‍රීය අප්ඩේට් අවශ්‍ය නම්: TIMESTAMP
• කාල කලාප වෙනස්කම් වළක්වා ගැනීමට අභිප්‍රේක්ෂා කරන්න: DATETIME
• වසර පමණක් අවශ්‍ය නම්: YEAR

6.6 ENUM / SET අනවශ්‍ය වශයෙන් භාවිතා කිරීම

සුලබ උදාහරණ

• අනාගතයේ විකල්ප වෙනස් විය හැකි වුවද ENUM භාවිතා කිරීම
• අන්තරා සංගුණක ලැයිස්තුවක් ලෙස SET භාවිතා කිරීම

ගැටලු

• වෙනස්කම් ALTER TABLE අවශ්‍ය වේ
• යෙදුම් පැත්තේ නිර්වචන සමඟ অসමගතතාව වැඩි විය හැක

වළක්වා ගන්නේ කෙසේද

• වලංගු වැඩි විය හැකි නම්, වෙනම ප්‍රධාන වගුවක ඒවා කළමනාකරණය කරන්න
• කුඩා සහ සැබෑවට ස්ථිර වූ සෙට් එකක් වන විට පමණක් ENUM භාවිතා කරන්න

6.7 JSON හි බොහෝ දේ ඇසුරුම් කිරීම “එය පහසු නිසා”

සුලබ උදාහරණ

• සාමාන්‍යකරණය කළ යුතු ව්‍යුහ JSON හි ඇසුරුම් කිරීම
• නිතිපතා සෙවෙන දත්ත JSON හි ගබඩා කිරීම

ගැටලු

• සෙවුම් කාර්ය සාධනය පහත වැටේ
• සුචිකඩ අඩු ඵලදායී / භාවිතා කිරීම අපහසු
• යෙදුම් පැත්තේ වැඩි පාර්සිං වැඩ
• ස්කීමා-රහිත නිර්මාණය ස්ථිරත්වය බිඳීම පහසු කරයි

වළක්වා ගන්නේ කෙසේද

• සෙවුම් නොකරන දත්ත සඳහා පමණක් JSON භාවිතා කරන්න
• එය “කුඩා, විචල්‍ය දත්ත” වන විට පමණක් සීමා කරන්න, උදා: සැකසුම්
• JOINs සහ සෙවීම් සඳහා භාවිතා වන තොරතුරු සාමාන්‍යකරණය කරන්න

6.8 වර්ග වෙනස්කම්වල පිරිවැය අවමන් කිරීම

ගැටලු

• ALTER TABLE විශාල වගුවල ඉතා බරපතල විය හැක
• සේවාව නිෂ්ක්‍රීය වීම හෝ දිගු ලොක් කාල සිදු විය හැක
• සමහර අවස්ථාවල දත්ත සංක්‍රමණය අවශ්‍ය වේ

වළක්වා ගන්නේ කෙසේද

• නිර්මාණ අදියරේදී අනාගත වර්ධනය සඳහා සැලසුම් කරන්න
• ENUM සැලකිල්ලෙන් භාවිතා කරන්න
• DECIMAL නිරවද්‍යතා/පරිමාණයේ ඉඩ තබන්න (නමුත් අධික නොකරන්න)

7. සාරාංශය

MySQL විවිධාකාර දත්ත වර්ග ලබා දෙයි, සහ ඔබ තෝරාගන්නා වර්ගය කාර්ය සාධනය, පරිමාණය, සහ නඩත්තු කිරීම මත සැලකිය යුතු බලපෑමක් ඇති කළ හැක.
විශේෂයෙන් වෙබ් යෙදුම් වැනි පරිසරවල දත්ත වර්ධනය වන අතර, මුල් නිර්මාණ තීරණ දිගුකාලීන ගුණාත්මකභාවය මත සෘජු බලපෑම් ඇති කරයි.

මෙම ලිපියේ ප්‍රධාන ඉගෙනුම්

• දත්ත වර්ග “වලංගු වර්ගය, පරාසය, නිරවද්‍යතාව, ගබඩාව, සහ කාර්ය සාධනය” බලපාන වැදගත් සාධක වේ.
• සංඛ්‍යාත්මක, සංගුණක, දින/කාල, JSON, ENUM/SET, සහ BLOB වර්ග එකිනෙකට ශක්තිමත් සහ දුර්වලතා ඇත.
• සම්ඛ්‍යා, සංගුණක, සහ දින/කාල වර්ග වඩාත් භාවිතා වේ, එබැවින් නිවැරදි තේරීම වැදගත්.
• JSON සහ ENUM පහසු වුවද, වැරදි භාවිතය නඩත්තුව අපහසු කරයි.
• TEXT සහ BLOB අධික භාවිතය කාර්ය සාධනය පහත වැටේ.
• තර්කානුකූල නිර්මාණ ප්‍රවේශය: “අරමුණ → පරාසය → කාර්ය සාධනය → පරිමාණය.”

අද සිට භාවිතා කළ හැකි නිර්මාණ පරීක්ෂා ලැයිස්තුව

• තීරුවේ අරමුණ පැහැදිලිව නිර්වචනය කර තිබේද?
• ඔබට උපරිම සහ අවම සම්භවිත අගයන් පිළිබඳ අවබෝධය තිබේද?
• තෝරාගත් VARCHAR දිග පිළිබඳ සාක්ෂි තිබේද?
• මුදල් සඳහා DECIMAL භාවිතා කරමින් සිටීද?
• “updated at” කාල සටහන් TIMESTAMP සහ අවශ්‍ය තැනේ ස්වයංක්‍රීය යාවත්කාලීන කිරීමෙන් කළමනාකරණය කර තිබේද?
• ENUM භාවිතා කිරීමට පෙර, අගයන් අනාගතයේදී වැඩි විය හැකිදැයි ඔබ සැලකිල්ලට ගත්තාද?
• JSON අධිකව භාවිතා කිරීමෙන් සෙවීම මන්දගාමී වන නිර්මාණ වලින් ඔබ වැළැක්වෙමින් සිටීද?
• විශාල දත්ත කට්ටලයන්හි බරපතළ ALTER TABLE මෙහෙයුම් වලින් වැළැක්වීමට ඔබ නිර්මාණය කර තිබේද?

Finally

MySQL දත්ත වර්ග තෝරා ගැනීමට සෑම විටම එකම “නිවැරදි පිළිතුර” නොමැත.
කෙසේ වෙතත්, ඔබ අරමුණ සහ අනාගත වර්ධනය සැලකිල්ලට ගෙන තෝරා ගන්නේ නම්, ප්‍රධාන ගැටළු වලින් වැළැක්විය හැකි අතර ඔබේ දත්ත ව්‍යුහය පිරිසිදුව තබා ගත හැක.

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

ඊළඟට, FAQ කොටස එකක් හඳුන්වා දෙනු ඇත, එය වාස්තුකාර්යයේ නිතර අසන ප්‍රශ්න සාරාංශ කරයි. ඔබට වර්ග තේරීම පිළිබඳ අසපසුනක් ඇත්නම්, මෙම FAQ පළමුව පරීක්ෂා කිරීම ඔබට තීරණය කිරීම පහසු කරයි.

8. FAQ

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

Q1. Should I use INT or BIGINT?

A: සාමාන්‍යයෙන් INT භාවිතා කරන්න. අනාගතයේ 2.1 බිලියන ඉක්මවා යා හැකි නම් පමණක් BIGINT භාවිතා කරන්න.

INT (බයිට් 4) සुमාරු 2.1 බිලියන දක්වා සහය දක්වයි, බොහෝ යෙදුම් සඳහා ප්‍රමාණවත් වේ. ලොග්, ඉහළ‑ට්‍රැෆික් සේවා, හෝ විශාල ID ගණනක් නිකුත් කළ හැකි පද්ධති සඳහා BIGINT ගැන සිතන්න.

Q2. Should I use VARCHAR or TEXT?

A: ඔබට සෙවීම අවශ්‍ය නම් VARCHAR භාවිතා කරන්න. දිගු අන්තර්ගත සඳහා TEXT භාවිතා කරන්න.

• VARCHAR : සූචිකරණයට සුහද සහ සෙවීම සඳහා වඩා හොඳ
• TEXT : දිගු අන්තර්ගත සඳහා හොඳ නමුත් සෙවීම හෝ JOIN සඳහා සුදුසු නොවේ

※ TEXT අධිකව භාවිතා කිරීමෙන් කාර්ය සාධන අඩු විය හැක.

Q3. Is it okay to store money as DOUBLE?

A: නැත. සෑමවිටම DECIMAL භාවිතා කරන්න.

DOUBLE සහ FLOAT වටාකාරක දෝෂ ඇති කරයි, එබැවින් මුදල් හෝ නිරවද්‍යතාවය අත්‍යවශ්‍ය අගයන් සඳහා සුදුසු නොවේ. ව්‍යාපාරික පද්ධතිවල, DECIMAL(10,2) හෝ DECIMAL(12,2) සාමාන්‍ය ප්‍රමිතියකි.

Q4. I don’t understand the difference between DATETIME and TIMESTAMP. How should I choose?

A: ඔබට ස්වයංක්‍රීය යාවත්කාලීන අවශ්‍ය නම් TIMESTAMP භාවිතා කරන්න. කාල කලාප පරිවර්තනය නොකළ නිරවද්‍ය කාල සටහන සුරැකීමට අවශ්‍ය නම් DATETIME භාවිතා කරන්න.

• TIMESTAMP : ස්වයංක්‍රීය යාවත්කාලීන සහ කාල කලාප පරිවර්තනය
• DATETIME : කාල කලාප වලින් බලපෑම නොලැබේ; දිනය/කාලය “ඇති පරිදි” සුරැකේ

DATETIME බොහෝවිට ලොග් සහ ඉතිහාස වගු සඳහා භාවිතා වේ.

Q5. Is it safe to use ENUM?

A: අගයන් “වෙනස් නොවන බව” සහතික වූ විට පමණක් එය ප්‍රයෝජනවත් වේ.

ENUM සුළු බර සහ පහසු, නමුත් අගයන් එකතු කිරීම හෝ වෙනස් කිරීම සඳහා ALTER TABLE අවශ්‍ය වේ. වර්ධනය විය හැකි ක්ෂේත්‍ර සඳහා, වෙනම වගුවක ප්‍රධාන කළමනාකරණය නිර්දේශ කරයි.

Q6. Can I just use JSON for now?

A: ඔබ සෙවීමට නොයැවූ දත්ත සඳහා පමණක් JSON භාවිතා කරන්න. සෙවීමට අවශ්‍ය දත්ත සාමාන්‍යීකරණය කළ යුතුය.

JSON සවිස්තරාත්මක වුවද, එයට කාර්ය සාධන දුර්වලතා ඇත.

• සෙවීමට දුර්වල
• සූචි ව්‍යුහයන් වැඩි සංකීර්ණ වේ
• දත්ත අඛණ්ඩතාවය රැක ගැනීම අධික වේ

එය සැකසුම් සහ විකල්ප සඳහා හොඳින් ක්‍රියා කරයි—සෙවීමේ කොන්දේසි ලෙස භාවිතා නොවන ගුණාංග.

Q7. How should I decide the maximum length for VARCHAR?

A: සැබෑ දත්ත මත පදනම්ව උපරිමය අනුමාන කර, සුළු අතිරේකයක් එක් කරන්න.

උදාහරණය: විද්‍යුත් තැපැල් ලිපිනය → VARCHAR(100) ප්‍රමාණවත්
උදාහරණය: පරිශීලක නාමය → VARCHAR(50) සාමාන්‍යයෙන් හොඳයි

“255” යන අංකය හේතුවක් නොමැතිව භාවිතා කිරීම නිර්දේශ නොවේ.

Q8. If I chose the wrong type, can I change it later?

A: ඔව්, නමුත් විශාල වගු වල එය බරපතළ විය හැක.

ALTER TABLE බොහෝවිට සම්පූර්ණ පරික්ෂණ සහ නැවත ගොඩනැගීමක් අඩංගු වේ, එය නතර කාලයක් හෝ දිගු ලොක් කාලයක් ඇති කරයි.

→ ආරම්භක නිර්මාණ අදියරේ සැලකිලිමත් සැලසුම් කිරීම ඉතා වැදගත්ය