Ee vun den typesche Szenarien an allen Uwendungen, mat deenen mir vertraut sinn, ass d'Sich no Daten no bestëmmte Critèren an weist se an enger einfach liesbarer Form. Et kënnen och zousätzlech Optiounen fir Sortéierung, Gruppéierung a Paging sinn. D'Aufgab ass, an der Theorie, trivial, awer wann se léisen, maachen vill Entwéckler eng Rei vu Feeler, déi spéider d'Produktivitéit leiden. Loosst eis probéieren verschidden Optiounen ze betruecht fir dëse Problem ze léisen an Empfehlungen ze formuléieren fir déi effektivst Ëmsetzung ze wielen.
Paging Optioun #1
Déi einfachst Optioun déi am Kapp kënnt ass eng Säit-fir-Säit Display vu Sichresultater a senger klassescher Form.
Loosst eis soen datt Är Applikatioun eng relational Datebank benotzt. An dësem Fall, fir Informatioun an dësem Formulaire ze weisen, musst Dir zwee SQL Ufroen ausféieren:
- Kritt Reihen fir déi aktuell Säit.
- Berechent d'Gesamtzuel vun den Zeilen, déi zu de Sichkriterien entspriechen - dat ass néideg fir Säiten ze weisen.
Loosst eis déi éischt Ufro kucken mat enger Test MS SQL Datebank als Beispill fir 2016 Server. Fir dësen Zweck benotze mir de Sales.SalesOrderHeader Dësch:
SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Déi uewe genannte Ufro gëtt déi éischt 50 Bestellungen aus der Lëscht zréck, zortéiert no erofkommend Datum vun der Zousatz, an anere Wierder, déi 50 lescht Bestellungen.
Et leeft séier op der Testbasis, awer loosst eis den Ausféierungsplang an I/O Statistiken kucken:
Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Dir kënnt I/O Statistike fir all Ufro kréien andeems Dir de SET STATISTICS IO ON Kommando an der Ufro Runtime leeft.
Wéi Dir aus dem Ausféierungsplang gesitt, ass déi meeschte Ressourceintensiv Optioun all Zeilen vun der Quelltabel no Datum dobäigesat ze sortéieren. An de Problem ass datt déi méi Reihen an der Tabell erschéngen, wat "méi haart" d'Sortéierung wäert sinn. An der Praxis solle sou Situatioune vermeit ginn, also loosst eis en Index zum Zousatzdatum addéieren a kucken ob de Ressourceverbrauch geännert huet:
Table 'SalesOrderHeader'. Scan count 1, logical reads 165, physical reads 0, read-ahead reads 5, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Natierlech ass et vill besser ginn. Awer sinn all Problemer geléist? Loosst eis d'Ufro änneren fir no Bestellungen ze sichen wou d'Gesamtkäschte vun de Wueren méi wéi $100 sinn:
SELECT * FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Table 'SalesOrderHeader'. Scan count 1, logical reads 1081, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Mir hunn eng witzeg Situatioun: den Ufroplang ass net vill méi schlëmm wéi dee virdrun, awer d'tatsächlech Zuel vu logesche Liesungen ass bal duebel sou grouss wéi mat engem vollen Dësch Scan. Et gëtt e Wee eraus - wa mir e Composite Index aus engem schonn existenten Index maachen an de Gesamtpräis vu Wueren als zweet Feld addéieren, kréie mir erëm 165 logesch Liesungen:
CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);
Dës Serie vu Beispiller ka laang weidergefouert ginn, awer déi zwee Haaptgedanken déi ech hei ausdrécke wëll sinn:
- All nei Critère oder Sortéierungsuerdnung op eng Sichufro bäizefügen kann e wesentlechen Impakt op d'Geschwindegkeet vun der Sichufro hunn.
- Awer wa mir nëmmen en Deel vun den Donnéeën subtrahéieren mussen, an net all d'Resultater déi mat de Sichbegrëffer passen, ginn et vill Weeër fir sou eng Ufro ze optimiséieren.
Loosst eis elo op déi zweet Ufro, déi am Ufank erwähnt gouf, weidergoen - déi, déi d'Zuel vun den Opzeechnungen zielt, déi de Sichcritère entspriechen. Loosst eis datselwecht Beispill huelen - no Bestellungen sichen déi méi wéi $100 sinn:
SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
Mat dem uewe genannte Composite Index kréien mir:
Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.D'Tatsaach datt d'Ufro duerch de ganzen Index geet ass net iwwerraschend, well d'SubTotal Feld net an der éischter Positioun ass, sou datt d'Ufro se net benotze kann. De Problem gëtt geléist andeems en en aneren Index am SubTotal Feld derbäigesat gëtt, an als Resultat gëtt et nëmmen 48 logesch Liesungen.
Dir kënnt e puer méi Beispiller vun Ufroe fir Quantitéiten ze zielen ginn, awer d'Essenz bleift déiselwecht: e Stéck Daten ze kréien an de Gesamtbetrag ze zielen sinn zwee grondsätzlech ënnerschiddlech Ufroen, a jidderee erfuerdert seng eege Moossname fir Optimisatioun. Am Allgemengen kënnt Dir keng Kombinatioun vun Indexen fannen déi gläich gutt fir béid Ufroen funktionnéiert.
Deementspriechend ass ee vun de wichtege Viraussetzungen, déi bei der Entwécklung vun esou enger Sichléisung gekläert ginn, ob et wierklech wichteg ass fir e Geschäft d'Gesamtzuel vun den fonnten Objeten ze gesinn. Et geschitt dacks datt nee. A Navigatioun no spezifesche Säitennummeren, menger Meenung no, ass eng Léisung mat engem ganz schmuele Spillraum, well déi meescht Paging Szenarie ausgesinn wéi "goen op déi nächst Säit."
Paging Optioun #2
Loosst eis unhuelen datt d'Benotzer egal sinn iwwer d'Gesamtzuel vun den fonnten Objeten ze wëssen. Loosst eis probéieren d'Sichsäit ze vereinfachen:
Tatsächlech ass dat eenzegt wat geännert huet ass datt et kee Wee ass fir op spezifesch Säitennummeren ze navigéieren, an elo brauch dës Tabell net ze wëssen wéi vill et ka sinn fir se ze weisen. Awer d'Fro stellt sech - wéi weess den Dësch ob et Daten fir déi nächst Säit gëtt (fir de Link "Nächst" richteg ze weisen)?
D'Äntwert ass ganz einfach: Dir kënnt aus der Datebank ee Rekord méi liesen wéi néideg fir ze weisen, an d'Präsenz vun dësem "zousätzleche" Rekord wäert weisen ob et en nächsten Deel gëtt. Op dës Manéier musst Dir nëmmen eng Ufro ausféieren fir eng Säit vun Daten ze kréien, wat d'Performance wesentlech verbessert an et méi einfach mécht sou Funktionalitéit z'ënnerstëtzen. A menger Praxis war et e Fall wou d'Refus vun der Gesamtzuel vun de Rekorder ze zielen huet d'Liwwerung vun de Resultater ëm 4-5 Mol beschleunegt.
Et gi verschidde User Interface Optiounen fir dës Approche: "zréck" an "Forward" Kommandoen, wéi am Beispill hei uewen, e "Lued méi" Knäppchen, deen einfach en neien Deel un déi ugewisen Resultater bäidréit, "onendlech Scroll", déi funktionnéiert op de Prinzip vun "méi lueden" ", mee d'Signal fir déi nächst Portioun ze kréien ass fir de Benotzer all ugewisen Resultater bis Enn ze scrollen. Wat och ëmmer déi visuell Léisung ass, bleift de Prinzip vun der Dateprobe déiselwecht.
Nuancen vun der Ëmsetzung vun der Paging
All déi uewe genannte Ufro Beispiller benotzen d'Approche "Offset + Count", wann d'Ufro selwer spezifizéiert a wéi enger Reiefolleg d'Resultat Reihen a wéivill Reihen musse zréckginn. Als éischt, kucke mer wéi am beschten d'Parameterpassage an dësem Fall organiséiert gëtt. An der Praxis hunn ech verschidde Methoden begéint:
- D'Seriennummer vun der ugefrote Säit (pageIndex), Säitgréisst (pageSize).
- D'Seriennummer vum éischte Rekord, deen zréckgeet (startIndex), déi maximal Unzuel vun Opzeechnungen am Resultat (Zuel).
- D'Sequenznummer vum éischte Rekord, deen zréckgeet (StartIndex), d'Sequenznummer vum leschte Rekord, deen zréckginn (endIndex).
Op den éischte Bléck kann et schéngen datt dëst sou elementar ass datt et keen Ënnerscheed ass. Awer dëst ass net sou - déi bequemst an universell Optioun ass déi zweet (StartIndex, zielen). Et gi verschidde Grënn dofir:
- Fir d'+1 Entrée Korrektur-Approche hei uewen uginn, ass déi éischt Optioun mat PageIndex a PageSize extrem onbequem. Zum Beispill wëlle mir 50 Posts pro Säit weisen. Geméiss dem uewe genannten Algorithmus musst Dir e Rekord méi liesen wéi néideg. Wann dës "+1" net op de Server ëmgesat ass, stellt sech eraus datt fir déi éischt Säit musse mir records vun 1 bis 51 ufroen, fir déi zweet - vun 51 bis 101, etc. Wann Dir eng Säitgréisst vun 51 spezifizéiert an PageIndex erhéicht, da gëtt déi zweet Säit vun 52 op 102 zréck, etc. Deementspriechend, an der éischter Optioun, ass deen eenzege Wee fir e Knäppchen richteg ëmzesetzen fir op déi nächst Säit ze goen ass de Server déi "extra" Linn ze korrigéieren, wat eng ganz implizit Nuance wäert sinn.
- Déi drëtt Optioun mécht guer kee Sënn, well fir Ufroen an de meeschten Datenbanken auszeféieren, musst Dir ëmmer nach d'Zuel passéieren anstatt den Index vum leschte Rekord. StartIndex vun endIndex subtrahéieren kann eng einfach arithmetesch Operatioun sinn, awer et ass iwwerflësseg hei.
Elo solle mir d'Nodeeler vun der Ëmsetzung vun der Paging duerch "Offset + Quantitéit" beschreiwen:
- All spéider Säit zréckzéien wäert méi deier a méi lues sinn wéi déi virdrun, well d'Datebank nach ëmmer all d'Records "vun Ufank un" no de Sich- a Sortéierungskriterien muss duerchgoën, an dann op de gewënschte Fragment stoppen.
- Net all DBMS kënnen dës Approche ënnerstëtzen.
Et ginn Alternativen, awer si sinn och onvollstänneg. Déi éischt vun dësen Approche gëtt "Keyset Paging" oder "Sichmethod" genannt an ass wéi follegt: nodeems Dir en Deel kritt hutt, kënnt Dir d'Feldwäerter am leschte Rekord op der Säit erënneren, a benotzt se dann fir ze kréien den nächsten Deel. Zum Beispill hu mir déi folgend Ufro gemaach:
SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
An am leschte Rekord krute mir de Wäert vum Bestellungsdatum '2014-06-29'. Dann fir déi nächst Säit ze kréien, kënnt Dir probéieren dëst ze maachen:
SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
De Problem ass datt OrderDate en net-eenzegaartegt Feld ass an d'Konditioun uewen spezifizéiert ass méiglecherweis vill erfuerderlech Reihen ze verpassen. Fir Eendeitegkeet zu dëser Ufro ze addéieren, musst Dir en eenzegaartegt Feld un d'Konditioun addéieren (uhuelen datt 75074 de leschte Wäert vum primäre Schlëssel aus dem éischten Deel ass):
SELECT * FROM Sales.SalesOrderHeader
WHERE (OrderDate = '2014-06-29' AND SalesOrderID < 75074)
OR (OrderDate < '2014-06-29')
ORDER BY OrderDate DESC, SalesOrderID DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Dës Optioun funktionnéiert richteg, awer allgemeng wäert et schwéier sinn ze optimiséieren, well d'Konditioun en ODER Bedreiwer enthält. Wann de Wäert vum primäre Schlëssel eropgeet wéi den OrderDate eropgeet, da kann d'Konditioun vereinfacht ginn andeems Dir nëmmen e Filter vum SalesOrderID hannerloosst. Awer wann et keng strikt Korrelatioun tëscht de Wäerter vum primäre Schlëssel an dem Feld ass, duerch deen d'Resultat zortéiert ass, kann dësen ODER net an de meeschte DBMSs vermeit ginn. Eng Ausnam, déi ech bewosst sinn, ass PostgreSQL, deen den Tupelvergleich voll ënnerstëtzt, an déi uewe genannte Konditioun kann als "WHERE (OrderDate, SalesOrderID) <('2014-06-29', 75074) geschriwwe ginn. Gitt e Composite Schlëssel mat dësen zwee Felder, soll eng Ufro wéi dës zimlech einfach sinn.
Eng zweet alternativ Approche kann fonnt ginn, zum Beispill, an oder - wann eng Ufro, zousätzlech zu den Donnéeën, e speziellen Identifizéierer zréckkënnt, mat deem Dir den nächsten Deel vun den Donnéeën kritt. Wann dësen Identifizéierer eng onlimitéiert Liewensdauer huet (wéi an Comsos DB), dann ass dëst e super Wee fir Paging mat sequenziellen Iwwergang tëscht Säiten ëmzesetzen (Optioun #2 uewen ernimmt). Seng méiglech Nodeeler: et gëtt net an all DBMSen ënnerstëtzt; déi resultéierend Next-Chunk Identifizéierer kann eng limitéiert Liewensdauer hunn, wat allgemeng net gëeegent ass fir d'Benotzerinteraktioun ëmzesetzen (wéi d'ElasticSearch Scroll API).
Komplex Filteren
Loosst eis d'Aufgab weider komplizéiere. Ugeholl datt et eng Fuerderung ass fir déi sougenannt facettéiert Sich ëmzesetzen, déi jidderengem aus Online Geschäfter ganz vertraut ass. Déi uewe genannte Beispiller baséiert op der Bestellungstabell sinn net ganz illustréiert an dësem Fall, also loosst eis op d'Produkttabelle vun der AdventureWorks Datebank wiesselen:
Wat ass d'Iddi hannert facettéierter Sich? D'Tatsaach ass datt fir all Filterelement d'Zuel vun den Opzeechnunge gewise gëtt, déi dëse Critère entspriechen berécksiichtegt Filteren ausgewielt an all aner Kategorien.
Zum Beispill, wa mir d'Bikes Kategorie an d'Faarf Schwaarz an dësem Beispill auswielen, weist d'Tabell nëmme schwaarz Vëloen, awer:
- Fir all Critère an der Kategorie Kategorien gëtt d'Zuel vun de Produkter aus där Kategorie schwaarz gewisen.
- Fir all Critère vun der Grupp "Faarwen" gëtt d'Zuel vun de Vëloen vun dëser Faarf ugewisen.
Hei ass e Beispill vum Resultatausgang fir sou Konditiounen:
Wann Dir och d'Kategorie "Kleeder" kuckt, weist den Dësch och schwaarz Kleeder déi op Lager sinn. D'Zuel vun de schwaarze Produkter an der Rubrik "Faarf" gëtt och no den neie Konditioune berechent, nëmmen an der Rubrik "Kategorien" ännert sech näischt ... Ech hoffen, datt dës Beispiller genuch sinn fir den üblechen facettéierte Sichalgorithmus ze verstoen.
Loosst eis elo virstellen, wéi dat op enger relational Basis ëmgesat ka ginn. All Grupp vu Critèren, wéi Kategorie a Faarf, erfuerdert eng separat Ufro:
SELECT pc.ProductCategoryID, pc.Name, COUNT(1) FROM Production.Product p
INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
INNER JOIN Production.ProductCategory pc ON ps.ProductCategoryID = pc.ProductCategoryID
WHERE p.Color = 'Black'
GROUP BY pc.ProductCategoryID, pc.Name
ORDER BY COUNT(1) DESC
SELECT Color, COUNT(1) FROM Production.Product p
INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
WHERE ps.ProductCategoryID = 1 --Bikes
GROUP BY Color
ORDER BY COUNT(1) DESC
Wat ass falsch mat dëser Léisung? Et ass ganz einfach - et scaléiert net gutt. All Filter Sektioun erfuerdert eng separat Ufro fir Quantitéiten ze berechnen, an dës Ufroe sinn net déi einfachst. An Online Geschäfter kënnen e puer Kategorien e puer Dosen Filtersektiounen hunn, wat e seriöse Performanceprobleem kann sinn.
Normalerweis ginn ech no dësen Aussoen e puer Léisungen ugebueden, nämlech:
- Kombinéiert all Quantitéit zielt an eng Ufro. Technesch ass dëst méiglech mat der UNION Schlësselwuert, awer et hëlleft net vill Leeschtung - d'Datebank muss nach ëmmer all Fragmenter aus Null ausféieren.
- Cache Quantitéiten. Dëst gëtt mir bal all Kéier proposéiert wann ech e Problem beschreiwen. Den Opgepasst ass datt dëst allgemeng onméiglech ass. Loosst eis soen datt mir 10 "Facetten" hunn, déi all 5 Wäerter hunn. Dëst ass eng ganz "bescheiden" Situatioun am Verglach mat deem wat an de selwechten Online Geschäfter gesi ka ginn. D'Wiel vun engem Facettenaen Element beaflosst d'Quantitéiten an 9 aner, an anere Wierder, fir all Kombinatioun vun Critèren d'Quantitéiten anescht kann. An eisem Beispill ginn et insgesamt 50 Critèren, déi de Benotzer auswielen kann, dofir ginn et 250 méiglech Kombinatioune. Hei kënnt Dir Objet a soen, datt net all Kombinatioune real sinn an de Benotzer wielt selten méi wéi 5-10 Critèren. Jo, et ass méiglech faul ze lueden an eng Quantitéit ze cache vun nëmmen deem wat jeemools ausgewielt gouf, awer wat méi Selektiounen et sinn, wat manner effizient esou e Cache wäert sinn an wat d'Äntwertzäitproblemer méi bemierkbar sinn (besonnesch wann de Datenset ännert sech regelméisseg).
Glécklecherweis huet sou e Problem laang zimlech effektiv Léisungen, déi viraussiichtlech op grousse Bänn vun Daten funktionnéieren. Fir eng vun dësen Optiounen ass et Sënn fir d'Neiberechnung vun de Facetten an d'Empfang vun der Resultater Säit an zwee parallel Uruff un de Server z'organiséieren an d'Benotzerinterface esou z'organiséieren datt d'Donnéeën duerch Facetten "net stéiert" mam Display vun Sich Resultater.
- Rufft eng komplett nei Berechnung vun "Facetten" sou seelen wéi méiglech. Zum Beispill, berechent net alles all Kéier wann d'Sichcritère ännert, awer fannt amplaz d'Gesamtzuel vun de Resultater déi mat den aktuellen Konditioune passen an de Benotzer froen se ze weisen - "1425 records fonnt, weisen?" De Benotzer kann entweder weider d'Sichbegrëffer änneren oder klickt op de "weisen" Knäppchen. Nëmmen am zweete Fall ginn all Ufroe fir d'Resultater ze kréien an d'Quantitéiten op all "Facetten" ze berechnen. An dësem Fall, wéi Dir einfach gesitt, musst Dir mat enger Demande këmmeren fir d'Gesamtzuel vun de Resultater a seng Optimisatioun ze kréien. Dës Method kann a ville klengen Online Geschäfter fonnt ginn. Natierlech ass dëst keng Panacea fir dëse Problem, awer an einfache Fäll kann et e gudde Kompromiss sinn.
- Benotzt Sichmotoren fir Resultater ze fannen an Facetten ze zielen, wéi Solr, ElasticSearch, Sphinx an anerer. All si sinn entwéckelt fir "Facetten" ze bauen an dëst ganz effizient ze maachen wéinst dem ëmgedréint Index. Wéi d'Sichmaschinne funktionnéieren, firwat se an esou Fäll méi effektiv si wéi allgemeng Zwecker Datenbanken, wéi eng Praktiken a Fallfäegkeeten ginn et - dëst ass en Thema fir en separaten Artikel. Hei wëll ech Iech op d'Tatsaach opmierksam maachen datt d'Sichmaschinn net en Ersatz fir d'Haaptdatenlagerung ka sinn, et gëtt als Zousatz benotzt: all Ännerungen an der Haaptdatenbank, déi fir d'Sich relevant sinn, ginn an de Sichindex synchroniséiert; D'Sichmaschinn interagéiert normalerweis nëmme mat der Sichmotor an huet net Zougang zu der Haaptdatenbank. Ee vun de wichtegste Punkten hei ass wéi Dir dës Synchroniséierung zouverlässeg organiséiert. Et hänkt alles vun den Ufuerderunge vun der "Reaktiounszäit" of. Wann d'Zäit tëscht enger Verännerung vun der Haaptdatenbank a senger "Manifestatioun" an der Sich net kritesch ass, kënnt Dir e Service erstellen deen all puer Minutten no kierzlech geännerten records sicht an se indexéiert. Wann Dir déi kuerst méiglech Äntwertzäit wëllt, kënnt Dir eppes implementéieren wéi fir Updates un de Sichservice ze schécken.
Conclusiounen
- Ëmsetzung vun Server-Säit Paging ass eng bedeitend Komplikatioun a mécht nëmme Sënn fir séier wuessend oder einfach grouss Datesets. Et gëtt keen absolut exakt Rezept fir wéi een "grouss" oder "schnell wuessend" bewäerten, awer ech géif dës Approche verfollegen:
- Wann Dir eng komplett Sammlung vun Daten kritt, andeems d'Serverzäit an d'Netzübertragung berücksichtegt gëtt, entsprécht d'Leeschtungsfuerderunge normalerweis, ass et kee Sënn fir Paging op der Serversäit ëmzesetzen.
- Et kann eng Situatioun ginn, wou keng Leeschtungsproblemer an der nächster Zukunft erwaart ginn, well et wéineg Donnéeën ass, awer d'Datesammlung wiisst konstant. Wann e puer Set vun Donnéeën an Zukunft net méi de fréiere Punkt erfëllen, ass et besser direkt unzefänken.
- Wann et keng strikt Fuerderung vum Deel vum Geschäft ass fir d'Gesamtzuel vun de Resultater ze weisen oder Säitnummeren ze weisen, an Äre System huet keng Sichmotor, ass et besser dës Punkten net ëmzesetzen an d'Optioun #2 ze berücksichtegen.
- Wann et eng kloer Fuerderung fir facettéiert Sich ass, hutt Dir zwou Méiglechkeeten ouni d'Performance ofzeginn:
- Berechent net all Quantitéiten all Kéier wann d'Sichkriterien änneren.
- Benotzt Sichmotoren wéi Solr, ElasticSearch, Sphinx an anerer. Mä et soll verstane ginn, datt et net en Ersatz fir d'Haaptdatenbank kann, a soll als Zousaz zu der Haaptrei Stockage fir léisen Sich Problemer benotzt ginn.
- Och am Fall vun facettéierten Sich mécht et Sënn fir d'Erhuelung vun der Sichresultater Säit an d'Zeechung an zwee parallel Ufroen opzedeelen. D'Quantitéite zielen kënnen méi laang daueren wéi d'Resultater ze kréien, während d'Resultater méi wichteg fir de Benotzer sinn.
- Wann Dir eng SQL Datebank fir Sich benotzt, all Code änneren am Zesummenhang mat dësem Deel soll gutt getest ginn fir Leeschtung op der entspriechend Quantitéit vun Donnéeën (iwwerschratt de Volume an der liewen Datebank). Et ass och ubruecht d'Iwwerwaachung vun der Ausféierungszäit vun Ufroen op all Instanzen vun der Datebank ze benotzen, a besonnesch op der "Live". Och wann alles gutt war mat Ufropläng an der Entwécklungsphase, wéi de Volume vun den Daten wiisst, kann d'Situatioun merkbar änneren.
Source: will.com