19 ਸਤੰ 2025·8 ਮਿੰਟ
ਡੋਨਲਡ ਚੇਬਰਲਿਨ ਅਤੇ SQL: ਡੇਟਾਬੇਸਾਂ 'ਤੇ ਪੁੱਛਤਾਛ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣਾ
ਡੋਨਲਡ ਚੇਬਰਲਿਨ ਨੇ IBM ਵਿੱਚ SQL ਦੇ ਖੋਜ ਵਿੱਚ ਕਿਵੇਂ ਯੋਗਦਾਨ ਦਿੱਤਾ, ਇਸਦੀ ਅੰਗਰੇਜ਼ੀ-ਸਮਾਨ ਵਿਆਕਰਨ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਅਤੇ SQL ਕਿਵੇਂ ਡੇਟਾਬੇਸਾਂ 'ਤੇ ਸਵਾਲ ਪੁੱਛਣ ਦਾ ਮਿਆਰੀ ਰਸਤਾ ਬਣਿਆ।
ਡੋਨਲਡ ਚੇਬਰਲਿਨ ਨੇ IBM ਵਿੱਚ SQL ਦੇ ਖੋਜ ਵਿੱਚ ਕਿਵੇਂ ਯੋਗਦਾਨ ਦਿੱਤਾ, ਇਸਦੀ ਅੰਗਰੇਜ਼ੀ-ਸਮਾਨ ਵਿਆਕਰਨ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਅਤੇ SQL ਕਿਵੇਂ ਡੇਟਾਬੇਸਾਂ 'ਤੇ ਸਵਾਲ ਪੁੱਛਣ ਦਾ ਮਿਆਰੀ ਰਸਤਾ ਬਣਿਆ।
Donald D. Chamberlin ਇੱਕ ਐਸਾ ਨਾਂ ਹੈ ਜੋ ਘਰੇਲੂ ਤੌਰ 'ਤੇ ਮਸ਼ਹੂਰ ਨਹੀਂ, ਪਰ ਉਸਦੇ ਕੰਮ ਨੇ ਚੁੱਪ ਚਾਪ ਤਰੀਕੇ ਨਾਲ ਵੱਧਤਰ ਸਾਫਟਵੇਅਰ ਟੀਮਾਂ ਦੇ ਡੇਟਾ ਸੰਭਾਲਣ ਦੇ ਢੰਗ ਨੂੰ ਅਤੇ ਰੂਪ ਦਿੱਤਾ। IBM ਦੇ ਇੱਕ ਰਿਸਰਚਰ ਦੇ ਤੌਰ 'ਤੇ, Chamberlin ਨੇ SQL (ਸਰਵਪ੍ਰਥਮ SEQUEL ਲਿਖਿਆ ਜਾਂਦਾ ਸੀ) ਦਾ ਸਹ-ਸਿਰਜਨ ਕੀਤਾ—ਇਹ ਭਾਸ਼ਾ ਉਹ ਸੀ ਜਿਸ ਨੇ ਵੱਡੇ ਡੇਟਾਬੇਸਾਂ ਤੋਂ ਜਵਾਬ ਮੰਗਣਾ ਰੋਜ਼ਮਰਰਾ ਦੇ ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਕਈ ਵਾਰ ਗੈਰ-ਮਾਹਿਰਾਂ ਲਈ ਪ੍ਰਯੋਗਯੋਗ ਬਣਾ ਦਿੱਤਾ।
SQL ਤੋਂ ਪਹਿਲਾਂ, ਸਟੋਰ ਕੀਤੇ ਡੇਟਾ ਵਿੱਚੋਂ ਜਵਾਬ ਲੱਭਣ ਲਈ ਅਕਸਰ ਕਸਟਮ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਪੈਂਦੇ ਸੀ ਜਾਂ ਐਸੇ টੂਲ ਵਰਤੇ ਜਾਂਦੇ ਜੋ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਅਸੁਵਿਧਾਜਨਕ ਹੁੰਦੇ। Chamberlin ਨੇ ਇੱਕ ਵੱਖਰਾ ਵਿਚਾਰ ਤਰੱਕੀ ਵਿੱਚ ਰੱਖਿਆ: ਕੰਪਿਊਟਰ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਦੱਸਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇਸ ਸ਼ੈਲੀ ਵਿੱਚ ਵਰਣਨ ਕਰ ਸਕੋ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ—ਇਹ ਐਨਗਰੇਜ਼ੀ ਵਰਗੀ ਪੜ੍ਹਨ-ਯੋਗ ਭਾਸ਼ਾ ਦੇ ਨੇੜੇ।
SQL ਦੇ ਕੇਂਦਰ ਵਿੱਚ ਇੱਕ ਹੈਰਾਨੀਜਨਕ ਤੌਰ ਤੇ ਮਨੁੱਖੀ-ਮਿੱਤਰ ਪਹੁੰਚ ਹੈ:
SELECT)FROM)WHERE)ਹੁਣ ਇਹ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਪਰ ਉਸ ਵੇਲੇ ਇਹ ਇੱਕ ਵੱਡਾ ਬਦਲਾਅ ਸੀ। ਇਸ ਨੇ “ਡੇਟਾਬੇਸ ਕੁਐਰੀ ਕਰਨ” ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ਜਨ ਦੇ ਕੰਮ ਤੋਂ ਉਸ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜੋ ਸਿੱਖਿਆ, ਸਾਂਝੀ ਕੀਤੀ, ਸਮੀਖਿਆ ਕੀਤੀ ਅਤੇ ਸੁਧਾਰੀ ਜਾ ਸਕਦੀ—ਹਰ ਹੋਰ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਦੇ ਹਿੱਸੇ ਵਾਂਗ।
ਇਹ SQL ਦੇ ਬਣਨ ਦੀ ਵਿਵਹਾਰਕ ਇਤਿਹਾਸ ਅਤੇ ਇਸਦੇ ਫੈਲਾਅ ਬਾਰੇ ਇੱਕ ਅਮਲਕਾਰੀ ਕਥਾ ਹੈ।
ਤੁਹਾਨੂੰ ਅਗੇ ਪੜ੍ਹਨ ਲਈ ਉੱਚ ਗਣਿਤ, ਫਾਰਮਲ ਲੌਜਿਕ ਜਾਂ ਡੇਟਾਬੇਸ ਦੇ ਥਿਊਰੀ ਦੀ ਲੋੜ ਨਹੀਂ ਪਏਗੀ। ਅਸੀਂ ਉਹ ਹਕੀਕਤੀਆਂ 'ਤੇ ਧਿਆਨ ਦੇਵਾਂਗੇ ਜੋ SQL ਨੇ ਹੱਲ ਕੀਤੀਆਂ, ਇਸਦੀ ਡਿਜ਼ਾਈਨ ਕਿਉਂ ਪਹੁੰਚਯੋਗ ਸੀ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਸਾਫਟਵੇਅਰ ਉਦਯੋਗ ਵਿੱਚ ਇੱਕ ਡਿਫਾਲਟ ਹੁੰਦਾ ਗਿਆ—ਬੈਕਐਂਡ ਇੰਜੀਨੀਅਰਿੰਗ ਤੋਂ ਲੈ ਕੇ ਵਿਸ਼ਲੇਸ਼ਣ, ਪ੍ਰੋਡੱਕਟ ਅਤੇ ਓਪਰੇਸ਼ਨ ਤੱਕ।
ਜੇ ਤੁਸੀਂ ਕਦੇ ਕਿਸੇ ਸੂਚੀ ਨੂੰ ਫਿਲਟਰ ਕੀਤਾ, ਨਤੀਜੇ ਗਰੂਪ ਕੀਤੇ ਜਾਂ ਦੋ ਸੈੱਟਾਂ ਨੂੰ ਜੋੜਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਸ ਸੋਚ ਵਿੱਚ ਲੱਗੇ ਹੋ ਜੋ SQL ਨੇ ਆਮ ਕੀਤਾ। Chamberlin ਦਾ ਸਥਾਈ ਯੋਗਦਾਨ ਇਹ ਸੀ ਕਿ ਉਸ ਨੇ ਉਹ ਸੋਚ ਇੱਕ ਐਸੀ ਭਾਸ਼ਾ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤੀ ਜੋ ਲੋਕ ਵਰਤ ਸਕਦੇ ਹਨ।
SQL ਤੋਂ ਪਹਿਲਾਂ, ਜ਼ਿਆਦਾਤਰ ਸੰਗਠਨਾਂ ਨੇ "ਡੇਟਾਬੇਸ ਕੁਐਰੀ" ਨਹੀਂ ਕੀਤੀ। ਉਹ ਡੇਟਾ ਫਾਈਲਾਂ ਵਿੱਚ ਰੱਖਿਆ ਹੁੰਦਾ—ਅਕਸਰ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇੱਕ ਫਾਈਲ—ਉਸੇ ਪ੍ਰੋਗਰਾਮ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਜੋ ਉਸ ਨੂੰ ਬਣਾਉਂਦਾ ਸੀ। ਪੇਰੋਲ ਦੀਆਂ ਫਾਈਲਾਂ ਆਪਣੀਆਂ, ਇਨਵੈਂਟਰੀ ਆਪਣੀਆਂ, ਅਤੇ ਗ੍ਰਾਹਕ ਰਿਕਾਰਡ ਕਈ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਵੰਡੇ ਹੋ ਸਕਦੇ ਸਨ।
ਫਾਈਲ-ਆਧਾਰਿਤ ਤਰੀਕਾ ਠੀਕ ਕੰਮ ਕਰਦਾ ਸੀ ਜਦੋਂ ਤੱਕ ਕਾਰੋਬਾਰ ਉਹ ਨਤੀਜੇ ਨਹੀਂ ਮੰਗਦੇ ਜੋ ਹਦਾਂ ਨੂੰ ਲਾਂਘਦੇ ਹੋਏ ਆਉਂਦੇ: “ਕਿਹੜੇ ਗਾਹਕ ਨੇ ਉਤਪਾਦ X ਖਰੀਦਿਆ ਅਤੇ ਉਹਨਾਂ ਕੋਲ ਬਕਾਇਆ ਇਨਵੌਇਸ ਵੀ ਹਨ?” ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਨਜ਼ਾਰੇ ਲਈ ਡੇਟਾ ਜੋੜਨਾ ਪੈਂਦਾ ਸੀ ਜੋ ਮਿਲਾਉਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਸੀ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ, ਡੇਟਾ ਫਾਰਮੇਟ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਕਾਫ਼ੀ ਕਸੇ ਹੋਏ ਹੁੰਦੇ। ਇਕ ਥਾਂ ਤੇ ਕੋਈ ਫੀਲਡ ਜੋੜਣਾ—ਜਿਵੇਂ ਗਾਹਕ ਦੇ ਫੋਨ ਨੰਬਰ ਲਈ ਨਵਾਂ ਖੇਤਰ—ਪ੍ਰੋਗਰਾਮ ਦੁਬਾਰਾ ਲਿਖਣ, ਫਾਈਲਾਂ ਬਦਲਣ ਅਤੇ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਅਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਪਾ ਸਕਦਾ ਸੀ। ਜਦੋਂ "ਡੇਟਾਬੇਸ ਸਿਸਟਮ" ਆਏ ਵੀ, ਬਹੁਤ ਸਾਰੇ ਹੇਠ ਲੈਵਲ ਐਕਸੈਸ ਤਰੀਕੇ ਦਿਖਾਂਦੇ ਰਹੇ ਜੋ ਪੁੱਛਤਾਛ ਕਰਨ ਦੀ ਥਾਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਜ਼ਿਆਦਾ ਲਗਦੇ।
ਜੇ ਤੁਹਾਨੂੰ ਜਾਣਕਾਰੀ ਚਾਹੀਦੀ ਸੀ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਵਿਕਲਪ ਹੁੰਦੇ:
ਇਨ੍ਹਾਂ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਵਿਕਲਪ ਖੋਜ-ਸੁਵਿਧਾ ਨਹੀਂ ਦਿੰਦਾ। ਛੋਟਾ-ਜਿਹਾ ਬਦਲਾਅ—ਤਾਰੀਖ ਦੀ ਰੇਂਜ ਜੋੜਨਾ, ਖੇਤਰ ਦੁਆਰਾ ਗਰੂਪ ਕਰਨਾ, ਵਾਪਸੀ ਨੂੰ ਬਿਨਾ ਗਿਣਤੀ ਕਰਨਾਂ—ਇੱਕ ਨਵੇਂ ਵਿਕਾਸ ਕੰਮ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਸੀ। ਨਤੀਜਾ ਇੱਕ ਬੋਤਲਨੇਕ ਸੀ: ਸਵਾਲ ਪੁੱਛਣ ਵਾਲਿਆਂ ਨੂੰ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਦੀ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਜੋ ਕੋਡ ਲਿਖ ਸਕਦੇ।
ਸੰਗਠਨਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝਾ ਢੰਗ ਚਾਹੀਦਾ ਸੀ ਜਿਸ ਨਾਲ ਡੇਟਾ ਸਵਾਲ ਦਾ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕੇ—ਕੁਝ ਐਸਾ ਜੋ ਮਸ਼ੀਨਾਂ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਵੇ, ਪਰ ਮਨੁੱਖਾਂ ਲਈ ਪੜ੍ਹਨਯੋਗ ਵੀ। ਕਾਰੋਬਾਰੀ ਲੋਕ "ਗ੍ਰਾਹਕ", "ਆਰਡਰ" ਅਤੇ "ਟੋਟਲ" ਵਿਚ ਸੋਚਦੇ ਹਨ। ਪ੍ਰਣਾਲੀਆਂ, ਦੂਜੇ ਪਾਸੇ, ਫਾਈਲ ਲੇਆਉਟ ਅਤੇ ਪ੍ਰੋਸੀਜਰਲ ਕਦਮਾਂ ਦੇ ਆਸਪਾਸ ਬਣੀਆਂ ਹੋਈਆਂ ਸਨ।
ਇਸ ਖੱਡ ਨੇ ਇੱਕ ਕੁਐਰੀ ਭਾਸ਼ਾ ਦੀ ਮੰਗ ਪੈਦਾ ਕੀਤੀ ਜੋ ਇਰਾਦੇ ਨੂੰ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲ ਸਕੇ: ਇੱਕ ਲਗਾਤਾਰ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਢੰਗ ਜੋ ਹਰ ਵਾਰੀ ਨਵਾਂ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਦੀ ਥਾਂ ਤੁਹਾਡੇ ਮੰਗੇ ਨੂੰ ਬਿਆਨ ਕਰੇ। ਇਹ ਜ਼ਮੀਨ ਸੈਟ ਕਰਨ ਲਈ SQL ਦੀ ਲੋੜ ਬਣੀ।
SQL ਵਜੂਦ ਵਿਚ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਡੇਟਾਬੇਸ ਦੀ ਦੁਨੀਆ ਨੂੰ ਡਾਟਾ ਬਾਰੇ ਸੋਚਣ ਲਈ ਇੱਕ ਸਾਫ਼ ਫਰੇਮਵਰਕ ਦੀ ਲੋੜ ਸੀ। ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਨੇ ਇਹ ਦਿੱਤਾ: ਇੱਕ ਸਧਾਰਣ, ਇੱਕਸਾਰ ਢੰਗ ਜਿੱਥੇ ਜਾਣਕਾਰੀ ਟੇਬਲਾਂ (ਰਿਲੇਸ਼ਨ) ਵਿੱਚ ਰੱਖੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿ ਕਤਾਰਾਂ ਅਤੇ ਕਾਲਮਾਂ ਨਾਲ ਬਣੀ ਹੁੰਦੀ ਹੈ।
ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਦਾ ਮੁੱਖ ਵਾਅਦਾ ਸਾਧਾ ਸੀ: ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇਕ-ਆਫ ਵਰਕ ਦੀ ਤਰ੍ਹਾਂ ਜੋੜੇ ਜਾਣ ਵਾਲੇ ਅਤੇ ਮੁਸ਼ਕਿਲ-ਰੱਖ-ਰਖਾਵ ਵਾਲੇ ਡੇਟਾ ਸਟਰੱਕਚਰ ਬਣਾਉਣ ਦੀ ਬਜਾਏ, ਡੇਟਾ ਨੂੰ ਇੱਕ ਮਿਆਰੀ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕਰੋ ਅਤੇ ਹੋਰ-ਹੋਰ ਪ੍ਰੋਗਰਾਮ ਵੱਖ-ਵੱਖ ਸਵਾਲ ਪੁੱਛ ਸਕਣ ਬਿਨਾਂ ਡੇਟਾ ਦੇ ਆਯੋਜਨ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ।
ਇਹ ਬਦਲਾਅ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਇਸਨੇ ਉਹ ਦੋ ਚੀਜ਼ਾਂ ਜੋ ਅਕਸਰ ਗੁੰਝੀਆਂ ਹੁੰਦੀਆਂ ਸਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਵੱਖ ਕੀਤਾ:
ਜਦ ਇਹ ਚਿੰਤਾਵਾਂ ਅਲੱਗ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਡੇਟਾ ਸਾਂਝਾ ਕਰਨ ਲਈ ਆਸਾਨ, ਅਪਡੇਟ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਅਤੇ ਕਿਸੇ ਖ਼ਾਸ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਅਨੋਖੀ ਤਕਨੀਕਾਂ 'ਤੇ ਨਿਰਭਰ ਘੱਟ ਹੋ ਜਾਂਦਾ ਹੈ।
Edgar F. Codd, ਜੋ IBM ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਨੇ ਇਸ ਵਿਚਾਰ ਨੂੰ ਨਿਯਮਤ ਕੀਤਾ ਅਤੇ ਸਮਝਾਇਆ ਕਿ ਇਹ ਰਿਕਾਰਡਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਰਾਹਾਂ ਦੁਆਰਾ ਨੇਵੀਗੇਟ ਕਰਨ ਨਾਲੋਂ ਕਿਉਂ ਬਿਹਤਰ ਹੈ। ਤੁਹਾਨੂੰ ਪੂਰੇ ਅਕਾਦਮਿਕ ਪਿਛੋਕੜ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਪ੍ਰਭਾਵ ਨੂੰ ਸਮਝਣ ਲਈ: ਉਸਨੇ ਉਦਯੋਗ ਨੂੰ ਇੱਕ ਐਸਾ ਮਾਡਲ ਦਿੱਤਾ ਜੋ ਸੋਚਿਆ, ਟੈਸਟ ਕੀਤਾ ਅਤੇ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਸੀ।
ਜਦੋਂ ਡੇਟਾ ਟੇਬਲਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਗਲਾ ਕੁਦਰਤੀ ਸਵਾਲ ਇਹ ਹੈ: ਆਮ ਲੋਕ ਆਪਣੀ ਲੋੜ ਕਿਵੇਂ ਪੁੱਛਣ? ਆਪਣੀ ਸਟੋਰੇਜ ਸਥਾਨ ਨੂੰ ਨਿਸ਼ਾਨਾ ਦਿਖਾ ਕੇ ਨਹੀਂ, ਪਰ ਨਤੀਜੇ ਦਾ ਵਰਣਨ ਕਰਕੇ।
ਉਹ "ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ" ਵਾਲੀ ਪਹੁੰਚ—ਇਹਨਾਂ ਕਾਲਮਾਂ ਨੂੰ ਚੁਣੋ, ਇਹਨਾਂ ਕਤਾਰਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰੋ, ਇਹਨਾਂ ਟੇਬਲਾਂ ਨੂੰ ਜੋੜੋ—ਇੱਕ ਮਨੁੱਖੀ-ਮਿੱਤਰ ਕੁਐਰੀ ਭਾਸ਼ਾ ਲਈ ਜਮੀਨ ਤਿਆਰ ਕੀਤੀ। SQL ਨੂੰ ਇਸ ਮਾਡਲ ਦੇ ਲਾਭ ਲੈਣ ਲਈ ਬਣਾਇਆ ਗਿਆ, ਰਿਲੇਸ਼ਨਲ ਥਿਊਰੀ ਨੂੰ ਰੋਜ਼ਾਨਾ ਕੰਮ ਵਿੱਚ ਬਦਲਣ ਲਈ।
IBM System R ਪਹਿਲਾਂ ਕੋਈ ਵਪਾਰਕ ਉਤਪਾਦ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਰਿਸਰਚ ਪ੍ਰੋਜੈਕਟ ਸੀ ਜਿਸਦਾ ਮਕਸਦ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਸੀ: ਕੀ Edgar F. Codd ਦਾ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਅਸਲ ਦੁਨੀਆਂ ਵਿੱਚ, ਵੱਡੇ ਪੱਧਰ ਤੇ, ਕਾਰੋਬਾਰੀ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ?
ਉਸ ਵੇਲੇ ਕਈ ਡੇਟਾਬੇਸ ਸਿਸਟਮ ਫਿਜ਼ੀਕਲ ਐਕਸੈਸ ਪਾਥ ਤੇ ਰਿਕਾਰਡ-ਬਾਈ-ਰਿਕਾਰਡ ਲੌਜਿਕ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਸੀ। ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਕੁਝ ਵੱਖਰਾ ਵਾਅਦਾ ਕਰਦੇ ਸਨ: ਡੇਟਾ ਨੂੰ ਟੇਬਲਾਂ ਵਿੱਚ ਰੱਖੋ, ਰਿਸ਼ਤਿਆਂ ਨੂੰ ਸਾਫ਼ ਵਰਣਨ ਕਰੋ, ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਇਹ ਨਿਰਣੈ ਕਰਨ ਦਿਓ ਕਿ ਨਤੀਜਾ ਕਿਵੇਂ ਰੁਝਾਇਆ ਜਾਵੇ। ਪਰ ਇਹ ਵਾਅਦਾ ਦੋ ਚੀਜ਼ਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਸੀ: ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰਿਲੇਸ਼ਨਲ ਇੰਜਿਨ ਅਤੇ ਇੱਕ ਕੁਐਰੀ ਭਾਸ਼ਾ ਜੋ ਆਮ ਡਿਵੈਲਪਰਾਂ (ਅਤੇ ਕੁਝ ਗੈਰ-ਡਿਵੈਲਪਰਾਂ) ਲਈ ਵਰਤਣ ਯੋਗ ਹੋਵੇ।
System R, ਜੋ 1970s ਵਿੱਚ IBM ਦੇ San Jose Research Laboratory ਵਿੱਚ ਵਿਕਸਿਤ ਕੀਤਾ ਗਿਆ, ਇੱਕ ਪ੍ਰੋਟੋਟਾਇਪ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਮੈਨੇਜਮੈਂਟ ਸਿਸਟਮ ਬਣਾਉਣ ਅਤੇ ਰਿਲੇਸ਼ਨਲ ਵਿਚਾਰ ਨੂੰ ਤਣਾਅ ਤਹਿਤ ਟੈਸਟ ਕਰਨ ਦਾ ਇਰਾਦਾ ਰੱਖਦਾ ਸੀ।
ਇਸ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ, ਇਸ ਨੇ ਅਜਿਹੀਆਂ ਤਕਨੀਕਾਂ 'ਤੇ ਅਨੁਸੰਧਾਨ ਕੀਤਾ ਜੋ ਹੁਣ ਮੁਢਲੇ ਨੀਵ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਕੁਐਰੀ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ। ਜੇ ਉਪਭੋਗਤਾ ਉੱਚ-ਸਤ੍ਹਰ ਬੇਨਤੀ ਲਿਖਣਗੇ ("ਮੈਨੂੰ ਇਹ ਰਿਕਾਰਡ ਦਿਖਾਓ ਜੋ ਇਹਨਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਮੀਟ ਕਰਦੇ ਹਨ"), ਤਾਂ ਸਿਸਟਮ ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਓਪਰੇਸ਼ਨਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਪੈਣਾ ਸੀ।
Donald Chamberlin, IBM ਦੇ ਰਿਸਰਚ ਮਾਹੌਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹੋਏ, ਗੁੰਝਲਦਾਰ ਹਿੱਸਾ ਤੇ ਧਿਆਨ ਦੇ ਰਿਹਾ ਸੀ: ਰਿਲੇਸ਼ਨਲ ਡੇਟਾ 'ਤੇ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਇੱਕ ਅਮਲੀ ਭਾਸ਼ਾ। Raymond Boyce ਸਮੇਤ ਸਹਯੋਗੀਆਂ ਨਾਲ, ਉਸ ਨੇ ਇੱਕ ਕੁਐਰੀ ਭਾਸ਼ਾ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ ਜੋ ਲੋਕਾਂ ਦੀ ਵਰਤਨ-ਭਾਸ਼ਾ ਨਾਲ ਮਿਲਦੀ ਸੀ।
ਇਹ ਭਾਸ਼ਾ-ਡਿਜ਼ਾਈਨ ਇੱਕ ਖ਼ਾਲੀ ਥਾਂ 'ਤੇ ਨਹੀਂ ਸੀ। System R ਨੇ ਫੀਡਬੈਕ ਲੂਪ ਪ੍ਰਦਾਨ ਕੀਤਾ: ਜੇ ਕੋਈ ਭਾਸ਼ਾ ਫੀਚਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਤਾਂ ਉਹ ਜੀਵਤ ਨਹੀਂ ਰਿਹਾ। ਜੇ ਕੋਈ ਫੀਚਰ ਆਮ ਕੰਮਾਂ ਨੂੰ ਅਸਾਨ ਬਣਾਉਂਦਾ, ਤਾਂ ਉਸ ਨੂੰ ਫੈਲਣ ਦਾ ਮੌਕਾ ਮਿਲਿਆ।
Codd ਨੇ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਨੂੰ ਫਾਰਮਲ ਗਣਿਤ (ਰਿਲੇਸ਼ਨਲ ਐਲਜੈਬਰਾ ਅਤੇ ਰਿਲੇਸ਼ਨਲ ਕੈਲਕੁਲਸ) ਦੀ ਵਰਤੋਂ ਨਾਲ ਵਰਣਨ ਕੀਤਾ। ਉਹ ਆਈਡੀਆਜ਼ ਬਲਸ਼ਾਲੀ ਸਨ, ਪਰ ਆਮ ਦਿਨ-ਚਿਰਿਆ ਕੰਮ ਲਈ ਬਹੁਤ ਅਕਾਦਮਿਕ ਸਨ। System R ਨੂੰ ਇੱਕ ਐਸੀ ਭਾਸ਼ਾ ਚਾਹੀਦੀ ਸੀ ਜੋ:
ਉਹ ਖੋਜ—ਇੱਕ ਕੰਮ ਕਰਦੇ ਰਿਲੇਸ਼ਨਲ ਪ੍ਰੋਟੋਟਾਇਪ 'ਤੇ ਆਧਾਰਿਤ—SEQUEL ਅਤੇ ਫਿਰ SQL ਲਈ ਰਸਤਾ ਢੋਹ ਰਹੀ ਸੀ।
Donald Chamberlin ਅਤੇ ਉਸਦੇ ਸਹਯੋਗੀਆਂ ਨੇ ਆਪਣੀ ਨਵੀਂ ਭਾਸ਼ਾ ਦਾ ਨਾਂ ਪਹਿਲਾਂ SEQUEL ਰੱਖਿਆ, ਜੋ ਕਿ Structured English Query Language ਦੇ ਲਈ ਛੋਟਾ ਸੀ। ਇਹ ਨਾਂ ਮੁੱਖ ਵਿਚਾਰ ਦਾ ਸੰਕੇਤ ਸੀ: ਪ੍ਰੋਸੀਜਰਲ ਕੋਡ ਲਿਖਣ ਦੀ ਥਾਂ, ਜੋ ਕਿ ਡੇਟਾ ਤਕ ਕਦਮ-ਦਰ-ਕਦਮ ਨੇਵੀਗੇਟ ਕਰਦਾ, ਤੁਸੀਂ ਇਕ ਐਸਾ ਬਿਆਨ ਦਿਓ ਜੋ ਰੋਜ਼ਮਰਰਾ ਦੀ ਅੰਗਰੇਜ਼ੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਵੇ।
SEQUEL ਬਾਅਦ ਵਿੱਚ ਛੋਟਾ ਕਰਕੇ SQL ਹੋ ਗਿਆ (ਅਕਸਰ ਵਿਆਖਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਇਹ ਹਿੱਸੇ-ਤੌਰ 'ਤੇ ਪ੍ਰਯੋਗਕਾਰੀ ਸੀ—ਛੋਟਾ, ਪ੍ਰਿੰਟ ਕਰਨ ਅਤੇ ਕਹਿਣ ਵਿੱਚ ਅਸਾਨ, ਅਤੇ ਨਾਂ ਅਤੇ ਟਰੇਡਮਾਰਕ ਲਈ ਵੀ ਸਹਾਇਕ)। ਪਰ "Structured English" ਦੀ ਲਕੜੀ ਉਹੀ ਰਹੀ।
ਡਿਜ਼ਾਈਨ ਦਾ ਲਕੜੀ هدف ਇਹ ਸੀ ਕਿ ਡੇਟਾਬੇਸ ਕੰਮ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਬੇਨਤੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਵੇ:
ਇਸ ਢਾਂਚੇ ਨੇ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਲਗਾਤਾਰ ਮਾਨਸਿਕ ਨਕਸ਼ਾ ਦਿੱਤਾ। ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੇਂਡਰ ਦੇ ਖਾਸ ਨੈਵੀਗੇਸ਼ਨ ਨਿਯਮ ਨਹੀਂ ਸਿੱਖਣੇ ਪੈਂਦੇ; ਤੁਸੀਂ ਇੱਕ ਪੜ੍ਹਨਯੋਗ ਪੈਟਰਨ ਸਿੱਖਦੇ ਹੋ ਜੋ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਕਾਰੋਬਾਰੀ ਸਵਾਲ ਸੋਚੋ: “ਇਸ ਸਾਲ ਕੈਲੀਫੋਰਨੀਆ ਦੇ ਕਿਹੜੇ ਗਾਹਕ ਸਭ ਤੋਂ ਵੱਧ ਖਰਚੇ ਨੇ?” SQL ਤੁਹਾਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਸ ਇਰਾਦੇ ਨੂੰ ਪ੍ਰਕਟ ਕਰਨ ਦਿੰਦਾ:
SELECT customer_id, SUM(amount) AS total_spent
FROM orders
WHERE state = 'CA' AND order_date >= '2025-01-01'
GROUP BY customer_id
ORDER BY total_spent DESC;
ਭਾਵੇਂ ਤੁਸੀਂ ਡੇਟਾਬੇਸਾਂ ਵਿਚ ਨਵੇਂ ਹੋ, ਅਕਸਰ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ:
ਉਹ ਪੜ੍ਹਨਯੋਗਤਾ—ਸਾਥ ਹੀ ਨਿਯਮਤ ਨਿਯਮ—ਜਿਸ ਨੇ SQL ਨੂੰ IBM System R ਤੋਂ ਬਾਹਰ ਫੈਲਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।
ਇੱਕ ਕਾਰਨ ਕਿ SQL ਜ਼ਿ਼ੰਦਾ ਰਹਿ ਗਿਆ ਹੈ ਇਹ ਹੈ ਕਿ ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਸਵਾਲ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣ ਦਿੰਦਾ ਹੈ ਜਿਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਮुँਹ ਫੋਲ੍ਹਕੇ ਪੁੱਛਦੇ ਹੋ: "ਇਹ ਚੀਜ਼ਾਂ ਚੁਣੋ, ਇਸ ਜਗ੍ਹਾ ਤੋਂ, ਇਹਨਾਂ ਸ਼ਰਤਾਂ ਨਾਲ।" ਤੁਹਾਨੂੰ ਨਤੀਜੇ ਲੱਭਣ ਲਈ ਕਦਮ-ਦਰ-ਕਦਮ ਨਹੀਂ ਦੱਸਣਾ ਪੈਂਦਾ; ਤੁਸੀਂ ਕਿੱਹੜਾ ਨਤੀਜਾ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਦੱਸੋ।
SELECT = ਤੁਸੀਂ ਜੋ ਕਾਲਮ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਚੁਣੋ।
FROM = ਉਹ ਕਿੱਸ ਟੇਬਲ (ਜਾਂ ਡੇਟਾਸੈੱਟ) ਤੋਂ ਆਉੰਦਾ ਹੈ।
WHERE = ਜੋ ਪੰਗਤੀਆਂ ਤੁਹਾਨੂੰ ਚਾਹੀਦੀਆਂ ਹਨ ਉਹ ਫਿਲਟਰ ਕਰੋ।
JOIN = ਸੰਬੰਧਤ ਟੇਬਲਾਂ ਨੂੰ ਮਿਲਾਓ (ਜਿਵੇਂ orders ਵਿੱਚ customer_id ਨੂੰ customers ਵਿੱਚੋਂ ਉਸੇ customer_id ਨਾਲ ਮਿਲਾਉਣਾ)।
GROUP BY = ਵਰਗਾਂ ਦੁਆਰਾ ਸਾਰਾਂਸ਼ ਕਰੋ, ਤਾਂ ਜੋ ਤੁਸੀਂ "ਪਰ ਗਾਹਕ", "ਪਰ ਮਹੀਨਾ" ਜਾਂ "ਪਰ ਉਤਪਾਦ" ਵਰਗੇ ਨਤੀਜੇ ਬਣਾ ਸਕੋ।
SELECT customer_name, COUNT(*) AS order_count
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE orders.status = 'Shipped'
GROUP BY customer_name;
ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪੜ੍ਹੋ: "ਹਰ ਗਾਹਕ ਦਾ ਨਾਮ ਅਤੇ ਆਰਡਰਾਂ ਦੀ ਗਿਣਤੀ ਚੁਣੋ, orders ਨੂੰ customers ਨਾਲ ਜੋੜ ਕੇ, ਸਿਰਫ਼ shipped ਆਰਡਰ ਰੱਖੋ, ਅਤੇ ਗਾਹਕ ਦੁਆਰਾ ਸਾਰਾਂਸ਼ ਕਰੋ।"
ਜੇ SQL ਘਬਰਾਹਟ ਜੇਹਾ ਲੱਗੇ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਆਪਣਾ ਲਕਸ਼ ਦੇ ਇੱਕ ਪੰਗਤੀ ਵਿੱਚ ਦੁਹਰਾਓ। ਫਿਰ ਸ਼ਬਦਾਂ ਨੂੰ ਨਕਸ਼ੇ 'ਤੇ ਲਿਉ:
ਇਹ ਸਵਾਲ-ਪਹਿਲਾ ਆਦਤ SQL ਦੇ ਮਨੁੱਖ-ਮਿੱਤਰ ਡਿਜ਼ਾਈਨ ਦੀ ਅਸਲ ਵਜ੍ਹਾ ਹੈ।
SQL ਨੇ ਸਿਰਫ਼ ਡੇਟਾ ਨਾਲ ਗੱਲ ਕਰਨ ਦਾ ਨਵਾਂ ਢੰਗ ਨਹੀਂ ਲਿਆ—ਇਸਨੇ ਇਹ ਘਟਾਇਆ ਕਿ "ਡੇਟਾਬੇਸ ਵਿਅਕਤੀ" ਕੌਣ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਜਵਾਬ ਮਿਲ ਸਕੇ। SQL ਤੋਂ ਪਹਿਲਾਂ, ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਅਕਸਰ ਪ੍ਰੋਸੀਜਰਲ ਕੋਡ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ, ਸਟੋਰੇਜ ਵਿਵਰਣ ਸਮਝਣੇ ਪੈਂਦੇ ਸਨ, ਜਾਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ਗਿਆ ਨੂੰ ਅਰਜ਼ੀ ਦੇਣੀ ਪੈਂਦੀ ਸੀ। Chamberlin ਦਾ ਕੰਮ ਇਸ ਨੂੰ ਫਲਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਸੀ: ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ ਬਿਆਨ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਡੇਟਾਬੇਸ ਇਹ ਨਿਰਧਾਰਨ ਕਰਦਾ ਕਿ ਕਿਵੇਂ ਨਤੀਜਾ ਲਿਆਣਾ ਹੈ।
SQL ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਪਹੁੰਚਯੋਗਤਾ ਦੀ ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਇਹ ਪਢ੍ਹਨਯੋਗ ਇ enoughness ਤੱਕ ਕਾਫੀ ਹੈ ਕਿ ਅਨਾਲਿਸਟ, ਡਿਵੈਲਪਰ ਅਤੇ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਇਸ ਨੂੰ ਸਾਂਝਾ ਕਰ ਸਕਣ। ਇਕ ਸ਼ੁਰੂਆਤੀ ਵੀ ਇੱਕ ਕਵੈਰੀ ਦਾ ਉਦੇਸ਼ ਸਮਝ ਸਕਦਾ ਹੈ ਜਿਵੇਂ:
SELECT product, SUM(revenue)
FROM sales
WHERE sale_date >= '2025-01-01'
GROUP BY product;
ਤੁਹਾਨੂੰ ਇੰਡੈਕਸ ਸਟ੍ਰਕਚਰ ਜਾਂ ਫਾਈਲ ਲੇਆਉਟਸ ਨੂੰ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਦੇਖ ਸਕੋ ਕਿ ਕੀ ਪੁੱਛਿਆ ਜਾ ਰਿਹਾ ਹੈ: ਤਾਰੀਖ-ਰੇਂਜ ਲਈ ਉਤਪਾਦ ਅਨੁਸਾਰ ਕੁੱਲ ਆਮਦਨੀ।
ਚੁੱਕੋਂ SQL ਘੋਸ਼ਣਾਤਮਕ ਅਤੇ ਆਮ ਤੌਰ ਤੇ ਸਿੱਖਾਈ ਜਾਣ ਵਾਲੀ ਹੈ, ਇਹ ਯੋਜ਼ਨਾ ਅਤੇ ਡੀਬੱਗਿੰਗ ਦੌਰਾਨ ਇੱਕ ਆਮ ਰੁਫ਼ ਤੌਰ 'ਤੇ ਵਰਤੀ ਜਾਂਦੀ। ਇੱਕ ਪ੍ਰੋਡਕਟ ਮੈਨੇਜਰ ਸਵਾਲ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ("ਕੀ ਅਸੀਂ ਰਿਫੰਡਾਂ ਗਿਣ ਰਹੇ ਹਾਂ?")। ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਕ ਸਪਰਸ਼ ਬਮੀਤ ਕਰ ਸਕਦਾ। ਇਕ ਇੰਜੀਨੀਅਰ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਸਕਦਾ ਜਾਂ ਲੌਜਿਕ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਮੂਵ ਕਰ ਸਕਦਾ ਹੈ।
ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ, SQL ਖੋਜ-ਪ੍ਰਸ਼ਨ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਵਰਜਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਟਿੱਪਣੀਆਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਟੈਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ—ਕੋਡ ਵਾਂਗ।
SQL ਪੁੱਛਣਾ ਆਸਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਭਰੋਸੇਯੋਗ ਨਤੀਜੇ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਤੁਹਾਨੂੰ ਹੁਣ ਵੀ ਚਾਹੀਦਾ ਹੈ:
SQL ਸਵੈ-ਸੇਵਾ ਡੇਟਾ ਕੰਮ ਲਈ ਰਸਤਾ ਖੋਲ੍ਹਦਾ ਹੈ, ਪਰ ਚੰਗਾ ਨਤੀਜਾ ਚੰਗੇ ਡੇਟਾ ਅਤੇ ਸਾਂਝੇ ਅਰਥ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
SQL ਨੇ ਜਿੱਤ ਨਹੀਂ ਕੀਤੀ ਕਿਉਂਕਿ ਇਹ ਇਕੱਲੀ ਕੁਐਰੀ ਭਾਸ਼ਾ ਸੀ—ਇਸ ਨੇ ਜਿੱਤ ਲਈ ਕਿਉਂਕਿ ਇਹ ਉਸ ਉਦਯੋਗ ਲਈ ਪ੍ਰਯੋਗਕਾਰੀ ਸੀ ਜੋ ਸਾਂਝੇ ਆਦਤਾਂ ਦੀ ਲੋੜ ਰੱਖਦਾ ਸੀ। ਜਿਵੇਂ-ਜਿਵੇਂ ਟੀਮਾਂ ਨੇ ਦੇਖਿਆ ਕਿ SQL ਉਨ੍ਹਾਂ ਨੂੰ ਹਰ ਰਿਪੋਰਟ ਲਈ ਨਵਾਂ ਕੋਡ ਲਿਖਣ ਤੋਂ ਬਗੈਰ ਡੇਟਾ ਤੋਂ ਸਪਸ਼ਟ ਸਵਾਲ ਪੁੱਛਣ ਦਿੰਦਾ, ਇਹ ਹੋਰ ਉਤਪਾਦਾਂ, ਟ੍ਰੇਨਿੰਗਾਂ ਅਤੇ ਨੌਕਰੀਆਂ ਵਿੱਚ ਦਾਖਲ ਹੋ ਗਿਆ।
ਜਿਵੇਂ ਡੇਟਾਬੇਸ ਵੇਂਡਰਾਂ ਨੇ SQL ਸਹਿਯੋਗ ਜੋੜਿਆ, ਹੋਰ ਸਾਫਟਵੇਅਰ ਨੇ ਵੀ ਇਸਦਾ फ़ਾਇਦਾ ਉਠਾਇਆ। ਰਿਪੋਰਟਿੰਗ ਟੂਲ, ਬਿਜ਼ਨਸ ਇੰਟੈਲਿਜੈਂਸ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਫਰੇਮਵਰਕਸ—ਸਭ ਨੇ ਇੱਕ ਆਮ ਢੰਗ ਨਾਲ ਡੇਟਾ ਖਿੱਚਣ ਅਤੇ ਸ਼ੇਪ ਕਰਨ ਦੀ ਸੁਵਿਧਾ ਪਾਈ।
ਇਸਨੇ ਇੱਕ ਸਕਾਰਾਤਮਕ ਚਕਰ ਬਣਾਇਆ:
ਇੱਥੇ ਤੱਕ ਕਿ ਜਦੋਂ ਡੇਟਾਬੇਸਾਂ ਦੀਆਂ ਅੰਦਰੂਨੀ ਵਿਭਿੰਨਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਇੱਕ ਪਛਾਣਯੋਗ SQL "ਸਰਫੇਸ" ਹੋਣ ਨਾਲ ਸਿਸਟਮਾਂ ਨੂੰ ਸਵਿੱਚ ਜਾਂ ਇਕੱਠਾ ਕਰਨ ਦੀ ਲੋੜ ਘਟ ਜਾਂਦੀ।
ਪੋਰਟੇਬਿਲਿਟੀ ਦਾ ਮਤਲਬ "ਬਿਨਾਂ ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਹਰ ਜਗ੍ਹਾ ਚੱਲੇ" ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਮੁੱਖ ਵਿਚਾਰ—SELECT, WHERE, JOIN, GROUP BY—ਉਤਪਾਦਾਂ ਵਿੱਚ ਪਛਾਣਯੋਗ ਰਹਿੰਦੇ ਹਨ। ਇੱਕ ਕੁਐਰੀ ਜੋ ਇੱਕ ਸਿਸਟਮ ਲਈ ਲਿਖੀ ਗਈ ਹੈ, ਅਕਸਰ ਦੂਜੇ ਲਈ ਸਿਰਫ ਛੋਟੀਆਂ ਸੋਧਾਂ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ। ਇਸਨੇ ਵੇਂਡਰ-ਲਾਕਇਨ ਨੂੰ ਘਟਾਇਆ ਅਤੇ ਮਾਈਗਰੇਸ਼ਨ ਨੂੰ ਘੱਟ ਡਰਾਵਣਾ ਬਣਾਇਆ।
ਸਮੇਂ ਨਾਲ, SQL ਨੂੰ ਮਿਆਰਿਤ ਕੀਤਾ ਗਿਆ: ਇੱਕ ਸਾਂਝਾ ਨਿਯਮ ਤੇ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦਾ ਸੈਟ ਜੋ ਵੇਂਡਰ ਅਕਸਰ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਇਸਨੂੰ ਗ੍ਰੈਮਰ ਵਾਂਗ ਸੋਚੋ। ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਦੇ ਆਪਣੇ ਉਚਾਰਣ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਮੁਢਲਾ ਗ੍ਰੈਮਰ ਤੁਹਾਨੂੰ ਸੰਚਾਰ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਲੋਕਾਂ ਅਤੇ ਸੰਗਠਨਾਂ ਲਈ, ਇਸ ਮਿਆਰੀਕਰਨ ਦੇ ਵੱਡੇ ਪ੍ਰਭਾਵ ਰਹੇ:
ਅੰਤਿਮ ਨਤੀਜਾ: SQL ਰਿਲੇਸ਼ਨਲ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਡਿਫਾਲਟ "ਆਮ ਭਾਸ਼ਾ" ਬਣ ਗਿਆ।
SQL ਸਿਰਫ਼ ਇਸ ਗੱਲ ਨੂੰ ਬਦਲਿਆ ਕਿ ਲੋਕ ਡੇਟਾ ਨੂੰ ਕਿਸ ਤਰ੍ਹਾਂ ਪ੍ਰਸ਼ਨ ਪੁੱਛਦੇ—ਇਸਨੇ ਇਸ ਗੱਲ ਨੂੰ ਵੀ ਬਦਲਿਆ ਕਿ ਸਾਫਟਵੇਅਰ ਕੀ ਤਰੀਕੇ ਨਾਲ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਆਮ ਢੰਗ ਹੋ ਗਿਆ ਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਕਿਵੇ ਪੁੱਛਣਾ ਹੈ, ਪੂਰੇ ਉਤਪਾਦ ਵਰਗਾਂ ਨੇ ਇਹ ਮੰਨ ਲਿਆ ਕਿ "SQL ਉਪਲਬਧ ਹੈ" ਅਤੇ ਉੱਪਰਲੇ ਤੱਥਾਂ ਤੇ ਧਿਆਨ ਦੇਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ।
ਤੁਸੀਂ SQL ਨੂੰ ਬਿਜ਼ਨਸ ਐਪਲੀਕੇਸ਼ਨ (CRM, ERP, ਫਾਇਨੈਂਸ ਸਿਸਟਮ), ਰਿਪੋਰਟਿੰਗ ਡੈਸ਼ਬੋਰਡਾਂ ਵਿੱਚ ਅਤੇ ਵੈੱਬ ਸਰਵਿਸਿਜ਼ ਦੇ ਪਿੱਛੇ ਦੇਖਦੇ ਹੋ ਜੋ ਰਿਕਾਰਡ ਫੈਚ ਅਤੇ ਅਪਡੇਟ ਕਰਦੇ ਹਨ। ਭਲੇ ਹੀ ਯੂਜ਼ਰਾਂ ਨੇ ਕਦੇ ਇੱਕ ਕੁਐਰੀ ਨਹੀਂ ਟਾਈਪ ਕੀਤੀ, ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਸ ਅੰਡਰ-ਹੱਡੀ ਵਿੱਚ SQL ਜਨਰੇਟ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਆਰਡਰ ਫਿਲਟਰ ਕਰਨ, ਟੋਟਲ ਗਣਨਾ ਕਰਨ ਜਾਂ ਗਾਹਕ ਪ੍ਰੋਫਾਇਲ ਬਣਾਉਣ ਲਈ।
ਇਸ ਵਿਸ਼ਾਲ ਉਪਸਥਿਤੀ ਨੇ ਇੱਕ ਮਜ਼ਬੂਤ ਪੈਟਰਨ ਬਣਾਇਆ: ਜੇ ਤੁਹਾਡਾ ਸਾਫਟਵੇਅਰ SQL ਬੋਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਘੱਟ ਕਸਟਮ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਨਾਲ ਕਈ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਾਂਝੀ ਕੁਐਰੀ ਭਾਸ਼ਾ ਨੇ ਅਜਿਹੇ ਟੂਲ ਬਣਾਉਣਾ ਸਮਭਵ ਕੀਤਾ ਜੋ ਡੇਟਾਬੇਸਾਂ ਦੇ "ਆਸ-ਪਾਸ" ਬੈਠਦੇ ਹਨ:
ਕੁੰਜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਟੂਲ ਕਿਸੇ ਇੱਕ ਵੇਂਡਰ ਦੀ ਇੰਟਰਫੇਸ ਨਾਲ ਬੱਝੇ ਨਹੀਂ—ਉਹ SQL ਦੀਆਂ ਧਾਰਨਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਜੋ ਟਰਾਂਸਫਰ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਇੱਕ ਕਾਰਨ ਕਿ 2025 ਵਿੱਚ ਵੀ SQL ਮਹੱਤਵਪੂਰਨ ਹੈ, ਇਹ ਹੈ ਕਿ ਇਹ ਇਰਾਦੇ ਅਤੇ ਕਾਰਜਾਨਵੈਨ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਟਿਕਾਊ ਸਹਿਮਤੀ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ। ਭਲੇ ਹੀ ਤੁਸੀਂ ਉੱਚ-ਸਤਰ ਦੇ ਟੂਲਾਂ ਜਾਂ AI ਨਾਲ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਇੱਕ ਡੇਟਾਬੇਸ ਲੇਅਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਵਿਆਖਿਆਯੋਗ, ਟੈਸਟਯੋਗ ਅਤੇ ਆਡੀਟਯੋਗ ਹੋਵੇ।
ਉਦਾਹਰਨ ਲਈ, Koder.ai ਦੇ ਉਪਰ (ਇੱਕ ਵਾਈਬ-ਕੋਡਿੰਗ ਪਲੈਟਫਾਰਮ ਜੋ ਚੈਟ ਰਾਹੀਂ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਂਦਾ ਹੈ), ਟੀਮਾਂ ਅਕਸਰ "ਐਪ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ" ਨੂੰ ਸਪਸ਼ਟ ਰਿਲੇਸ਼ਨਲ ਟੇਬਲਾਂ ਅਤੇ SQL ਕੁਐਰੀਆਂ ਵਿੱਚ ਗਰਾਊਂਡ ਕਰਦੇ ਹਨ। ਅੰਦਰਲੀ ਤੌਰ 'ਤੇ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ Go ਬੈਕਐਂਡ ਨਾਲ PostgreSQL ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ SQL ਜੋਇਨ, ਫਿਲਟਰ ਅਤੇ ਐਗ੍ਰੀਗੇਟ ਲਈ ਸਾਂਝੀ ਭਾਸ਼ਾ ਰਹਿੰਦੀ ਹੈ—ਜਦਕਿ ਪਲੈਟਫਾਰਮ ਸਕੈਫੋਲਡਿੰਗ, ਇਟਰੇਸ਼ਨ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਤੇਜ਼ ਕਰਦਾ ਹੈ।
SQL ਨੂੰ ਕਈ ਦਹਾਕਿਆਂ ਤੋਂ ਟਿਕਣ ਦੀ ਵਜ੍ਹਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਇਸਨੇ ਦਹਾਕਿਆਂ ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਇਕੱਠੀਆਂ ਕੀਤੀਆਂ ਹਨ। ਕਈ ਆਲੋਚਨਾਵਾਂ ਸੰਕਿਰਣ ਸੰਦਰਭ ਵਿੱਚ ਵੈਧ ਹਨ, ਪਰ ਕਈ ਵਾਰੀ ਉਹਨਾਂ ਨੂੰ ਬਿਨਾਂ ਹਕੀਕਤੀ ਨੁਭੂਤਿ ਦੇ ਦੋਹਰਾਇਆ ਜਾਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਨਿਰਭਰ ਰਹਿੰਦੀਆਂ ਹਨ।
SQL ਸੌਖਾ ਲੱਗਦਾ ਹੈ ਜਦ ਤੁਸੀਂ SELECT ... FROM ... WHERE ... ਵੇਖਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਅਚਾਨਕ ਇਹ ਵੱਡਾ ਲੱਗਣ ਲੱਗਦਾ ਹੈ: ਜੋਇਨ, ਗਰੂਪਿੰਗ, ਵਿਂਡੋ ਫੰਕਸ਼ਨ, CTEs, ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ, ਅਧਿਕਾਰ, ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ ਆਦਿ। ਇਹ ਛਲਾਂ ਕਾਫ਼ੀ ਨਿਰਾਸ਼ਾਜਨਕ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਇੱਕ ਲਾਭਦਾਇਕ ਢੰਗ ਇਹ ਸੋਚਣਾ ਹੈ ਕਿ SQL ਕੇਂਦਰ 'ਤੇ ਛੋਟੀ ਅਤੇ ਕਿਨਾਰਿਆਂ 'ਤੇ ਵੱਡੀ ਹੈ। ਕੇਂਦਰੀ ਵਿਚਾਰ—ਪੰਗਤੀਆਂ ਫਿਲਟਰ ਕਰੋ, ਕਾਲਮ ਚੁਣੋ, ਟੇਬਲ ਜੋੜੋ, ਐਗਰੀਗੇਟ ਕਰੋ—ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੇ ਜਾ ਸਕਦੇ ਹਨ। ਜਟਿਲਤਾ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਵੇਲੇ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅਸਲ-ਜੰਮਾਂ ਡੇਟੇ (ਗੁੰਮ ਮੁੱਲ, ਡੁਪਲੀਕੇਟ, ਟਾਈਮਜ਼ੋਨ) ਜਾਂ ਪੱਧਰ ਤੇ ਤੇਜੀ ਲਈ ਸੰਯਮ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ।
ਕੁਝ "ਅਜੀਬਿ" SQL ਦਾ ਸੱਚ ਬਾਰੇ ਸਚ ਹੈ। ਉਦਾਹਰਨ ਲਈ, NULL "ਅਣਜਾਣ" ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ—"ਜ਼ੀਰੋ" ਜਾਂ ਖਾਲੀ ਸਤਰ ਨਹੀਂ—ਇਸ ਲਈ ਤੁਲਨਾਵਾਂ ਉਸ ਤਰ੍ਹਾਂ ਵਿਹਾਰ ਨਹੀਂ ਕਰਦੀਆਂ ਜਿਵੇਂ ਲੋਕ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਇੱਕ ਹੋਰ ਆਮ ਹੈਰਾਨੀ ਇਹ ਹੈ ਕਿ ਬਿਨਾਂ ORDER BY ਦੇ ਉਹੀ ਕੁਐਰੀ ਵੱਖ-ਵੱਖ ਕ੍ਰਮ ਵਿੱਚ ਰਿਜ਼ਲਟ ਦੇ ਸਕਦੀ ਹੈ—ਕਿਉਂਕਿ ਇੱਕ ਟੇਬਲ ਇੱਕ ਸਪ੍ਰੈੱਡਸ਼ੀਟ ਨਹੀਂ ਹੁੰਦੀ।
ਇਹ SQL ਤੋਂ ਬਚਣ ਦੇ ਕਾਰਣ ਨਹੀਂ ਹਨ; ਇਹ ਯਾਦ ਦਿਵਾਉਂਦੇ ਹਨ ਕਿ ਡੇਟਾਬੇਸ ਸਪੱਸ਼ਟਤਾ ਅਤੇ ਸਹੀਪਨ ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ ਨਾ ਕਿ ਅਨੁਮਾਨੀ ਧਾਰਣਾਵਾਂ ਤੇ।
ਇਹ ਆਲੋਚਨਾ ਦੋ ਚੀਜ਼ਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦੀ ਹੈ:
ਵੇਂਡਰ ਮੁਕਾਬਲੇ ਲਈ ਫੀਚਰ ਜੋੜਦੇ ਹਨ—ਹੋਰ ਫੰਕਸ਼ਨ, ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਤਾਰੀਖ ਹਿਲਡਿੰਗ, ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਐਕਸਟੈਂਸ਼ਨ, ਵਿਸ਼ੇਸ਼ ਇੰਡੈਕਸਿੰਗ—ਇਸ ਲਈ ਇੱਕ ਹੀ ਕੁਐਰੀ ਇਕ ਸਿਸਟਮ ਵਿੱਚ ਚੱਲਦੀ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਛੋਟੀਆਂ ਸੋਧਾਂ ਦੀ ਲੋੜ ਹੋਵੇ।
ਪਹਿਲਾਂ ਪੋਰਟੇਬਲ ਮੁੱਢਲੇ ਆਧਾਰ ਸਿੱਖੋ: SELECT, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, ਅਤੇ ਬੁਨਿਆਦੀ INSERT/UPDATE/DELETE। ਜਦ ਇਹ ਆਮ ਹੋ ਜਾਵੇ, ਤਾਂ ਉਸ ਡੇਟਾਬੇਸ ਨੂੰ ਚੁਣੋ ਜਿਸਦਾ ਤੁਸੀਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਉਪਯੋਗ ਕਰਨ ਵਾਲੇ ਹੋ ਅਤੇ ਇਸਦੇ ਖਾਸ ਫਾਇਦੇ (ਅਤੇ ਖਾਸ) ਸਿੱਖੋ।
ਆਪਣੇ ਆਪ ਤੇ ਸਿੱਖ ਰਹੇ ਹੋ ਤਾਂ ਇੱਕ ਨਿੱਜੀ ਚੀਟ-ਸ਼ੀਟ ਰੱਖਣਾ ਵੀ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ—ਜੋ ਤੁਸੀਂ ਟੁਕੜਿਆਂ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕਰਦੇ ਹੋ। ਇਹ "ਡਾਇਲੈਕਟ ਭੜਕਾਉਂ ਹਨ" ਨੂੰ "ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਦੇਖਣੀ ਹੈ" ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜੋ ਰੋਜ਼ਾਨਾ ਕੰਮ ਲਈ ਜ਼ਿਆਦਾ ਅਸਲੀ ਹੁਨਰ ਹੈ।
SQL ਸਿੱਖਣਾ ਸਿੰਟੈਕਸ ਯਾਦ ਕਰਨ ਤੋਂ ਜ਼ਿਆਦਾ ਇੱਕ ਆਦਤ ਬਣਾਉਣ بارے ਹੈ: ਇੱਕ ਸਪਸ਼ਟ ਸਵਾਲ ਪੁੱਛੋ, ਫਿਰ ਇਸਨੂੰ ਇੱਕ ਕੁਐਰੀ ਵਿੱਚ ਤਰਜਮਾ ਕਰੋ।
ਇੱਕ ਛੋਟੀ ਟੇਬਲ (ਧਿਆਨ ਵਿੱਚ: customers ਜਾਂ orders) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪਹਿਲਾਂ ਡੇਟਾ ਪੜ੍ਹਨਾ ਅਭਿਆਸ ਕਰੋ ਬਿਲਕੁਲ ਕਿ "ਕੁਝ ਕਰਨ" ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
WHERE ਅਤੇ ORDER BY ਨਾਲ ਫਿਲਟਰ ਅਤੇ ਸੋਰਟ ਕਰੋ। ਸਿਰਫ ਉਹ ਕਾਲਮ ਚੁਣੋ ਜੋ ਲੋੜੀਂਦੇ ਹਨ।orders + customers) ਨੂੰ JOIN ਨਾਲ ਜੁੜੋ।GROUP BY ਸਿੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ "ਕਿੰਨੇ?" ਅਤੇ "ਕਿੰਨਾ?" ਦੇ ਸਵਾਲ ਦੇ ਜਵਾਬ ਲੈ ਸਕੋ—ਕਾਉਂਟ, ਸਮ, ਔਸਤ ਅਤੇ ਮਹੀਨਾਵਾਰ ਟੋਟਲ।ਇਹ ਪ੍ਰਗਟੀਬੀ ਧਾਰਾ SQL ਦੀ ਡਿਜ਼ਾਈਨ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ: ਹਿੱਸਿਆਂ ਵਿੱਚ ਇੱਕ ਸਵਾਲ ਦਾ ਵਰਣਨ ਕਰੋ, ਫਿਰ ਡੇਟਾਬੇਸ ਨੂੰ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਦਿਓ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਸਾਂਝੇ ਡੇਟਾਬੇਸ 'ਤੇ ਅਭਿਆਸ ਕਰ ਰਹੇ ਹੋ—ਜਾਂ ਤੁਸੀਂ ਨਾ ਸਮਝਦਿਆਂ ਗਲਤ ਚੀਜ਼ 'ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਦੇ ਹੋ—ਤਾਂ ਕੁਝ ਨਿਯਮਾਂ ਨਾਲ ਸੁਰੱਖਿਆ ਕਰੋ:
SELECT ਨਾਲ ਹੀ ਕਰੋ। ਇਸਨੂੰ "ਰੀਡ ਮੋਡ" ਸਮਝੋ।LIMIT 50 ਵਰਗਾ ਜੋ ਤੁਹਾਨੂੰ ਅਕਸਮਾਤ ਲੱਖਾਂ ਰਿਕਾਰਡ ਨਾ ਖਿੱਚਣ ਦੇਵੇ।DELETE, UPDATE, DROP) ਜਦ ਤੱਕ ਤੁਸੀਂ WHERE ਕਲਾਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝ ਲੈਂਦੇ ਅਤੇ ਇਕ ਸੁਰੱਖਿਅਤ ਸੈਂਡਬਾਕਸ ਨਹੀਂ ਹੈ।WHERE ਕਨਡੀਸ਼ਨ SELECT ਕਰਕੇ ਚਲਾਓ ਤਾਂ ਕਿ ਵੇਖ ਸਕੋ ਕਿ ਕਿਹੜੀਆਂ ਪੰਗਤੀਆਂ ਬਦਲੇਂਗੀਆਂ।ਚੰਗਾ SQL ਅਭਿਆਸ ਅਸਲੀ ਕੰਮ ਵਾਂਗ ਦਿਖਦਾ ਹੈ:
ਇੱਕ ਸਵਾਲ ਲਓ, ਕੁਐਰੀ ਲਿਖੋ, ਫਿਰ ਦੇਖੋ ਕਿ ਨਤੀਜਾ ਆਮ-ਰੂਪ ਵਿੱਚ ਦੂਰਲਾਭੀ ਹੈ। ਇਹ ਫੀਡਬੈਕ ਲੂਪ SQL ਨੂੰ ਸੁਭਾਵਿਕ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਇੱਕ ਛੋਟਾ PostgreSQL-ਅਧਾਰਿਤ ਐਪ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਟੇਬਲਾਂ ਅਤੇ ਕੁਐਰੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਚੇਂਜਾਂ ਨੂੰ ਸਨੇਪਸ਼ੌਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਜਦ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ SQL ਲੌਜਿਕ ਤੋਂ ਨਜ਼ਰ ਘਟਾਏ।
Donald Chamberlin ਦਾ ਸਥਾਈ ਯੋਗਦਾਨ ਸਿਰਫ਼ ਇੱਕ ਸਿੰਟੈਕਸ ਬਣਾਉਣਾ ਹੀ ਨਹੀਂ ਸੀ—ਇਹ ਲੋਕਾਂ ਅਤੇ ਡੇਟਾ ਦਰਮਿਆਨ ਇੱਕ ਪੜ੍ਹਨਯੋਗ ਪُل ਬਣਾਉਣਾ ਸੀ। SQL ਕਿਸੇ ਨੂੰ ਇਹ ਵਰਣਨ ਕਰਨ ਦਿੰਦੀ ਹੈ ਕਿ ਉਹ ਕੀ ਚਾਹੁੰਦੇ ਹਨ (ਕੈਲੀਫੋਰਨੀਆ ਦੇ ਗਾਹਕ, ਮਹੀਨਾਵਾਰ ਵਿਕਰੀ, ਘੱਟ ਇਨਵੈਂਟਰੀ ਵਾਲੇ ਉਤਪਾਦ), ਬਿਨਾਂ ਇਹ ਦੱਸੇ ਕਿ ਕੰਪਿਊਟਰ ਨੂੰ ਉਹਨੂੰ ਕਿਵੇਂ ਲੱਭਣਾ ਹੈ। ਉਹ ਬਦਲਾਅ ਡੇਟਾਬੇਸ ਕੁਐਰੀ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ਜਨ ਕਲਾ ਤੋਂ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਿਸ 'ਤੇ ਟੀਮਾਂ ਚਰਚਾ, ਸਮੀਖਿਆ ਅਤੇ ਸੁਧਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।
SQL ਦੀ ਟਿਕਾਊਤਾ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਮੱਧ-ਜ਼ਮੀਨ ਤੇ ਬੈਠਦੀ ਹੈ: ਇਹ ਕੁਝ ਪਟਿੱਕੇ ਸਵਾਲਾਂ ਲਈ ਪ੍ਰਗਟਣਯੋਗ ਹੈ, ਪਰ ਇਸਦੀ ਰਚਨਾ ਇਸ ਤਰੀਕੇ ਨਾਲ ਹੈ ਕਿ ਉਹ ਆਪਟੀਮਾਈਜ਼ ਕੀਤੀ ਅਤੇ ਮਿਆਰਿਤ ਕੀਤੀ ਜਾ ਸਕੇ। ਜਿਵੇਂ ਨਵੇਂ ਡੇਟਾ ਟੂਲ ਆਉਂਦੇ ਹਨ—ਡੈਸ਼ਬੋਰਡ, “ਨੋ-ਕੋਡ” ਇੰਟਰਫੇਸ ਅਤੇ AI ਸਹਾਇਕ—SQL ਅਜੇ ਵੀ ਥੱਲੇ ਇੱਕ ਭਰੋਸੇਯੋਗ ਪੱਧਰ ਹੈ। ਬਹੁਤ ਅਧੁਨਿਕ ਪ੍ਰਣਾਲੀਆਂ ਕਲਿਕ, ਫਿਲਟਰ ਅਤੇ ਪ੍ਰਾਪਤੀਆਂ ਨੂੰ SQL-ਵਾਂਗ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਤਰਜਮਾ ਕਰਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਇਸਨੂੰ ਵੈਰੀਫਾਈ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹਨ।
ਇੰਟਰਫੇਸ ਬਦਲ ਸਕਦੇ ਹਨ, ਪਰ ਸੰਗਠਨਾਂ ਨੂੰ ਹਮੇਸ਼ਾ ਲੋੜ ਹੁੰਦੀ ਹੈ:
SQL ਇਹ ਸਭ ਗੱਲਾਂ ਪੂਰੀ ਕਰਦਾ ਹੈ। ਇਹ ਪਰਫੈਕਟ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਸਿੱਖਣਯੋਗ ਹੈ—ਅਤੇ ਇਹ ਸਿੱਖਣਯੋਗਤਾ ਕਿਰਤ ਦਾ ਇੱਕ ਅਹੰਕਾਰਿਕ ਹਿੱਸਾ ਹੈ।
Chamberlin ਦੀ ਅਸਲ ਵਿਰਾਸਤ ਇਹ ਵਿਚਾਰ ਹੈ ਕਿ ਸਭ ਤੋਂ ਵਧੀਆ ਔਜ਼ਾਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਭਾਸ਼ਾ ਪੜ੍ਹਨ ਯੋਗ ਹੁੰਦੀ ਹੈ, ਇਹ ਜਿਆਦਾ ਲੋਕਾਂ ਨੂੰ ਗੱਲਬਾਤ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਲਈ ਆਮੰਤ੍ਰਿਤ ਕਰਦੀ ਹੈ—ਅਤੇ ਇੱਥੇ ਹੀ ਤਕਨੀਕ ਲੈਬਨੋਂ ਰੋਜ਼ਾਨਾ ਕੰਮ ਤੱਕ ਫੈਲਦੀ ਹੈ।
Donald D. Chamberlin IBM ਦਾ ਇੱਕ ਰਿਸਰਚਰ ਸੀ ਜਿਸ ਨੇ System R ਪ੍ਰੋਜੈਕਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ SQL (ਮੂਲ ਰੂਪ ਵਿੱਚ SEQUEL) ਦਾ ਸਹ-ਸਿਰਜਨ ਕੀਤਾ। ਉਸਦਾ ਮੁੱਖ ਯੋਗਦਾਨ ਇਹ ਸੀ ਕਿ ਉਹ ਇੱਕ ਘੋਸ਼ਣਾਤਮਕ (declarative) ਅਤੇ ਪੜ੍ਹਨ ਯੋਗ ਭਾਸ਼ਾ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਤਾਂ ਜੋ ਲੋਕ ਡੇਟਾਬੇਸਾਂ ਨੂੰ ਨਤੀਜੇ ਮੰਗਣ ਲਈ ਪਦ-ਪਦ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਗਰਾਮ ਨਾ ਲਿਖਣ ਪੈਣ।
SQL ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਡੇਟਾ ਐਕਸੈਸ ਸਾਂਝਾ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਹੋ ਗਿਆ। ਨਵੇਂ ਰਿਪੋਰਟਾਂ ਜਾਂ ਕਸਟਮ ਪ੍ਰੋਗਰਾਮਾਂ ਦੀ ਮੰਗ ਕਰਨ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਹੁਣ ਕੁਐਰੀਆਂ ਲਿਖ ਸਕਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੌਡ ਦੀ ਤਰ੍ਹਾਂ ਮੈਨੇਜ ਕਰ ਸਕਦੀਆਂ ਹਨ—ਇਸ ਨਾਲ ਖੋਜ ਤੇਜ਼ ਹੋਈ ਅਤੇ ਬੋਤਲਨੇਕ ਘੱਟ ਹੋਏ।
ਇੱਕ ਘੋਸ਼ਣਾਤਮਕ (declarative) ਭਾਸ਼ਾ ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਨੂੰ ਕੀ ਨਤੀਜਾ ਚਾਹੀਦਾ ਹੈ ਦੱਸਦੇ ਹੋ, ਨਾ ਕਿ ਉਹ ਨਤੀਜਾ ਕਿਵੇਂ ਲੱਭਣਾ ਹੈ। ਅਮਲ ਵਿੱਚ, ਤੁਸੀਂ ਕਾਲਮ, ਟੇਬਲ, ਫਿਲਟਰ ਅਤੇ ਸਮੂਹ (grouping) ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਅਤੇ ਡੇਟਾਬੇਸ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ালী ਐਕਸਿਕਿਊਸ਼ਨ ਪਲਾਨ ਚੁਣ ਲੈਂਦਾ ਹੈ (ਅਕਸਰ ਕੁਐਰੀ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਰਾਹੀਂ)।
ਮੁੱਢਲੀ ਸੋਚ ਇਹ ਹੈ:
SELECT: ਤੁਸੀਂ ਜੋ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ (ਕਾਲਮ ਜਾਂ ਐਕਸਪਰੇਸ਼ਨ)FROM: ਇਹ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ (ਟੇਬਲ/ਵਿਊ)WHERE: ਕਿਹੜੀਆਂ ਪੰਗਤੀਆਂ ਯੋਗ ਹਨ (ਫਿਲਟਰ)ਇਸ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਨਾਲ ਟੇਬਲ ਜੋੜ ਸਕਦੇ ਹੋ, ਨਾਲ ਸਾਰਾਂਸ਼ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਨਾਲ ਸੋਰਟ ਕਰ ਸਕਦੇ ਹੋ।
JOIN ਦੋ ਜਾਂ ਹੋਰ ਟੇਬਲਾਂ ਤੋਂ ਪੰਗਤੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਇਕ ਮਿਲਦੀ-ਜੁਲਦੀ ਸ਼ਰਤ ਦੇ ਆਧਾਰ 'ਤੇ—ਅਕਸਰ ਇੱਕ ਸਾਂਝਾ ਪਹਿਚਾਣਕਰਨ ਜਿਸ ਤਰ੍ਹਾਂ customer_id। ਜਦੋਂ ਤੁਹਾਨੂੰ ਜਾਣਕਾਰੀ ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ ਵਿੱਚ ਵੰਡੇ ਹੋਏ ਮਿਲਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ orders ਵਿੱਚ ਆਰਡਰ ਅਤੇ customers ਵਿੱਚ ਗਾਹਕਾਂ ਦੇ ਨਾਮ), ਤਦੋਂ JOIN ਵਰਤੋ।
GROUP BY ਤੁਹਾਨੂੰ "ਹਰ ਵਰਗ ਲਈ" ਨਤੀਜੇ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ (ਜਿਵੇਂ ਹਰ ਗਾਹਕ ਲਈ ਕੁੱਲ, ਹਰ ਮਹੀਨੇ ਲਈ ਗਿਣਤੀ, ਹਰ ਉਤਪਾਦ ਲਈ ਆਮਦਨੀ)। ਇਕ ਕਾਰਗਰ ਵਰਕਫਲੋ ਇਹ ਹੈ:
SELECT ... FROM ... WHERE ... ਲਿਖੋ ਜੋ ਸਹੀ ਪੰਗਤੀਆਂ ਦਿਖਾਵੇ।System R IBM ਦਾ 1970s ਦਾ ਰਿਸਰਚ ਪ੍ਰੋਟੋਟਾਇਪ ਸੀ ਜਿਸਦਾ ਮਕਸਦ ਇਹ ਸਾਬਤ ਕਰਨਾ ਸੀ ਕਿ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਰੀਅਲ-ਵਰਲਡ ਡੇਟਾ ਤੇ ਕਿੱਦੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਨੇ ਜ਼ਰੂਰੀ ਵਿਚਾਰਾਂ ਨੂੰ ਭੁਨਿਆ—ਖਾਸ ਕਰਕੇ ਕੁਐਰੀ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ—ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਂਦੇ ਹਨ ਕਿ ਉੱਚ-ਸਤ੍ਹਰ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸਿਸਟਮ ਕੁਸ਼ਲ ਢੰਗ ਨਾਲ ਅਮਲ ਕਰ ਸਕੇ।
SQL ਇਕ IBM ਰਿਸਰਚ ਭਾਸ਼ਾ ਹੀ ਨਹੀਂ ਰਹਿ ਗਈ ਕਿਉਂਕਿ ਇਸਦਾ ਨਿਆਰੁ ਸੁਲੂਕ ਅਤੇ ਵਿਸਥਾਰਕ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਸਿਸਟਮਾਂ ਅਤੇ ਟੂਲਾਂ ਵਿੱਚ ਆ ਗਿਆ। ਇਹ ਇੱਕ ਧੱਕਾ ਬਣ ਗਿਆ:
ਇਸ ਤਰ੍ਹਾਂ ਕੋਰ ਧਾਰਨਾਵਾਂ ਪਹਚਾਣਯੋਗ ਰਹੀਅਾਂ ਤੇ ਵਿਕਾਸ ਤੇ ਅਮਲ ਤੇਜ਼ ਹੋਇਆ।
SQL ਡਾਇਲੈਕਟ ਵਾਕਈ ਮੌਜੂਦ ਹਨ, ਪਰ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰਸਤਾ ਇਹ ਹੈ:
SELECT, WHERE, JOIN, , ਅਤੇ ਮੁੱਢਲੀ ।ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਕਦਮ-ਦਰ-ਕਦਮ ਅਭਿਆਸ ਬਣਾਓ:
SELECT ਨਾਲ ਅਭਿਆਸ ਕਰੋ (ਇਸਨੂੰ "ਰੀਡ ਮੋਡ" ਮੰਨੋ)।JOINGROUP BYORDER BYCOUNT()SUM()AVG()GROUP BY ਵਿੱਚ ਪਾਓ।GROUP BYORDER BYINSERT/UPDATE/DELETEਇਸ ਨਾਲ ਡਾਇਲੈਕਟਾਂ ਦੀ ਨਿਰੰਤਰਤਾ ਨੂੰ ਯਥਾਰਥਪੂਰਕ ਤੌਰ 'ਤੇ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
LIMIT 50 ਵਰਗਾ ਵਰਤੋ ਤਾਂ ਕਿ ਅਕਸਮਾਤ ਬਹੁਤ ਸਾਰੇ ਰਿਕਾਰਡ ਨਾ ਖਿੱਚ ਲਏ।UPDATE/DELETE ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹੀ WHERE ਕਨਡિશਨ SELECT ਵਜੋਂ ਚਲਾਕੇ ਦਿੱਖੋ ਕਿ ਕਿਹੜੀਆਂ ਪੰਗਤੀਆਂ ਪ੍ਰਭਾਵਤ ਹੋਣਗੀਆਂ।ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਸਪਸ਼ਟ ਸਵਾਲ ਨੂੰ ਇੱਕ ਕੁਐਰੀ ਵਿੱਚ ਬਦਲਣਾ, ਨਾ ਕਿ ਸਿਰਫ਼ ਸਿੰਟੈਕਸ ਯਾਦ ਕਰਨਾ।