ਖੋਜ ਨਤੀਜੇ ਆਉਟਪੁੱਟ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਦੇ

ਉਹਨਾਂ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਇੱਕ ਖਾਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਜਿਹਨਾਂ ਤੋਂ ਅਸੀਂ ਜਾਣੂ ਹਾਂ ਕੁਝ ਮਾਪਦੰਡਾਂ ਦੇ ਅਨੁਸਾਰ ਡੇਟਾ ਦੀ ਖੋਜ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਰੂਪ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨਾ ਹੈ। ਛਾਂਟੀ ਕਰਨ, ਸਮੂਹ ਬਣਾਉਣ ਅਤੇ ਪੇਜਿੰਗ ਲਈ ਵਾਧੂ ਵਿਕਲਪ ਵੀ ਹੋ ਸਕਦੇ ਹਨ। ਕੰਮ, ਸਿਧਾਂਤ ਵਿੱਚ, ਮਾਮੂਲੀ ਹੈ, ਪਰ ਇਸਨੂੰ ਹੱਲ ਕਰਦੇ ਸਮੇਂ, ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਕਈ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ, ਜੋ ਬਾਅਦ ਵਿੱਚ ਉਤਪਾਦਕਤਾ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ। ਆਉ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਵੱਖ-ਵੱਖ ਵਿਕਲਪਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਅਤੇ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲਾਗੂ ਕਰਨ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਸਿਫਾਰਸ਼ਾਂ ਤਿਆਰ ਕਰੀਏ.

ਪੇਜਿੰਗ ਵਿਕਲਪ #1

ਸਭ ਤੋਂ ਸਰਲ ਵਿਕਲਪ ਜੋ ਮਨ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਉਹ ਹੈ ਇਸਦੇ ਸਭ ਤੋਂ ਕਲਾਸਿਕ ਰੂਪ ਵਿੱਚ ਖੋਜ ਨਤੀਜਿਆਂ ਦਾ ਇੱਕ ਪੰਨਾ-ਦਰ-ਪੰਨਾ ਡਿਸਪਲੇ।

ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਸ ਫਾਰਮ ਵਿੱਚ ਜਾਣਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਦੋ SQL ਸਵਾਲਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ:

• ਮੌਜੂਦਾ ਪੰਨੇ ਲਈ ਕਤਾਰਾਂ ਪ੍ਰਾਪਤ ਕਰੋ।
• ਖੋਜ ਮਾਪਦੰਡ ਦੇ ਅਨੁਸਾਰੀ ਲਾਈਨਾਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਦੀ ਗਣਨਾ ਕਰੋ - ਪੰਨਿਆਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਇਹ ਜ਼ਰੂਰੀ ਹੈ।

ਆਉ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਇੱਕ ਟੈਸਟ MS SQL ਡਾਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪਹਿਲੀ ਪੁੱਛਗਿੱਛ ਨੂੰ ਵੇਖੀਏ ਐਡਵੈਂਚਰ ਵਰਕਸ 2016 ਸਰਵਰ ਲਈ. ਇਸ ਉਦੇਸ਼ ਲਈ ਅਸੀਂ Sales.SalesOrderHeader ਟੇਬਲ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

ਉਪਰੋਕਤ ਪੁੱਛਗਿੱਛ ਸੂਚੀ ਵਿੱਚੋਂ ਪਹਿਲੇ 50 ਆਰਡਰ ਵਾਪਸ ਕਰੇਗੀ, ਜੋੜਨ ਦੀ ਘਟਦੀ ਮਿਤੀ ਦੁਆਰਾ ਕ੍ਰਮਬੱਧ, ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, 50 ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਆਰਡਰ।

ਇਹ ਟੈਸਟ ਬੇਸ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਦਾ ਹੈ, ਪਰ ਆਓ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ ਅਤੇ I/O ਅੰਕੜਿਆਂ ਨੂੰ ਵੇਖੀਏ:

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.

ਤੁਸੀਂ ਪੁੱਛਗਿੱਛ ਰਨਟਾਈਮ ਵਿੱਚ SET STATISTICS IO ON ਕਮਾਂਡ ਚਲਾ ਕੇ ਹਰੇਕ ਪੁੱਛਗਿੱਛ ਲਈ I/O ਅੰਕੜੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਸਭ ਤੋਂ ਵੱਧ ਸੰਸਾਧਨ-ਸੰਬੰਧੀ ਵਿਕਲਪ ਸਰੋਤ ਸਾਰਣੀ ਦੀਆਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਜੋੜੀ ਗਈ ਮਿਤੀ ਦੁਆਰਾ ਕ੍ਰਮਬੱਧ ਕਰਨਾ ਹੈ। ਅਤੇ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਸਾਰਣੀ ਵਿੱਚ ਜਿੰਨੀਆਂ ਜ਼ਿਆਦਾ ਕਤਾਰਾਂ ਦਿਖਾਈ ਦੇਣਗੀਆਂ, ਛਾਂਟੀ ਓਨੀ ਹੀ "ਸਖ਼ਤ" ਹੋਵੇਗੀ। ਅਭਿਆਸ ਵਿੱਚ, ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ ਆਓ ਜੋੜਨ ਦੀ ਮਿਤੀ ਵਿੱਚ ਇੱਕ ਸੂਚਕਾਂਕ ਜੋੜੀਏ ਅਤੇ ਵੇਖੀਏ ਕਿ ਕੀ ਸਰੋਤ ਦੀ ਖਪਤ ਬਦਲ ਗਈ ਹੈ:

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.

ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੋ ਗਿਆ ਹੈ. ਪਰ ਕੀ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਹੋ ਗਈਆਂ ਹਨ? ਆਉ ਉਹਨਾਂ ਆਰਡਰਾਂ ਦੀ ਖੋਜ ਕਰਨ ਲਈ ਪੁੱਛਗਿੱਛ ਨੂੰ ਬਦਲੀਏ ਜਿੱਥੇ ਮਾਲ ਦੀ ਕੁੱਲ ਕੀਮਤ $100 ਤੋਂ ਵੱਧ ਹੈ:

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.

ਸਾਡੇ ਕੋਲ ਇੱਕ ਮਜ਼ਾਕੀਆ ਸਥਿਤੀ ਹੈ: ਪੁੱਛਗਿੱਛ ਯੋਜਨਾ ਪਿਛਲੇ ਇੱਕ ਨਾਲੋਂ ਬਹੁਤ ਮਾੜੀ ਨਹੀਂ ਹੈ, ਪਰ ਲਾਜ਼ੀਕਲ ਰੀਡਜ਼ ਦੀ ਅਸਲ ਸੰਖਿਆ ਪੂਰੀ ਟੇਬਲ ਸਕੈਨ ਨਾਲ ਲਗਭਗ ਦੁੱਗਣੀ ਹੈ। ਇਸ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ - ਜੇਕਰ ਅਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਸੂਚਕਾਂਕ ਤੋਂ ਇੱਕ ਸੰਯੁਕਤ ਸੂਚਕਾਂਕ ਬਣਾਉਂਦੇ ਹਾਂ ਅਤੇ ਮਾਲ ਦੀ ਕੁੱਲ ਕੀਮਤ ਨੂੰ ਦੂਜੇ ਖੇਤਰ ਵਜੋਂ ਜੋੜਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਦੁਬਾਰਾ 165 ਲਾਜ਼ੀਕਲ ਰੀਡਜ਼ ਮਿਲਣਗੇ:

CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);

ਉਦਾਹਰਣਾਂ ਦੀ ਇਹ ਲੜੀ ਲੰਬੇ ਸਮੇਂ ਲਈ ਜਾਰੀ ਰੱਖੀ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਦੋ ਮੁੱਖ ਵਿਚਾਰ ਜੋ ਮੈਂ ਇੱਥੇ ਪ੍ਰਗਟ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਉਹ ਹਨ:

• ਖੋਜ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਕੋਈ ਨਵਾਂ ਮਾਪਦੰਡ ਜਾਂ ਲੜੀਬੱਧ ਕ੍ਰਮ ਜੋੜਨਾ ਖੋਜ ਪੁੱਛਗਿੱਛ ਦੀ ਗਤੀ 'ਤੇ ਮਹੱਤਵਪੂਰਣ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦਾ ਹੈ।
• ਪਰ ਜੇ ਸਾਨੂੰ ਡੇਟਾ ਦੇ ਸਿਰਫ ਹਿੱਸੇ ਨੂੰ ਘਟਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਖੋਜ ਸ਼ਬਦਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਸਾਰੇ ਨਤੀਜੇ ਨਹੀਂ, ਤਾਂ ਅਜਿਹੀ ਪੁੱਛਗਿੱਛ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੇ ਬਹੁਤ ਸਾਰੇ ਤਰੀਕੇ ਹਨ.

ਹੁਣ ਆਉ ਸ਼ੁਰੂ ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤੀ ਗਈ ਦੂਜੀ ਪੁੱਛਗਿੱਛ ਵੱਲ ਵਧੀਏ - ਇੱਕ ਜੋ ਖੋਜ ਮਾਪਦੰਡ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਾਲੇ ਰਿਕਾਰਡਾਂ ਦੀ ਗਿਣਤੀ ਕਰਦਾ ਹੈ। ਚਲੋ ਉਹੀ ਉਦਾਹਰਣ ਲੈਂਦੇ ਹਾਂ - $100 ਤੋਂ ਵੱਧ ਦੇ ਆਰਡਰਾਂ ਦੀ ਖੋਜ ਕਰਨਾ:

SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100

ਉੱਪਰ ਦਰਸਾਏ ਸੰਯੁਕਤ ਸੂਚਕਾਂਕ ਦੇ ਮੱਦੇਨਜ਼ਰ, ਅਸੀਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ:

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.

ਇਹ ਤੱਥ ਕਿ ਪੁੱਛਗਿੱਛ ਪੂਰੇ ਸੂਚਕਾਂਕ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ ਹੈਰਾਨੀ ਵਾਲੀ ਗੱਲ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਸਬ-ਟੋਟਲ ਫੀਲਡ ਪਹਿਲੀ ਸਥਿਤੀ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਪੁੱਛਗਿੱਛ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਸਬ-ਟੋਟਲ ਫੀਲਡ ਉੱਤੇ ਇੱਕ ਹੋਰ ਸੂਚਕਾਂਕ ਜੋੜ ਕੇ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਇਹ ਸਿਰਫ 48 ਲਾਜ਼ੀਕਲ ਰੀਡ ਦਿੰਦਾ ਹੈ।

ਤੁਸੀਂ ਮਾਤਰਾਵਾਂ ਦੀ ਗਿਣਤੀ ਕਰਨ ਲਈ ਬੇਨਤੀਆਂ ਦੀਆਂ ਕੁਝ ਹੋਰ ਉਦਾਹਰਣਾਂ ਦੇ ਸਕਦੇ ਹੋ, ਪਰ ਸਾਰ ਉਹੀ ਰਹਿੰਦਾ ਹੈ: ਡੇਟਾ ਦਾ ਇੱਕ ਟੁਕੜਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਅਤੇ ਕੁੱਲ ਰਕਮ ਦੀ ਗਿਣਤੀ ਕਰਨਾ ਦੋ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖਰੀਆਂ ਬੇਨਤੀਆਂ ਹਨ, ਅਤੇ ਹਰੇਕ ਨੂੰ ਅਨੁਕੂਲਨ ਲਈ ਆਪਣੇ ਖੁਦ ਦੇ ਉਪਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਸੂਚਕਾਂਕ ਦੇ ਸੁਮੇਲ ਨੂੰ ਲੱਭਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੋਗੇ ਜੋ ਦੋਵਾਂ ਸਵਾਲਾਂ ਲਈ ਬਰਾਬਰ ਕੰਮ ਕਰਦਾ ਹੈ।

ਇਸ ਅਨੁਸਾਰ, ਅਜਿਹੇ ਖੋਜ ਹੱਲ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਵੇਲੇ ਸਪੱਸ਼ਟ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਮਹੱਤਵਪੂਰਨ ਲੋੜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਕੀ ਕਿਸੇ ਕਾਰੋਬਾਰ ਲਈ ਲੱਭੀਆਂ ਗਈਆਂ ਵਸਤੂਆਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਨੂੰ ਦੇਖਣਾ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ. ਇਹ ਅਕਸਰ ਹੁੰਦਾ ਹੈ ਕਿ ਨਹੀਂ. ਅਤੇ ਖਾਸ ਪੰਨਾ ਨੰਬਰਾਂ ਦੁਆਰਾ ਨੈਵੀਗੇਸ਼ਨ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇੱਕ ਬਹੁਤ ਹੀ ਤੰਗ ਸਕੋਪ ਵਾਲਾ ਇੱਕ ਹੱਲ ਹੈ, ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਪੇਜਿੰਗ ਦ੍ਰਿਸ਼ "ਅਗਲੇ ਪੰਨੇ 'ਤੇ ਜਾਓ" ਵਰਗੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।

ਪੇਜਿੰਗ ਵਿਕਲਪ #2

ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਉਪਭੋਗਤਾ ਲੱਭੀਆਂ ਗਈਆਂ ਵਸਤੂਆਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਨੂੰ ਜਾਣਨ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ। ਆਉ ਖੋਜ ਪੰਨੇ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ:

ਵਾਸਤਵ ਵਿੱਚ, ਸਿਰਫ ਇੱਕ ਚੀਜ਼ ਜੋ ਬਦਲ ਗਈ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਖਾਸ ਪੰਨਾ ਨੰਬਰਾਂ 'ਤੇ ਨੈਵੀਗੇਟ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਹੁਣ ਇਸ ਸਾਰਣੀ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ ਕਿ ਇਸ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਕਿੰਨੇ ਹੋ ਸਕਦੇ ਹਨ. ਪਰ ਸਵਾਲ ਉੱਠਦਾ ਹੈ - ਸਾਰਣੀ ਨੂੰ ਕਿਵੇਂ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਕੀ ਅਗਲੇ ਪੰਨੇ ਲਈ ਡੇਟਾ ਹੈ ("ਅਗਲਾ" ਲਿੰਕ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ)?

ਜਵਾਬ ਬਹੁਤ ਸਧਾਰਨ ਹੈ: ਤੁਸੀਂ ਡੈਟਾਬੇਸ ਤੋਂ ਡਿਸਪਲੇ ਲਈ ਲੋੜੀਂਦੇ ਇੱਕ ਹੋਰ ਰਿਕਾਰਡ ਨੂੰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਸ "ਵਾਧੂ" ਰਿਕਾਰਡ ਦੀ ਮੌਜੂਦਗੀ ਦਿਖਾਏਗੀ ਕਿ ਕੀ ਕੋਈ ਅਗਲਾ ਹਿੱਸਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਤੁਹਾਨੂੰ ਡੇਟਾ ਦੇ ਇੱਕ ਪੰਨੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਿਰਫ ਇੱਕ ਬੇਨਤੀ ਚਲਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜੋ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਸੁਧਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਅਜਿਹੀ ਕਾਰਜਸ਼ੀਲਤਾ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ। ਮੇਰੇ ਅਭਿਆਸ ਵਿੱਚ, ਇੱਕ ਅਜਿਹਾ ਕੇਸ ਸੀ ਜਦੋਂ ਰਿਕਾਰਡਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਨੂੰ ਗਿਣਨ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਨਾਲ ਨਤੀਜਿਆਂ ਦੀ ਸਪੁਰਦਗੀ ਨੂੰ 4-5 ਗੁਣਾ ਵੱਧ ਗਿਆ.

ਇਸ ਪਹੁੰਚ ਲਈ ਕਈ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਵਿਕਲਪ ਹਨ: "ਪਿੱਛੇ" ਅਤੇ "ਅੱਗੇ" ਕਮਾਂਡਾਂ, ਜਿਵੇਂ ਕਿ ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਵਿੱਚ, ਇੱਕ "ਲੋਡ ਮੋਰ" ਬਟਨ, ਜੋ ਸਿਰਫ਼ ਪ੍ਰਦਰਸ਼ਿਤ ਨਤੀਜਿਆਂ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਹਿੱਸਾ ਜੋੜਦਾ ਹੈ, "ਅਨੰਤ ਸਕਰੋਲ", ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ। "ਹੋਰ ਲੋਡ ਕਰੋ" ਦੇ ਸਿਧਾਂਤ 'ਤੇ, ਪਰ ਅਗਲਾ ਹਿੱਸਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸੰਕੇਤ ਉਪਭੋਗਤਾ ਲਈ ਸਾਰੇ ਪ੍ਰਦਰਸ਼ਿਤ ਨਤੀਜਿਆਂ ਨੂੰ ਅੰਤ ਤੱਕ ਸਕ੍ਰੌਲ ਕਰਨ ਲਈ ਹੈ। ਵਿਜ਼ੂਅਲ ਹੱਲ ਜੋ ਵੀ ਹੋਵੇ, ਡੇਟਾ ਸੈਂਪਲਿੰਗ ਦਾ ਸਿਧਾਂਤ ਇੱਕੋ ਜਿਹਾ ਰਹਿੰਦਾ ਹੈ।

ਪੇਜਿੰਗ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਬਾਰੀਕੀਆਂ

ਉੱਪਰ ਦਿੱਤੀਆਂ ਸਾਰੀਆਂ ਪੁੱਛਗਿੱਛ ਉਦਾਹਰਨਾਂ ਵਿੱਚ, "ਆਫਸੈੱਟ + ਗਿਣਤੀ" ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਦੋਂ ਕਿਊਰੀ ਖੁਦ ਦੱਸਦੀ ਹੈ ਕਿ ਨਤੀਜਾ ਕਤਾਰਾਂ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ ਹਨ ਅਤੇ ਕਿੰਨੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਵਾਪਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਹਿਲਾਂ, ਆਓ ਦੇਖੀਏ ਕਿ ਇਸ ਕੇਸ ਵਿੱਚ ਪੈਰਾਮੀਟਰ ਪਾਸਿੰਗ ਨੂੰ ਕਿਵੇਂ ਸੰਗਠਿਤ ਕਰਨਾ ਹੈ। ਅਭਿਆਸ ਵਿੱਚ, ਮੈਂ ਕਈ ਤਰੀਕਿਆਂ ਵਿੱਚ ਆਇਆ ਹਾਂ:

• ਬੇਨਤੀ ਕੀਤੇ ਪੰਨੇ ਦਾ ਸੀਰੀਅਲ ਨੰਬਰ (ਪੇਜ ਇੰਡੈਕਸ), ਪੰਨੇ ਦਾ ਆਕਾਰ (ਪੰਨਾ ਆਕਾਰ)।
• ਵਾਪਸ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਪਹਿਲੇ ਰਿਕਾਰਡ ਦਾ ਸੀਰੀਅਲ ਨੰਬਰ (startIndex), ਨਤੀਜੇ ਵਿੱਚ ਰਿਕਾਰਡਾਂ ਦੀ ਅਧਿਕਤਮ ਸੰਖਿਆ (ਗਿਣਤੀ)।
• ਵਾਪਸ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਪਹਿਲੇ ਰਿਕਾਰਡ ਦੀ ਕ੍ਰਮ ਸੰਖਿਆ (startIndex), ਵਾਪਸ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਆਖਰੀ ਰਿਕਾਰਡ ਦੀ ਕ੍ਰਮ ਸੰਖਿਆ (endIndex)।

ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਇਹ ਇੰਨਾ ਮੁਢਲਾ ਹੈ ਕਿ ਕੋਈ ਫਰਕ ਨਹੀਂ ਹੈ. ਪਰ ਇਹ ਅਜਿਹਾ ਨਹੀਂ ਹੈ - ਸਭ ਤੋਂ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਯੂਨੀਵਰਸਲ ਵਿਕਲਪ ਦੂਜਾ ਹੈ (ਸਟਾਰਟ ਇੰਡੈਕਸ, ਗਿਣਤੀ)। ਇਸਦੇ ਕਈ ਕਾਰਨ ਹਨ:

• ਉੱਪਰ ਦਿੱਤੀ ਗਈ +1 ਐਂਟਰੀ ਪਰੂਫ ਰੀਡਿੰਗ ਪਹੁੰਚ ਲਈ, pageIndex ਅਤੇ pageSize ਵਾਲਾ ਪਹਿਲਾ ਵਿਕਲਪ ਬਹੁਤ ਅਸੁਵਿਧਾਜਨਕ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਪ੍ਰਤੀ ਪੰਨਾ 50 ਪੋਸਟਾਂ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਉਪਰੋਕਤ ਐਲਗੋਰਿਦਮ ਦੇ ਅਨੁਸਾਰ, ਤੁਹਾਨੂੰ ਲੋੜ ਤੋਂ ਵੱਧ ਇੱਕ ਹੋਰ ਰਿਕਾਰਡ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ. ਜੇ ਇਹ "+1" ਸਰਵਰ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਪਹਿਲੇ ਪੰਨੇ ਲਈ ਸਾਨੂੰ 1 ਤੋਂ 51 ਤੱਕ ਰਿਕਾਰਡਾਂ ਦੀ ਬੇਨਤੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਦੂਜੇ ਲਈ - 51 ਤੋਂ 101 ਤੱਕ, ਆਦਿ. ਜੇਕਰ ਤੁਸੀਂ ਪੰਨੇ ਦਾ ਆਕਾਰ 51 ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ ਅਤੇ ਪੇਜ ਇੰਡੈਕਸ ਨੂੰ ਵਧਾਉਂਦੇ ਹੋ, ਤਾਂ ਦੂਜਾ ਪੰਨਾ 52 ਤੋਂ 102 ਤੱਕ ਵਾਪਸ ਆ ਜਾਵੇਗਾ, ਆਦਿ। ਇਸ ਅਨੁਸਾਰ, ਪਹਿਲੇ ਵਿਕਲਪ ਵਿੱਚ, ਅਗਲੇ ਪੰਨੇ 'ਤੇ ਜਾਣ ਲਈ ਇੱਕ ਬਟਨ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ ਸਰਵਰ ਨੂੰ "ਵਾਧੂ" ਲਾਈਨ ਨੂੰ ਪਰੂਫ ਰੀਡ ਕਰਨਾ, ਜੋ ਕਿ ਇੱਕ ਬਹੁਤ ਹੀ ਸਪੱਸ਼ਟ ਸੂਖਮਤਾ ਹੋਵੇਗੀ।
• ਤੀਜਾ ਵਿਕਲਪ ਬਿਲਕੁਲ ਵੀ ਅਰਥ ਨਹੀਂ ਰੱਖਦਾ, ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਆਖਰੀ ਰਿਕਾਰਡ ਦੇ ਸੂਚਕਾਂਕ ਦੀ ਬਜਾਏ ਗਿਣਤੀ ਨੂੰ ਪਾਸ ਕਰਨ ਦੀ ਲੋੜ ਪਵੇਗੀ। ਸਟਾਰਟਇੰਡੈਕਸ ਨੂੰ ਐਂਡਇੰਡੈਕਸ ਤੋਂ ਘਟਾਉਣਾ ਇੱਕ ਸਧਾਰਨ ਅੰਕਗਣਿਤ ਕਾਰਜ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਥੇ ਇਹ ਲੋੜ ਤੋਂ ਵੱਧ ਹੈ।

ਹੁਣ ਸਾਨੂੰ "ਆਫਸੈੱਟ + ਮਾਤਰਾ" ਦੁਆਰਾ ਪੇਜਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਨੁਕਸਾਨਾਂ ਦਾ ਵਰਣਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

• ਹਰੇਕ ਅਗਲੇ ਪੰਨੇ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਪਿਛਲੇ ਪੰਨੇ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹਿੰਗਾ ਅਤੇ ਹੌਲੀ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਅਜੇ ਵੀ ਖੋਜ ਅਤੇ ਛਾਂਟਣ ਦੇ ਮਾਪਦੰਡ ਦੇ ਅਨੁਸਾਰ "ਸ਼ੁਰੂ ਤੋਂ" ਸਾਰੇ ਰਿਕਾਰਡਾਂ ਵਿੱਚੋਂ ਲੰਘਣ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਅਤੇ ਫਿਰ ਲੋੜੀਂਦੇ ਟੁਕੜੇ 'ਤੇ ਰੁਕਣਾ ਹੋਵੇਗਾ।
• ਸਾਰੇ DBMS ਇਸ ਪਹੁੰਚ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਨ।

ਇੱਥੇ ਵਿਕਲਪ ਹਨ, ਪਰ ਉਹ ਅਪੂਰਣ ਵੀ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਪਹਿਲੀ ਪਹੁੰਚ ਨੂੰ "ਕੀਸੈਟ ਪੇਜਿੰਗ" ਜਾਂ "ਸੀਕ ਵਿਧੀ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ: ਇੱਕ ਹਿੱਸਾ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਪੰਨੇ 'ਤੇ ਆਖਰੀ ਰਿਕਾਰਡ ਵਿੱਚ ਫੀਲਡ ਮੁੱਲਾਂ ਨੂੰ ਯਾਦ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ ਅਗਲਾ ਹਿੱਸਾ. ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਪੁੱਛਗਿੱਛ ਚਲਾਈ:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

ਅਤੇ ਪਿਛਲੇ ਰਿਕਾਰਡ ਵਿੱਚ ਸਾਨੂੰ ਆਰਡਰ ਮਿਤੀ ਮੁੱਲ '2014-06-29' ਮਿਲਿਆ। ਫਿਰ ਅਗਲਾ ਪੰਨਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤੁਸੀਂ ਇਹ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ:

SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਆਰਡਰ ਡੇਟ ਇੱਕ ਗੈਰ-ਵਿਲੱਖਣ ਖੇਤਰ ਹੈ ਅਤੇ ਉੱਪਰ ਦੱਸੀ ਗਈ ਸਥਿਤੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ ਕਤਾਰਾਂ ਖੁੰਝਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ। ਇਸ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਅਸਪਸ਼ਟਤਾ ਜੋੜਨ ਲਈ, ਤੁਹਾਨੂੰ ਸਥਿਤੀ ਵਿੱਚ ਇੱਕ ਵਿਲੱਖਣ ਖੇਤਰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ (ਮੰਨ ਲਓ ਕਿ 75074 ਪਹਿਲੇ ਹਿੱਸੇ ਤੋਂ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਦਾ ਆਖਰੀ ਮੁੱਲ ਹੈ):

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

ਇਹ ਵਿਕਲਪ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰੇਗਾ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਸਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ ਕਿਉਂਕਿ ਸ਼ਰਤ ਵਿੱਚ ਇੱਕ OR ਆਪਰੇਟਰ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਦਾ ਮੁੱਲ OrderDate ਵਧਣ ਨਾਲ ਵਧਦਾ ਹੈ, ਤਾਂ SalesOrderID ਦੁਆਰਾ ਸਿਰਫ਼ ਇੱਕ ਫਿਲਟਰ ਛੱਡ ਕੇ ਸਥਿਤੀ ਨੂੰ ਸਰਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਪਰ ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਦੇ ਮੁੱਲ ਅਤੇ ਫੀਲਡ ਜਿਸ ਦੁਆਰਾ ਨਤੀਜਾ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ, ਵਿਚਕਾਰ ਕੋਈ ਸਖ਼ਤ ਸਬੰਧ ਨਹੀਂ ਹੈ, ਤਾਂ ਜ਼ਿਆਦਾਤਰ DBMS ਵਿੱਚ ਇਸ OR ਨੂੰ ਟਾਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਅਪਵਾਦ ਜਿਸ ਬਾਰੇ ਮੈਂ ਜਾਣਦਾ ਹਾਂ PostgreSQL ਹੈ, ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟੂਪਲ ਤੁਲਨਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਪਰੋਕਤ ਸਥਿਤੀ ਨੂੰ "WHERE (OrderDate, SalesOrderID) < ('2014-06-29', 75074)" ਵਜੋਂ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਦੋ ਖੇਤਰਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸੰਯੁਕਤ ਕੁੰਜੀ ਦਿੱਤੇ ਜਾਣ 'ਤੇ, ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਇੱਕ ਪੁੱਛਗਿੱਛ ਕਾਫ਼ੀ ਆਸਾਨ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਇੱਕ ਦੂਜੀ ਵਿਕਲਪਿਕ ਪਹੁੰਚ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਵਿੱਚ ElasticSearch ਸਕ੍ਰੌਲ API ਜ Cosmos DB - ਜਦੋਂ ਇੱਕ ਬੇਨਤੀ, ਡੇਟਾ ਤੋਂ ਇਲਾਵਾ, ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪਛਾਣਕਰਤਾ ਵਾਪਸ ਕਰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਡੇਟਾ ਦਾ ਅਗਲਾ ਹਿੱਸਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਇਸ ਪਛਾਣਕਰਤਾ ਦਾ ਬੇਅੰਤ ਜੀਵਨ ਕਾਲ ਹੈ (ਜਿਵੇਂ ਕਿ Comsos DB ਵਿੱਚ), ਤਾਂ ਇਹ ਪੰਨਿਆਂ ਦੇ ਵਿਚਕਾਰ ਕ੍ਰਮਵਾਰ ਤਬਦੀਲੀ ਦੇ ਨਾਲ ਪੇਜਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ ਹੈ (ਉਪਰੋਕਤ ਵਿਕਲਪ #2)। ਇਸਦੇ ਸੰਭਵ ਨੁਕਸਾਨ: ਇਹ ਸਾਰੇ DBMS ਵਿੱਚ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ; ਨਤੀਜੇ ਵਜੋਂ ਅਗਲੇ-ਚੰਕ ਪਛਾਣਕਰਤਾ ਦਾ ਇੱਕ ਸੀਮਤ ਜੀਵਨ ਕਾਲ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਇੰਟਰੈਕਸ਼ਨ (ਜਿਵੇਂ ਕਿ ElasticSearch ਸਕ੍ਰੌਲ API) ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ।

ਗੁੰਝਲਦਾਰ ਫਿਲਟਰਿੰਗ

ਆਓ ਕੰਮ ਨੂੰ ਹੋਰ ਗੁੰਝਲਦਾਰ ਕਰੀਏ. ਮੰਨ ਲਓ ਕਿ ਅਖੌਤੀ ਪਹਿਲੂ ਖੋਜ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜੋ ਔਨਲਾਈਨ ਸਟੋਰਾਂ ਤੋਂ ਹਰ ਕਿਸੇ ਲਈ ਬਹੁਤ ਜਾਣੂ ਹੈ. ਆਰਡਰ ਟੇਬਲ 'ਤੇ ਆਧਾਰਿਤ ਉਪਰੋਕਤ ਉਦਾਹਰਨਾਂ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਆਖਿਆਤਮਕ ਨਹੀਂ ਹਨ, ਇਸ ਲਈ ਆਓ ਐਡਵੈਂਚਰ ਵਰਕਸ ਡੇਟਾਬੇਸ ਤੋਂ ਉਤਪਾਦ ਸਾਰਣੀ 'ਤੇ ਸਵਿਚ ਕਰੀਏ:

ਪਹਿਲੂ ਖੋਜ ਦੇ ਪਿੱਛੇ ਕੀ ਵਿਚਾਰ ਹੈ? ਤੱਥ ਇਹ ਹੈ ਕਿ ਹਰੇਕ ਫਿਲਟਰ ਤੱਤ ਲਈ ਇਸ ਮਾਪਦੰਡ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਾਲੇ ਰਿਕਾਰਡਾਂ ਦੀ ਗਿਣਤੀ ਦਿਖਾਈ ਗਈ ਹੈ ਹੋਰ ਸਾਰੀਆਂ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਚੁਣੇ ਗਏ ਫਿਲਟਰਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ.

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਅਸੀਂ ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ ਬਾਈਕਸ ਸ਼੍ਰੇਣੀ ਅਤੇ ਰੰਗ ਕਾਲਾ ਚੁਣਦੇ ਹਾਂ, ਤਾਂ ਸਾਰਣੀ ਵਿੱਚ ਸਿਰਫ਼ ਕਾਲੀਆਂ ਬਾਈਕ ਹੀ ਦਿਖਾਈ ਦੇਣਗੀਆਂ, ਪਰ:

• ਸ਼੍ਰੇਣੀਆਂ ਸਮੂਹ ਵਿੱਚ ਹਰੇਕ ਮਾਪਦੰਡ ਲਈ, ਉਸ ਸ਼੍ਰੇਣੀ ਦੇ ਉਤਪਾਦਾਂ ਦੀ ਸੰਖਿਆ ਕਾਲੇ ਰੰਗ ਵਿੱਚ ਦਿਖਾਈ ਜਾਵੇਗੀ।
• "ਰੰਗ" ਸਮੂਹ ਦੇ ਹਰੇਕ ਮਾਪਦੰਡ ਲਈ, ਇਸ ਰੰਗ ਦੇ ਸਾਈਕਲਾਂ ਦੀ ਗਿਣਤੀ ਦਿਖਾਈ ਜਾਵੇਗੀ।

ਇੱਥੇ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਲਈ ਨਤੀਜਾ ਆਉਟਪੁੱਟ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ:

ਜੇ ਤੁਸੀਂ "ਕੱਪੜੇ" ਸ਼੍ਰੇਣੀ ਦੀ ਵੀ ਜਾਂਚ ਕਰਦੇ ਹੋ, ਤਾਂ ਟੇਬਲ ਕਾਲੇ ਕੱਪੜੇ ਵੀ ਦਿਖਾਏਗਾ ਜੋ ਸਟਾਕ ਵਿੱਚ ਹਨ। "ਰੰਗ" ਭਾਗ ਵਿੱਚ ਕਾਲੇ ਉਤਪਾਦਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਵੀ ਨਵੀਆਂ ਸਥਿਤੀਆਂ ਦੇ ਅਨੁਸਾਰ ਮੁੜ ਗਿਣਿਆ ਜਾਵੇਗਾ, ਕੇਵਲ "ਸ਼੍ਰੇਣੀਆਂ" ਭਾਗ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲੇਗਾ... ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਹ ਉਦਾਹਰਣਾਂ ਆਮ ਪਹਿਲੂ ਖੋਜ ਐਲਗੋਰਿਦਮ ਨੂੰ ਸਮਝਣ ਲਈ ਕਾਫ਼ੀ ਹਨ।

ਆਓ ਹੁਣ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਇਸ ਨੂੰ ਰਿਲੇਸ਼ਨਲ ਆਧਾਰ 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਮਾਪਦੰਡ ਦੇ ਹਰੇਕ ਸਮੂਹ, ਜਿਵੇਂ ਕਿ ਸ਼੍ਰੇਣੀ ਅਤੇ ਰੰਗ, ਲਈ ਇੱਕ ਵੱਖਰੀ ਪੁੱਛਗਿੱਛ ਦੀ ਲੋੜ ਹੋਵੇਗੀ:

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

ਇਸ ਹੱਲ ਵਿੱਚ ਕੀ ਗਲਤ ਹੈ? ਇਹ ਬਹੁਤ ਸਰਲ ਹੈ - ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਾਲ ਮਾਪਦਾ ਨਹੀਂ ਹੈ। ਹਰੇਕ ਫਿਲਟਰ ਸੈਕਸ਼ਨ ਨੂੰ ਮਾਤਰਾਵਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਇੱਕ ਵੱਖਰੀ ਪੁੱਛਗਿੱਛ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਪੁੱਛਗਿੱਛਾਂ ਸਭ ਤੋਂ ਆਸਾਨ ਨਹੀਂ ਹਨ। ਔਨਲਾਈਨ ਸਟੋਰਾਂ ਵਿੱਚ, ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਕਈ ਦਰਜਨ ਫਿਲਟਰ ਸੈਕਸ਼ਨ ਹੋ ਸਕਦੇ ਹਨ, ਜੋ ਇੱਕ ਗੰਭੀਰ ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਦਾ ਹੋ ਸਕਦਾ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਬਿਆਨਾਂ ਤੋਂ ਬਾਅਦ ਮੈਨੂੰ ਕੁਝ ਹੱਲ ਪੇਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਰਥਾਤ:

• ਸਾਰੀਆਂ ਮਾਤਰਾਵਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਇੱਕ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਜੋੜੋ। ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਇਹ UNION ਕੀਵਰਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਭਵ ਹੈ, ਪਰ ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਜ਼ਿਆਦਾ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ - ਡੇਟਾਬੇਸ ਨੂੰ ਅਜੇ ਵੀ ਸਕ੍ਰੈਚ ਤੋਂ ਹਰੇਕ ਟੁਕੜੇ ਨੂੰ ਚਲਾਉਣਾ ਹੋਵੇਗਾ।
• ਕੈਸ਼ ਮਾਤਰਾਵਾਂ। ਇਹ ਮੈਨੂੰ ਲਗਭਗ ਹਰ ਵਾਰ ਸੁਝਾਅ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਮੈਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹਾਂ। ਚੇਤਾਵਨੀ ਇਹ ਹੈ ਕਿ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਅਸੰਭਵ ਹੈ. ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ 10 "ਪਹਿਲੂ" ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਦੇ 5 ਮੁੱਲ ਹਨ। ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ "ਮਾਮੂਲੀ" ਸਥਿਤੀ ਹੈ ਜੋ ਸਮਾਨ ਔਨਲਾਈਨ ਸਟੋਰਾਂ ਵਿੱਚ ਦੇਖੀ ਜਾ ਸਕਦੀ ਹੈ. ਇੱਕ ਪਹਿਲੂ ਤੱਤ ਦੀ ਚੋਣ 9 ਹੋਰਾਂ ਵਿੱਚ ਮਾਤਰਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ, ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਮਾਪਦੰਡਾਂ ਦੇ ਹਰੇਕ ਸੁਮੇਲ ਲਈ ਮਾਤਰਾਵਾਂ ਵੱਖਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਸਾਡੇ ਉਦਾਹਰਨ ਵਿੱਚ, ਕੁੱਲ 50 ਮਾਪਦੰਡ ਹਨ ਜੋ ਉਪਭੋਗਤਾ ਚੁਣ ਸਕਦਾ ਹੈ; ਇਸ ਲਈ, ਇੱਥੇ 250 ਸੰਭਾਵੀ ਸੰਜੋਗ ਹੋਣਗੇ। ਡੇਟਾ ਦੀ ਅਜਿਹੀ ਐਰੇ ਨੂੰ ਭਰਨ ਲਈ ਲੋੜੀਂਦੀ ਮੈਮੋਰੀ ਜਾਂ ਸਮਾਂ ਨਹੀਂ ਹੈ। ਇੱਥੇ ਤੁਸੀਂ ਇਤਰਾਜ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਕਹਿ ਸਕਦੇ ਹੋ ਕਿ ਸਾਰੇ ਸੰਜੋਗ ਅਸਲੀ ਨਹੀਂ ਹਨ ਅਤੇ ਉਪਭੋਗਤਾ ਘੱਟ ਹੀ 5-10 ਮਾਪਦੰਡਾਂ ਤੋਂ ਵੱਧ ਚੁਣਦਾ ਹੈ। ਹਾਂ, ਆਲਸੀ ਲੋਡਿੰਗ ਅਤੇ ਕੈਸ਼ ਨੂੰ ਸਿਰਫ ਉਹੀ ਮਾਤਰਾ ਵਿੱਚ ਕਰਨਾ ਸੰਭਵ ਹੈ ਜੋ ਕਦੇ ਚੁਣਿਆ ਗਿਆ ਹੈ, ਪਰ ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਚੋਣ ਹੋਣਗੇ, ਅਜਿਹਾ ਕੈਸ਼ ਘੱਟ ਕੁਸ਼ਲ ਹੋਵੇਗਾ ਅਤੇ ਜਵਾਬ ਸਮੇਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵਧੇਰੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੋਣਗੀਆਂ (ਖਾਸ ਕਰਕੇ ਜੇ ਡਾਟਾ ਸੈੱਟ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਹੈ)।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਅਜਿਹੀ ਸਮੱਸਿਆ ਦੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਕਾਫ਼ੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੱਲ ਹਨ ਜੋ ਅਨੁਮਾਨਤ ਤੌਰ 'ਤੇ ਡੇਟਾ ਦੀ ਵੱਡੀ ਮਾਤਰਾ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਵਿਕਲਪ ਲਈ, ਪਹਿਲੂਆਂ ਦੀ ਮੁੜ ਗਣਨਾ ਅਤੇ ਨਤੀਜਿਆਂ ਦੇ ਪੰਨੇ ਨੂੰ ਸਰਵਰ ਨੂੰ ਦੋ ਸਮਾਨਾਂਤਰ ਕਾਲਾਂ ਵਿੱਚ ਵੰਡਣਾ ਅਤੇ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵਿਵਸਥਿਤ ਕਰਨਾ ਸਮਝਦਾਰ ਹੈ ਕਿ ਪਹਿਲੂਆਂ ਦੁਆਰਾ ਡੇਟਾ ਲੋਡ ਕਰਨ ਨਾਲ ਡਿਸਪਲੇਅ ਵਿੱਚ "ਵਿਘਨ ਨਾ ਪਵੇ" ਖੋਜ ਨਤੀਜੇ.

• ਸੰਭਵ ਤੌਰ 'ਤੇ ਘੱਟ ਹੀ ਸੰਭਵ ਤੌਰ 'ਤੇ "ਪਹਿਲੂਆਂ" ਦੀ ਪੂਰੀ ਮੁੜ ਗਣਨਾ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ, ਹਰ ਵਾਰ ਖੋਜ ਮਾਪਦੰਡ ਬਦਲਣ 'ਤੇ ਹਰ ਚੀਜ਼ ਦੀ ਮੁੜ ਗਣਨਾ ਨਾ ਕਰੋ, ਸਗੋਂ ਮੌਜੂਦਾ ਸਥਿਤੀਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਨਤੀਜਿਆਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਲੱਭੋ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਦਿਖਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰੋ - "1425 ਰਿਕਾਰਡ ਮਿਲੇ, ਦਿਖਾਓ?" ਉਪਭੋਗਤਾ ਜਾਂ ਤਾਂ ਖੋਜ ਸ਼ਬਦਾਂ ਨੂੰ ਬਦਲਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ ਜਾਂ "ਸ਼ੋ" ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਦਾ ਹੈ। ਕੇਵਲ ਦੂਜੇ ਕੇਸ ਵਿੱਚ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਸਾਰੇ "ਪਹਿਲੂਆਂ" 'ਤੇ ਮਾਤਰਾਵਾਂ ਦੀ ਮੁੜ ਗਣਨਾ ਕਰਨ ਲਈ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਦੇਖ ਸਕਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਨਤੀਜਿਆਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਅਤੇ ਇਸਦੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਬੇਨਤੀ ਨਾਲ ਨਜਿੱਠਣਾ ਹੋਵੇਗਾ. ਇਹ ਵਿਧੀ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਔਨਲਾਈਨ ਸਟੋਰਾਂ ਵਿੱਚ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ. ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਹ ਇਸ ਸਮੱਸਿਆ ਦਾ ਇਲਾਜ ਨਹੀਂ ਹੈ, ਪਰ ਸਧਾਰਨ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਇੱਕ ਚੰਗਾ ਸਮਝੌਤਾ ਹੋ ਸਕਦਾ ਹੈ.
• ਨਤੀਜੇ ਲੱਭਣ ਅਤੇ ਪਹਿਲੂਆਂ ਦੀ ਗਿਣਤੀ ਕਰਨ ਲਈ ਖੋਜ ਇੰਜਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਜਿਵੇਂ ਕਿ ਸੋਲਰ, ਇਲਾਸਟਿਕ ਖੋਜ, ਸਪਿੰਕਸ ਅਤੇ ਹੋਰ। ਇਹ ਸਾਰੇ "ਪਹਿਲੂ" ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਉਲਟੇ ਸੂਚਕਾਂਕ ਦੇ ਕਾਰਨ ਇਹ ਕਾਫ਼ੀ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕਰਦੇ ਹਨ। ਖੋਜ ਇੰਜਣ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਉਹ ਆਮ-ਉਦੇਸ਼ ਵਾਲੇ ਡੇਟਾਬੇਸ ਨਾਲੋਂ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਕਿਉਂ ਹੁੰਦੇ ਹਨ, ਇੱਥੇ ਕਿਹੜੇ ਅਭਿਆਸ ਅਤੇ ਨੁਕਸਾਨ ਹਨ - ਇਹ ਇੱਕ ਵੱਖਰੇ ਲੇਖ ਲਈ ਇੱਕ ਵਿਸ਼ਾ ਹੈ. ਇੱਥੇ ਮੈਂ ਇਸ ਤੱਥ ਵੱਲ ਤੁਹਾਡਾ ਧਿਆਨ ਖਿੱਚਣਾ ਚਾਹਾਂਗਾ ਕਿ ਖੋਜ ਇੰਜਣ ਮੁੱਖ ਡੇਟਾ ਸਟੋਰੇਜ ਦਾ ਬਦਲ ਨਹੀਂ ਹੋ ਸਕਦਾ; ਇਹ ਇੱਕ ਜੋੜ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ: ਮੁੱਖ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੋਈ ਵੀ ਬਦਲਾਅ ਜੋ ਖੋਜ ਲਈ ਢੁਕਵੇਂ ਹਨ ਖੋਜ ਸੂਚਕਾਂਕ ਵਿੱਚ ਸਮਕਾਲੀ ਹੁੰਦੇ ਹਨ; ਖੋਜ ਇੰਜਣ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਖੋਜ ਇੰਜਣ ਨਾਲ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ ਅਤੇ ਮੁੱਖ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਕਰਦਾ। ਇੱਥੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਇਸ ਸਮਕਾਲੀਕਰਨ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਸੰਗਠਿਤ ਕਰਨਾ ਹੈ। ਇਹ ਸਭ "ਪ੍ਰਤੀਕਿਰਿਆ ਸਮਾਂ" ਦੀਆਂ ਲੋੜਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇ ਮੁੱਖ ਡੇਟਾਬੇਸ ਵਿੱਚ ਤਬਦੀਲੀ ਅਤੇ ਖੋਜ ਵਿੱਚ ਇਸਦੇ "ਪ੍ਰਗਟਾਵੇ" ਵਿਚਕਾਰ ਸਮਾਂ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਸੇਵਾ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਹਰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਹਾਲ ਹੀ ਵਿੱਚ ਬਦਲੇ ਹੋਏ ਰਿਕਾਰਡਾਂ ਦੀ ਖੋਜ ਕਰਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਭ ਤੋਂ ਘੱਟ ਸੰਭਵ ਜਵਾਬ ਸਮਾਂ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕੁਝ ਅਜਿਹਾ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ ਲੈਣ-ਦੇਣ ਆਊਟਬਾਕਸ ਖੋਜ ਸੇਵਾ ਨੂੰ ਅੱਪਡੇਟ ਭੇਜਣ ਲਈ।

ਸਿੱਟਾ

1. ਸਰਵਰ-ਸਾਈਡ ਪੇਜਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪੇਚੀਦਗੀ ਹੈ ਅਤੇ ਸਿਰਫ ਤੇਜ਼ੀ ਨਾਲ ਵਧਣ ਵਾਲੇ ਜਾਂ ਸਿਰਫ਼ ਵੱਡੇ ਡੇਟਾ ਸੈੱਟਾਂ ਲਈ ਅਰਥ ਰੱਖਦਾ ਹੈ। "ਵੱਡੇ" ਜਾਂ "ਤੇਜੀ ਨਾਲ ਵਧ ਰਹੇ" ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਕੋਈ ਬਿਲਕੁਲ ਸਹੀ ਵਿਅੰਜਨ ਨਹੀਂ ਹੈ, ਪਰ ਮੈਂ ਇਸ ਪਹੁੰਚ ਦੀ ਪਾਲਣਾ ਕਰਾਂਗਾ:
   • ਜੇਕਰ ਡੇਟਾ ਦਾ ਪੂਰਾ ਸੰਗ੍ਰਹਿ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਸਰਵਰ ਦੇ ਸਮੇਂ ਅਤੇ ਨੈਟਵਰਕ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਸਾਈਡ 'ਤੇ ਪੇਜਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ।
   • ਅਜਿਹੀ ਸਥਿਤੀ ਹੋ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ ਕੋਈ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਕਿਉਂਕਿ ਬਹੁਤ ਘੱਟ ਡੇਟਾ ਹੈ, ਪਰ ਡੇਟਾ ਸੰਗ੍ਰਹਿ ਲਗਾਤਾਰ ਵਧ ਰਿਹਾ ਹੈ. ਜੇਕਰ ਭਵਿੱਖ ਵਿੱਚ ਡਾਟਾ ਦਾ ਕੁਝ ਸੈੱਟ ਹੁਣ ਪਿਛਲੇ ਬਿੰਦੂ ਨੂੰ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਰੰਤ ਪੇਜਿੰਗ ਸ਼ੁਰੂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ।
2. ਜੇਕਰ ਕਾਰੋਬਾਰ ਦੇ ਨਤੀਜਿਆਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਜਾਂ ਪੰਨਾ ਨੰਬਰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਕੋਈ ਸਖ਼ਤ ਲੋੜ ਨਹੀਂ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਖੋਜ ਇੰਜਣ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹਨਾਂ ਬਿੰਦੂਆਂ ਨੂੰ ਲਾਗੂ ਨਾ ਕਰਨਾ ਅਤੇ ਵਿਕਲਪ #2 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਬਿਹਤਰ ਹੈ।
3. ਜੇਕਰ ਪਹਿਲੂ ਖੋਜ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਕੁਰਬਾਨ ਕੀਤੇ ਬਿਨਾਂ ਦੋ ਵਿਕਲਪ ਹਨ:
   • ਹਰ ਵਾਰ ਖੋਜ ਮਾਪਦੰਡ ਬਦਲਣ 'ਤੇ ਸਾਰੀਆਂ ਮਾਤਰਾਵਾਂ ਦੀ ਮੁੜ ਗਣਨਾ ਨਾ ਕਰੋ।
   • ਸੋਲਰ, ਇਲਾਸਟਿਕ ਸਰਚ, ਸਪਿੰਕਸ ਅਤੇ ਹੋਰ ਵਰਗੇ ਖੋਜ ਇੰਜਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਪਰ ਇਹ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਮੁੱਖ ਡੇਟਾਬੇਸ ਦਾ ਬਦਲ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਅਤੇ ਖੋਜ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਮੁੱਖ ਸਟੋਰੇਜ਼ ਦੇ ਜੋੜ ਵਜੋਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
4. ਨਾਲ ਹੀ, ਪਹਿਲੂ ਖੋਜ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਖੋਜ ਨਤੀਜੇ ਪੰਨੇ ਦੀ ਮੁੜ ਪ੍ਰਾਪਤੀ ਅਤੇ ਗਿਣਤੀ ਨੂੰ ਦੋ ਸਮਾਨਾਂਤਰ ਬੇਨਤੀਆਂ ਵਿੱਚ ਵੰਡਣ ਦਾ ਮਤਲਬ ਬਣਦਾ ਹੈ. ਮਾਤਰਾਵਾਂ ਦੀ ਗਿਣਤੀ ਕਰਨ ਵਿੱਚ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਨਾਲੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਨਤੀਜੇ ਉਪਭੋਗਤਾ ਲਈ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।
5. ਜੇਕਰ ਤੁਸੀਂ ਖੋਜ ਕਰਨ ਲਈ ਇੱਕ SQL ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਸ ਹਿੱਸੇ ਨਾਲ ਸਬੰਧਤ ਕਿਸੇ ਵੀ ਕੋਡ ਤਬਦੀਲੀ ਨੂੰ ਡੇਟਾ ਦੀ ਉਚਿਤ ਮਾਤਰਾ (ਲਾਈਵ ਡੇਟਾਬੇਸ ਵਿੱਚ ਵਾਲੀਅਮ ਤੋਂ ਵੱਧ) 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਂਚਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਦੀਆਂ ਸਾਰੀਆਂ ਸਥਿਤੀਆਂ, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ "ਲਾਈਵ" 'ਤੇ ਪੁੱਛਗਿੱਛ ਦੇ ਅਮਲ ਦੇ ਸਮੇਂ ਦੀ ਨਿਗਰਾਨੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਵੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਭਾਵੇਂ ਵਿਕਾਸ ਦੇ ਪੜਾਅ 'ਤੇ ਪੁੱਛਗਿੱਛ ਯੋਜਨਾਵਾਂ ਦੇ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਸੀ, ਜਿਵੇਂ ਕਿ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਵਧਦੀ ਹੈ, ਸਥਿਤੀ ਧਿਆਨ ਨਾਲ ਬਦਲ ਸਕਦੀ ਹੈ।

ਸਰੋਤ: www.habr.com