കീകളിൽ പേജിനേഷനായി നിങ്ങൾക്ക് ഉപകരണ പിന്തുണ ആവശ്യമായി വരുന്നത് എന്തുകൊണ്ട്?

എല്ലാവർക്കും ഹായ്! ഞാൻ Java + Spring-ൽ മൈക്രോ സർവീസുകൾ എഴുതുന്ന ഒരു ബാക്കെൻഡ് ഡെവലപ്പറാണ്. ടിങ്കോഫിലെ ആന്തരിക ഉൽപ്പന്ന വികസന ടീമുകളിലൊന്നിൽ ഞാൻ പ്രവർത്തിക്കുന്നു.

ഞങ്ങളുടെ ടീമിൽ, ഒരു DBMS-ൽ ചോദ്യങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനുള്ള ചോദ്യം പലപ്പോഴും ഉയർന്നുവരുന്നു. നിങ്ങൾ എപ്പോഴും അൽപ്പം വേഗത്തിലാകാൻ ആഗ്രഹിക്കുന്നു, എന്നാൽ ചിന്താപൂർവ്വം നിർമ്മിച്ച സൂചികകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും എത്തിച്ചേരാനാകില്ല-നിങ്ങൾ ചില പരിഹാരങ്ങൾക്കായി നോക്കേണ്ടതുണ്ട്. ഡാറ്റാബേസുകളിൽ പ്രവർത്തിക്കുമ്പോൾ ന്യായമായ ഒപ്റ്റിമൈസേഷനുകൾക്കായി വെബിൽ ചുറ്റിത്തിരിയുന്ന ഇവയിലൊന്നിൽ, ഞാൻ കണ്ടെത്തി Marcus Wynand ൻ്റെ അനന്തമായ സഹായകരമായ ബ്ലോഗ്, SQL പ്രകടനത്തിൻ്റെ രചയിതാവ് വിശദീകരിച്ചു. നിങ്ങൾക്ക് എല്ലാ ലേഖനങ്ങളും തുടർച്ചയായി വായിക്കാൻ കഴിയുന്ന അപൂർവ തരം ബ്ലോഗാണിത്.

മർകസിൻ്റെ ഒരു ചെറിയ ലേഖനം നിങ്ങൾക്കായി വിവർത്തനം ചെയ്യാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. എസ്‌ക്യുഎൽ സ്റ്റാൻഡേർഡ് അനുസരിച്ച് ഓഫ്‌സെറ്റ് പ്രവർത്തനത്തിൻ്റെ പ്രകടനത്തിൻ്റെ പഴയതും എന്നാൽ ഇപ്പോഴും പ്രസക്തവുമായ പ്രശ്‌നത്തിലേക്ക് ശ്രദ്ധ ആകർഷിക്കാൻ ശ്രമിക്കുന്ന ഒരു മാനിഫെസ്റ്റോ എന്ന് ഇതിനെ ഒരു പരിധിവരെ വിളിക്കാം.

ചില സ്ഥലങ്ങളിൽ ഞാൻ രചയിതാവിനെ വിശദീകരണങ്ങളും അഭിപ്രായങ്ങളും സപ്ലിമെൻ്റ് ചെയ്യും. അത്തരം എല്ലാ സ്ഥലങ്ങളെയും ഞാൻ "ഏകദേശം" എന്ന് പരാമർശിക്കും. കൂടുതൽ വ്യക്തതയ്ക്കായി

ചെറിയ ആമുഖം

ഓഫ്‌സെറ്റ് മുഖേനയുള്ള പേജ് സെലക്ട്‌സ് ഉപയോഗിച്ച് എത്രത്തോളം പ്രശ്‌നകരവും മന്ദഗതിയിലുള്ള പ്രവർത്തനവുമാണെന്ന് പലർക്കും അറിയാമെന്ന് ഞാൻ കരുതുന്നു. കൂടുതൽ കാര്യക്ഷമമായ ഡിസൈൻ ഉപയോഗിച്ച് ഇത് വളരെ എളുപ്പത്തിൽ മാറ്റിസ്ഥാപിക്കാമെന്ന് നിങ്ങൾക്കറിയാമോ?

അതിനാൽ, ഓഫ്‌സെറ്റ് കീവേഡ്, അഭ്യർത്ഥനയിലെ ആദ്യത്തെ n റെക്കോർഡുകൾ ഒഴിവാക്കാൻ ഡാറ്റാബേസിനോട് പറയുന്നു. എന്നിരുന്നാലും, ഡാറ്റാബേസിന് ഇപ്പോഴും ഈ ആദ്യ n റെക്കോർഡുകൾ ഡിസ്കിൽ നിന്ന്, തന്നിരിക്കുന്ന ക്രമത്തിൽ വായിക്കേണ്ടതുണ്ട് (ശ്രദ്ധിക്കുക: അത് വ്യക്തമാക്കിയിട്ടുണ്ടെങ്കിൽ സോർട്ടിംഗ് പ്രയോഗിക്കുക), അതിനുശേഷം മാത്രമേ n+1 മുതലുള്ള റെക്കോർഡുകൾ തിരികെ നൽകാൻ കഴിയൂ. ഏറ്റവും രസകരമായ കാര്യം, പ്രശ്നം ഡിബിഎംഎസിലെ നിർദ്ദിഷ്ട നിർവ്വഹണത്തിലല്ല, മറിച്ച് സ്റ്റാൻഡേർഡ് അനുസരിച്ച് യഥാർത്ഥ നിർവചനത്തിലാണ്:

… വരികൾ ആദ്യം അനുസരിച്ചാണ് അടുക്കുന്നത് എന്നതിൽ വ്യക്തമാക്കിയ വരികളുടെ എണ്ണം ഒഴിവാക്കി പരിമിതപ്പെടുത്തുന്നു തുടക്കം മുതൽ…
-SQL:2016, ഭാഗം 2, 4.15.3 ഉരുത്തിരിഞ്ഞ പട്ടികകൾ (ശ്രദ്ധിക്കുക: നിലവിൽ ഏറ്റവും കൂടുതൽ ഉപയോഗിക്കുന്ന സ്റ്റാൻഡേർഡ്)

ഓഫ്‌സെറ്റിന് ഒരൊറ്റ പാരാമീറ്റർ എടുക്കുന്നു എന്നതാണ് ഇവിടെ പ്രധാന കാര്യം - ഒഴിവാക്കേണ്ട റെക്കോർഡുകളുടെ എണ്ണം, അത്രമാത്രം. ഈ നിർവ്വചനം പിന്തുടർന്ന്, DBMS-ന് എല്ലാ രേഖകളും വീണ്ടെടുക്കാനും തുടർന്ന് അനാവശ്യമായവ ഉപേക്ഷിക്കാനും മാത്രമേ കഴിയൂ. വ്യക്തമായും, ഓഫ്‌സെറ്റിൻ്റെ ഈ നിർവചനം അധിക ജോലി ചെയ്യാൻ നമ്മെ പ്രേരിപ്പിക്കുന്നു. അത് SQL ആണോ NoSQL ആണോ എന്നത് പോലും പ്രശ്നമല്ല.

കുറച്ചു കൂടി വേദന മാത്രം

ഓഫ്‌സെറ്റിലെ പ്രശ്‌നങ്ങൾ അവിടെ അവസാനിക്കുന്നില്ല, എന്തുകൊണ്ടാണിത്. ഡിസ്കിൽ നിന്നുള്ള ഡാറ്റയുടെ രണ്ട് പേജുകൾ വായിക്കുന്നതിനിടയിൽ, മറ്റൊരു പ്രവർത്തനം ഒരു പുതിയ റെക്കോർഡ് ചേർക്കുകയാണെങ്കിൽ, ഈ സാഹചര്യത്തിൽ എന്ത് സംഭവിക്കും?

മുൻ പേജുകളിൽ നിന്നുള്ള റെക്കോർഡുകൾ ഒഴിവാക്കാൻ ഓഫ്‌സെറ്റ് ഉപയോഗിക്കുമ്പോൾ, വ്യത്യസ്ത പേജുകളുടെ വായനകൾക്കിടയിൽ ഒരു പുതിയ റെക്കോർഡ് ചേർക്കുന്ന സാഹചര്യത്തിൽ, നിങ്ങൾക്ക് മിക്കവാറും ഡ്യൂപ്ലിക്കേറ്റുകൾ ലഭിക്കും (ശ്രദ്ധിക്കുക: നിർമ്മാണം വഴി ക്രമം ഉപയോഗിച്ച് പേജ് പേജ് വായിക്കുമ്പോൾ ഇത് സാധ്യമാണ്, തുടർന്ന് ഞങ്ങളുടെ ഔട്ട്‌പുട്ടിൻ്റെ മധ്യത്തിൽ അതിന് ഒരു പുതിയ എൻട്രി ലഭിച്ചേക്കാം).

ചിത്രം ഈ അവസ്ഥയെ വ്യക്തമായി ചിത്രീകരിക്കുന്നു. അടിസ്ഥാനം ആദ്യത്തെ 10 റെക്കോർഡുകൾ വായിക്കുന്നു, അതിനുശേഷം ഒരു പുതിയ റെക്കോർഡ് ചേർക്കുന്നു, അത് എല്ലാ റീഡ് റെക്കോർഡുകളെയും 1 കൊണ്ട് ഓഫ്‌സെറ്റ് ചെയ്യുന്നു. തുടർന്ന് അടിസ്ഥാനം അടുത്ത 10 റെക്കോർഡുകളിൽ നിന്ന് ഒരു പുതിയ പേജ് എടുക്കുകയും 11-ാം തീയതി മുതൽ ആരംഭിക്കുകയും ചെയ്യേണ്ടതില്ല, മറിച്ച് 10-ാമത്, ഈ റെക്കോർഡ് ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യുന്നു. ഈ പദപ്രയോഗത്തിൻ്റെ ഉപയോഗവുമായി ബന്ധപ്പെട്ട മറ്റ് അപാകതകൾ ഉണ്ട്, എന്നാൽ ഇത് ഏറ്റവും സാധാരണമാണ്.

ഞങ്ങൾ ഇതിനകം കണ്ടെത്തിയതുപോലെ, ഇവ ഒരു പ്രത്യേക ഡിബിഎംഎസിൻ്റെയോ അവയുടെ നടപ്പാക്കലുകളുടെയോ പ്രശ്നങ്ങളല്ല. SQL സ്റ്റാൻഡേർഡ് അനുസരിച്ച് പേജിനേഷൻ നിർവചിക്കുന്നതിലാണ് പ്രശ്നം. ഏത് പേജ് എടുക്കണം അല്ലെങ്കിൽ എത്ര റെക്കോർഡുകൾ ഒഴിവാക്കണം എന്ന് ഞങ്ങൾ DBMS-നോട് പറയുന്നു. ഡാറ്റാബേസിന് അത്തരമൊരു അഭ്യർത്ഥന ഒപ്റ്റിമൈസ് ചെയ്യാൻ കഴിയില്ല, കാരണം ഇതിന് വളരെ കുറച്ച് വിവരങ്ങൾ മാത്രമേ ഉള്ളൂ.

ഇത് ഒരു നിർദ്ദിഷ്ട കീവേഡിൻ്റെ പ്രശ്‌നമല്ല, മറിച്ച് അന്വേഷണത്തിൻ്റെ സെമാൻ്റിക്‌സിൻ്റെ പ്രശ്‌നമാണെന്ന് വ്യക്തമാക്കുന്നത് മൂല്യവത്താണ്. പ്രശ്നകരമായ സ്വഭാവത്തിൽ സമാനമായ നിരവധി വാക്യഘടനകൾ കൂടിയുണ്ട്:

• ഓഫ്‌സെറ്റ് കീവേഡ് നേരത്തെ സൂചിപ്പിച്ചതാണ്.
• രണ്ട് കീവേഡുകളുടെ നിർമ്മാണം പരിധി [ഓഫ്സെറ്റ്] (പരിധി അത്ര മോശമല്ലെങ്കിലും).
• വരി നമ്പറിംഗ് (ഉദാഹരണത്തിന്, row_number(), rownum, മുതലായവ) അടിസ്ഥാനമാക്കി താഴത്തെ അതിരുകൾ ഉപയോഗിച്ച് ഫിൽട്ടർ ചെയ്യുന്നു.

ഈ എക്‌സ്‌പ്രഷനുകളെല്ലാം എത്ര വരികൾ ഒഴിവാക്കണം, അധിക വിവരങ്ങളോ സന്ദർഭങ്ങളോ ഒന്നുമില്ല.

ഈ ലേഖനത്തിൽ പിന്നീട്, ഈ എല്ലാ ഓപ്ഷനുകളുടെയും സംഗ്രഹമായി ഓഫ്‌സെറ്റ് കീവേഡ് ഉപയോഗിക്കുന്നു.

OFFSET ഇല്ലാത്ത ജീവിതം

ഈ പ്രശ്‌നങ്ങളൊന്നുമില്ലാതെ നമ്മുടെ ലോകം എങ്ങനെയായിരിക്കുമെന്ന് ഇപ്പോൾ നമുക്ക് ഊഹിക്കാം. ഓഫ്‌സെറ്റ് ഇല്ലാത്ത ജീവിതം അത്ര ബുദ്ധിമുട്ടുള്ള കാര്യമല്ലെന്ന് ഇത് മാറുന്നു: ഒരു തിരഞ്ഞെടുത്തത് ഉപയോഗിച്ച്, ഞങ്ങൾ ഇതുവരെ കണ്ടിട്ടില്ലാത്ത വരികൾ മാത്രമേ നിങ്ങൾക്ക് തിരഞ്ഞെടുക്കാനാകൂ (ശ്രദ്ധിക്കുക: അതായത്, മുമ്പത്തെ പേജിൽ ഇല്ലാത്തവ), എവിടെ എന്ന അവസ്ഥ ഉപയോഗിച്ച്.

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

    SELECT ...
    FROM ...
    WHERE ...
    AND id < ?last_seen_id
    ORDER BY id DESC
    FETCH FIRST 10 ROWS ONLY

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

ഈ സമീപനത്തെ തിരയൽ രീതി അല്ലെങ്കിൽ കീസെറ്റ് പേജിനേഷൻ എന്ന് വിളിക്കുന്നു. ഇത് ഫ്ലോട്ടിംഗ് റിസൾട്ട് പ്രശ്നം പരിഹരിക്കുന്നു (ശ്രദ്ധിക്കുക: പേജ് റീഡുകൾക്കിടയിൽ എഴുതുന്ന സാഹചര്യം, നേരത്തെ വിവരിച്ചത്) കൂടാതെ, തീർച്ചയായും, നമ്മൾ എല്ലാവരും ഇഷ്ടപ്പെടുന്നത്, ക്ലാസിക് ഓഫ്‌സെറ്റിനേക്കാൾ വേഗത്തിലും സ്ഥിരതയിലും ഇത് പ്രവർത്തിക്കുന്നു. അഭ്യർത്ഥന പ്രോസസ്സിംഗ് സമയം അഭ്യർത്ഥിച്ച പട്ടികയുടെ എണ്ണത്തിന് ആനുപാതികമായി വർദ്ധിക്കുന്നില്ല എന്ന വസ്തുതയിലാണ് സ്ഥിരത സ്ഥിതിചെയ്യുന്നത് (ശ്രദ്ധിക്കുക: പേജിനേഷനിലേക്കുള്ള വ്യത്യസ്ത സമീപനങ്ങളുടെ പ്രവർത്തനത്തെക്കുറിച്ച് കൂടുതലറിയാൻ നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് കഴിയും രചയിതാവിൻ്റെ അവതരണത്തിലൂടെ നോക്കുക. വ്യത്യസ്ത രീതികൾക്കായുള്ള താരതമ്യ മാനദണ്ഡങ്ങളും നിങ്ങൾക്ക് അവിടെ കണ്ടെത്താനാകും).

സ്ലൈഡുകളിൽ ഒന്ന് അതിനെക്കുറിച്ച് സംസാരിക്കുന്നുകീകൾ ഉപയോഗിച്ചുള്ള പേജിനേഷൻ തീർച്ചയായും സർവ്വശക്തമല്ല - അതിന് അതിൻ്റേതായ പരിമിതികളുണ്ട്. റാൻഡം പേജുകൾ വായിക്കാനുള്ള കഴിവ് അവൾക്കില്ല എന്നതാണ് ഏറ്റവും പ്രധാനം (ശ്രദ്ധിക്കുക: പൊരുത്തമില്ലാതെ). എന്നിരുന്നാലും, അനന്തമായ സ്ക്രോളിംഗ് കാലഘട്ടത്തിൽ (ശ്രദ്ധിക്കുക: മുൻവശത്ത്), ഇത് അത്തരമൊരു പ്രശ്നമല്ല. ക്ലിക്കുചെയ്യുന്നതിനായി ഒരു പേജ് നമ്പർ വ്യക്തമാക്കുന്നത് എന്തായാലും UI രൂപകൽപ്പനയിൽ ഒരു മോശം തീരുമാനമാണ് (ശ്രദ്ധിക്കുക: ലേഖനത്തിൻ്റെ രചയിതാവിൻ്റെ അഭിപ്രായം).

ഉപകരണങ്ങളുടെ കാര്യമോ?

ഈ രീതിക്ക് ഇൻസ്ട്രുമെൻ്റൽ പിന്തുണയുടെ അഭാവം കാരണം കീകളിലെ പേജിനേഷൻ പലപ്പോഴും അനുയോജ്യമല്ല. വിവിധ ചട്ടക്കൂടുകൾ ഉൾപ്പെടെയുള്ള മിക്ക വികസന ഉപകരണങ്ങളും, പേജിനേഷൻ എങ്ങനെ നിർവഹിക്കണമെന്ന് കൃത്യമായി തിരഞ്ഞെടുക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നില്ല.

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

എന്നിരുന്നാലും, കീകളിൽ പേജിനേഷനെ പിന്തുണയ്ക്കുന്ന ചട്ടക്കൂടുകളുടെ എണ്ണം ക്രമേണ വളരുകയാണ്. ഞങ്ങൾക്ക് ഇപ്പോൾ ഉള്ളത് ഇതാ:

• jOOQ ജാവയ്ക്ക്;
• ഓർഡർ_ചോദ്യം റൂബിക്ക്;
• ചുങ്കക്കാരൻ и ജാംഗോ അനന്ത സ്ക്രോൾ പേജിനേഷൻ ജാങ്കോയ്ക്ക് വേണ്ടി;
• SQL ആൽക്കെമി sqlakeyset പൈത്തണിന്;
• ജ്വലനം-സ്ഥിരത - ജെപിഎ നടപ്പാക്കലുകൾക്കുള്ള API മാനദണ്ഡം;
• DBIx:: ക്ലാസ്:: റാപ്പർ പേളിന്;
• Massive.js, Node.js നായുള്ള മാപ്പർ കീസെറ്റ് ഡോക്യുമെൻ്റേഷൻ.

(ശ്രദ്ധിക്കുക: വിവർത്തന സമയത്ത് ചില ലൈബ്രറികൾ 2017-2018 മുതൽ അപ്‌ഡേറ്റ് ചെയ്തിട്ടില്ലാത്തതിനാൽ ചില ലിങ്കുകൾ നീക്കം ചെയ്‌തു. നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, യഥാർത്ഥ ഉറവിടം നോക്കാവുന്നതാണ്.)

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

കീകൾ മുഖേനയുള്ള പേജിനേഷനുള്ള പിന്തുണ ലഭിക്കുന്നതിന് യോഗ്യമാണെന്ന് നിങ്ങൾ കരുതുന്ന റെഡിമെയ്ഡ് സൊല്യൂഷനുകൾ നിങ്ങൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, ഒരു അഭ്യർത്ഥന സൃഷ്ടിക്കുക അല്ലെങ്കിൽ സാധ്യമെങ്കിൽ ഒരു റെഡിമെയ്ഡ് പരിഹാരം വാഗ്ദാനം ചെയ്യുക. നിങ്ങൾക്ക് ഈ ലേഖനത്തിലേക്ക് ലിങ്ക് ചെയ്യാനും കഴിയും.

തീരുമാനം

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

തൽഫലമായി, പേജിനേഷനിലേക്കുള്ള സമീപനം മാറ്റുന്നതിനെക്കുറിച്ച് കുറച്ച് ആളുകൾ ചിന്തിക്കുന്നു, ഇക്കാരണത്താൽ, ചട്ടക്കൂടുകളിൽ നിന്നും ലൈബ്രറികളിൽ നിന്നുമുള്ള ഉപകരണ പിന്തുണ മോശമായി വികസിക്കുന്നു. അതിനാൽ, ഓഫ്‌സെറ്റ് രഹിത പേജിനേഷൻ്റെ ആശയവും ലക്ഷ്യവും നിങ്ങൾക്ക് അടുത്താണെങ്കിൽ, അത് പ്രചരിപ്പിക്കാൻ സഹായിക്കൂ!

അവലംബം: https://use-the-index-luke.com/no-offset
രചയിതാവ്: മാർക്കസ് വിനാൻഡ്

അവലംബം: www.habr.com