ഡേറ്റാബേസ് ഡിസൈൻ ചെയ്തിട്ടുള്ള കോമൺ മിഴികൾ

നിങ്ങൾ നൂറുകണക്കിന് രേഖകളോ ദശലക്ഷക്കണക്കിന് റെക്കോർഡുകളോ കൈവശം വച്ചിരിക്കുന്ന ഒരു ഡേറ്റാബേസിൽ പ്രവർത്തിച്ചാലും, ഡേറ്റാബേസ് ഡിസൈൻ എപ്പോഴും പ്രധാനമാണ്. വിവരങ്ങൾ വളരെ എളുപ്പത്തിൽ തിരിച്ചെടുക്കാൻ മാത്രമല്ല, ഭാവിയിൽ ഡാറ്റാബേസിനെ വിപുലീകരിക്കുന്നതും ഇത് എളുപ്പമാക്കും. നിർഭാഗ്യവശാൽ, ഭാവിയിൽ കാര്യങ്ങൾ ബുദ്ധിമുട്ടാക്കാൻ കഴിയുന്ന ചില കെണുകളിലേയ്ക്ക് എളുപ്പത്തിൽ എത്തിച്ചേരാം.

ഒരു ഡേറ്റാബേസ് ലളിതമാക്കുന്നതിന്റെ വിഷയത്തിൽ എഴുതപ്പെട്ട മുഴുവൻ പുസ്തകങ്ങളും ഉണ്ട്, എന്നാൽ നിങ്ങൾ ഈ സാധാരണ തെറ്റുകൾ ഒഴിവാക്കുകയാണെങ്കിൽ, നിങ്ങൾ നല്ല ഡാറ്റാബേസ് രൂപകൽപ്പനയ്ക്ക് ശരിയായ പാതയിലായിരിക്കും.

ഡാറ്റാബേസ് തെറ്റാണ് # 1: ഒരു പട്ടികയിൽ ആവർത്തിക്കുന്ന ഫീൽഡുകൾ

നല്ല ഡാറ്റാ ബേസ് ഡിസൈനിനുള്ള അടിസ്ഥാന മൂല്യം, ആവർത്തിച്ചുള്ള ഡാറ്റ തിരിച്ചറിഞ്ഞ് ആ പട്ടിക നിരത്തുന്നു. സ്പ്രെഡ്ഷീറ്റുകളുടെ ലോകത്തുനിന്ന് വരുന്നവർക്ക് ഒരു പട്ടികയിൽ ആവർത്തിക്കുന്ന ഫീൽഡുകൾ സാധാരണമാണ്, പക്ഷെ സ്പ്രെഡ്ഷീറ്റുകൾ ഡിസൈൻ കൊണ്ട് പരന്നതാണെങ്കിലും ഡാറ്റാബേസുകളെ ബന്ധപ്പെടുത്തണം. ഇത് 2D മുതൽ 3D വരെ പോകുന്നു.

ഭാഗ്യവശാൽ, ആവർത്തിക്കുന്ന വയലുകൾ സാധാരണയായി എളുപ്പത്തിൽ കണ്ടെത്താം. ഈ പട്ടിക കാണുക:

ഒരു ഓർഡറിൽ നാല് ഉൽപ്പന്നങ്ങൾ അടങ്ങിയിരിക്കുമ്പോൾ എന്തുസംഭവിക്കും? മൂന്നിൽ കൂടുതൽ ഉൽപ്പന്നങ്ങളെ പിന്തുണയ്ക്കുന്നതിനായി ഞങ്ങൾ മറ്റൊരു ഫീൽഡ് പട്ടികയിലേക്ക് ചേർക്കേണ്ടതാണ്. ഇൻപുട്ട് ഡാറ്റയ്ക്കായി ഞങ്ങളെ സഹായിക്കുന്നതിന് ഞങ്ങൾ ഒരു ക്ലയന്റ് ആപ്ലിക്കേഷൻ നിർമ്മിച്ചിട്ടുണ്ടെങ്കിൽ, പുതിയ പ്രൊഡക്ട് ഫീൽഡിൽ ഞങ്ങൾക്ക് ഇത് മാറ്റം വരുത്തേണ്ടതുണ്ട്. ക്രമപ്രകാരം ജല്ലിബാൻറെ എല്ലാ ഓർഡുകളും എങ്ങനെ കണ്ടെത്താം? പട്ടികയിൽ ഓരോ ഉൽപ്പന്ന ഫീൽഡിലും ഒരു ചോദ്യം ഉന്നയിക്കാൻ ഞങ്ങൾ നിർബന്ധിതരാകും. അത് കാണാവുന്ന ഒരു SQL സ്റ്റേറ്റ്മെന്റ്: SELECT * FROM PRODUCTS WHERE Product1 = 'ജെല്ലി ബീൻസ്' അല്ലെങ്കിൽ പ്രൊഡക്ട് 2 = 'ജെല്ലി ബീൻസ്' അല്ലെങ്കിൽ പ്രൊഡക്ട് 3 = 'ജെല്ലി ബീൻസ്'.

എല്ലാ വിവരവും ഒരുമിച്ചു ചേർക്കുന്ന ഒരു ടേബിളിന് പകരം, ഓരോന്നും വ്യത്യസ്തമായ ഒരു വിവരങ്ങൾ ഉൾക്കൊള്ളുന്ന മൂന്ന് പട്ടികകൾ നമുക്ക് ഉണ്ടായിരിക്കണം. ഈ ഉദാഹരണത്തിൽ, ഓർഡറുകളുടെ പട്ടികയുമായി ബന്ധപ്പെട്ട ഉൽപ്പന്നങ്ങളുമായി ഞങ്ങളുടെ ഉൽപ്പന്നങ്ങളെല്ലാം ഉൾപ്പെടുന്ന ഉൽപ്പന്ന ഉൽപന്നങ്ങളും ഉൽപ്പന്ന ഉൽപകർ ടാബ്ലറ്റുകളും ഒരു ഓർഡർ പട്ടികയിൽ ഉൾപ്പെടുത്തണം.

ഓരോ ടേബിളിന് അതിന്റേതായ തനതായ ID ഫീൽഡ് ഉള്ളത് എങ്ങനെയെന്ന് ശ്രദ്ധിക്കുക. ഇതാണ് പ്രാഥമിക കീ. മറ്റൊരു പട്ടികയിൽ ഒരു വിദേശ കീ ആയി ഒരു പ്രാഥമിക കീ മൂല്യം ഉപയോഗിച്ച് ഞങ്ങൾ പട്ടികകൾ ലിങ്കുചെയ്യുന്നു. പ്രാഥമിക കീ, വിദേശ കീകൾ എന്നിവയെക്കുറിച്ച് കൂടുതൽ വായിക്കുക.

ഡാറ്റാബേസ് പിഴവ് # 2: പട്ടികയിൽ ഒരു പട്ടിക ഉൾച്ചേർക്കുക

ഇതൊരു സാധാരണ തെറ്റ്, പക്ഷെ അത് എല്ലായ്പ്പോഴും ആവർത്തിക്കപ്പെടാത്ത വയലുകളിൽ നിന്നും ഉയർന്നു നിൽക്കുന്നില്ല. ഒരു ഡാറ്റാബേസ് ഉണ്ടാക്കുന്ന സമയത്ത്, ഒരു പട്ടികയിലെ എല്ലാ ഡാറ്റയും സ്വയം ബന്ധപ്പെടുത്തിയിട്ടുണ്ടെന്നുറപ്പാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു. കുട്ടിയുടെ കളി പോലെ മറ്റൊന്ന് എന്താണെന്നു കണ്ടെത്താനാകും. നിങ്ങൾക്ക് ഒരു വാഴ, ഒരു സ്ട്രോബെറി, ഒരു പീച്ച്, ഒരു ടെലിവിഷൻ സെറ്റ് എന്നിവ ഉണ്ടെങ്കിൽ, ടെലിവിഷൻ സെറ്റ് മറ്റെവിടെയോ ആണ്.

അതേ വരികളിലുടനീളം, നിങ്ങൾ വിൽപനക്കാരനായ ആളുകളുടെ പട്ടികയിൽ ഉണ്ടെങ്കിൽ, ആ പട്ടികയിലെ എല്ലാ വിവരങ്ങളും ആ സെയിൽസ് വ്യക്തിയുമായി പ്രത്യേകിച്ച് ബന്ധപ്പെട്ടതായിരിക്കണം. ആ വിൽപ്പന വ്യക്തിക്ക് അദ്വിതീയമല്ലാത്ത ഏതൊരു അധിക വിവരങ്ങളും നിങ്ങളുടെ ഡാറ്റാബേസിൽ മറ്റെവിടെയെങ്കിലും ചേർന്നേക്കാം.

ഈ പട്ടിക വ്യക്തിഗത വിൽപ്പനക്കാരനുമായി ബന്ധപ്പെട്ടതാണെന്ന് തോന്നിയേക്കാമെങ്കിലും, ഇതിന് പട്ടികയിൽ ഉൾച്ചേർത്ത ഒരു പട്ടികയുണ്ട്. ഓഫീസ്, ഓഫീസ് നമ്പര് എങ്ങനെയാണ് "ഓസ്റ്റിൻ ഡൌൗൺടൗണുമായി" ആവർത്തിക്കുന്നത് എങ്ങനെയെന്ന് നോക്കുക. ഓഫീസ് ഫോൺ നമ്പർ മാറുകയാണെങ്കിലോ? ഒരൊറ്റ വിവരം മാറ്റാൻ നിങ്ങൾ ഒരു ഡാറ്റ സെറ്റ് അപ്ഡേറ്റുചെയ്യേണ്ടതുണ്ട്, അത് ഒരിക്കലും നല്ല കാര്യമല്ല. ഈ ഫീൽഡുകൾ അവരുടെ സ്വന്തം പട്ടികയിൽ നീക്കിയിരിക്കണം.

ഇത്തരത്തിലുള്ള ഡിസൈൻ ഓഫീസ് ടേബിളിന് അധിക വിവരങ്ങൾ ചേർക്കുവാനുള്ള കഴിവു നൽകും കൂടാതെ സെയിൽസ് ടേബിൾ ടേബിളിൽ ഘടിപ്പിച്ച ഒരു പേടിസ്വപ്നം സൃഷ്ടിക്കാതെ തന്നെ. ആ വിവരങ്ങൾ സെയിൽസ് വ്യക്തിഗത പട്ടികയിൽ ഉണ്ടെങ്കിൽ സ്ട്രീറ്റ് വിലാസം, നഗരം, സംസ്ഥാനം, സിപ്പ് കോഡ് എന്നിവയുടെ ട്രാക്ക് സൂക്ഷിക്കാൻ എത്രമാത്രം പണി ഉണ്ടാവുമെന്ന് ആലോചിക്കുക!

ഡാറ്റാബേസ് തെറ്റ് # 3: ഒരു ഫീൽഡിൽ രണ്ടോ അതിലധികമോ വിവരങ്ങൾ സ്ഥാപിക്കുക

സെയിൽസ് വ്യക്തിഗത പട്ടികയിൽ ഓഫീസ് വിവരങ്ങൾ ഉൾച്ചേർക്കുന്നത് ആ ഡാറ്റാബേസിലുള്ള ഒരേയൊരു പ്രശ്നം മാത്രമായിരുന്നില്ല. വിലാസ മേഖലയിൽ മൂന്ന് വിവരങ്ങളാണ് ഉള്ളത്: സ്ട്രീറ്റ് വിലാസം, നഗരം, സംസ്ഥാനം. ഡാറ്റാബേസിലെ ഓരോ ഫീൽഡും ഒരൊറ്റ വിവരം മാത്രമേ അടങ്ങിയിട്ടുള്ളൂ. ഒരൊറ്റ ഫീൽഡിൽ നിങ്ങൾക്ക് ഒന്നിലധികം വിവരങ്ങൾ ഉണ്ടെങ്കിൽ, വിവരങ്ങൾക്കായി ഡാറ്റാബേസിനെ അന്വേഷിക്കാൻ കൂടുതൽ ബുദ്ധിമുട്ടാകും.

ഉദാഹരണത്തിന്, ഞങ്ങൾ ഓസ്റ്റിനിൽ നിന്നുള്ള എല്ലാ വിൽപനക്കാരുടേയും ഒരു ചോദ്യം നടത്താൻ ആഗ്രഹിക്കുകയാണെങ്കിൽ എന്തുചെയ്യും? ഞങ്ങൾക്ക് വിലാസ ഫീൽഡിൽ തിരയാൻ കഴിയും, അത് കാര്യക്ഷമമല്ല മാത്രമല്ല, തെറ്റായ വിവരങ്ങൾ നൽകാം. ഓറിഗോണിലെ പോർട്ട്ലാൻഡിൽ ഒരാൾ ഓസ്റ്റിൻ സ്ട്രീറ്റിൽ ജീവിച്ചിരുന്നെങ്കിൽ എന്തുസംഭവിക്കും?

പട്ടിക ഇതെങ്ങനെ ആയിരിക്കണം:

ഇവിടെ ശ്രദ്ധിക്കേണ്ട ചില കാര്യങ്ങൾ ഉണ്ട്. ഒന്നാമത്തേത്, "Address1", "Address2" എന്നിവ ആവർത്തിക്കപ്പെടാത്ത വയലുകളുടെ തെറ്റായി വരുന്നതായി തോന്നും.

എന്നിരുന്നാലും, ഈ സാഹചര്യത്തിൽ, അവരുടെ സ്വന്തം പട്ടികയിൽ പോകേണ്ട ആവർത്തിച്ചുവരുന്ന ഒരു കൂട്ടം ഗ്രൂപ്പുകളേക്കാളേറെ വിൽപന നടത്തുന്ന വ്യക്തിയെ നേരിട്ട് വിവരിക്കുന്ന ഡാറ്റയുടെ പ്രത്യേക ഭാഗങ്ങൾ അവർ സൂചിപ്പിക്കുന്നു.

കൂടാതെ, ഒഴിവാക്കാൻ ബോണസ് ചെയ്ത തെറ്റ്, ഫോൺ നമ്പറിനായി ഫോർമാറ്റിങ് എങ്ങനെ പട്ടികയിൽ നിന്നും ഒഴിവാക്കി എന്ന് ശ്രദ്ധിക്കുക. കഴിയുന്നത്ര വേഗത്തിൽ ഫീൽഡിന്റെ ഫോർമാറ്റ് സൂക്ഷിക്കുന്നത് ഒഴിവാക്കണം. ഫോൺ നമ്പറുകളുടെ കാര്യത്തിൽ, ആളുകളുടെ ഫോൺ നമ്പർ എഴുതുക: 215-555-5858 അല്ലെങ്കിൽ (215) 555-5858. ഇത് ഒരു സെലക്ട് വ്യക്തിയെ അവരുടെ ഫോൺ നമ്പറിലൂടെ അന്വേഷിക്കുകയോ അല്ലെങ്കിൽ ഒരേ സ്ഥലത്ത് വിൽപന നടത്തുന്നവരുടെ തിരച്ചിൽ നടത്തുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാക്കും.

ഡാറ്റാബേസ് പിഴവ് # 4: ശരിയായ പ്രാരംഭ കീ ഉപയോഗിച്ചിട്ടില്ല

മിക്കപ്പോഴും, നിങ്ങളുടെ പ്രാഥമിക കീയ്ക്കായി ഒരു യാന്ത്രിക ഇൻക്രിമെന്റുകളും സംഖ്യയും അല്ലെങ്കിൽ മറ്റ് ജനറേറ്റുചെയ്ത നമ്പറോ ആൽഫാന്യൂമെറിക് ഉപയോഗിക്കാം. പ്രാഥമിക കീയിൽ ഒരു യഥാർത്ഥ ഐഡന്റിഫയർ ഉണ്ടാക്കുന്നതായി തോന്നുകയാണെങ്കിൽ പോലും യഥാർത്ഥ വിവരങ്ങൾ ഉപയോഗിക്കുന്നത് ഒഴിവാക്കുക.

ഉദാഹരണത്തിന്, ഓരോരുത്തർക്കും ഞങ്ങളുടെ സ്വന്തം വ്യക്തിഗത സോഷ്യൽ സെക്യൂരിറ്റി നമ്പർ ഉണ്ട്, അതിനാൽ ഒരു ജീവനക്കാരുടെ ഡാറ്റാബേസിന് സോഷ്യൽ സെക്യൂരിറ്റി നമ്പർ ഉപയോഗിച്ച് ഒരു നല്ല ആശയം തോന്നാം. എന്നിരുന്നാലും അപൂർവ്വമായി, ഒരു സോഷ്യൽ സുരക്ഷാ നമ്പർ മാറ്റാൻ പോലും സാധ്യതയുണ്ട്, ഞങ്ങളുടെ പ്രാഥമിക കീ മാറ്റാൻ ഞങ്ങൾ ഒരിക്കലും ആഗ്രഹിക്കുന്നില്ല.

യഥാർത്ഥ വിവരങ്ങൾ ഒരു പ്രധാന മൂല്യമായി ഉപയോഗിക്കുന്നതിനുള്ള പ്രശ്നമാണിത്. അത് മാറ്റാൻ കഴിയും.

ഡാറ്റാബേസ് തെറ്റാണ് # 5: നാമകരണ കൺവെൻഷൻ ഉപയോഗിക്കുന്നില്ല

നിങ്ങൾ ആദ്യം നിങ്ങളുടെ ഡാറ്റാബേസ് രൂപകൽപന ചെയ്യാൻ തുടങ്ങുമ്പോഴേ ഇത് ഒരു വലിയ ഇടപാട് പോലെയല്ല, പക്ഷെ വിവരങ്ങളുടെ വിവരം ശേഖരിക്കാൻ ഡാറ്റാബേസിനു നേരെ അന്വേഷണത്തിന്റെ പോയിൻറിനായി, ഫീൽഡ് പേരുകൾ മനസിലാക്കുന്നതിനൊപ്പം ഒരു നാമകരണ കൺവെൻഷൻ സഹായിക്കും.

പേരുകൾ ഒന്നിലധികം പട്ടികയിൽ ഒന്നാമത്തേത്, Lastameame ഒരു table- ലും first_name, last_name- ലും ശേഖരിച്ചാൽ ആ പ്രക്രിയ എത്രമാത്രം ബുദ്ധിമുട്ടായിരിക്കും എന്ന് സങ്കൽപ്പിക്കുക.

രണ്ട് ജനപ്രിയ നാമധേയം കൺവെൻഷനുകൾ ഫീൽഡിൽ എല്ലാ പദത്തിന്റെയും ആദ്യത്തെ അക്ഷരമോ വാക്കുകളോ അടിവരയിട്ടാണ് ഉപയോഗിക്കുന്നത്. ആദ്യ വാക്കിനൊഴികെയുള്ള എല്ലാ വാക്കുകളുടേയും ആദ്യ അക്ഷരം മുതലെടുക്കുന്ന ചില ഡവലപ്പർമാരെയും നിങ്ങൾ കാണും: firstName, lastName.

ഒറ്റയൊറ്റ പട്ടിക നാമങ്ങളോ ബഹുവചനം പട്ടിക നാമങ്ങളോ ഉപയോഗിക്കേണ്ടതും തീരുമാനിക്കാം. ഇത് ഒരു ഓർഡർ പട്ടികയോ ഒരു ഓർഡറുകളുടെ പട്ടികയാണോ? ഇത് ഒരു ഉപഭോക്തൃ പട്ടികയോ കസ്റ്റമർമാരുടെ പട്ടികയാണോ? വീണ്ടും, നിങ്ങൾ ഒരു ഓർഡർ ടേബിൾ, ഒരു കസ്റ്റമർ ടേബിൾ എന്നിവ ഉപയോഗിച്ച് തഴയാൻ ആഗ്രഹിക്കുന്നില്ല.

നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന നാമകരണ കൺവെൻഷൻ യഥാർത്ഥത്തിൽ ഒരു നാമകരണ കൺവെൻഷനിൽ തെരഞ്ഞെടുക്കാനും ഉത്തേജിപ്പിക്കാനും ഉള്ള ഒരു പ്രക്രിയയല്ല.

ഡാറ്റാബേസ് പിഴവ് # 6: അനുചിതമായ സൂചിക

ഇന്ഡക്സിങ്ങ് ശരിയായത്, പ്രത്യേകിച്ച് ഡാറ്റാബേസ് ഡിസൈനില് പുതിയവയ്ക്ക് വേണ്ടി ഏറ്റവും പ്രയാസമേറിയ കാര്യങ്ങളിലൊന്നാണ്. എല്ലാ പ്രാഥമിക കീകളും വിദേശ കീകളും ഇൻഡെക്സ് ചെയ്യണം. ഇവയെല്ലാം തന്നെ ഒരുമിച്ച് ലിങ്ക് പട്ടികകളാണ്, അതിനാൽ ഒരു ഇൻഡെക്സ് ഇല്ലാതെ, നിങ്ങളുടെ ഡാറ്റാബേസിൽ നിന്നും വളരെ മോശം പ്രകടനം കാണും.

എന്നാൽ മറ്റു പല മേഖലകളും പലപ്പോഴും നഷ്ടപ്പെടും. ഇതാണ് "WHERE" ഫീൽഡുകൾ. നിങ്ങൾ WHERE ക്ലോസിൽ ഒരു ഫീൽഡ് ഉപയോഗിച്ച് നിങ്ങളുടെ തിരയൽ ചുരുക്കുകയാണെങ്കിൽ, ആ ഫീൽഡിൽ ഒരു ഇൻഡക്സ് നൽകുന്നത് സംബന്ധിച്ച് നിങ്ങൾ ചിന്തിക്കണം. എന്നിരുന്നാലും, പ്രകടനത്തെ ഉപദ്രവിക്കുന്നതും അത്യന്തം ഇൻഡെക്സ് ചെയ്യാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ല.

എങ്ങനെ തീരുമാനിക്കണം? ഇത് ഡാറ്റാബേസ് ഡിസൈനിന്റെ കലയാണ്. ഒരു പട്ടികയിൽ എത്ര ഇൻഡെക്സുകൾ ചേർക്കണം എന്നതിന് ഹാർഡ് പരിധിയൊന്നുമില്ല. പ്രാഥമികമായി, നിങ്ങൾ WHERE ക്ലോസസിൽ പതിവായി ഉപയോഗിക്കുന്ന ഒരു ഫീൽഡും ഇൻഡെക്സ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നു. നിങ്ങളുടെ ഡാറ്റാബേസ് ശരിയായി സൂചിപ്പിക്കുന്നതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കുക.