30 ਅਕਤੂ 2025·8 ਮਿੰਟ
Raymond Boyce ਅਤੇ ਸ਼ੁਰੂਆਤੀ SQL: ਪ੍ਰਯੋਗਿਕ ਫੈਸਲੇ ਜੋ ਕੰਮ ਕਰ ਗਏ
Raymond Boyce ਦੀ ਸ਼ੁਰੂਆਤੀ SQL ਵਿੱਚ ਭੂਮਿਕਾ ਅਤੇ ਉਹ ਪ੍ਰਯੋਗਿਕ ਡਿਜ਼ਾਈਨ ਫੈਸਲੇ—joins, grouping, NULLs ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ—ਜਿਹੜਿਆਂ ਨੇ ਇਹ ਅੰਗਠੀ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਵਰਤਣਯੋਗ ਬਣਾਈ।
Raymond Boyce ਦੀ ਸ਼ੁਰੂਆਤੀ SQL ਵਿੱਚ ਭੂਮਿਕਾ ਅਤੇ ਉਹ ਪ੍ਰਯੋਗਿਕ ਡਿਜ਼ਾਈਨ ਫੈਸਲੇ—joins, grouping, NULLs ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ—ਜਿਹੜਿਆਂ ਨੇ ਇਹ ਅੰਗਠੀ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਵਰਤਣਯੋਗ ਬਣਾਈ।
Raymond Boyce IBM ਦੇ System R ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ 1970 ਦੇ ਦਹਾਕੇ ਦੇ ਮੁੱਖ ਗਵੈਸ਼ਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ—ਉਹ ਯਤਨ ਜਿਸ ਨੇ ਰਿਲੇਸ਼ਨਲ ਡੈਟਾਬੇਸ ਸਿਧਾਂਤ ਨੂੰ ਉਸ ਰੂਪ ਵਿੱਚ ਲਿਆਂਦਾ ਜੋ ਲੋਕ ਕੰਮ 'ਤੇ ਵਰਤ ਸਕਦੇ ਸਨ। ਜੇ ਤੁਸੀਂ ਕਦੇ SELECT ਕੁਐਰੀ ਲਿਖੀ ਹੈ, GROUP BY ਦਾ ਫਾਇਦਾ ਉਠਾਇਆ ਹੈ, ਜਾਂ ਇੱਕ ਡੈਟਾਬੇਸ 'ਤੇ ਨਿਰਭਰ ਰਹੇ ਹੋ ਤਾਂ ਅਪਡੇਟਸ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਲਈ, ਤਾਂ ਤੁਸੀਂ ਉਹੀ ਵਿਚਾਰ ਵਰਤ ਰਹੇ ਹੋ ਜੋ ਉਸ ਸਮੇਂ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ।
ਸੰਭਵ ਹੈ ਇਹ ਗੱਲ ਨਿਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਏ ਕਿ SQL ਨੇ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਾਮਯਾਬੀ ਨਹੀਂ ਪਾਈ ਕਿ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਸੁੰਦਰ ਸੀ। ਇਸ ਦੀ ਕਾਮਯਾਬੀ ਦੀ ਇੱਕ ਵੱਡੀ ਵਜ੍ਹਾ ਇਹ ਸੀ ਕਿ ਸ਼ੁਰੂਆਤੀ ਡਿਜ਼ਾਈਨਰ—ਜਿਨ੍ਹਾਂ ਵਿੱਚ Boyce ਵੀ ਸ਼ਾਮਿਲ ਸਨ—ਨਿਰੰਤਰ ਇਕ ਪ੍ਰਯੋਗਿਕ ਸਵਾਲ ਪੁੱਛਦੇ ਰਹੇ: ਅਸਲ ਸੰਸਥਾਵਾਂ, ਅਸਲ ਡਾਟਾ, ਡੈਡਲਾਈਨ ਅਤੇ ਸੀਮਾਵਾਂ ਨਾਲ ਰਿਹਾ ਹੋਇਆ ਰਿਲੇਸ਼ਨਲ ਕੁਐਰੀੰਗ ਕਿਵੇਂ ਕਾਰਗਰ ਬਣਾਇਆ ਜਾਵੇ? ਇਸ ਪੋਸਟ ਦਾ ਫੋਕਸ ਉਹਨਾਂ ਪ੍ਰਯੋਗਿਕ ਫੈਸਲਿਆਂ 'ਤੇ ਹੈ: ਉਹ ਫੀਚਰ ਜੋ ਵਿਵਹਾਰਕ ਤੌਰ 'ਤੇ ਐਨਾਲਿਸਟ, ਡਿਵੈਲਪਰ ਅਤੇ ਬਿਜ਼ਨਸ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਹੀ ਪ੍ਰਣਾਲੀ ਸਾਂਝਾ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਗਹਿਰੀ ਅਕਾਦਮਿਕ ਪਿਛੋਕੜ ਦੇ।
ਰਿਲੇਸ਼ਨਲ ਸਿਧਾਂਤ ਬਹੁਤ ਕੁਝ ਵਾਅਦਾ ਕਰਦਾ ਸੀ: ਡਾਟਾ ਨੂੰ ਟੇਬਲਾਂ ਵਿੱਚ ਸਟੋਰ ਕਰੋ, ਘੋਸ਼ਣਾਤਮਕ ਸਵਾਲ ਪੁੱਛੋ, ਅਤੇ ਰਿਕਾਰਡਾਂ ਵਿੱਚ ਹੱਥੋਂ-ਹੱਥ ਨੈਵੀਗੇਸ਼ਨ ਤੋਂ ਬਚੋ। ਪਰ ਸੰਸਥਾਵਾਂ ਨੂੰ ਸਿਰਫ਼ ਵਾਅਦੇ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਉਨ੍ਹਾਂ ਨੂੰ ਐਸੀ ਭਾਸ਼ਾ ਚਾਹੀਦੀ ਸੀ ਜੋ:
Boyce ਦੀ ਮਹੱਤਤਾ ਇਸ ਅਨੁਵਾਦਕਾਰੀ ਕੰਮ ਨਾਲ ਜੁੜੀ ਹੈ: ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਧਾਰਣਾ ਨੂੰ ਇੱਕ ਐਸੇ ਟੂਲ ਵਿੱਚ ਬਦਲਣਾ ਜੋ ਆਮ ਵਰਕਫ਼ਲੋਜ਼ ਵਿੱਚ ਫਿੱਟ ਬੈਠੇ।
ਤੁਸੀਂ ਸ਼ੁਰੂਆਤੀ SQL ਦੇ ਡਿਜ਼ਾਈਨ ਫੈਸਲਿਆਂ ਦੀ ਇਕ ਇਤਿਹਾਸ-ਜਾਣੂ, ਸਾਦੀ-ਅੰਗ੍ਰੇਜ਼ੀ ਸੈਰ ਲੈਣ ਵਾਲਾ ਵਾਕ-ਵਿਵਰਣ ਪੜ੍ਹੋਗੇ—ਕਿਉਂ ਭਾਸ਼ਾ ਐਸਾ ਦਿਖਦੀ ਹੈ ਜਿਵੇਂ ਦਿਖਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਤਰਾਜੂ ਚੁੱਕੇ ਗਏ ਤਾਂ ਜੋ ਇਸ ਨੂੰ ਵਰਤਣਾ ਆਸਾਨ ਰਹੇ। ਅਸੀਂ joins, aggregation, views, transactions ਅਤੇ optimization ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਉਹਨਾਂ ਸੰਸਥਾਗਤ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਜੋੜਾਂਗੇ ਜੋ ਇਨ੍ਹਾਂ ਨੇ ਹੱਲ ਕੀਤੀਆਂ।
ਇਹ ਕੋਈ ਨਾਇਕ ਕਹਾਣੀ ਜਾਂ "ਇੱਕ ਹੀ ਐਜਾਦਕਾਰ" ਦਾ ਮਿਥ ਨਹੀਂ ਹੈ। SQL ਨੂੰ ਕਈ ਲੋਕਾਂ ਅਤੇ ਸੀਮਾਵਾਂ ਨੇ ਸ਼ੇਪ ਕੀਤਾ; ਇਸਦੇ ਵਿਕਾਸ ਵਿੱਚ ਸਮਝੌਤੇ ਸ਼ਾਮਿਲ ਸਨ। ਅਸੀਂ Boyce ਦੀ ਪੂਰੀ ਜੀਵਨੀ ਜਾਂ System R ਦਾ ਪੂਰਾ ਅਕਾਦਮਿਕ ਇਤਿਹਾਸ ਵੀ ਨਹੀਂ ਦੇਵਾਂਗੇ। ਮਨੋਰਥ ਸਧਾਰਨ ਹੈ: ਜਾਣੋ ਉਹ ਪ੍ਰਯੋਗਿਕ ਫੈਸਲੇ ਜੋ ਕੰਮ ਕੀਤੇ—ਅਤੇ ਅਧੁਨਿਕ ਟੀਮਾਂ ਉਹਨਾਂ ਤੋਂ ਕੀ ਸਿੱਖ ਸਕਦੀਆਂ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਸਿਧਾਂਤ ਇਕ ਸਾਫ਼ ਵਾਅਦਾ ਲੈ ਕੇ ਆਇਆ: ਤਥਾਂ ਨੂੰ ਟੇਬਲਾਂ ਵਿੱਚ ਰੱਖੋ, ਸੰਬੰਧ ਲੋਜਿਕਲ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕਰੋ, ਅਤੇ ਸਿਸਟਮ ਸਹੀ ਜਵਾਬ ਪਾਉਣ ਲਈ ਖੋਜ ਕਰੇ। ਕਾਗਜ਼ 'ਤੇ, ਇਹ ਡਾਟਾ ਪ੍ਰਬੰਧਨ ਨੂੰ ਗਣਿਤ-ਜਿਹਾ ਨਿਯਮਾਂ ਤੱਕ ਘਟਾ ਦਿੰਦਾ ਸੀ। ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਤਾਂ ਸੰਸਥਾਵਾਂ ਕਾਗਜ਼ 'ਤੇ ਨਹੀਂ ਰਹਿੰਦੀਆਂ—ਉਹਨਾਂ ਕੋਲ ਪੇਰੋਲ ਫਾਇਲਾਂ, ਇਨਵੈਂਟਰੀ ਲਿਸਟਾਂ, ਗੰਦ ਕੋਡ, ਅਧੂਰੇ ਰਿਕਾਰਡ ਅਤੇ ਰਿਪੋਰਟ ਜਾਰੀ ਕਰਨ ਦਾ ਨਿੱਤ-ਭਾਰੀ ਦਬਾਅ ਹੁੰਦਾ ਹੈ ਬਿਨਾਂ ਹਰ ਵਾਰ ਪ੍ਰੋਗਰਾਮ ਦੁਬਾਰਾ ਲਿਖੇ।
ਉਹ ਖਾਈ—ਸੁੰਦਰ ਵਿਚਾਰ ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ ਪ 시스템 ਦੇ ਵਿਚਕਾਰ—ਸ਼ੁਰੂਆਤੀ SQL ਨੇ ਆਪਣੀ ਜਗ੍ਹਾ ਬਣਾਈ। ਗਵੈਸ਼ਕ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਰਹੇ ਸਨ ਕਿ ਰਿਲੇਸ਼ਨਲ ਡੈਟਾਬੇਸ ਮੌਜੂਦ ਹੋ ਸਕਦੇ ਹਨ; ਉਨ੍ਹਾਂ ਨੂੰ ਦਿਖਾਉਣਾ ਪੈ ਰਿਹਾ ਸੀ ਕਿ ਉਹ ਅਸਲ ਵਰਕਲੋਡ ਅਤੇ ਅਸਲ ਲੋਕਾਂ ਨਾਲ ਜੀਉਣ-ਰਹਿ ਸਕਦੇ ਹਨ।
IBM ਦਾ System R ਪ੍ਰੋਜੇਕਟ ਇਸ ਦੀ ਪਰਖ ਸੀ। ਇਸਨੇ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਨੂੰ ਇਕ ਐਸੇ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜੋ ਅਪਰੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਬੈਂਚਮਾਰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਅਤੇ ਸਾਂਝੇ ਮਸ਼ੀਨਾਂ 'ਤੇ ਚਲਾਇਆ ਜਾ ਸਕਦਾ। ਇਸਦਾ ਅਰਥ ਸੀ ਪੂਰੇ ਚੇਨ ਨੂੰ ਬਣਾਉਣਾ: ਸਟੋਰੇਜ਼ ਸਟ੍ਰਕਚਰ, ਇੱਕ ਕੁਐਰੀ ਪ੍ਰੋਸੈਸਰ, concurrency control, ਅਤੇ—ਅਹਮ—ਇੱਕ ਭਾਸ਼ਾ ਜੋ ਸਿਖਾਈ ਜਾ ਸਕੇ, ਟਾਈਪ ਕੀਤੀ ਜਾ ਸਕੇ ਅਤੇ ਰੀਪੀਟ ਕੀਤੀ ਜਾ ਸਕੇ।
ਸ਼ੁਰੂਆਤੀ SQL ਨੂੰ ਪਹਿਲਾਂ SEQUEL (Structured English Query Language) ਦੇ ਨਾਮ ਨਾਲ ਜਾਣਿਆ ਜਾਂਦਾ ਸੀ। ਇਹ ਨਾਮ ਇਸ ਮਕਸਦ ਨੂੰ ਦਰਸਾਂਦਾ ਸੀ: ਏਕੋ ਜਿਹੀ ਕੁਐਰੀ ਸਿੰਟੈਕਸ ਜੋ ਕਾਰੋਬਾਰੀ ਯੂਜ਼ਰਾਂ ਦੇ ਸਵਾਲ ਪੁੱਛਣ ਦੇ ਢੰਗ ਦੇ ਨੇੜੇ ਮਹਿਸੂਸ ਹੋਵੇ, ਫਿਰ ਵੀ ਸਿਸਟਮ ਲਈ ਨਿਸ਼ਚਿਤ ਆਪਰੇਸ਼ਨਾਂ ਨਾਲ ਮੇਪ ਹੋ ਸਕੇ।
System R ਬਹੁਤ ਪ੍ਰਯੋਗਿਕ ਸੀਮਾਵਾਂ ਹੇਠਾਂ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਜਿਸ ਨੇ ਅਨੁਸ਼ਾਸਨ ਲਿਆ:
ਇਹ ਸੀਮਾਵਾਂ SQL ਨੂੰ ਇੱਕ ਐਸੇ ਅੰਦਾਜ਼ ਵੱਲ ਧੱਕਦੀਆਂ ਰਹੀਆਂ ਜਿਸ ਨੇ ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਨਿਆਂਯੋਗ ਨਿਯਮਾਂ ਦੇ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਇਆ—ਜਿਹੜਾ joins, grouping ਅਤੇ transaction ਸੁਰੱਖਿਆ ਵਰਗੇ ਫੀਚਰਾਂ ਲਈ ਮੰਜਿਲ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰਯੋਗਿਕ ਤੌਰ 'ਤੇ ਲੈਬ ਤੋਂ ਬਾਹਰ ਵੀ ਕੰਮ ਕਰ ਸਕਣ।
ਸ਼ੁਰੂਆਤੀ SQL ਸਿਰਫ਼ ਇਸ ਲਈ ਕਾਮਯਾਬ ਨਹੀਂ ਹੋਇਆ ਕਿ ਇਹ ਰਿਲੇਸ਼ਨਲ ਸਿਧਾਂਤ ਨਾਲ ਮਿਲਦਾ ਸੀ—ਇਸ ਲਈ ਵੀ ਕਿ ਇਹ ਇਕ ਸਾਂਝੀ ਕੰਮਕਾਜੀ ਭਾਸ਼ਾ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਸੀ। Raymond Boyce ਅਤੇ System R ਟੀਮ ਨੇ “ਵਰਤੋਂਯੋਗ” ਨੂੰ ਇੱਕ ਮੂਲ ਲੋੜ ਮੰਨੀ: ਇੱਕ ਕੁਐਰੀ ਐਸੀ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ ਜੋ ਲੋਕ ਪੜ੍ਹ ਸਕਣ, ਲਿਖ ਸਕਣ, ਰਿਵਿਊ ਕਰ ਸਕਣ ਅਤੇ ਸਮੇਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਸੰਭਾਲ ਸਕਣ।
SQL ਨੂੰ ਕਈ ਦਰਸ਼ਕਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ:
ਇਹ ਮਿਲਾਪ SQL ਨੂੰ ਇੱਕ ਐਸੇ ਅੰਦਾਜ਼ ਵੱਲ ਧੱਕਦਾ ਹੈ ਜੋ "select ਇਹ ਕਾਲਮਾਂ from ਇਹ ਟੇਬਲਾਂ where..." ਵਰਗੇ ਸੰਰਚਿਤ ਬੇਨਤੀ ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਨਾ ਕਿ ਹੇਠਲੇ-ਪੱਧਰੀ ਪ੍ਰੋਸੀਜਰਲ ਕੋਡ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਕੁਐਰੀ ਭਾਸ਼ਾ ਹੱਥ ਦੇ ਰੱਖਣ ਵਾਲੇ ਮਾਮਲੇ ਨੂੰ ਸਹਾਰਾ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ: ਇੱਕ ਰਿਪੋਰਟ ਕੁਐਰੀ ਆਡਿੱਟ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ; ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਕੁਐਰੀ ਡੈਸ਼ਬੋਰਡ ਦੀ ਨੀਂਦ ਬਣ ਜਾਂਦੀ ਹੈ; ਕੋਈ ਨਵਾਂ ਵਿਅਕਤੀ ਮਹੀਨਿਆਂ ਬਾਅਦ ਵਾਰੀ ਨੂੰ ਵਾਰਖੰਡ ਦੇ ਜ਼ਿੰਮੇਵਾਰ ਬਣਦਾ ਹੈ। SQL ਦੀ ਘੋਸ਼ਣਾਤਮਕ ਸ਼ੈਲੀ ਇਸ ਹਕੀਕਤ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਕਿਵੇਂ ਰੋਜ਼ਾਂ ਲੱਭਣੇ ਹਨ—ਕਦਮ-ਦਰ-ਕਦਮ ਨਹੀਂ—ਇਸਦੀ ਬਜਾਏ ਤੁਸੀਂ ਇਹ ਵਰਣਨ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਡੈਟਾਬੇਸ ਯੋਜਨਾ ਨਿਰਣਾ ਕਰਦਾ ਹੈ।
SQL ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਣ ਦਾ ਅਰਥ ਸੀ ਕਿ ਕੁਝ ਤਰਾਜੂ ਮਨਜ਼ੂਰ ਕਰਨੇ ਪਏ:
ਇਹ ਉਦੇਸ਼ ਉਹਨਾਂ ਕੰਮਾਂ ਵਿੱਚ ਦਿਸਦਾ ਹੈ ਜੋ SQL ਨੇ ਰੋਜ਼ਾਨਾ ਰੁਟੀਨ ਬਣਾਏ: ਦੌਰਾਨੀ ਰਿਪੋਰਟਾਂ, ਟ੍ਰੇਸੇਬਲ ਆਡਿਟ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਓਪਰੇਸ਼ਨਲ ਕੁਐਰੀਆਂ ਜੋ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਹਨ। ਮਕਸਦ ਸੁੰਦਰਤਾ ਖੁਦ ਨਹੀਂ ਸੀ—ਮੁੱਖ ਮਕਸਦ ਰਿਲੇਸ਼ਨਲ ਡਾਟਾ ਨੂੰ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਲਈ ਵਰਤਣਯੋਗ ਬਣਾਉਣਾ ਸੀ ਜੋ ਇਸਦੇ ਜ਼ਿੰਮੇਵਾਰ ਹਨ।
SQL ਦੀ ਸ਼ੁਰੂਆਤੀ ਕਾਮਯਾਬੀ ਸਿਰਫ਼ ਚਤੁਰ ਕੁਐਰੀ ਸਿੰਟੈਕਸ ਦੀ ਬਜਾਏ ਇਹ ਦਿਤੀ ਗਈ ਸਾਂਝ ਵਾਲੀ ਤਰੀਕ ਸੀ ਕਿ ਉਹਨਾਂ ਦੀ ਡਾਟਾ ਕੀ ਹੈ। ਟੇਬਲ ਮਾਡਲ ਸੌਖਾ ਹੈ, ਵ੍ਹਾਈਟਬੋਰਡ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਦਰਸਾਉਣਯੋਗ ਹੈ, ਅਤੇ ਟੀਮਾਂ ਦਰਮਿਆਨ ਸਾਂਝਾ ਕਰਨ ਯੋਗ ਹੈ।
ਇੱਕ ਟੇਬਲ ਇਕ ਨਾਮਵਾਲੀ ਰਿਕਾਰਡਾਂ ਦਾ ਸੈੱਟ ਹੁੰਦਾ ਹੈ: customers, invoices, shipments ਵਗੈਰਹ।
ਹਰ ਰੋ ਇਕ ਰਿਕਾਰਡ ਹੁੰਦਾ (ਇੱਕ ਗਾਹਕ, ਇੱਕ ਇੰਵੌਇਸ)। ਹਰ ਕਾਲਮ ਉਸ ਰਿਕਾਰਡ ਦੀ ਇੱਕ ਖਾਸੀਅਤ ਹੁੰਦੀ (customer_id, invoice_date, total_amount)। ਇਹ ਗਰਿੱਡ ਮੈਟਾਫਰ ਮੈਟਚ ਕਰਦੀ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਕਾਰੋਬਾਰੀ ਯੂਜ਼ਰ ਸੂਚੀਆਂ, ਫਾਰਮ ਅਤੇ ਰਿਪੋਰਟਾਂ ਨੂੰ ਕਿਵੇਂ ਸੋਚਦੇ ਹਨ।
ਇੱਕ ਸਕੀਮਾ ਉਹ ਮੰਨਿਆ ਢਾਂਚਾ ਹੈ ਜੋ ਟੇਬਲਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੁੰਦਾ: ਟੇਬਲਾਂ ਦੇ ਨਾਮ, ਕਾਲਮ ਨਾਮ, ਡੇਟਾ ਟਾਈਪ ਅਤੇ ਸੰਬੰਧ। ਇਹ ਫਰਕ ਬਣਾਂਦਾ ਹੈ ਕਿ "ਸਾਡੇ ਕੋਲ ਕੁਝ ਸੇਲਜ਼ ਡਾਟਾ ਹੈ" ਅਤੇ "ਇੱਥੇ ਇਹ ਠੀਕ ਹੈ ਕਿ ਇੱਕ ਸੇਲ ਕੀ ਹਨ ਅਤੇ ਅਸੀਂ ਇਹ ਡਾਟਾ ਕਿਵੇਂ ਸਟੋਰ ਕਰਦੇ ਹਾਂ" ਵਿੱਚ।
ਨਿਰੰਤਰ naming ਅਤੇ types ਬਿਆਨਬੱਧਤਾ ਬਿਉਰੋਕਰੇਸੀ ਨਹੀਂ—ਇਹ ਉਹ ਹੈ ਜਿਸ ਨਾਲ ਟੀਮਾਂ ਸੁਖਾਦ ਬੇਨਤੀ-ਮਿਲਾਓਟ ਤੋਂ ਬਚਦੀਆਂ ਹਨ। ਜੇ ਇੱਕ ਸਿਸਟਮ ਤਤਾਰਾਂ ਨੂੰ ਟੈਕਸਟ ਵਜੋਂ ਰੱਖਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਅਸਲ date ਟਾਈਪ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਰਿਪੋਰਟਾਂ ਇਕ ਦੂਜੇ ਨਾਲ ਮਿਲਣਗੀਆਂ ਨਹੀਂ।
ਕਿਉਂਕਿ ਸਕੀਮਾ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਲੋਕ ਬਿਨਾਂ ਲਗਾਤਾਰ ਤਰਜਮਿਆਂ ਦੇ ਕੋਆਰਡੀਨੇਟ ਕਰ ਸਕਦੇ ਹਨ। ਵਿਸ਼ਲੇਸ਼ਕ ਕੁਐਰੀ ਲਿਖ ਸਕਦੇ ਹਨ ਜੋ ਪ੍ਰੋਡਕਟ ਮੈਨੇਜਰ ਰਿਵਿਊ ਕਰ ਸਕਦੇ ਹਨ। ਫਾਇਨੈਂਸ ਗਿਣਤੀਆਂ ਨੂੰ ਆਪਰੇਸ਼ਨ ਨਾਲ ਮਿਲਾ ਸਕਦੀ ਹੈ। ਅਤੇ ਜਦੋਂ ਕੋਈ ਨਵੀਂ ਟੀਮ ਪ੍ਰਣਾਲੀ ਵਾਰਸਦਾਰ ਬਣਦੀ ਹੈ, ਸਕੀਮਾ ਉਹ ਨਕਸ਼ਾ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਡਾਟਾ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤੀ SQL ਵਿੱਡਿਆਉਂਦੀਆਂ ਹਕੀਕਤਾਂ ਨਾਲ ਰੂਬਰੂ ਹੋ ਕੇ ਫੈਸਲੇ ਕੀਤੇ ਗਏ: ਡਾਟਾ ਦੀ ਗੁਣਵੱਤਾ ਬਦਲਦੀ ਰਹਿੰਦੀ ਹੈ, ਫੀਲਡਾਂ ਸਮੇਂ ਦੇ ਨਾਲ ਸ਼ਾਮਿਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਲੋੜਾਂ ਮਿਡ-ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਸਕੀਮਾਂ ਇਕ ਸਥਿਰ ਸਮਝੌਤੇ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ ਪਰ ਨਿਯੰਤਰਿਤ ਤਰ੍ਹਾਂ ਬਦਲ ਦੀ ਆਗਿਆ ਵੀ ਦਿੰਦੀਆਂ ਹਨ—ਕਾਲਮ ਜੋੜਨਾ, ਟਾਈਪ ਕੱਦਨਾ ਜਾਂ ਐਸੇ ਕੰਸਟ੍ਰੇਨਟ ਲਾਉਣਾ ਜੋ ਗਲਤ ਡਾਟਾ ਫੈਲਣ ਤੋਂ ਰੋਕਦੇ ਹਨ।
SQL ਦੇ ਸਭ ਤੋਂ ਦਿਰਘਤਮਕ ਵਿਚਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਸਵਾਲ ਇੱਕ ਸਥਿਰ ਸਜ਼ਾ-ਜਿਹੇ ਰੂਪ ਵਿੱਚ ਪੁੱਛੇ ਜਾ ਸਕਦੇ ਹਨ। ਸ਼ੁਰੂਆਤੀ SQL ਡਿਜ਼ਾਈਨਰ—Raymond Boyce ਸਮੇਤ—ਢਾਂਚਾ ਇਸ ਤਰ੍ਹਾਂ ਰੱਖਦੇ ਸਨ ਕਿ ਲੋਕ ਆਸਾਨੀ ਨਾਲ ਸਿੱਖ ਸਕਣ ਅਤੇ ਪਛਾਣ ਸਕਣ: SELECT … FROM … WHERE …।
ਉਸ ਪੇਸ਼ਗੀਰਤਾ ਦੀ ਮਹੱਤਤਾ ਸੋਚਣ ਤੋਂ ਵੱਧ ਹੈ। ਜਦ ਹਰ ਕੁਐਰੀ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਪੜ੍ਹਨਹਾਰ ਹਰ ਵਾਰੀ ਇੱਕੋ ਅਨੁਕ੍ਰਮ ਵਿੱਚ ਇਸ ਨੂੰ ਸਕੈਨ ਕਰ ਸਕਦਾ ਹੈ:
ਇਹ ਇੱਕਸਾਰਤਾ ਟ੍ਰੇਨਿੰਗ, ਕੋਡ ਰਿਵਿਊ ਅਤੇ ਹੈਂਡਆਫ਼ ਲਈ ਮਦਦਗਾਰ ਹੈ।
ਦੋ ਸਧਾਰਣ ਸੰਚਾਲਨ ਬਹੁਤ ਕੰਮ ਆਉਂਦੇ ਹਨ:
ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸੇਲਜ਼ ਮੈਨੇਜਰ ਪੁੱਛ ਸਕਦਾ ਹੈ: “ਇਸ ਤਿਮਾਹੀ ਵਿੱਚ ਖੁੱਲ੍ਹੇ ਐਕਟੀਵ ਖਾਤੇ ਦੀ ਸੂਚੀ ਦਿਖਾਓ।” SQL ਵਿੱਚ ਇਹ ਬੇਨਤੀ ਕੁਝ ਖੇਤਰਾਂ ਨੂੰ ਚੁਣ ਕੇ, ਟੇਬਲ ਦਾ ਨਾਮ ਦੱਸ ਕੇ ਅਤੇ ਤਾਰੀਖ ਤੇ ਸਥਿਤੀ ਫਿਲਟਰ ਲਾ ਕੇ ਸਧਾਰਣੀ ਤੌਰ 'ਤੇ ਨਕਸ਼ੇਬੰਦੀ ਹੋ ਜਾਂਦੀ ਹੈ—ਕੋਈ ਵਿਸ਼ੇਸ਼ ਪ੍ਰੋਗਰਾਮ ਲੂਪ ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਕਿਉਂਕਿ ਮੂਲ ਫਾਰਮ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਜੋੜਨਯੋਗ ਹੈ, ਇਹ joins, grouping, views ਅਤੇ transactions ਵਰਗੀਆਂ ਉੱਨਤ ਸਵੱਧਤਾਵਾਂ ਲਈ ਮੂਲ ਬਣ ਗਈ—ਬਿਨਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਜਟਿਲ ਪ੍ਰੋਸੀਜਰਲ ਕੋਡ ਵਿੱਚ ਫਸਾਉਣ ਦੇ। ਤੁਸੀਂ ਸਧਾਰਣ ਰਿਪੋਰਟਿੰਗ ਕੁਐਰੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਹੌਲੇ-ਹੌਲੇ ਵਧ ਸਕਦੇ ਹੋ, ਫਿਰ ਵੀ ਇਕੋ ਭਾਸ਼ਾ ਬੋਲਦੇ ਰਹਿੰਦੇ ਹੋ।
ਸੰਗਠਨਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਾਰਾ ਕਾਰੋਬਾਰ ਇੱਕ ਵਿਸ਼ਾਲ ਟੇਬਲ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦੀਆਂ। ਗਾਹਕ ਦਾ ਵੇਰਵਾ ਆਦੇਸ਼ਾਂ ਨਾਲ ਵੱਖ-ਵੱਖ ਤਰ੍ਹਾਂ ਬਦਲਦਾ ਹੈ। ਜਾਣਕਾਰੀ ਨੂੰ ਟੇਬਲਾਂ ਵਿੱਚ ਵੰਡਣ ਨਾਲ ਦੁਹਰਾਵ ਘਟਦਾ ਹੈ, ਪਰ ਜਦ ਤੁਸੀਂ ਇਕ ਉੱਤਰ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਫਿਰ ਮਿਲਾਉਣ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਦੋ ਟੇਬਲਾਂ ਦੀ:
ਜੇ ਤੁਸੀਂ “ਗਾਹਕ ਦਾ ਨਾਮ ਦੇ ਨਾਲ ਸਾਰੇ ਆਦੇਸ਼” ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ join ਚਾਹੀਦਾ ਹੈ: ਹਰ ਆਦੇਸ਼ ਨੂੰ ਉਸ ਗਾਹਕ ਰੋ ਨਾਲ ਮਿਲਾਓ ਜਿਸਦਾ identifier ਮਿਲਦਾ ਹੈ।
SELECT c.name, o.id, o.order_date, o.total
FROM orders o
JOIN customers c ON c.id = o.customer_id;
ਇੱਕੋ ਬਿਆਨ ਇੱਕ ਆਮ ਕਾਰੋਬਾਰੀ ਸਵਾਲ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਡਾਟਾ ਨੂੰ ਐਪ ਕੋਡ ਵਿੱਚ ਹੱਥੋਂ-ਹੱਥ ਜੋੜਨ ਦੇ।
Joins ਅਸਲ ਦੁਨੀਆ ਦੀ ਗੰਦਗੀ ਨੂੰ ਵੀ ਰੌਸ਼ਨ ਕਰਦੇ ਹਨ।
ਜੇ ਇੱਕ ਗਾਹਕ ਦੇ ਕਈ ਆਦੇਸ਼ ਹਨ, ਤਾਂ ਗਾਹਕ ਦਾ ਨਾਮ ਨਤੀਜੇ ਵਿੱਚ ਬਾਰ-ਬਾਰ ਦਿਖੇਗਾ। ਇਹ ਸਟੋਰੇਜ਼ ਵਿੱਚ “ਨਕਲ ਡਾਟਾ” ਨਹੀਂ ਹੈ—ਇਹ ਸਿਰਫ਼ ਦਿਖਾਈ ਦੇਣ ਦਾ ਤਰੀਕਾ ਹੈ ਜਦ ਸੰਬੰਧ ਇਕ-ਤੋਂ-ਅਨੇਕ ਹੋਵੇ।
ਗੁੰਮ ਹੋਏ ਮੇਚਾਂ ਦੇ ਨਾਲ ਕੀ? ਜੇ ਇੱਕ ਆਦੇਸ਼ ਦਾ customer_id ਮੌਜੂਦ ਨਹੀਂ ਹੈ (ਖਰਾਬ ਡਾਟਾ), ਤਾਂ inner join ਉਸ ਰੋ ਨੂੰ ਚੁੱਪ ਚਾਪ ਹਟਾ ਦੇਵੇਗਾ। ਇਕ left join ਆਦੇਸ਼ ਨੂੰ ਰੱਖੇਗਾ ਅਤੇ customer ਫੀਲਡਾਂ NULL ਵਜੋਂ ਦਿਖਾਏਗਾ:
SELECT o.id, c.name
FROM orders o
LEFT JOIN customers c ON c.id = o.customer_id;
ਇੱਥੇ ਡਾਟਾ ਇੰਟੀਗ੍ਰਿਟੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕੀਜ਼ ਅਤੇ ਕੰਸਟ੍ਰੇਨਟਸ ਸਿਰਫ਼ ਸਿਧਾਂਤ ਨੂੰ ਖੁਸ਼ ਨਹੀਂ ਕਰਦੇ; ਉਹ “ਅਨਾਥਾ” ਰੋਜ਼ਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ ਜੋ ਰਿਪੋਰਟਾਂ ਨੂੰ ਗਲਤ ਕਰ ਸਕਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤੀ SQL ਚੋਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੇ ਸੈੱਟ-ਅਧਾਰਤ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ: ਤੁਸੀਂ ਆਪਣੀਆਂ ਇੱਛਿਤ ਸੰਬੰਧਾਂ ਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਅਤੇ ਡੈਟਾਬੇਸ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਨਿਕਾਲਣਾ ਹੈ। ਆਦੇਸ਼ਾਂ 'ਤੇ ਇਕ-ਇਕ ਕਰ ਕੇ ਲੂਪ ਕਰਨ ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਮਿਲਦੇ-ਜੁਲਦੇ ਗਾਹਕ ਲੱਭਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇਕ ਵਾਰੀ ਮਿਲਾਪ ਦੱਸਦੇ ਹੋ। ਇਹ ਬਦਲਾਅ ਹੀ ਹੈ ਜੋ ਰਿਲੇਸ਼ਨਲ ਕੁਐਰੀਿੰਗ ਨੂੰ ਸੰਗਠਨਾਤਮਕ ਪੱਧਰ 'ਤੇ ਕਾਰਗਰ ਬਣਾਉਂਦਾ ਹੈ।
ਸੰਗਠਨਾਂ ਸਿਰਫ਼ ਰਿਕਾਰਡ ਸਟੋਰ ਨਹੀਂ ਕਰਦੀਆਂ—ਉਹ ਜਵਾਬ ਚਾਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਹਫ਼ਤੇ ਅਸੀਂ ਕਿੰਨੇ ਆਦੇਸ਼ ਭੇਜੇ? ਹਰ ਕੈਰੀਅਰ ਦੇ ਅਨੁਸਾਰ ਔਸਤ ਡਿਲਿਵਰੀ ਸਮਾਂ ਕੀ ਹੈ? ਕਿਹੜੇ ਉਤਪਾਦ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਰੇਵਨਿਊ ਲਿਆਉਂਦੇ ਹਨ? ਸ਼ੁਰੂਆਤੀ SQL ਨੇ ਇਹਨਾਂ ਰੋਜ਼ਾਨਾ 'ਰਿਪੋਰਟ' ਸਵਾਲਾਂ ਨੂੰ ਪਹਿਲ-ਕ੍ਰਮ ਦਾ ਕੰਮ ਮੰਨਿਆ ਅਤੇ ਇਸ ਲਈ ਹਿੱਸਾ ਸੱਭ ਤੋਂ ਵੱਧ ਸਹਾਇਕ ਸੀ।
Aggregation ਫੰਕਸ਼ਨ ਕਈ ਰੋਜ਼ਾਂ ਨੂੰ ਇੱਕ ਨੰਬਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ: COUNT ਮਾਤਰਾ ਲਈ, SUM ਟੋਟਲ ਲਈ, AVG ਔਸਤ ਲਈ, ਅਤੇ MIN/MAX ਰੇਂਜ ਲਈ। ਇਕੱਲੇ, ਇਹ ਫੰਕਸ਼ਨ ਸਾਰੇ ਨਤੀਜੇ ਸਾਰਾਂਸ਼ ਕਰਦੇ ਹਨ।
GROUP BY ਉਸ ਸਾਰ ਨੂੰ ਉਪਯੋਗੀ ਬਣਾਉਂਦਾ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਹਰ ਸ਼੍ਰੇਣੀ ਲਈ ਇੱਕ ਲਾਈਨ ਪ੍ਰਦਾਨ ਕਰਨ ਦਿੰਦਾ—ਦ.store, ਮਹੀਨਾ, ਗਾਹਕ ਸੈਗਮੈਂਟ—ਬਿਨਾਂ ਲੂਪ ਜਾਂ ਕਸਟਮ ਰਿਪੋਰਟ ਕੋਡ ਲਿਖੇ।
SELECT
department,
COUNT(*) AS employees,
AVG(salary) AS avg_salary
FROM employees
WHERE active = 1
GROUP BY department;
WHERE ਦਾ ਉਪਯੋਗ ਗਰੁੱਪਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਕਤਾਰਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ ਹੁੰਦਾ ਹੈ (ਕਿਹੜੀਆਂ ਕਤਾਰਾਂ ਸ਼ਾਮਲ ਹਨ)।HAVING ਦਾ ਉਪਯੋਗ aggregation ਤੋਂ ਬਾਅਦ ਗਰੁੱਪਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ ਹੁੰਦਾ ਹੈ (ਕਿਹੜੇ ਸਾਹਮਾਂ ਰੱਖਣੇ ਹਨ)।SELECT department, COUNT(*) AS employees
FROM employees
WHERE active = 1
GROUP BY department
HAVING COUNT(*) >= 10;
ਜਿਆਦਾਤਰ ਰਿਪੋਰਟਿੰਗ ਬੱਗ ਅਸਲ ਵਿੱਚ “ਗ੍ਰੈਨੂਲੈਰਿਟੀ” ਦੀਆਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: ਗਲਤ ਪੱਧਰ 'ਤੇ ਗਰੁੱਪ ਕਰਨਾ। ਜੇ ਤੁਸੀਂ orders ਨੂੰ order_items ਨਾਲ ਜੋਇਨ ਕਰਦੇ ਹੋ ਅਤੇ ਫਿਰ SUM(order_total) ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਦਾਂਸ਼ ਦੇ ਆਈਟਮਾਂ ਦੀ ਗਿਣਤੀ ਦੇ ਅਨੁਸਾਰ ਟੋਟਲ ਨੂੰ ਗੁਣਾ ਸਕਦੇ ਹੋ—ਇਹ ਦੋਹਰੀ ਗਿਣਤੀ ਦੀ ਕਲਾਸੀਕਲ ਮਿਸਟੇਕ ਹੈ। ਇੱਕ ਵਧੀਆ ਅਭਿਆਸ ਇਹ ਪੁੱਛਣਾ ਹੈ: “ਮੇਰੇ joins ਤੋਂ ਬਾਅਦ ਇੱਕ ਰੋ ਹੁਣ ਕੀ ਦਰਸਾਉਂਦੀ ਹੈ?” ਅਤੇ ਉੱਥੇ ਹੀ aggregation ਕਰੋ।
ਇੱਕ ਹੋਰ ਆਮ ਗਲਤੀ ਉਹ ਕਾਲਮ ਚੁਣਨਾ ਹੈ ਜੋ GROUP BY ਵਿੱਚ ਨਹੀਂ ਹਨ (ਜਾਂ aggregates ਨਹੀਂ)। ਇਹ ਅਕਸਰ ਇੱਕ ਅਸਪਸ਼ਟ ਰਿਪੋਰਟ ਪਰਿਭਾਸ਼ਾ ਦਾ ਸੰਕੇਤ ਹੁੰਦਾ ਹੈ: ਪਹਿਲਾਂ ਗਰੁੱਪਿੰਗ ਕੀ ਹੈ ਫੈਸਲਾ ਕਰੋ, ਫਿਰ ਉਸ ਪੱਧਰ ਲਈ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ।
ਅਸਲ ਸੰਸਥਾਗਤ ਡਾਟਾ ਵਿੱਚ ਖਾਲੀਆਂ ਥਾਵਾਂ ਭਰ-ਭਰ ਕੇ ਮਿਲਦੀਆਂ ਹਨ। ਇੱਕ ਗਾਹਕ ਦੇ ਰਿਕਾਰਡ ਵਿੱਚ ਈਮੇਲ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਇੱਕ ਸ਼ਿਪਮੈਂਟ ਦੇ ਕੋਲ ਹਜੇ ਡਿਲਿਵਰੀ ਤਾਰੀਖ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਜਾਂ ਇਕ ਲੈਗੇਸੀ ਸਿਸਟਮ ਨੇ ਕਦੇ ਕਿਸੇ ਫੀਲਡ ਨੂੰ ਇਕੱਠਾ ਹੀ ਨਹੀਂ ਕੀਤਾ ਹੋ ਸਕਦਾ। ਹਰ ਗੁੰਮ ਮੁੱਲ ਨੂੰ “ਖਾਲੀ” ਜਾਂ “ਜ਼ੀਰੋ” ਸਮਝਣ ਨਾਲ ਰਿਪੋਰਟਾਂ ਨੂੰ ਛੁਪੇ ਹੋਏ ਤੌਰ 'ਤੇ ਬਰਬਾਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਇਸ ਲਈ ਸ਼ੁਰੂਆਤੀ SQL ਨੇ NULL ਲਈ ਖੁੱਲ੍ਹਾ ਥਾਂ ਬਣਾ ਦਿੱਤਾ: “ਅਸੀਂ ਨਹੀਂ ਜਾਣਦੇ।”
SQL ਨੇ NULL ਨੂੰ “ਗੁੰਮ” (ਜਾਂ ਅਣਲਾਗੂ) ਮੰਨਿਆ, ਨਾ ਕਿ “ਖਾਲੀ” ਜਾਂ “ਝੂਠਾ”। ਇਸ ਫੈਸਲੇ ਦਾ ਇਕ ਅਹੰਕਾਰਮਈ ਨਿਯਮ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਤੁਲਨਾਤਮਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜਿਨ੍ਹਾਂ ਵਿੱਚ NULL ਸ਼ਾਮਲ ਹੋਵੇਂ ਉਹ ਨਾ ਤਾਂ ਸੱਚ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਨਾ ਹੀ ਝੂਠ—ਉਹ ਅਣਜਾਣ ਹੁੰਦੀਆਂ ਹਨ।
ਉਦਾਹਰਨ ਵਜੋਂ, salary > 50000 ਅਣਜਾਣ ਹੈ ਜਦ salary NULL ਹੈ। ਅਤੇ NULL = NULL ਵੀ ਅਣਜਾਣ ਹੀ ਰਹਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਿਸਟਮ ਦੋ ਗੁੰਮ ਮੁੱਲਾਂ ਦੀ ਬਰਾਬਰੀ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ।
IS NULL (ਅਤੇ IS NOT NULL) ਦੀ ਵਰਤੋਂ ਕਰੋ:
WHERE email IS NULL ਗੁੰਮ ਇਮੇਲਾਂ ਲੱਭਦਾ ਹੈ।WHERE email = NULL ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਮੁਤਾਬਕ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ।ਰਿਪੋਰਟਿੰਗ ਦੇ ਸਮੇਂ ਸੁਰੱਖਿਅਤ fallback ਦੇਣ ਲਈ COALESCE ਵਰਤੋਂ:
SELECT COALESCE(region, 'Unassigned') AS region, COUNT(*)
FROM customers
GROUP BY COALESCE(region, 'Unassigned');
ਉਹ ਫਿਲਟਰਾਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਅਣਜਾਣਾਂ ਨੂੰ ਗਲਤੀ ਵਜੋਂ ਹਟਾ ਦਿੰਦੇ ਹੋ, ਉਹ ਨਤੀਜਿਆਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ। WHERE status <> 'Cancelled' ਉਹ ਰੋਜ਼ਾਂ ਜੋ status ਵਿੱਚ NULL ਹਨ ਉਨ੍ਹਾਂ ਨੂੰ ਬਾਹਰ ਕਰ ਦੇਵੇਗਾ (ਕਿਉਂਕਿ ਤੁਲਨਾ ਅਣਜਾਣ ਹੈ)। ਜੇ ਤੁਹਾਡਾ ਕਾਰੋਬਾਰੀ ਨਿਯਮ "ਨ ਰੱਦ ਕੀਤੇ ਜਾਂ ਗੁੰਮ" ਹੈ, ਤਾਂ ਇਹ ਸਪਸ਼ਟ ਲਿਖੋ:
WHERE status <> 'Cancelled' OR status IS NULL
NULL ਵਿਵਹਾਰ ਟੋਟਲ, ਕਨਵਰਜ਼ਨ ਰੇਟ, ਅਡਿਗਤਾ ਜਾਂ "ਡਾਟਾ ਗੁਣਵੱਤਾ" ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਉਹ ਟੀਮਾਂ ਜੋ NULL ਨੂੰ ਇਰਾਦੇ ਨਾਲ ਸੰਭਾਲਦੀਆਂ ਹਨ—ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਅਣਜਾਣਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਣਾ, ਲੇਬਲ ਕਰਨਾ ਜਾਂ ਡਿਫਾਲਟ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ—ਉਨ੍ਹਾਂ ਕੋਲ ਐਸੀਆਂ ਰਿਪੋਰਟਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਕਾਰੋਬਾਰੀ ਮਾਇਨੇ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਨਾ ਕਿ ਦੋਸ਼ੀ ਕੁਐਰੀ ਵਿਵਹਾਰ।
View ਇੱਕ ਸੇਵ ਕੀਤੀ ਕੁਐਰੀ ਹੈ ਜੋ ਵਰਚੁਅਲ ਟੇਬਲ ਵਾਂਗ ਵਰਤਦੀ ਹੈ। ਡਾਟਾ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇਹ ਸੰਭਾਲਦੇ ਹੋ ਕਿ ਨਤੀਜਾ-ਸੇਟ ਕਿਵੇਂ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਫਿਰ ਹਰ ਕੋਈ ਇਸਨੂੰ ਵੇਖ ਸਕਦਾ ਹੈ ਅਤੇ ਉਸੇ SELECT–FROM–WHERE ਪੈਟਰਨ ਨਾਲ ਕੁਐਰੀ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਹ ਪਹਿਲਾਂ ਜਾਣਦੇ ਹਨ।
Views ਆਮ ਸਵਾਲਾਂ ਨੂੰ ਦੁਹਰਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਮੁਸ਼ਕਿਲ joins ਅਤੇ ਫਿਲਟਰਾਂ ਨੂੰ ਮੁੜ ਲਿਖਣ ਦੇ। ਇੱਕ ਫਾਇਨੈਂਸ ਐਨਲਿਸਟ monthly_revenue_view ਤੋਂ ਕੁਐਰੀ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਯਾਦ ਰੱਖਣ ਦੇ ਕਿ ਇਨਵੌਇਸ, ਕਰੈਡਿਟ ਅਤੇ ਐਡਜਸਟਮੈਂਟ ਕਿਹੜੇ ਟੇਬਲਾਂ ਵਿੱਚ ਹਨ।
ਉਹ ਟੀਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਾਵਾਂ ਸਟੈਂਡਰਡ ਕਰਨ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰਦੇ ਹਨ। “Active customer” ਦਾ ਕੀ ਮਤਲਬ ਹੈ: ਕੀ ਇਹ ਪਿਛਲੇ 30 ਦਿਨਾਂ ਵਿਚ ਖਰੀਦਦਾਰੀ ਕੀਤੀ ਹੈ, ਖੁੱਲ੍ਹਾ ਕਾਂਟ੍ਰੈਕਟ ਹੈ, ਜਾਂ ਹਾਲ ਹੀ ਵਿੱਚ ਲੌਗਇਨ ਕੀਤਾ? ਇੱਕ view ਨਾਲ ਸੰਸਥਾ ਉਹ ਨਿਯਮ ਇਕ ਵਾਰੀ ਕੋਡ ਕਰ ਸਕਦੀ ਹੈ:
CREATE VIEW active_customers AS
SELECT c.customer_id, c.name
FROM customers c
WHERE c.status = 'ACTIVE' AND c.last_purchase_date >= CURRENT_DATE - 30;
ਹੁਣ ਡੈਸ਼ਬੋਰਡ, ਐਕਸਪੋਰਟ ਅਤੇ ਆਡ-ਹਾਕ ਕੁਐਰੀਆਂ ਇਕਸਾਰ ਤਰੀਕੇ ਨਾਲ active_customers ਨੂੰ ਰਿਫਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।
Views ਉੱਚ-ਸਤਰ 'ਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਨੂੰ ਸਮਰਥਨ ਦੇ ਸਕਦੇ ਹਨ, ਇਕ curated ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਦਿਖਾਈ ਦੀ ਗਈ ਚੀਜ਼ ਨੂੰ ਸੀਮਿਤ ਕਰਕੇ। ਕੱਚੇ ਟੇਬਲਾਂ 'ਤੇ ਵਿਆਪਕ ਅਧਿਕਾਰ ਦੇਣ ਦੀ ਥਾਂ, ਟੀਮ ਇੱਕ ਐਸੇ view ਨੂੰ ਸਹਾਇਤਾ ਦੇ ਸਕਦੀ ਹੈ ਜੋ ਸਿਰਫ਼ ਰੋਲ ਲਈ ਲੋੜੀਂਦੇ ਫੀਲਡ ਵੇਖਾਉਂਦਾ ਹੈ।
ਅਸਲ ਓਪਰੇਸ਼ਨਲ ਲਾਭ ਮੈਂਟੇਨਬਿਲਟੀ ਵਿੱਚ ਹੈ। ਜਦੋ ਸਰੋਤ ਟੇਬਲਾਂ ਵਧਦੀਆਂ ਹਨ—ਨਵੇਂ ਕਾਲਮ, ਨਾਮ-ਬਦਲਾਅ, ਜਾਂ ਬਦਲੇ ਕਾਰੋਬਾਰੀ ਨਿਯਮ—ਤਾਂ ਤੁਸੀਂ view ਦੀ ਪਰਿਭਾਸ਼ਾ ਇਕਥੇ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਨਾਲ “ਕਈ ਰਿਪੋਰਟ ਇੱਕ ਵਾਰ ਵਿੱਚ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ” ਸਮੱਸਿਆ ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ SQL-ਅਧਾਰਿਤ ਰਿਪੋਰਟਿੰਗ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਨ ਕਿ ਨਾਜੁਕ।
SQL ਸਿਰਫ਼ ਡਾਟਾ ਨੂੰ ਸੁੰਦਰ ਢੰਗ ਨਾਲ ਪੜ੍ਹਣ ਹੀ ਨਹੀਂ सीਖਾਉਂਦਾ—ਇਸਨੂੰ ਲਿਖਣ ਨੂੰ ਵੀ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ ਪਿਆ, ਜਦ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਇੱਕੋ ਸਮੇਂ ਕਿਰਿਆਵਾਂ ਕਰ ਰਹੇ ਹੋਣ। ਇੱਕ ਅਸਲ ਸੰਸਥਾ ਵਿੱਚ ਅਪਡੇਟ ਲਗਾਤਾਰ ਹੁੰਦੇ ਰਹਿੰਦੇ ਹਨ: ਆਦੇਸ਼ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਇਨਵੈਂਟਰੀ ਬਦਲਦੀ ਹੈ, ਇਨਵੌਇਸ ਪੋਸਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਸੀਟਾਂ ਰੇਜ਼ਰਵ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਇਹ ਅਪਡੇਟ ਅਧੂਰੇ ਤਰੀਕੇ ਨਾਲ ਸਫਲ ਹੁੰਦੀਆਂ ਹਨ ਜਾਂ ਦੂਜੇ ਦੋਸ਼ ਪੈ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਡੈਟਾਬੇਸ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਰਹਿਣਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ।
ਇੱਕ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਉਹ ਬਦਲਾਅ ਬੰਨ੍ਹਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਡੈਟਾਬੇਸ ਇੱਕ ਕੰਮ ਦੀ ਇਕਾਈ ਵਜੋਂ ਦੱਸੀਦਾ ਹੈ: ਜਾਂ ਸਾਰੇ ਬਦਲਾਅ ਹੁੰਦੇ ਹਨ, ਜਾਂ ਕੋਈ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਕਿਤੇ ਅਧਾਰਮਧ ਵਿੱਚ ਕੁਝ ਫੇਲ ਹੋ ਜਾਂਦਾ—ਪਾਵਰ ਲੋਸ, ਐਪ ਕਰੈਸ਼, ਜਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਤਰੁਟਿ—ਤਾਂ ਡੈਟਾਬੇਸ ਪਹਿਲਾਂ ਦੀ ਸਥਿਤੀ 'ਤੇ ਰੋਲਬੈਕ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ “ਸਾਰੇ-ਜਾਂ-ਕੋਈ-ਞਹੀ” ਵਰਤੋਂਕਾਰ ਕਾਰਵਾਈਆਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਕ ਇਨਵੌਇਸ ਦਿਆਂ ਭੁਗਤਾਨ ਦੀ ਕਾਰਵਾਈ ਗਾਹਕ ਦੀ ਬਕਾਇਆ ਘਟਾਉਂਦੀ ਹੈ, ਭੁਗਤਾਨ ਦਰਜ ਕਰਦੀ ਹੈ, ਅਤੇ ਜਨਰਲ ਲੇਜਰ ਅਪਡੇਟ ਕਰਦੀ ਹੈ—ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇਕ ਹੀ ਚੱਲ ਜਾਵੇ, ਤਾਂ ਅਕਾਊਂਟਿੰਗ ਅਸਥਿਰ ਹੋ ਜਾਏਗੀ।
ਭਾਵੇਂ ਹਰ ਯੂਜ਼ਰ ਦੀਆਂ ਬਦਲਾਅ ਸਹੀ ਹਨ, ਦੋ ਯੂਜ਼ਰ ਇੱਕੋ ਸਮੇਂ ਕੰਮ ਕਰਨ ਨਾਲ ਮਾੜੇ ਨਤੀਜੇ ਬਣ ਸਕਦੇ ਹਨ। ਇਕ ਬੁਕਿੰਗ ਨਿਯਮ ਨੂੰ ਸੋਚੋ:
ਜੇ isolation ਨਿਯਮ ਨਾ ਹੋਣ ਤਾਂ ਦੋਹਾਂ ਅਪਡੇਟ ਸਫਲ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਡਬਲ ਬੁਕਿੰਗ ਹੋ ਸਕਦੀ ਹੈ। ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਸਥਿਰਤਾ ਨਿਯੰਤਰਣ ਡੈਟਾਬੇਸ ਨੂੰ concurrency ਦੇ ਦੌਰਾਨ ਸਹੀ ਤਰ੍ਹਾਂ ਕੋਆਰਡੀਨੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਹਰ ਟਰਾਂਜ਼ੈਕਸ਼ਨ coherent view ਵੇਖੇ ਅਤੇ ਸੰਘਰਸ਼ਾਂ ਨੂੰ ਪੇਸ਼ਗੀ ਨਿਯਮਾਂ ਮੁਤਾਬਕ ਹੱਲ ਕੀਤਾ ਜਾਵੇ।
ਇਹ ਗਾਰੰਟੀਜ਼ ਅਕਾਉਂਟਿੰਗ ਦੀ ਸ਼ੁੱਧਤਾ, ਆਡੀਟਬਿਲਟੀ ਅਤੇ ਰੋਜ਼ਾਨਾ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਸਾਮ੍ਹਣੇ ਲਿਆਉਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਇੱਕ ਡੈਟਾਬੇਸ ਇਹ ਸਾਬਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਅਪਡੇਟਸ consistent ਹਨ—ਭਾਰੀ, ਮਲਟੀ-ਯੂਜ਼ਰ ਲੋਡ ਹੇਠਾਂ—ਤਾਂ ਉਹ ਪੇਰੋਲ, ਬਿਲਿੰਗ, ਇਨਵੈਂਟਰੀ ਅਤੇ ਕੰਪਲਾਇੰਸ ਰਿਪੋਰਟਿੰਗ ਲਈ ਭਰੋਸੇਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ।
SQL ਦੀ ਸ਼ੁਰੂਆਤੀ ਵਾਅਦਾ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਤੁਸੀਂ ਡਾਟਾ 'ਤੇ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹੋ—ਇਹ ਸੀ ਕਿ ਸੰਗਠਨ ਉਹ ਸਵਾਲ ਪੁੱਛਦੇ ਰਹਿ ਸਕਣ ਜਿਵੇਂ ਡੈਟਾ ਵੱਧਦਾ ਹੈ। Raymond Boyce ਅਤੇ System R ਟੀਮ ਨੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲਿਆ ਕਿਉਂਕਿ ਏਕ ਭਾਸ਼ਾ ਜੋ ਸਿਰਫ ਛੋਟੇ ਟੇਬਲਾਂ 'ਤੇ ਕੰਮ ਕਰਦੀ ਸੀ ਉਹ ਪ੍ਰਯੋਗਿਕ ਨਹੀਂ ਸੀ।
ਇੱਕ ਕੁਐਰੀ ਜੋ 5,000 ਦੀ ਟੇਬਲ ਵਿੱਚੋਂ 50 ਰੋਜ਼ ਵਾਪਸ ਕਰਦੀ ਹੈ ਉਹ ਲਗਭਗ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ, ਭਾਵੇਂ ਡੈਟਾਬੇਸ "ਸਭ ਕੁਝ ਸਕੈਨ" ਕਰ ਰਿਹਾ ਹੋਵੇ। ਪਰ ਜਦ ਇਹੀ ਟੇਬਲ 50 ਮਿਲੀਅਨ ਰੋਜ਼ ਦੀ ਹੋ ਜਾਵੇ, ਤਾਂ ਫੁੱਲ ਸਕੈਨ ਇੱਕ ਛੋਟਾ ਲੁਕਅੱਪ ਨੂੰ ਕਾਰਜਿੰਤਾ ਵਿੱਚ ਕਈ ਮਿੰਟ ਕਰ ਸਕਦਾ ਹੈ।
SQL ਟੈਕਸਟ ਇੱਕੋ ਰਹਿ ਸਕਦਾ ਹੈ:
SELECT *
FROM orders
WHERE order_id = 12345;
ਪਰ ਜੇਕਰ ਡੇਟਾ ਵਧ ਗਿਆ ਤਾਂ ਉਹ ਲੱਭਣ ਦਾ ਤਰੀਕਾ (ਕਿਸ ਤਰ੍ਹਾਂ ਡੈਟਾਬੇਸ order_id = 12345 ਲੱਭਦਾ ਹੈ) ਮਹੱਤਵਪੂਰਨ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਇੰਡੈਕਸ ਪੁਸਤਕ ਦੇ ਪਿੱਛੇ ਦੇ ਸੂਚੀ-ਪੱਤਰ ਵਾਂਗ ਹੈ: ਹਰ ਪੰਨੇ ਨੂੰ ਖੋਲ੍ਹਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਸਿੱਧਾ ਸੰਬੰਧਿਤ ਪੰਨੇ ਤੱਕ ਜਾ ਸਕਦੇ ਹੋ। ਡੈਟਾਬੇਸ ਵਿੱਚ ਇੰਡੈਕਸ ਮੈਚਿੰਗ ਰੋਜ਼ਾਂ ਨੂੰ ਖੋਜਣ ਤੋਂ ਬਿਨਾਂ ਲੱਭਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।
ਪਰ ਇੰਡੈਕਸ ਮੁਫ਼ਤ ਨਹੀਂ ਹੁੰਦਾ। ਉਹ ਸਟੋਰੇਜ਼ ਲੈ ਲੈਂਦੇ ਹਨ, ਲਿਖਤਾਂ ਨੂੰ ਹੌਲਾ ਕਰ ਦਿੰਦੇ ਹਨ (ਕਿਉਂਕਿ ਇੰਡੈਕਸ ਨੂੰ ਵੀ ਅਪਡੇਟ ਕਰਨਾ ਪੈਂਦਾ ਹੈ), ਅਤੇ ਹਰ ਕੁਐਰੀ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੇ। ਜੇ ਤੁਸੀਂ ਪੂਰੇ ਟੇਬਲ ਦਾ ਬਹੁਤ ਵੱਡਾ ਹਿੱਸਾ ਮੰਗ ਰਹੇ ਹੋ, ਤਾਂ ਕਈ ਵਾਰੀ ਸਕੈਨ ਕਰਨਾ ਲੰਬੇ ਸਮੇਂ ਲਈ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤੀ SQL ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਯੋਗਿਕ ਚੋਣ ਇਹ ਸੀ ਕਿ ਡੈਟਾਬੇਸ ਐਕਜ਼ੇਕਯੂਸ਼ਨ ਯੋਜਨਾ ਖੁਦ ਚੁਣੇ। ਪਟਿਮਾਈਜ਼ਰ ਲਾਗਤਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਯੋਜਨਾ ਚੁਣਦਾ ਹੈ—ਇੰਡੈਕਸ ਵਰਤਣਾ, ਟੇਬਲ ਸਕੈਨ, ਜੋਇਨ ਕਾਰਜਕ੍ਰਮ ਦੇ ਨਿਰਧਾਰ। ਇਸ ਨਾਲ ਹਰ ਯੂਜ਼ਰ ਨੂੰ ਹਰੇਕ ਕੁਐਰੀ ਲਈ ਡੈਟਾਬੇਸ ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਸੋਚਣਾ ਨਹੀਂ ਪੈਂਦਾ।
ਰਾਤ-ਦਰ-ਰਾਤ ਜਾਂ ਹਫ਼ਤਾਵਾਰ ਰਿਪੋਰਟ ਚਲਾਉਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ, ਪ੍ਰਗਟ ਪ੍ਰਦਰਸ਼ਨ ਸਿਫਾਰਸ਼ੀ ਹੈ। ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਪਟਿਮਾਈਜ਼ੇਸ਼ਨ ਨੇ ਇਹ ਹਕੀਕਤ ਬਣਾਈ ਕਿ ਰਿਪੋਰਟਿੰਗ ਵਿੰਡੋਜ਼ ਸ਼ਡਿਊਲ ਕੀਤੀਆਂ ਜਾ ਸਕਣ, ਕਾਰੋਬਾਰੀ ਡੈਸ਼ਬੋਰਡ ਜਵਾਬਦੇਹ ਰਹਿਣ, ਅਤੇ "ਇਹ ਪਿਛਲੇ ਮਹੀਨੇ ਚੱਲਿਆ ਸੀ" ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ ਜਦ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਬਰੱਧਦੀ ਹੈ।
Raymond Boyce ਦਾ ਕੰਮ ਸ਼ੁਰੂਆਤੀ SQL (System R ਯੁੱਗ ਵਿੱਚ) ਇਸ ਲਈ ਕਾਮਯਾਬ ਰਿਹਾ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੇ ਉਹ ਚੋਣਾਂ ਪਸੰਦ ਕੀਤੀਆਂ ਜੋ ਟੀਮਾਂ ਸਹਿਣ ਕਰ ਸਕਦੀਆਂ ਸਨ: ਇੱਕ ਪੜ੍ਹਨਯੋਗ, ਘੋਸ਼ਣਾਤਮਕ ਭਾਸ਼ਾ; ਟੇਬਲ-ਅਤੇ-ਸਕੀਮਾ ਮਾਡਲ ਜੋ ਸੰਸਥਾਵਾਂ ਦੇ ਡਾਟਾ ਨੂੰ ਵਰਣਨ ਕਰਨ ਦੇ ਢੰਗ ਨਾਲ ਮੇਲ ਖਾਂਦਾ; ਅਤੇ ਗੰਦ ਡਾਟਾ (ਜਿਵੇਂ ਗੁੰਮ ਮੁੱਲ) ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਇੱਛਾ, ਬਜਾਏ ਕਿ ਪੂਰੇ ਸਿਧਾਂਤ ਦੀ ਉਡੀਕ ਕਰਨ। ਇਹ ਫੈਸਲੇ ਸਮਾਜਿਕ ਪੱਧਰ 'ਤੇ ਸਕੇਲ ਹੁੰਦੇ ਰਹੇ—ਸਿਰਫ਼ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਨਹੀਂ।
SQL ਦਾ ਮੂਲ ਵਿਚਾਰ—ਜੋ ਨਤੀਜਾ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਵਰਣਨ ਕਰੋ, ਕਦਮ-ਕਦਮ ਨਹੀਂ—ਅਜੇ ਵੀ ਮਿਲੀ-ਜੁਲੀ ਟੀਮਾਂ ਨੂੰ ਸਹਿਯੋਗੀ ਬਣਾਉਂਦਾ ਹੈ। Views ਨੇ ਇੱਕ ਵਾਰੀ ਪਰਿਭਾਸ਼ਾਵਾਂ ਸਾਂਝਾ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ ਬਿਨਾਂ ਕੁਐਰੀਆਂ ਨੂੰ ਹਰ ਜਗ੍ਹਾ ਨਕਲ ਕਰਨ ਦੇ। ਟਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਨੇ "ਇਹ ਅਪਡੇਟ ਹੋਇਆ ਜਾਂ ਨਹੀਂ" ਦੀ ਸਾਂਝੀ ਉਮੀਦ ਬਣਾਈ, ਜੋ ਭਰੋਸੇ ਲਈ ਅੱਜ ਵੀ ਬੁਨਿਆਦੀ ਹੈ।
ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਸਮਝੌਤੇ ਹਰ ਰੋਜ਼ ਦੇ ਕੰਮ ਵਿੱਚ ਅਜੇ ਵੀ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:
ਅੰਨ੍ਹੇ-ਪੱਕੇ ਨਿਯਮਾਂ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ ਜੋ ਗੁੰਮ-ਭਰਮ ਘਟਾਓਂ: naming conventions, join ਸਟਾਈਲ, ਤਾਰੀਖ ਹ್ಯಾಂਡਲਿੰਗ, ਅਤੇ "active", "revenue" ਜਾਂ "customer" ਦਾ ਕੀ ਮਤਲਬ। ਮਹੱਤਵਪੂਰਨ ਕੁਐਰੀਆਂ ਨੂੰ ਉਤਪਾਦ ਕੋਡ ਵਾਂਗ ਬTreat ਕਰੋ: ਪੀਅਰ ਰਿਵਿਊ, ਵਰਜਨ ਕੰਟਰੋਲ, ਅਤੇ ਹਲਕੀ-ਫੈਸਲੇ ਜਾਂਚਾਂ (ਰੋ ਗਿਣਤੀ, ਯੂਨੀਕਨੈਸ ਚੈਕ ਅਤੇ "ਜਾਣਿਆ-ਪਹਚਾਨਿਆ" ਉਦਾਹਰਨ)। ਵਿਸ਼ਵਾਸਯੋਗ ਡਿਫਿਨਿਸ਼ਨਾਂ ਨੂੰ ਸਾਂਝੇ ਕਰੋ—ਅਕਸਰ views ਜਾਂ curated tables ਰਾਹੀਂ—ਤਾਂ ਜੋ ਮੈਟ੍ਰਿਕਸ ਟੁੱਟ ਕੇ ਫਰੈਗਮੈਂਟ ਨਾ ਹੋਣ।
ਜੇ ਤੁਸੀਂ ਉਹ ਕੁਐਰੀਆਂ ਅੰਦਰੂਨੀ ਟੂਲਾਂ (ਐਡਮਿਨ ਪੈਨਲ, ਡੈਸ਼ਬੋਰਡ, ਓਪਰੇਸ਼ਨਲ ਵਰਕਫ਼ਲੋ) ਵਿੱਚ ਬਦਲ ਰਹੇ ਹੋ, ਤਾਂ ਵਹੀ ਸਿਧਾਂਤ ਐਪ ਲੇਅਰ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ: ਸਾਂਝੇ ਨਿਰਧਾਰ, ਨਿਯੰਤਰਿਤ ਐਕਸੈਸ ਅਤੇ ਰੋਲਬੈਕ ਦੀ ਕਹਾਣੀ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਇਸ "ਪ੍ਰਯੋਗਿਕ SQL" ਵਿਰਾਸਤ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ, ਜਿੱਥੇ ਟੀਮਾਂ ਚੈਟ-ਚਲਿਤ ਵਰਕਫ਼ਲੋ ਤੋਂ ਵੈੱਬ, ਬੈਕਅੰਦ ਜਾਂ ਮੋਬਾਈਲ ਐਪ ਤਿਆਰ ਕਰ ਸਕਦੀਆਂ ਹਨ—ਫਿਰ ਵੀ ਪਾਰੰਪਰਿਕ ਬੁਨਿਆਦਾਂ (React ਫਰੰਟ ਐਂਡ, Go + PostgreSQL ਬੈਕ ਐਂਡ, Flutter ਮੋਬਾਈਲ) ਅਤੇ ਡੇਟਾਬੇਸ-ਯੁੱਗ ਦੀਆਂ ਆਦਤਾਂ (planning mode, snapshots, rollback) ਉਪਰੰੇ ਹਨ।
Raymond Boyce IBM ਦੇ System R ਪ੍ਰਾਜੈਕਟ ਵਿੱਚ ਇੱਕ ਮੁੱਖ ਗਵੈਸ਼ਕ ਸੀ, ਜਿਸ ਨੇ ਰਿਲੇਸ਼ਨਲ ਡੈਟਾਬੇਸ ਖਿਆਲਾਂ ਨੂੰ ਅਸਲੀ ਦਫਤਰਾਂ ਲਈ ਇੱਕ ਵਰਤਣਯੋਗ ਸੰਸਥਾ ਵਜੋਂ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਉਸਦਾ ਪ੍ਰਭਾਵ SQL ਨੂੰ ਪ੍ਰਯੋਗਾਤਮਕ ਬਣਾਉਣ ਨਾਲ ਜੁੜਿਆ ਹੈ: ਪੜ੍ਹਨਯੋਗ ਕੁਐਰੀਆਂ, ਮੈਸੀ ਡਾਟਾ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ, ਅਤੇ ਐਸੇ ਫੀਚਰ ਜੋ ਕੁਇ ਲੋਗ-ਵਰ ਕਰਨਾ, ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਸੰਭਾਲਦੇ ਹਨ—ਸਿਰਫ਼ ਸਿਧਾਂਤਕ ਸੁੰਦਰਤਾ ਨਹੀਂ।
System R IBM ਦਾ 1970 ਦੇ ਦਹਾਕੇ ਦਾ ਰਿਸਰਚ ਪ੍ਰੋਜੈਕਟ ਸੀ ਜਿਸ ਨੇ ਸਾਬਤ ਕੀਤਾ ਕਿ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਇੱਕ ਅੰਤ-ਤੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਪ੍ਰਣਾਲੀ ਵਜੋਂ ਸੰਭਵ ਹੈ: ਸਟੋਰੇਜ਼, ਕੁਐਰੀ ਪ੍ਰੋਸੈਸਿੰਗ, concurrency control ਅਤੇ ਇੱਕ ਸਿੱਖਣਯੋਗ ਭਾਸ਼ਾ। ਇਸ ਨੇ SQL ਦੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਹਕੀਕਤੀ ਸੀਮਾਵਾਂ—ਸਿਮਤ ਕੰਪਿਊਟ, ਸਾਂਝੇ ਵਰਕਲੋਡ ਅਤੇ ਅਪੂਰਨ ਕਾਰੋਬਾਰੀ ਡਾਟਾ—ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ।
SEQUEL ਦਾ ਅਰਥ ‘Structured English Query Language’ ਸੀ, ਜਿਸ ਦਾ ਉਦੇਸ਼ ਪੜ੍ਹਨ-ਲਈ ਅਸਾਨ ਅਤੇ ਵਾਕ-ਜਿਹੇ ਸਰਾਂਚੇ ਨਾਲ ਇੱਕ ਕੁਐਰੀ ਭਾਸ਼ਾ ਬਣਾਉਣਾ ਸੀ, ਤਾਂ ਜੋ ਕਾਰੋਬਾਰੀ ਯੂਜ਼ਰ ਅਤੇ ਵਿਕਾਸਕਾਰ ਝੱਟੀ ਸਿੱਖ ਸਕਣ। “English-like” ਢੰਗ ਨੇ ਇਹ ਦਰਸਾਇਆ ਕਿ ਹਦਫ਼ ਹੈ: ਰਿਲੇਸ਼ਨਲ ਕੁਐਰੀ ਨੂੰ ਸਧਾਰਣ ਅਤੇ ਸਹਿਜ ਬਣਾਉਣਾ, ਪਰ ਫਿਰ ਵੀ ਨਿਸ਼ਚਿਤ ਤਰੀਕੇ ਨਾਲ ਕਿਰਿਆਨਵਿਤ ਹੋ ਸਕਣ।
ਇੱਕ ਹੀ ਢਾਂਚਾ ਦਾ ਹੋਣਾ ਕੁਐਰੀਆਂ ਨੂੰ ਸਕੈਨ, ਰਿਵਿਊ ਅਤੇ ਮੇਨਟੇਨ ਕਰਨ ਯੋਗ ਬਣਾ ਦਿੰਦਾ ਹੈ:
SELECT: ਜੋ ਤੁਸੀਂ ਵਾਪਸ ਚਾਹੁੰਦੇ ਹੋFROM: ਇਹ ਕਿੱਥੋਂ ਆ ਰਿਹਾ ਹੈWHERE: ਕਿਹੜੀਆਂ ਕਤਾਰਾਂ ਯੋਗ ਹਨਇਹ ਪੇਸ਼ਗੀਰਤਾ ਟ੍ਰੇਨਿੰਗ, ਹੈਂਡਆਫ਼ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੋਂ ਲਈ ਸਹਾਇਕ ਹੈ—ਜਦੋਂ ਕੁਐਰੀਆਂ ਆੜ-ਖੜ ਹੋ ਕੇ ਲੰਮੇ ਸਮੇਂ ਵਾਲੇ ਓਪਰੇਸ਼ਨਲ ਲਾਜਿਕ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
Joins ਤੁਹਾਨੂੰ ਨਾਰਮਲਾਈਜ਼ਡ ਟੇਬਲਾਂ (ਜੇਵੇਂ customers ਅਤੇ orders) ਨੂੰ ਮਿਲਾ ਕੇ ਸੁਆਲਾਂ ਦੇ ਜਵਾਬ ਪਾਉਣ ਦਿੰਦੇ ਹਨ, ਬਿਨਾਂ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਵਿੱਚ ਡਾਟਾ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਚੁਪਕਾਉਣ ਦੇ। ਵਿਹਾਰਕ ਤੌਰ 'ਤੇ:
INNER JOIN ਨਾਲ ਲੁਕ ਜਾ ਸਕਦੇ ਹਨ ਜਾਂ ਨਾਲ ਰੱਖੇ ਜਾ ਸਕਦੇ ਹਨGROUP BY ਕੱਚੇ ਰੋਜ਼ਾਂ ਨੂੰ ਇਕ ਚੁਣੇ ਪੱਧਰ 'ਤੇ ਸੰਖੇਪ (ਕਾਉਂਟ, ਟੋਟਲ, ਔਸਤ) ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ—ਮਾਹ, ਵਿਭਾਗ ਜਾਂ ਗ੍ਰਾਹਕ ਸੈਕਸ਼ਨ ਵੱਲੋਂ ਇੱਕ ਲਾਈਨ ਪ੍ਰਤੀ ਸ਼੍ਰੇਣੀ। ਇੱਕ ਅਮਲੀ ਨਿਯਮ:
WHERE ਵਰਤੋਂHAVING ਵਰਤੋਂਜਿਆਦਤਰ ਗਲਤੀਆਂ ਗ੍ਰੈਨੂਲੈਰਿਟੀ ਜਾਂ ਦੋਹਰਾ ਗਿਣਤੀ (joins ਕਰਕੇ) ਤੋਂ ਹੁੰਦੀਆਂ ਹਨ।
NULL ਅਣਜਾਣ/ਗੁੰਮ ਡਾਟਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ 'ਖਾਲੀ' ਜਾਂ 'ਜ਼ੀਰੋ'—ਇਸ ਨਾਲ ਤਿੰਨ-ਮੁੱਲੀ ਤਰਕ (true/false/unknown) ਆਉਂਦੀ ਹੈ। ਅਮਲੀ ਸੁਝਾਅ:
IS NULL / IS NOT NULL ਵਰਤੋਂ (ਨ ਕਿ )ਇੱਕ view ਇੱਕ ਸੇਵ ਕੀਤੀ ਕੁਐਰੀ ਹੈ ਜੋ ਵਰਚੁਅਲ ਟੇਬਲ ਵਾਂਗ ਵਰਤਦੀ ਹੈ। ਇਹ ਟੀਮਾਂ ਲਈ ਸਹਾਇਕ ਹੈ:
ਇਹ ਅਕਸਰ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸਹੀ ਰੱਖਣ ਦਾ ਸਬ ਤੋਂ ਸਧਾਰਣ ਤਰੀਕਾ ਹੈ।
ਇੱਕ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਕਈ ਬਦਲਾਵਾਂ ਨੂੰ ਇਕਾਈ ਕੰਮ ਵਜੋਂ ਗਰੁੱਪ ਕਰਦਾ ਹੈ: ਜਾਂ ਤਮਾਮ ਬਦਲਾਵ ਹੋਣ ਜਾਂ ਕੋਈ ਨਹੀਂ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਕਾਰੋਬਾਰੀ ਕਦਮ ਬਹੁ-ਕਦਮੀ ਹੁੰਦੇ ਹਨ (ਜਿਵੇਂ ਪੇਮੈਂਟ ਰਿਕਾਰਡ + ਬੈਲੰਸ ਅਪਡੇਟ)। concurrency ਦੇ ਨਾਲ, isolation ਨਿਯਮ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਦੋ ਵਰਤੋਂਕਾਰ ਇੱਕੋ ਸਮੇਂ ਸਮਾਨ ਆਈਟਮ ਲਈ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਘਟਨਾ ਨੂੰ ਦੇਖਣ ਅਤੇ ਅਪਡੇਟ ਕਰਨ।
ਇੰਡੈਕਸLookup ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਪੂਰੀ ਟੇਬਲ ਸਕੈਨ ਕਰਕੇ ਨਹੀਂ ਦੇਖਣਾ ਪੈਂਦਾ, ਪਰ ਇੰਡੈਕਸ ਸਟੋਰੇਜ਼ ਖਰਚਦੇ ਹਨ ਅਤੇ ਲਿਖਤਾਂ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦੇ ਹਨ। ਕੁਐਰੀ ਪਟਿਮਾਈਜ਼ਰ ਇਕ ਚੰਗੀ ਰਣਨੀਤੀ ਚੁਣਦਾ ਹੈ (ਸਕੈਨ ਬਨਾਮ ਇੰਡੈਕਸ, ਜੋਇਨ ਕ੍ਰਮ ਆਦਿ), ਜਿਸ ਨਾਲ ਯੂਜ਼ਰ ਹਰੇਕ ਕਦਮ ਲਈ ਡੇਟਾਬੇਸ ਇੰਜੀਨੀਅਰ ਵਰਗਾ ਸੋਚਣ ਦੀ ਲੋੜ ਤੋਂ ਬਚਦੇ ਹਨ। ਆਖ਼ਰਕਾਰ, ਇਹੀ ਚੀਜ਼ ਰਿਪੋਰਟਿੰਗ ਵਿੰਡੋਜ਼ ਅਤੇ ਡੈਸ਼ਬੋਰਡਾਂ ਨੂੰ ਵੇਲੇ 'ਤੇ ਅਤੇ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀ ਹੈ ਜਦੋਂ ਡਾਟਾ ਵਧਦਾ ਹੈ।
LEFT JOIN= NULLCOALESCE ਵਰਤੋਂ... OR status IS NULL)