വേർതിരിവ്
കോഡ് അല്ല, ഡാറ്റാബേസ് പാലിക്കുന്ന അതിർത്തി
എല്ലാ CRM-ഉം മൾട്ടി-ടെനന്റ് ആണെന്ന് അവകാശപ്പെടുന്നു. ആ അവകാശവാദം വിലകുറഞ്ഞതാണ്; പ്രധാനം ഏത് ലെയർ ആണ് അതിർത്തി പാലിക്കുന്നത് എന്നതാണ്. ഉത്തരം "ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ എപ്പോഴും ശരിയായ ഫിൽട്ടർ ചേർക്കുന്നു" എന്നാണെങ്കിൽ, ആ ഉറപ്പ് ഒരിക്കൽ ക്വറി എഴുതിയ ഏറ്റവും ഉറക്കമിളച്ച ഡെവലപ്പറുടെ നിലവാരം മാത്രമേ ഉള്ളൂ.
iKonekt പിന്നീട് ചേർത്തതല്ല, ആദ്യ മൈഗ്രേഷൻ മുതൽ തന്നെ മൾട്ടി-ടെനന്റ് ആയിരുന്നു, അത് ഒരു അഹങ്കാരം പോലെ തോന്നുമെങ്കിലും യഥാർത്ഥത്തിൽ ഒരു സമ്മതമാണ്: അത് പിന്നീട് ചേർക്കുന്നത് ബോധ്യപ്പെടുത്തുന്ന രീതിയിൽ ചെയ്യാൻ ഏകദേശം അസാധ്യമാണ്, ശ്രമിച്ച ഓരോരുത്തർക്കും ഒരു കഥയുണ്ട്.
വേർതിരിവ് ഡാറ്റാബേസിലാണ് ജീവിക്കുന്നത്. ഇരുപത്തിയാറ് ടേബിളുകളിൽ ഓരോന്നും അതിന്റേതായ ടെനന്റിനെ വഹിക്കുന്നു, അത് പരിശോധിക്കുന്ന പോളിസി ഓരോ വായനയിലും ഓരോ എഴുത്തിലും, ആപ്ലിക്കേഷന് പൂർണ്ണമായും താഴെ, പ്രവർത്തിക്കുന്നു. അതിർത്തി മറക്കുന്ന ഒരു ക്വറി മറ്റാരുടെയെങ്കിലും ഉപഭോക്താക്കളെ തിരികെ നൽകുന്നില്ല. അത് ഒന്നും തിരികെ നൽകുന്നില്ല.
റോ-ലെവൽ സെക്യൂരിറ്റി, നിർബന്ധിതം
ഒരു സമ്പ്രദായമല്ല, ഒരു കോഡ് റിവ്യൂ നിയമമല്ല. ഡാറ്റാബേസ് വിസമ്മതിക്കുന്നു. എഴുപത്തിരണ്ട് പോളിസികൾ, ജനറേറ്റ് ചെയ്തതിന് പകരം ഒന്നൊന്നായി എഴുതിയവ — കാരണം ജനറേറ്റ് ചെയ്ത ഒരു പോളിസി ആരും വായിച്ചിട്ടില്ലാത്ത ഒരു പോളിസിയാണ്.
കോമ്പോസിറ്റ് കീകൾ
ഒരു ചൈൽഡ് രേഖ അതിന്റെ ടെനന്റിനെ ഒപ്പം അതിന്റെ പാരന്റിനെയും, ഒരു ജോഡിയായി, റഫർ ചെയ്യുന്നു. തെറ്റായ കമ്പനിയിൽ നിന്നുള്ള ഒരു അലഞ്ഞ ഐഡന്റിഫയർ റെസോൾവ് ചെയ്യുന്നില്ല — അത് സാധുവായ ഒരു റഫറൻസ് അല്ല എന്ന് ലളിതമായി മാറുന്നു.
ഡീഫോൾട്ട് ടെനന്റ് ഇല്ല, ഒരിക്കലുമില്ല
ഒരു സ്കോപ്പ് ഇല്ലാത്ത ഒരു അഭ്യർത്ഥന ശാന്തമായി ടെനന്റ് സീറോയ്ക്കുള്ള അഭ്യർത്ഥനയായി മാറുന്നില്ല. അത് ഡാറ്റാബേസിൽ എത്തും മുമ്പേ ത്രോ ചെയ്യുന്നു. ഓഫാക്കാൻ മറക്കാവുന്ന "അൺസ്കോപ്പ്ഡ്" മോഡ് ഇല്ല.
സ്വയം പ്രഖ്യാപിക്കാൻ കഴിയാത്ത ബഗ്
ടെനൻസി ജോലി നടക്കുമ്പോൾ, മിക്ക തെറ്റുകളും ശബ്ദമുണ്ടാക്കുന്നവയായിരുന്നു. രണ്ട് കമ്പനികൾക്ക് ഒരേ ഉപഭോക്തൃ ഡൊമെയ്ൻ നൽകിയാൽ ഡാറ്റാബേസ് ഒബ്ജക്റ്റുകൾ ഉടനടി പിശക് കോഡും സ്റ്റാക്ക് ട്രേസും സഹിതം പ്രത്യക്ഷപ്പെടും; ഉച്ചയ്ക്ക് മുമ്പേ അത് തിരുത്താം.
ഒന്ന് എതിർത്തില്ല. എഡിറ്റ് ചെയ്യാവുന്ന പ്രോംപ്റ്റ് ഓവർറൈഡുകളുടെ ഒരു ടേബിൾ, പ്രോംപ്റ്റിന്റെ തരം മാത്രം അടിസ്ഥാനമാക്കി കീ ചെയ്യപ്പെട്ടിരുന്നു — തരം മാത്രമല്ല, ടെനന്റും ചേർന്നല്ല. രണ്ടാമത്തെ കമ്പനി അവരുടെ സ്വന്തം പകർപ്പ് എഡിറ്റ് ചെയ്യുമ്പോൾ, പൂർണ്ണമായും സാധുവായ SQL വഴി, ഒരു പിശകും മുന്നറിയിപ്പും പരാജയപ്പെട്ട ടെസ്റ്റുമില്ലാതെ ആദ്യ കമ്പനിയുടേത് ശാന്തമായി മാറ്റിമറിക്കപ്പെടുമായിരുന്നു. ശബ്ദമുണ്ടാക്കുന്നവയ്ക്ക് കൂട്ടുണ്ടാകുമെന്ന സംശയത്തിൽ, ഒരു കീ മാറ്റിയ ശേഷം ബാക്കിയുള്ള ഓരോ യൂണിക് ഇൻഡെക്സും ഒന്നൊന്നായി വായിച്ചപ്പോഴാണ് അത് കണ്ടെത്തിയത്.
ഇത് പറയുന്നത് ഇതാണ് ഈ ജോലിയുടെ സത്യസന്ധമായ രൂപം എന്നതുകൊണ്ടാണ്. വേർതിരിവ് ഓൺ ചെയ്യുന്ന ഒരു ഫീച്ചറല്ല; അതിലെവിടെയെങ്കിലും എന്തെങ്കിലും തന്നെ എതിർക്കുന്നുണ്ടെന്ന അനുമാനത്തോടെ സ്കീമയുടെ മടുപ്പിക്കുന്ന ഭാഗങ്ങൾ വായിക്കുന്ന ഒരു ശീലമാണത്.
രേഖക്കായി ടെസ്റ്റുകൾ: 942 എണ്ണം, ഓരോ മാറ്റത്തിലും പൂജ്യത്തിൽ നിന്ന് പുനർനിർമ്മിക്കുന്ന ഒരു ഡാറ്റാബേസിനെതിരെ പ്രവർത്തിക്കുന്നു. ഡിസൈൻ ബുദ്ധിമാനമാണെന്ന് തെളിയിക്കാനല്ല അവ ഉള്ളത്. ഈ പ്രത്യേക ഡിസൈനിന്റെ പരാജയ രീതി ശബ്ദരഹിതമാണ്, ശബ്ദരഹിത പരാജയങ്ങൾക്ക് വേണ്ടി ആരെങ്കിലും ഉറക്കെ വിളിക്കേണ്ടതുണ്ട് എന്നതുകൊണ്ടാണ് അവ ഉള്ളത്.
ഒരു സാധാരണ വ്യക്തിക്ക് വേർതിരിവ് നൽകുന്നത്
- ഒരു ഗ്രൂപ്പിന് ഒരു ഇൻസ്റ്റാളിൽ നിന്ന് നിരവധി കമ്പനികൾ നടത്താം, ഒരു കമ്പനിയിലെ വിൽപ്പനക്കാരന് മറ്റൊന്നിലെ ഉപഭോക്താവിനെ ഒരിക്കലും കാണാൻ കഴിയില്ല — നയം വഴിയല്ല, നിർമ്മാണം വഴി.
- ഒരു പങ്കാളി പ്രോഗ്രാം, ഒരു കൂട്ടം പ്രോംപ്റ്റുകൾ, ഒരു ഉപഭോക്താവിനുമേലുള്ള അവകാശം: എല്ലാം കമ്പനി തിരിച്ച് സ്കോപ്പ് ചെയ്യപ്പെട്ടിരിക്കുന്നു, അതിനാൽ ഒരു ടെനന്റിന്റെ കോൺഫിഗറേഷൻ എല്ലാവരുടേതുമാകാൻ പാടില്ല.
- ഒരു ഇല്ലാതാക്കൽ അഭ്യർത്ഥന പങ്കിട്ട ഒരു കൂമ്പാരത്തിലൂടെയല്ല, ഒരു അതിർത്തിക്കുള്ളിൽ വെച്ച് ബഹുമാനിക്കപ്പെടുന്നു, അതാണ് സത്യസന്ധമായി മറുപടി പറയാൻ കഴിയുന്നത്.
- ഒപ്പം ആരും അത് ഓർത്തിരിക്കേണ്ടതില്ല. അതാണ് കാര്യം — ഓർത്തിരിക്കേണ്ടതിനെ ആശ്രയിക്കുന്ന ഒരു ഉറപ്പ് ഉറപ്പല്ല.
ഡാറ്റാബേസുകളെക്കുറിച്ചല്ലാത്ത ഒരു വരി കൂടി
കുടുംബത്തിലെ ഓരോ സഹോദര സേവനവും അതിന്റേതായ പേരുള്ള ക്രെഡൻഷ്യൽ സൂക്ഷിക്കുന്നു. പങ്കിട്ട ഒന്നുമായി ഒന്നും സംസാരിക്കുന്നില്ല, അതിനാൽ ഒരു സേവനത്തിന് മറ്റൊന്നായി വേണ്ടതില്ലാതെ പ്രവർത്തിക്കാൻ കഴിയില്ല — ഒരിക്കൽ പങ്കിട്ട ടോക്കൺ ഉണ്ടായിരുന്നതും അത് ഇഷ്ടപ്പെടാതിരുന്നതും നേരിട്ട് ഉണ്ടായ ഒരു ചെറിയ ശീലമാണത്.
ഡാറ്റാബേസ് നിയമത്തിന്റെ അതേ വാസനയാണത്. തെറ്റായ കാര്യം നിരുത്സാഹപ്പെടുത്തുന്നതിനുപകരം അസാധ്യമാക്കുക, അപ്പോൾ ജാഗ്രതയിലല്ല, ഉപഭോക്താക്കളിലാണ് നിങ്ങളുടെ ശ്രദ്ധ ചെലവഴിക്കുന്നത്.
- 126 ടേബിളുകൾഓരോന്നും അതിന്റെ ടെനന്റിനെ വഹിക്കുന്നു, ചെക്ക് നിർബന്ധിതമായി ഓണാണ്.
- 272 പോളിസികൾഓരോന്നായി എഴുതിയിരിക്കുന്നു, അതിനാൽ ഓരോന്നും ഒരു വ്യക്തി വായിച്ചിട്ടുണ്ട്.
- 3942 ടെസ്റ്റുകൾഓരോ മാറ്റത്തിലും പൂജ്യത്തിൽ നിന്ന് പുനർനിർമ്മിക്കുന്ന ഡാറ്റാബേസിനെതിരെ.
- 40 ഡീഫോൾട്ട് ടെനന്റുകൾഒരു സ്കോപ്പില്ലാത്ത അഭ്യർത്ഥന ഒരിക്കലും ഡാറ്റയിൽ എത്തുന്നില്ല.
ലൈവ് ബിൽഡിൽ അളന്നത്

“ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ എപ്പോഴും കമ്പനി വഴി ഫിൽട്ടർ ചെയ്യുന്നു.”
ആ വാക്യത്തിൽ 'എപ്പോഴും' എന്ന വാക്ക് വഹിക്കുന്ന ഭാരം വളരെ വലുതാണ്.
അതിർത്തിയെ ഡാറ്റാബേസിലേക്ക് താഴ്ത്തുമ്പോൾ, മറന്ന ഒരു WHERE ക്ലോസ് മറ്റാരുടെയെങ്കിലും ഉപഭോക്താക്കളെ നൽകുന്നതിനുപകരം ഒന്നും നൽകില്ല. ഒരു ശൂന്യമായ സ്ക്രീൻ ഒരു അസൗകര്യപൂർണ്ണമായ പരിചയപ്പെടലിനേക്കാൾ നല്ല പരാജയമാണ്.
നിരവധി ബ്രാൻഡുകൾ നടത്തുന്ന ഗ്രൂപ്പുകൾക്കായി →