30 ਅਗ 2025·8 ਮਿੰਟ
Edgar F. Codd ਦਾ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ: ਕਿਉਂ SQL ਨੇ ਕਾਰੋਬਾਰ ਜਿੱਤਿਆ?
ਜਾਣੋ ਕਿ Edgar F. Codd ਦਾ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਕਿਵੇਂ ਡੇਟਾ ਨੂੰ ਟੇਬਲਾਂ, ਕੀਜ਼ ਅਤੇ ਨਿਯਮਾਂ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ—ਜਿਸ ਨਾਲ SQL ਡੇਟਾਬੇਸਾਂ ਲਈ ਰਸਤਾ ਬਣਿਆ ਜੋ ਕਾਰੋਬਾਰੀ ਐਪਾਂ ਚਲਾਉਂਦੇ ਹਨ।
ਜਾਣੋ ਕਿ Edgar F. Codd ਦਾ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਕਿਵੇਂ ਡੇਟਾ ਨੂੰ ਟੇਬਲਾਂ, ਕੀਜ਼ ਅਤੇ ਨਿਯਮਾਂ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ—ਜਿਸ ਨਾਲ SQL ਡੇਟਾਬੇਸਾਂ ਲਈ ਰਸਤਾ ਬਣਿਆ ਜੋ ਕਾਰੋਬਾਰੀ ਐਪਾਂ ਚਲਾਉਂਦੇ ਹਨ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਜਾਣਕਾਰੀ ਨੂੰ ਇੱਕ ਟੇਬਲਾਂ ਦੇ ਸੈਟ (ਜਿਨ੍ਹਾਂ ਨੂੰ Codd ਨੇ “relations” ਕਿਹਾ) ਦੇ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ ਜੋ ਸਾਂਝੀਆਂ ਵੈਲਿਊਜ਼ ਰਾਹੀਂ ਜੁੜੇ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ ਟੇਬਲ ਇੱਕ ਸਾਫ਼ ਗ੍ਰਿਡ ਹੁੰਦੀ ਹੈ:
ਕਾਰੋਬਾਰ ਡੇਟਾ ਨੂੰ ਅਲੱਗ ਤੌਰ 'ਤੇ ਨਹੀਂ ਰੱਖਦੇ। ਇੱਕ ਵਿਕਰੀ ਵਿੱਚ ਗਾਹਕ, ਉਤਪਾਦ, ਕੀਮਤ, ਸੇਲਜ਼ਪერსਨ ਅਤੇ ਤਾਰੀਖ ਸ਼ਾਮਿਲ ਹੁੰਦੇ ਹਨ—ਹਰ ਇੱਕ ਦੀ ਅਪਡੇਟਿੰਗ ਦੀ ਰਫਤਾਰ ਵੱਖ-ਵੱਖ ਅਤੇ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਦੇ ਹਵਾਲੇ ਹੁੰਦੀ ਹੈ। ਪਹਿਲੇ ਸਿਸਟਮ ਅਕਸਰ ਇਹ ਵੇਰਵੇ ਕਠੋਰ, ਘੁੰਮੜੇ ਅਤੇ ਬਦਲਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਸਟਰੱਕਚਰਾਂ ਵਿੱਚ ਰੱਖਦੇ ਸਨ। ਇਸ ਨਾਲ ਰਿਪੋਰਟਿੰਗ ਧੀਮੀ ਹੁੰਦੀ, ਬਦਲਾਅ ਖਤਰਨਾਕ ਬਣ ਜਾਂਦੇ, ਅਤੇ “ਸਧਾਰਨ ਪ੍ਰਸ਼ਨ” ਅਚਾਨਕ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ।
ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਨੇ ਇੱਕ ਸਪਸ਼ਟ ਰਸਤਾ ਦਿਖਾਇਆ: ਵੱਖ-ਵੱਖਧਾਰਨਾਵਾਂ ਲਈ ਵੱਖ ਟੇਬਲ ਰੱਖੋ, ਫਿਰ ਜਦ ਤੁਹਾਨੂੰ ਜਵਾਬ ਲੋੜੇ ਹੋਣ ਉਸ ਵੇਲੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜੋ। ਹਰ ਚਲਾਨ 'ਤੇ ਗਾਹਕ ਦੇ ਵੇਰਵੇ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਗਾਹਕਾਂ ਨੂੰ ਇੱਕ ਵਾਰੀ ਸਟੋਰ ਕਰਦੇ ਹੋ ਅਤੇ ਚਲਾਨਾਂ ਤੋਂ ਉਹਨਾਂ ਨੂੰ ਸੰਦਰਭ ਕਰਦੇ ਹੋ। ਇਸ ਨਾਲ ਟਕਰਾਉਂਘਟ (ਅਤੇ ਇੱਕੋ ਗਾਹਕ ਦੇ ਦੋ ਵੱਖ-ਵੱਖ ਸਪੈਲਿੰਗ) ਘੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਅਪਡੇਟਾਂ ਹੋਰ ਭਵਿੱਖਬਾਣੀਯੋਗ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਚੰਗੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਟੇਬਲਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜਨ ਦੇ ਨਿਯਮਾਂ ਨੂੰ ਉਭਾਰ ਕੇ, ਮਾਡਲ ਇੱਕ ਨਵੀਂ ਉਮੀਦ ਰੱਖਦਾ ਹੈ: ਜਿਵੇਂ-ਜਿਵੇਂ ਡੇਟਾਬੇਸ ਵਧਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦ ਬਹੁਤ ਲੋਕ ਅਤੇ ਸਿਸਟਮ ਲਿਖਦੇ ਹਨ, ਡੇਟਾਬੇਸ ਅਸੰਗਤਤਾ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰੇ।
Codd ਦਾ ਮਾਡਲ ਖੁਦ ਕੋਈ ਕੁਇਰੀ ਭਾਸ਼ਾ ਨਹੀਂ ਸੀ, ਪਰ ਇਸਨੇ ਇੱਕ ਨੂੰ ਪ੍ਰੇਰਿਤ ਕੀਤਾ। ਜੇ ਡੇਟਾ ਸਬੰਧਿਤ ਟੇਬਲਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਮਿਆਰੀ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ:
ਇਸ ਰਸਤੇ ਨੇ SQL ਨੂੰ ਜਨਮ ਦਿੱਤਾ, ਜਿਸ ਨੇ ਮਾਡਲ ਨੂੰ ਦૈਨੰਦਿਨ ਟੀਮਾਂ ਲਈ ਕਾਰੋਬਾਰਿਕ ਡੇਟਾ 'ਤੇ ਸਵਾਲ ਪੁੱਛਣ ਦਾ ਇੱਕ ਅਮਲੀ ਤਰੀਕਾ ਬਣਾ ਦਿੱਤਾ—ਜਿੱਥੇ ਨਤੀਜੇ ਦੁਹਰਾਏ ਅਤੇ ਆਡਿਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਗਠਨਾਵਾਂ ਮਹੱਤਵਪੂਰਨ ਜਾਣਕਾਰੀ ਨੂੰ ਫਾਈਲਾਂ ਵਿੱਚ ਰੱਖਦੀਆਂ ਸਨ—ਅਕਸਰ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇੱਕ ਫਾਈਲ। ਪੇਰੋਲ ਦੇ ਆਪਣੇ ਰਿਕਾਰਡ, ਇਨਵੈਂਟਰੀ ਦੇ ਹੋਰ, ਅਤੇ ਗਾਹਕ ਸੇਵਾ ਦੇ ਆਪਣੇ “ਗਾਹਕ” ਦੇ ਵੱਖ-ਵੱਖ ਵਰਜਨ। ਹਰ ਸਿਸਟਮ ਅਲੱਗ ਕੰਮ ਕਰਦਾ ਸੀ, ਅਤੇ ਇਹ ਅਲਗਾਵ ਹਮੇਸ਼ਾ ਦਰਦ ਲਿਆਉਂਦਾ।
ਸ਼ੁਰੂਆਤੀ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਕਸਟਮ ਫਾਈਲ ਫਾਰਮੈਟ ਅਤੇ ਇੱਕ ਹੀ ਮਕਸਦ ਲਈ ਲਿਖੇ ਪ੍ਰੋਗਰਾਮਾਂ 'ਤੇ ਆਧਾਰਿਤ ਸੀ। ਡੇਟਾ ਦੀ ਬਣਤਰ (ਕੋਣ-ਕਿਹੜਾ ਫ਼ੀਲਡ ਕਿੱਥੇ ਹੈ, ਕਤਾਰਾਂ ਕਿਵੇਂ ਆਰਡਰ ਹੋਈਆਂ) ਉਸ ਕੋਡ ਨਾਲ ਬਹੁਤ ਜੁੜੀ ਹੋਈ ਸੀ ਜੋ ਉਸ ਨੂੰ ਪੜ੍ਹਦਾ ਸੀ। ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਇੱਕ ਨਵਾਂ ਫੀਲਡ ਜੋੜਨਾ, ਕਿਸੇ ਸ਼੍ਰੇਣੀ ਦਾ ਨਾਮ ਬਦਲਣਾ ਜਾਂ ਪਤਾ ਫਾਰਮੈਟ ਬਦਲਣਾ ਕਈ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪੈ ਸਕਦਾ ਸੀ।
ਕਿਉਂਕਿ ਟੀਮਾਂ ਇੱਕ ਇਕੱਲੇ ਸੱਚ ਦੇ ਸਾਂਝੇ ਸਰੋਤ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸ਼ੇਅਰ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ, ਉਹ ਡੇਟਾ ਨਕਲ ਕਰ ਲੈਂਦੀਆਂ। ਗਾਹਕ ਦੇ ਪਤੇ ਸੇਲਜ਼ ਫਾਈਲਾਂ, ਸ਼ਿਪਿੰਗ ਫਾਈਲਾਂ ਅਤੇ ਬਿਲਿੰਗ ਫਾਈਲਾਂ ਵਿੱਚ ਹੋ ਸਕਦੇ ਸਨ।
ਜਦ ਪਤਾ ਬਦਲਦਾ, ਹਰ ਨਕਲ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਪੈਂਦਾ ਸੀ। ਜੇ ਇੱਕ ਸਿਸਟਮ ਛੁੱਟ ਜਾਂਦਾ, ਤਾਂ ਅਸੰਗਤਤਾਵਾਂ ਆਉਂਦੀਆਂ: ਚਲਾਨ ਗਲਤ ਠਿਕਾਣੇ 'ਤੇ ਜਾਂਦੇ, ਸ਼ਿਪਮੈਂਟ ਲੇਟ ਹੋ ਜਾਂਦੇ, ਅਤੇ ਸਹਾਇਤਾ ਏਜੰਟ ਹਰ ਸਕ੍ਰੀਨ 'ਤੇ ਵੱਖ-ਵੱਖ “ਤੱਥ” ਵੇਖਦੇ। ਡੇਟਾ ਕਲੀਨਅਪ ਮੁਲਤਬ ਇੱਕ-ਵਾਰੀ ਫਿਕਸ ਨਹੀਂ ਰਹਿ ਕੇ ਦੁਹਰਾਈ ਪ੍ਰੋਜੈਕਟਾਂ ਬਣ ਗਏ।
ਕਾਰੋਬਾਰੀ ਯੂਜ਼ਰ ਫਿਰ ਵੀ ਪੁੱਛਦੇ ਰਹਿੰਦੇ ਸਨ—“ਕਿਹੜੇ ਗਾਹਕ ਨੇ ਉਤਪਾਦ X ਖ਼ਰੀਦਿਆ ਅਤੇ ਬਾਦ ਵਿੱਚ ਵਾਪਸ ਕੀਤਾ?”—ਪਰ ਇਹਨਾਂ ਦੇ ਜਵਾਬ ਲਈ ਅਕਸਰ ਉਹ ਫਾਈਲਾਂ ਜੋੜਣੀਆਂ ਪੈਂਦੀਆਂ ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਲਈ ਬਣੀਆਂ ਨਹੀਂ ਸਨ। ਟੀਮਾਂ ਅੰਕ-ਇਕਸਟਰੈਕਟ ਬਣਾਉਂਦੀਆਂ ਜੋ ਹੋਰ ਨਕਲ ਬਣਾਉਂਦੇ ਅਤੇ ਮਿਲਾਪ ਦੇ ਹੋਰ ਮੌਕੇ ਬਣਾਉਂਦੇ।
ਨਤੀਜਾ: ਰਿਪੋਰਟਿੰਗ ਚੱਕਰ ਧੀਮੇ ਹੋ ਗਏ, ਅਤੇ “ਤੇਜ਼ ਸਵਾਲ” ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਬਣ ਗਏ।
ਸੰਗਠਨਾਂ ਨੂੰ ਸਾਂਝੀ ਡੇਟਾ ਦੀ ਲੋੜ ਸੀ ਜਿਸ ਤੇ ਕਈ ਐਪਲੀਕੇਸ਼ਨ ਭਰੋਸਾ ਕਰ ਸਕਣ, ਘੱਟ ਅਸੰਗਤਤਾ ਅਤੇ ਘੱਟ ਨਕਲ ਨਾਲ। ਉਹਨਾਂ ਨੂੰ ਇਹ ਵੀ ਚਾਹੀਦਾ ਸੀ ਕਿ ਨਵੀਂ ਪ੍ਰਸ਼ਨ ਪੁੱਛਣ ਲਈ ਹਰੇਕ ਵਾਰੀ ਮੂਲ ਸਟੋਰੇਜ ਨੂੰ ਦੁਬਾਰਾ ਨਾ ਬਣਾਉਣਾ ਪਏ। ਇਹ ਖਾਲੀ ਇਹੋ ਜਗ੍ਹਾ ਸੀ ਜਿਸ ਨੇ Codd ਦੇ ਮੁੱਖ ਵਿਚਾਰ ਦੀ ਰਹਿਤ ਰਚੀ: ਡੇਟਾ ਨੂੰ ਇੱਕ ਸਥਿਰ, ਐਪ-ਅਜ਼-ਇੰਡਿਪੈਂਡੈਂਟ ਤਰੀਕੇ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਤਾਂ ਜੋ ਸਿਸਟਮ ਬਿਨਾਂ "ਸੱਚ" ਨੂੰ ਟੁਟਣ ਦੇ ਵਿਕਸਿਤ ਹੋ ਸਕਣ।
Edgar F. Codd ਇੱਕ ਬ੍ਰਿਟਿਸ਼ ਕੰਪਿਊਟਰ ਸਾਇੰਟਿਸਟ ਸੀ ਜੋ ਆਪਣਾ ਅਧਿਕਾਰਿਕ ਕੈਰੀਅਰ IBM ਵਿੱਚ ਬਿਤਾਇਆ, ਅਤੇ ਇਸ ਬਾਰੇ ਕੰਮ ਕੀਤਾ ਕਿ ਸੰਗਠਨ ਜਾਣਕਾਰੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਸ਼ালী ਤਰੀਕੇ ਨਾਲ ਸਟੋਰ ਅਤੇ ਰੀਟਰੀਵ ਕਰ ਸਕਦੇ ਹਨ। 1960ਜ਼ ਵਿੱਚ, ਜ਼ਿਆਦਾਤਰ “ਡੇਟਾਬੇਸ” ਸਿਸਟਮ ਉਸੇ ਤਰ੍ਹਾਂ ਹੋਰਾਂ ਦੀ ਬਜਾਏ ਧੁਆਪ ਵਾਲੇ ਫਾਈਲ ਕੈਬਿਨੇਟ ਵਰਗੇ ਹੀ ਸਨ: ਡੇਟਾ ਠੋਸ, ਪਹਿਲਾਂ-ਨਿਰਧਾਰਿਤ ਸਟਰੱਕਚਰਾਂ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਉਹਨਾਂ ਸਟਰੱਕਚਰਾਂ ਨੂੰ ਬਦਲਣ ਦਾ ਮਤਲਬ ਅਕਸਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਹੁੰਦਾ ਸੀ। ਇਹ ਭਾਗਦੋੜ ਟੀਮਾਂ ਨੂੰ ਨਿਰਾਸ਼ ਕਰਦੀ ਜਦ ਕਾਰੋਬਾਰ ਵਧਦੇ ਤੇ ਮੰਗਾਂ ਬਦਲਦੀਆਂ।
1970 ਵਿੱਚ, Codd ਨੇ ਇੱਕ ਪੇਪਰ ਪ੍ਰਕਾਸ਼ਤ ਕੀਤਾ—"A Relational Model of Data for Large Shared Data Banks"—ਜਿਸਨੇ ਇੱਕ ਆਸ਼ਚਰਜਪੂਰਕ ਸਾਦਾ ਵਿਚਾਰ ਸੁਝਾਇਆ: ਡੇਟਾ ਨੂੰ ਸਬੰਧਿਤ ਟੇਬਲਾਂ ਵਜੋਂ ਦਰਸਾਓ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੁਇਰੀ ਕਰਨ ਅਤੇ ਜੋੜਨ ਲਈ ਪਰਿਭਾਸ਼ਿਤ ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਇੱਕ formal ਸੈਟ ਵਰਤੋ।
ਉਪਰਲੀ ਪੱਧਰ 'ਤੇ ਇਹ ਪੇਪਰ ਇਹ ਦਲੀਲ ਦਿੰਦਾ ਸੀ ਕਿ:
Codd ਨੇ ਆਪਣੀ ਸੁਝਾਵ ਨੂੰ ਗਣਿਤ (ਸੈੱਟ ਥਿਊਰੀ ਅਤੇ ਲਾਜਿਕ) ਨਾਲ ਜ਼ਮੀਨ ਦਿੱਤੀ। ਇਹ ਕੋਈ ਅਕਾਦਮਿਕ ਦਿਖਾਵਾ ਨਹੀਂ ਸੀ—ਇਹ ਡੈਟਾਬੇਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ, ਟੈਸਟ ਕਰਨ ਯੋਗ ਆਧਾਰ ਦਿੰਦੀ ਸੀ। ਇੱਕ formal ਮਾਡਲ ਨਾਲ, ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ ਕਿ ਕੋਈ ਕੁਇਰੀ ਸਹੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਕਿ ਦੋ ਕੁਇਰੀਆਂ ਬਰਾਬਰ ਹਨ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਨਤੀਜੇ ਬਦਲੇ ਬਿਨਾਂ ਕਾਰਜਨਿਵੇਸ਼ (optimization) ਕਿਵੇਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਲਈ, ਇਹ ਦਾ ਅਰਥ ਹੈ ਕਿ ਜਿਵੇਂ-ਜਿਵੇਂ ਸਿਸਟਮ ਵੱਧਦੇ ਹਨ, ਘੱਟ ਅਚਰਜ ਰਹਿੰਦੇ ਹਨ।
ਉਸ ਸਮੇਂ, ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ ਹਾਇਰਾਰਕੀਕਲ ਜਾਂ ਨੈੱਟਵਰਕ ਮਾਡਲਾਂ 'ਤੇ ਆਧਾਰਿਤ ਸਨ ਜਿੱਥੇ ਡੇਵਲਪਰ ਡੇਟਾ ਨੂੰ ਪਹਿਲਾਂ-ਨਿਰਧਾਰਿਤ ਰਾਹਾਂ ਤੇ "ਨੈਵੀਗੇਟ" ਕਰਦੇ ਸਨ। Codd ਦਾ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਇਨ੍ਹਾਂ ਮਨੋਭਾਵਾਂ ਨੂੰ ਚੁਣੌਤੀ ਦਿੰਦਾ ਸੀ ਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਭਾਰੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਟੋਰੇਜ ਲੇਆਉਟ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ; ਉਹਨਾਂ ਨੂੰ ਚਾਹੀਦਾ ਨਤੀਜਾ ਵੇਰਵਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ালী ਤਰੀਕੇ ਨਾਲ ਉਹ ਨਤੀਜਾ ਤਿਆਰ ਕਰਨ ਦੀ ਜਿੰਮੇਵਾਰੀ ਲੈਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇਹ concerns ਵੱਖ-ਅਲੱਗ ਕਰਨ ਵਾਲਾ ਦ੍ਰਿਸ਼ਟਿਕੋਣ SQL ਅਤੇ ਉਹ ਡੇਟਾਬੇਸ ਬਣਾਉਣ ਲਈ ਮੰਚ ਤਿਆਰ ਕਰਨ ਦਾ ਆਧਾਰ ਬਣਿਆ ਜੋ ਬਦਲਦੀਆਂ ਉਤਪਾਦ ਮੰਗਾਂ ਦੇ ਸਾਲਾਂ ਬਾਅਦ ਵੀ ਬਚ ਸਕਦੀਆਂ ਹਨ।
Codd ਦਾ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਤੱਥਾਂ ਨੂੰ relations ਵਿੱਚ ਸਟੋਰ ਕਰੋ—ਜਿਹਨਾਂ ਨੂੰ ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਟੇਬਲਾਂ ਵਜੋਂ ਜਾਣਦੇ ਹਨ—ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਤ ਤਰੀਕੇ ਨਾਲ ਡੇਟਾ ਦਰਸਾਉਣ ਦੇ ਤਰੀਕੇ ਵਜੋਂ ਵਰਤੋ, ਨਾ ਕਿ "ਸਮਰੱਥ spreadsheet" ਵਜੋਂ। ਇੱਕ relation ਉਹਨਾਂ ਗੱਲਾਂ ਦੀ ਇੱਕ ਸੈੱਟ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਗਾਹਕ, ਆਰਡਰ, ਭੁਗਤਾਨ, ਉਤਪਾਦ, ਸ਼ਿਪਮੈਂਟ।
ਇੱਕ relation ਇੱਕ ਕਿਸਮ ਦੇ ਤੱਥ ਪੈਟਰਨ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ Orders relation ਇਹ ਕੈਪਚਰ ਕਰ ਸਕਦੀ ਹੈ: “ਇੱਕ order ਦੀ ID, ਤਾਰੀਖ, ਗਾਹਕ ਤੇ ਕੁੱਲ ਹੈ।” ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰ relation ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਅਰਥ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਕਾਲਮ ਉਸ ਅਰਥ ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਕਤਾਰ (Codd ਨੇ ਇਸਨੂੰ ਟਿਊਪਲ ਕਿਹਾ) ਉਸ ਤੱਥ ਦਾ ਇੱਕ ਖਾਸ ਉਦਾਹਰਨ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਨਿਰਧਾਰਤ ਆਰਡਰ। ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਵਿੱਚ, ਕਤਾਰਾਂ ਦੀ ਕੋਈ ਅੰਦਰੂਨੀ “ਪੋਜ਼ੀਸ਼ਨ” ਨਹੀਂ ਹੁੰਦੀ। ਕਤਾਰ 5 ਖਾਸ ਨਹੀਂ—ਜ਼ਰੂਰੀ ਗੱਲ ਵੈਲਿਊਜ਼ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਾਲੇ ਨਿਯਮ ਹਨ।
ਇੱਕ ਕਾਲਮ (ਇੱਕ ਐਟਰਿਬਿਊਟ) relation ਵਿੱਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਗੁਣ ਹੈ: OrderDate, CustomerID, TotalAmount। ਕਾਲਮ ਸਿਰਫ ਲੇਬਲ ਨਹੀਂ; ਉਹ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਕਿਸ ਕਿਸਮ ਦੀ ਵੈਲਿਊ ਦੀ ਆਗਿਆ ਹੈ।
ਇੱਕ ਡੋਮੇਨ ਇੱਕ Attribute ਲਈ ਆਗਿਆ ਪ੍ਰਾਪਤ ਵੈਲਿਊਜ਼ ਦਾ ਸੈੱਟ ਹੁੰਦਾ ਹੈ—ਜਿਵੇਂ OrderDate ਲਈ ਤਾਰੀਖਾਂ, TotalAmount ਲਈ ਸਕਾਰਾਤਮਕ ਨੰਬਰ, ਜਾਂ Status ਲਈ ਨਿਯੰਤਰਤ ਕੋਡ ਲਿਸਟ (ਉਦਾਹਰਨ: Pending, Paid, Refunded)। ਡੋਮੇਨ ਅਸਪਸ਼ਟਤਾ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਸੁਟਲੀ ਗਲਤੀਆਂ ਰੋਕਦੇ ਹਨ ਜਿਵੇਂ ਵੱਖ-ਵੱਖ ਤਾਰੀਖ ਫਾਰਮੈਟਾਂ ਦਾ ਮਿਕਸ ਹੋਣਾ ਜਾਂ ਗਿਣਤੀ ਵਾਲੇ ਫੀਲਡ ਵਿੱਚ “N/A” ਰੱਖਣਾ।
“ਰਿਲੇਸ਼ਨਲ” ਇਸ ਗੱਲ ਨੂੰ ਦਰਸਾਂਦਾ ਹੈ ਕਿ ਤੱਥ ਕਿਵੇਂ relations ਪਾਰ ਕਰਕੇ ਜੁੜੇ ਹੋ ਸਕਦੇ ਹਨ (ਜਿਵੇਂ ਗਾਹਕਾਂ ਨੂੰ ਆਰਡਰਾਂ ਨਾਲ ਜੋੜਨਾ), ਜਿਸ ਨਾਲ ਆਮ ਕਾਰੋਬਾਰੀ ਕਾਰਜ—ਬਿਲਿੰਗ, ਰਿਪੋਰਟਿੰਗ, ਆਡਿਟਿੰਗ, ਗਾਹਕ ਸਹਾਇਤਾ—ਟੇਬਲਾਂ ਨੂੰ ਹਰ ਜਗ੍ਹਾ ਨਕਲ ਕੀਤੇ ਬਿਨਾਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਟੇਬਲ ਆਪਣਾ ਕੰਮ ਆਪਣੇ ਆਪ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਕਾਰੋਬਾਰੀ ਡੇਟਾ ਤਬ ਹੀ ਅਰਥਪੂਰਨ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਤੱਥਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਜੋੜ ਸਕੋ: ਕਿਹੜਾ ਗਾਹਕ ਕਿਸ ਆਰਡਰ ਨੂੰ ਕੀਤਾ, ਕਿਸ ਆਈਟਮਾਂ ਆਰਡਰ ਵਿੱਚ ਸਨ, ਅਤੇ ਕਿੰਨੀ ਰਕਮ ਚਾਰਜ ਕੀਤੀ ਗਈ। ਕੀਜ਼ ਉਹੀ ਮੈਕੈਨੀਜ਼ਮ ਹਨ ਜੋ ਇਹ ਸੰਬੰਧ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਕੀ ਇੱਕ ਕਾਲਮ (ਜਾਂ ਕਾਲਮਾਂ ਦਾ ਸੈੱਟ) ਹੈ ਜਿਸਦੀ ਵੈਲਿਊ ਹਰ ਕਤਾਰ ਨੂੰ ਵਿਲੱਖਣ ਤੌਰ 'ਤੇ ਪਛਾਣਦੀ ਹੈ। ਇਸੇ ਨੂੰ ਰੋ ਦੀ “ਨਾਮ ਟੈਗ” ਸਮਝੋ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਸਥਿਰਤਾ ਹੈ: ਨਾਮ, ਈਮੇਲ ਅਤੇ ਪਤੇ ਬਦਲ ਸਕਦੇ ਹਨ, ਪਰ ਅੰਦਰੂਨੀ ID ਨਹੀਂ।
ਚੰਗੀ ਪ੍ਰਾਇਮਰੀ ਕੀ ਡੁਪਲਿਕੇਟ ਜਾਂ ਅਸਪਸ਼ਟ ਰਿਕਾਰਡ ਰੋਕਦੀ ਹੈ। ਜੇ ਦੋ ਗਾਹਕਾਂ ਦਾ ਇਕੋ ਹੀ ਨਾਮ ਹੋਵੇ, ਪ੍ਰਾਇਮਰੀ ਕੀ ਹਰ ਇੱਕ ਨੂੰ ਵੱਖ-ਵੱਖ ਪਛਾਣੇਗੀ।
ਇੱਕ ਫੌਰਨ ਕੀ ਉਹ ਕਾਲਮ ਹੁੰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਟੇਬਲ ਦੀ ਪ੍ਰਾਇਮਰੀ ਕੀ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਇਹ ਰਿਸ਼ਤਿਆਂ ਨੂੰ ਪੂਰਾ ਕੀਤੇ ਬਿਨਾਂ ਸਾਰੇ ਡੇਟਾ ਦੀ ਨਕਲ ਕੀਤੇ ਬਿਨਾਂ ਦਰਸਾਉਂਦਾ ਹੈ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਤੁਸੀਂ ਵਿਕਰੀ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਮਾਡਲ ਕਰ ਸਕਦੇ ਹੋ:
ਫੌਰਨ ਕੀ constraints ਗਾਰਡਰੇਲ ਵਾਂਗ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਰੋਕਦੇ ਹਨ:
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਕੀਜ਼ ਅਤੇ constraints ਟੀਮਾਂ ਨੂੰ ਰਿਪੋਰਟਾਂ ਅਤੇ ਵਰਕਫਲੋਜ਼ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਜਦ ਡੇਟਾਬੇਸ ਰਿਸ਼ਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਬਿਲਿੰਗ, ਫ਼ੁਲਫ਼ਿਲਮੈਂਟ ਅਤੇ ਗਾਹਕ ਸਹਾਇਤਾ ਵਿਚ ਘੱਟ ਬੱਗ ਆਉਂਦੇ ਹਨ—ਕਿਉਂਕਿ ਡੇਟਾ ਚੁੱਪ ਚਾਪ ਅਸੰਭਵ ਹਾਲਤਾਂ ਵੱਲ ਨਹੀਂ ਭਟਕਦਾ।
ਨਾਰਮਲਾਈਜੇਸ਼ਨ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਦਾ ਤਰੀਕਾ ਹੈ ਕਿ ਜਿਵੇਂ-ਜਿਵੇਂ ਡੇਟਾ ਵਧਦਾ ਹੈ, ਉਹ ਅਸਪੱਸ਼ਟਤਾਵਾਂ ਵੱਲ ਨਾ ਘੁਮੇ। ਜਦ ਇੱਕੋ ਤੱਥ ਕਈ ਜਗ੍ਹਾਂ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਕੌਪੀ ਦਾ ਅਪਡੇਟ ਹੋ ਕੇ ਦੂਜੀ ਵਿੱਚ ਨਹੀਂ ਹੋਣ ਦਾ ਖਤਰਾ ਵਧ ਜਾਂਦਾ ਹੈ। ਇਹੀ ਤਰੀਕਾ ਕਾਰਨ ਬਣਦੀ ਹੈ ਕਿ ਬਿਲਾਨਾ ਗਲਤ ਠਿਕਾਣੇ 'ਤੇ ਜਾਂਦੇ, ਰਿਪੋਰਟ ਮੇਲ ਨਾ ਖਾਂਦੀਆਂ, ਜਾਂ ਇੱਕ ਸਕ੍ਰੀਨ ਤੇ ਗਾਹਕ “inactive” ਅਤੇ ਦੂਜੇ ਤੇ “active” ਹੋ ਸਕਦਾ ਹੈ।
ਅਮਲੀ ਪੱਧਰ 'ਤੇ, ਨਾਰਮਲਾਈਜੇਸ਼ਨ ਆਮ ਸਮੱਸਿਆਵਾਂ ਘਟਾਉਂਦਾ ਹੈ:
ਇਸ ਨਾਲ ਇਨਸਰਟ ਐਨੋਮਲੀਜ਼ (ਤੁਸੀਂ ਨਵਾਂ ਗਾਹਕ ਜੋੜ ਨਹੀਂ ਸਕਦੇ ਜਦ ਤੱਕ ਉਹ ਆਰਡਰ ਨਾ ਪੁੱਟੇ) ਅਤੇ ਡਿਲੀਟ ਐਨੋਮਲੀਜ਼ (ਆਖਰੀ ਆਰਡਰ ਮਿਟਾਉਣ ਨਾਲ ਗਾਹਕ ਦੀ ਇਕੱਲੀ ਜਾਣਕਾਰੀ ਮਿਟ ਜਾਂਦੀ) ਤੋਂ ਵੀ ਬਚਾਅ ਹੁੰਦਾ ਹੈ।
ਭਾਰੀ ਥਿਊਰੀ ਦੀ ਲੋੜ ਨਹੀਂ:
First Normal Form (1NF): ਹਰ ਫੀਲਡ ਨੂੰ ਐਟਾ੍ਮਿਕ ਰੱਖੋ। ਜੇ ਇੱਕ ਗਾਹਕ ਦੇ ਕਈ ਫੋਨ ਨੰਬਰ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸੈਲ ਵਿੱਚ ਇੱਕਠੇ ਨਾ ਕਰੋ; ਵੱਖ ਟੇਬਲ (ਜਾਂ ਵੱਖ ਕਤਾਰਾਂ) ਵਰਤੋ ਤਾਂ ਹਰ ਵੈਲਿਊ ਖੋਜਣ ਅਤੇ ਅਪਡੇਟ ਕਰਨ ਯੋਗ ਹੋਵੇ।
Second Normal Form (2NF): ਜੇ ਇੱਕ ਟੇਬਲ ਦੀ ਪਛਾਣ ਕਈ ਕਾਲਮਾਂ ਤੇ ਨਿਰਭਰ ਹੈ (ਕੰਪੋਜ਼ਿਟ ਕੀ), ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਗੈਰ-ਕੀ ਵੇਰਵੇ ਪੂਰੇ ਸੈੱਟ ਤੇ ਨਿਰਭਰ ਹਨ। ਇੱਕ ਆਰਡਰ ਲਾਈਨ ਉਸ ਲਾਈਨ ਲਈ item quantity ਅਤੇ price ਸਟੋਰ ਕਰੇ, ਨਾ ਕਿ ਗਾਹਕ ਦਾ ਪਤਾ।
Third Normal Form (3NF): “ਸਾਈਡ ਫੈਕਟ” ਨੂੰ ਦੂਰ ਕਰੋ ਜੋ ਹੋਰਥਾਂ ਦਾ ਹਿੱਸਾ ਹਨ। ਜੇ ਇੱਕ ਟੇਬਲ CustomerId ਅਤੇ CustomerCity ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ city ਗਾਹਕ ਟੇਬਲ ਵਿੱਚ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਹਰ ਆਰਡਰ ਵਿੱਚ ਨਕਲ ਹੋਵੈ।
ਵੱਧ ਨਾਰਮਲਾਈਜੇਸ਼ਨ ਆਮਤੌਰ 'ਤੇ ਵਧੇਰੇ ਟੇਬਲਾਂ ਅਤੇ ਵਧੇਰੇ joins ਦਾ ਮਤਲਬ ਹੁੰਦੀ ਹੈ। ਇਹ ਸੰਗਠਨ ਨੂੰ ਸੁਸੰਗਤਤਾ ਦਿੰਦਾ, ਪਰ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਜਟਿਲ ਬਣਾਉਂਦਾ ਅਤੇ ਕਈ ਵਾਰ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਅਸਰ ਪਾ ਸਕਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਮੂਲ ਐਂਟਿਟੀਜ਼ (ਗਾਹਕ, ਉਤਪਾਦ, ਚਲਾਨ) ਲਈ 3NF ਨੂੰ ਨਿਸ਼ਾਨ ਬਨਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਫਿਰ read-heavy ਡੈਸ਼ਬੋਰਡ ਲਈ ਨਾਪਤੌਲ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣਣਵਾਰ ਡੀਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਕਰਦੀਆਂ ਹਨ—ਫਿਰ ਭੀ ਇੱਕ ਅਧਿਕਾਰਕ ਸੋਰਸ ਆਫ ਟਰੂਥ primary/foreign key ਰਿਸ਼ਤਿਆਂ ਨਾਲ ਬਚਾ ਰਹਿੰਦੇ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਬੀਜਗਣਿਤ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਦੇ ਪਿੱਛੇ ਦੀ “ਮੈਥ”: ਕਤਾਰਾਂ ਦੇ ਇੱਕ ਸੈਟ (ਟੇਬਲ) ਨੂੰ ਦੂਜੇ ਸੈਟ ਵਿੱਚ ਬਦਲਣ ਲਈ ਥੋੜ੍ਹੇ ਅਤੇ ਸੁਚੱਜੇ ਓਪਰੇਸ਼ਨ।
ਉਹ ਸਹੀ ਪਰਿਭਾਸ਼ਾ ਮੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਨਿਯਮ ਸਪਸ਼ਟ ਹਨ, ਤਾਂ ਕੁਇਰੀ ਨਤੀਜੇ ਵੀ ਸਪਸ਼ਟ ਹੋਂਦੇ ਹਨ। ਤੁਸੀਂ ਪੂਰਨਤਾ ਨਾਲ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਜਦ ਤੁਸੀਂ ਡੇਟਾ ਫਿਲਟਰ, ਰੀਸ਼ੇਪ, ਜਾਂ ਜੋਇਨ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਨਤੀਜਾ ਆਏਗਾ—ਬਿਨਾਂ ਅਣਦਸਤਾਵਜ਼ ਵਰਤੋਂ ਜਾਂ ਹੱਥ-ਨੈਵੀਗੇਸ਼ਨ ਦੇ।
ਰਿਲੇਸ਼ਨਲ ਬੀਜਗਣਿਤ ਉਸੇ ਤਰ੍ਹਾਂ ਦੀਆਂ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਜੋੜ ਕੇ ਵਰਤੋਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਤਿੰਨ ਮਹੱਤਵਪੂਰਨ ਹਨ:
Select: ਉਹ ਕਤਾਰਾਂ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ।
ਉਦਾਹਰਨ: “ਕੇਵਲ ਪਿਛਲੇ ਮਹੀਨੇ ਦੇ ਆਰਡਰ” ਜਾਂ “ਕੇਵਲ ਫ੍ਰਾਂਸ ਦੇ ਗਾਹਕ।” ਤੁਸੀਂ ਉਹੀ ਕਾਲਮ ਰੱਖਦੇ ਹੋ ਪਰ ਕਤਾਰਾਂ ਘਟਾਉਂਦੇ ਹੋ।
Project: ਉਹ ਕਾਲਮ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ਉਦਾਹਰਨ: “ਗਾਹਕ ਦਾ ਨਾਮ ਅਤੇ ਈਮੇਲ ਦਿਖਾਓ।” ਤੁਸੀਂ ਤਰਕਸੰਗਤ ਰੂਪ ਵਿੱਚ ਉਹੀ ਕਤਾਰਾਂ ਰੱਖਦੇ ਹੋ ਪਰ ਜੋ ਕਾਲਮ ਨਹੀਂ ਚਾਹੀਦੇ ਉਹ ਹਟਾ ਦਿੰਦੇ ਹੋ।
Join: ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ ਤੋਂ ਸੰਬੰਧਤ ਤੱਥ ਜੋੜੋ।
ਉਦਾਹਰਨ: “ਹਰ ਆਰਡਰ ਦੇ ਨਾਲ ਗਾਹਕ ਵੇਰਵੇ ਜੋੜੋ,” ਇਕ ਸਾਂਝੇ ਪਹਚਾਨਕਾਰ (ਜਿਵੇਂ customer_id) ਵਰਤ ਕੇ। ਆਉਟਪੁੱਟ ਇੱਕ ਨਵੀਂ ਟੇਬਲ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਹਰ ਰੋ ਵਿੱਚ ਉਹ ਖੇਤਰ ਹੁੰਦੇ ਹਨ ਜੋ ਪਹਿਲਾਂ ਵੱਖਰੇ ਸਟੋਰ ਕੀਤੇ ਗਏ ਸਨ।
ਕਾਰੋਬਾਰੀ ਡੇਟਾ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵਿਸ਼ਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਹੁੰਦਾ ਹੈ: ਗਾਹਕ, ਆਰਡਰ, ਚਲਾਨ, ਉਤਪਾਦ, ਭੁਗਤਾਨ। ਇਹ ਵੱਖਰਾ ਰੱਖਣਾ ਹਰ ਤੱਥ ਨੂੰ ਇੱਕ ਵਾਰੀ ਸਟੋਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ (ਜਿਸ ਨਾਲ ਮਿਲਾਪ ਘੱਟ ਹੁੰਦਾ ਹੈ), ਪਰ ਇਹ ਵੀ ਮਤਲਬ ਹੈ ਕਿ ਅਕਸਰ ਜਵਾਬਾਂ ਲਈ ਉਹਨਾਂ ਤੱਥਾਂ ਨੂੰ ਦੁਬਾਰਾ ਮਿਲਾਉਣਾ ਪੈਂਦਾ ਹੈ।
joins ਉਹ ਸੰਗਠਿਤ ਤਰੀਕਾ ਹਨ ਜੋ ਉਹ ਦੁਬਾਰਾ-ਮਿਲਾਉ ਨੂੰ ਮੈਨੇਜਦੀਆਂ ਹਨ ਅਤੇ ਮਾਇਨਿੰਗ ਦੇ ਅਰਥ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੀਆਂ ਹਨ।
ਕਿਉਂਕਿ ਰਿਲੇਸ਼ਨਲ ਬੀਜਗਣਿਤ ਕਤਾਰਾਂ ਦੇ ਸੈਟਾਂ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਓਪਰੇਸ਼ਨਾਂ ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਹਰ ਕਦਮ ਦਾ ਉਮੀਦ ਕੀਤਾ ਨਤੀਜਾ ਵਧੀਆ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ:
ਇਹ ਉਹ ਸੰਕਲਪਿਕ ਢਾਂਚਾ ਹੈ ਜਿਸ ਨੇ ਬਾਅਦ ਵਿੱਚ SQL ਨੂੰ ਪ੍ਰੈਕਟਿਕਲ ਬਣਾਇਆ: ਕੁਇਰੀਆਂ ਸੁਚੱਜੀਆਂ ਪਰਿਭਾਸ਼ਿਤ ਤਬਦੀਲੀਆਂ ਦੀ ਲੜੀ ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਐਡ-ਹੌਕ ਡੇਟਾ ਫੈਚਿੰਗ।
Codd ਦਾ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਇਹ ਦਰਸਾਉਂਦਾ ਸੀ ਕਿ ਡੇਟਾ ਦਾ ਕੀ ਅਰਥ ਹੈ (relations, ਕੀਜ਼, ਅਤੇ ਓਪਰੇਸ਼ਨ) ਬਿਨਾਂ ਲੋਕਾਂ ਲਈ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਯੋਗ ਤਰੀਕਾ ਦੱਸੇ। SQL ਨੇ ਉਹ ਖਾਲੀ ਥਾਂ ਭਰੀ: ਇਸਨੇ ਰਿਲੇਸ਼ਨਲ ਵਿਚਾਰਾਂ ਨੂੰ ਇੱਕ ਅਮਲੀ, ਪੜਨਯੋਗ ਭਾਸ਼ਾ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜੋ ਵਿਸ਼ਲੇਸ਼ਕ, ਡਿਵੈਲਪਰ ਅਤੇ ਡੇਟਾਬੇਸ ਉਤਪਾਦ ਸਾਂਝੇ ਕਰ ਸਕਦੇ ਸਨ।
SQL ਰਿਲੇਸ਼ਨਲ ਬੀਜਗਣਿਤ ਤੋਂ ਪ੍ਰੇਰਿਤ ਹੈ, ਪਰ ਇਹ Codd ਦੀ ਮੂਲ ਸਿਧਾਂਤਿਕ ਥਿਊਰੀ ਦੀ ਪੂਰੀ ਨਕਲ ਨਹੀਂ।
ਇੱਕ ਮੁੱਖ ਫਰਕ ਇਹ ਹੈ ਕਿ SQL ਗੁੰਮ ਹੋਏ ਜਾਂ ਅਣਜਾਣ ਮੁੱਲਾਂ ਨੂੰ NULL ਰਾਹੀਂ ਸਮਭਾਲਦਾ ਹੈ। ਪਾਰੰਪਰਿਕ ਰਿਲੇਸ਼ਨਲ ਥਿਊਰੀ ਦੋ-ਮੁੱਲੀ ਲਾਜਿਕ (true/false) 'ਤੇ ਆਧਾਰਿਤ ਹੈ, ਜਦਕਿ SQL NULL ਦੇ ਨਾਲ ਤਿੰਨ-ਮੁੱਲੀ ਲਾਜਿਕ (true/false/unknown) ਲਿਆਉਂਦੀ ਹੈ। ਦੂਜਾ ਫਰਕ: ਰਿਲੇਸ਼ਨਲ ਥਿਊਰੀ ਸੈਟਾਂ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ (ਕੋਈ duplicates ਨਹੀਂ), ਪਰ SQL ਟੇਬਲ ਅਕਸਰ duplicate rows ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਰੋਕਣ ਲਈ explicit ਨਾ ਕਰੋ।
ਇਨ੍ਹਾਂ ਫਰਕਾਂ ਦੇ ਬਾਵਜੂਦ, SQL ਨੇ ਮੁੱਖ ਵਾਅਦਾ ਕਾਇਮ ਰੱਖਿਆ: ਤੁਸੀਂ ਨਤੀਜਾ ਵੇਰਵਾ ਕਰਦੇ ਹੋ (ਘੋਸ਼ਣਾਤਮਕ ਕੁਇਰੀ), ਅਤੇ ਡੇਟਾਬੇਸ execution ਦੇ ਕਦਮ ਨਿਰਧਾਰਿਤ ਕਰ ਲੈਂਦਾ ਹੈ।
Codd ਨੇ ਆਪਣਾ ਪ੍ਰਮੁੱਖ ਪੇਪਰ 1970 ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਤ ਕੀਤਾ। 1970 ਦੇ ਦਹਾਕੇ ਵਿੱਚ, IBM ਨੇ ਪਹਿਲੇ ਪ੍ਰੋਟੋਟਾਈਪ (ਖ਼ਾਸ ਕਰਕੇ System R) ਤਿਆਰ ਕੀਤੇ ਜੋ ਦਿਖਾਉਂਦੇ ਸਨ ਕਿ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਵਾਸਤਵਿਕ ਵਰਕਲੋਡ ਲਈ ਕਾਫੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿ ਇੱਕ ਉੱਚ-ਸਤਹ ਕੁਇਰੀ ਭਾਸ਼ਾ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ execution plans ਵਿੱਚ ਕੰਪਾਈਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇਸਦੇ ਨਾਲ-ਨਾਲ, ਅਕਾਦਮਿਕ ਅਤੇ ਵਪਾਰਕ ਯਤਨਾਂ ਨੇ SQL ਅੱਗੇ ਵਧਾਇਆ। 1980 ਦੇ ਅਖੀਰ ਤੱਕ, SQL ਦਾ ਸਟੈਂਡਰਡਾਈਜੇਸ਼ਨ (ANSI/ISO) ਨੇ ਵੇਂਡਰਾਂ ਨੂੰ ਇੱਕ ਆਮ ਭਾਸ਼ਾ 'ਤੇ ਆਉਣ ਦਾ ਮੌਕਾ ਦਿੱਤਾ—ਹਾਲਾਂਕਿ ਹਰ ਉਤਪਾਦ ਨੇ ਆਪਣੇ ਕੁਝ ਵਧਾਏ ਹੋਏ ਫੀਚਰ ਰੱਖੇ।
SQL ਨੇ ਸਵਾਲ ਪੁੱਛਣ ਦੀ ਲਾਗਤ ਘਟਾਈ। ਹਰ ਰਿਪੋਰਟ ਲਈ ਕਸਟਮ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਸਿੱਧਾ ਪ੍ਰਸ਼ਨ ਵਰਣਨ ਕਰ ਪਾਂਦੀਆਂ:
GROUP BY ਵਰਤ ਕੇ ਖੇਤਰ ਅਤੇ ਮਹੀਨੇ ਅਨੁਸਾਰ ਵਿਕਰੀਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਲਈ, joins ਅਤੇ aggregation ਦਾ ਮਿਲਾਪ ਇੱਕ ਬ੍ਰੇਕਥਰੂ ਸਾਬਤ ਹੋਇਆ। ਫਾਇਨੈਨਸ ਟੀਮ ਇੰਵਾਇਸਾਂ ਨੂੰ ਭੁਗਤਾਨਾਂ ਨਾਲ reconcile ਕਰ ਸਕਦੀ ਸੀ; ਪ੍ਰੋਡਕਟ ਟੀਮ conversion funnels ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦੀ ਸੀ; ਓਪਰੇਸ਼ਨ ਟੀਮ ਇਨਵੈਂਟਰੀ ਅਤੇ ਫੁਲਫ਼ਿਲਮੈਂਟ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦੀ ਸੀ—ਸਾਰਾ ਕੁਝ ਇੱਕ ਸਾਂਝੇ, ਸੰਰਚਿਤ ਡੇਟਾ ਮਾਡਲ 'ਤੇ ਕੁਇਰੀ ਕਰਕੇ।
ਇਹ ਵਰਤੋਂਕਾਰੀਤਾ ਇੱਕ ਵੱਡਾ ਕਾਰਣ ਹੈ ਕਿ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਖੋਜ ਵਿਸ਼ਵ ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਕੇ ਰੋਜ਼ਾਨਾ ਟੂਲ ਬਣ گیا।
ਕਾਰੋਬਾਰੀ ਸਿਸਟਮ ਭਰੋਸੇ ਤੇ ਜ਼ਿੰਦਾ ਰਹਿੰਦੇ ਹਨ। ਸਿਰਫ਼ ਡੇਟਾ "ਸਟੋਰ" ਕਰਨਾ ਕਾਫੀ ਨਹੀਂ—ਡੇਟਾਬੇਸ ਨੂੰ ਸਹੀ ਬਕਾਏ, ਸਹੀ ਇਨਵੈਂਟਰੀ ਗਿਣਤੀ, ਅਤੇ ਇੱਕ ਮੰਨਣਯੋਗ ਆਡਿਟ ਟਰੇਲ ਬਚਾਓਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਕਈ ਲੋਕ ਇੱਕੱਠੇ ਸਿਸਟਮ ਵਰਤ ਰਹੇ ਹੋਣ।
ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਕਈ ਸੋਧਾਂ ਨੂੰ ਇੱਕ ਇਕਾਈ ਕਾਰੋਬਾਰੀ ਕਾਰਵਾਈ ਵਜੋਂ ਗੱਠਦਾ ਹੈ। ਸੋਚੋ: “$100 ਟ੍ਰਾਂਸਫਰ ਕਰੋ”, “ਇੱਕ ਆਰਡਰ ਭੇਜੋ”, ਜਾਂ “ਪੇਰੋਲ ਰਨ ਪੋਸਟ ਕਰੋ”。 ਇਹਨਾਂ ਵਿੱਚ ਕਈ ਟੇਬਲ ਅਤੇ ਕਈ ਕਤਾਰਾਂ ਛੁਹੀਆਂ ਜਾਣੀਆਂ ਹਨ।
ਮੁੱਖ ਵਿਚਾਰ ਸਾਰਾ-ਜਾ-ਕਿਛ ਨਾ-ਹੋਵੇ:
ਇਸੇ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਇੰਝ ਸਥਿਤੀਆਂ ਤੋਂ ਬਚਦੇ ਹੋ ਜਿਵੇਂ ਪੈਸਾ ਇੱਕ ਖਾਤੇ ਤੋਂ ਜਾਂਦਾ ਪਰ ਦੂਜੇ ਵਿੱਚ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਜਾਂ ਇਨਵੈਂਟਰੀ ਘੱਟ ਹੋ ਜਾਂਦੀ ਪਰ ਆਰਡਰ ਦਰਜ ਨਹੀਂ ਹੁੰਦਾ।
ACID ਉਹ ਰੰਗ-ਨੁਮਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਤੇ ਕਾਰੋਬਾਰ ਭਰੋਸਾ ਕਰਦੇ ਹਨ:
constraints (ਜਿਵੇਂ primary keys, foreign keys, ਅਤੇ checks) ਗਲਤ ਹਾਲਤਾਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ। ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿ ਟੇਬਲਾਂ 'ਤੇ ਸਬੰਧਿਤ ਅਪਡੇਟ ਇਕੱਠੇ ਆਉਣ।
ਅਮਲੀ ਤੌਰ 'ਤੇ: ਇੱਕ ਆਰਡਰ ਸੇਵ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਉਸ ਦੀਆਂ ਲਾਈਨ ਆਈਟਮਾਂ ਸੇਵ ਹੁੰਦੀਆਂ ਹਨ, ਇਨਵੈਂਟਰੀ ਘਟਾਈ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਆਡਿਟ ਲੌਗ ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ ਲਿਖੀ ਜਾਂਦੀ ਹੈ—ਇਹ ਸਾਰਾ ਕਮ ਕਰਦਾ ਹੈ ਜਾਂ ਕੁਝ ਵੀ ਨਹੀਂ। ਇਹ ਜੋੜ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ+constraints ਹੀ SQL ਡੇਟਾਬੇਸਾਂ ਨੂੰ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਗੰਭੀਰ ਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਸਹਾਇਤਾ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
SQL ਡੇਟਾਬੇਸਾਂ ਨੇ ਨਹੀਂ “ਜਿੱਤਿਆ” ਕਿਉਂਕਿ ਉਹ ਫੈਸ਼ਨਬਤੇ ਸਨ—ਉਹ ਇਸ ਲਈ ਫਿੱਟ ਹੋਏ ਕਿ ਉਹ ਜ਼ਿਆਦਾਤਰ ਸੰਗਠਨਾਂ ਦੀ ਸੋਚ ਅਤੇ ਕੰਮ ਕਰਨ ਦੇ ਢੰਗ ਨਾਲ ਮਿਲਦੇ ਸਨ। ਇੱਕ ਕੰਪਨੀ ਢੇਰ ਸਾਰੀਆਂ ਦੁਹਰਾਈ, ਸੰਰਚਿਤ ਚੀਜ਼ਾਂ ਨਾਲ ਭਰੀ ਹੁੰਦੀ ਹੈ: ਗਾਹਕ, ਚਲਾਨ, ਉਤਪਾਦ, ਭੁਗਤਾਨ, ਕਰਮਚਾਰੀ। ਹਰ ਇੱਕ ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਲਿਸਟ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਉਹ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਤਰੀਕਿਆਂ ਵਿੱਚ ਜੁੜਦੇ ਹਨ। ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਇਸ ਹੱਕੀਕਤ ਨੂੰ ਖੂਬਸੂਰਤੀ ਨਾਲ ਮੇਚ ਕਰਦਾ ਹੈ: ਇੱਕ ਗਾਹਕ ਬਹੁਤ ਸਾਰੇ ਆਰਡਰ ਕਰ ਸਕਦਾ ਹੈ, ਆਰਡਰ ਵਿੱਚ ਲਾਈਨ ਆਈਟਮ ਹੁੰਦੇ ਹਨ, ਭੁਗਤਾਨ ਚਲਾਨਾਂ ਨੂੰ reconcile ਕਰਦੇ ਹਨ।
ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸਥਿਰਤਾ ਅਤੇ ਟਰੇਸੇਬਿਲਿਟੀ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਜਦ ਫਾਇਨੈਂਸ ਪੁਛਦਾ ਹੈ, “ਕਿਹੜੇ ਚਲਾਨ ਅਣਭੁਗਤ ਹਨ?” ਜਾਂ ਸਹਾਇਤਾ ਪੁੱਛਦੀ ਹੈ, “ਇਸ ਗਾਹਕ ਦਾ ਪਲਾਨ ਕੀ ਹੈ?”, ਜਵਾਬ ਉਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਭਾਵੇਂ ਕਿਹੜਾ ਉਪਕਰਨ ਜਾਂ ਟੀਮ ਪੁੱਛ ਰਹੀ ਹੋਵੇ। ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਤੱਥਾਂ ਨੂੰ ਇੱਕ ਵਾਰੀ ਸਟੋਰ ਕਰਨ ਅਤੇ ਹਰ ਜਗ੍ਹਾ ਹਵਾਲਾ ਦੇਣ ਲਈ ਬਣਾਏ ਗਏ ਹਨ, ਜਿਸ ਨਾਲ ਉਹ ਟਕਰਾਅ ਘੱਟ ਕਰਦੇ ਜੋ ਮਹਿੰਗਾ ਦੁਬਾਰਾ ਕੰਮ ਬਣਦਾ ਹੈ।
ਜਿਵੇਂ SQL ਵਿਆਪਕ ਹੋਇਆ, ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕecosystem ਬਣੀ: ਰਿਪੋਰਟਿੰਗ ਟੂਲ, BI ਡੈਸ਼ਬੋਰਡ, ETL ਪਾਈਪਲਾਈਨ, ਕਨੈਕਟਰ, ਅਤੇ ਟਰੇਨਿੰਗ। ਇਸ ਸੰਕੁਚਿਤਤਾ ਨੇ ਆਪਣੀ ਪਛਾਣ ਬਣਾਉਣ ਦੀ ਲਾਗਤ ਘਟਾ ਦਿੱਤੀ। ਜੇ ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਆਮ ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਵਰਕਫਲੋਜ਼ ਨਾਲ ਜੁੜਨਾ ਸੁਲਭ ਹੁੰਦਾ ਹੈ ਬਿਨਾਂ ਕਸਟਮ glue ਕੋਡ ਦੇ।
ਐਪਸ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਤ ਹੁੰਦੀਆਂ ਹਨ—ਨਵੇਂ ਫੀਚਰ, ਨਵੀਆਂ UI, ਨਵੀਆਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ। ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸਕੀਮਾ ਇੱਕ ਦਰੁਸਤ ਠੇਕੇ ਵਾਂਗ ਕੰਮ ਕਰਦਾ: ਭਾਵੇਂ ਸੇਵਾਵਾਂ ਅਤੇ ਸਕ੍ਰੀਨ ਬਦਲ ਜਾਣ, ਕੋਰ ਟੇਬਲਾਂ ਅਤੇ ਰਿਸ਼ਤਿਆਂ ਨਾਲ ਡੇਟਾ ਦਾ ਅਰਥ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਸਥਿਰਤਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ SQL ਡੇਟਾਬੇਸ ਸਾਫਟਵੇਅਰ ਦਾ ਭਰੋਸੇਯੋਗ ਕੇਂਦਰ ਬਣੇ।
ਸਕੀਮਾਂ ਸਿਰਫ ਡੇਟਾ ਨਹੀਂ ਠਹਿਰਾਉਂਦੀਆਂ—ਉਹ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਵੀ ਸਾਫ਼ ਕਰਦੀਆਂ ਹਨ। ਟੀਮਾਂ ਇਹ ਮੰਨ ਸਕਦੀਆਂ ਹਨ ਕਿ “Customer” ਕੀ ਹੈ, ਕਿਹੜੇ ਫੀਲਡ ਜ਼ਰੂਰੀ ਹਨ, ਅਤੇ ਰਿਕਾਰਡ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ। ਪ੍ਰਾਇਮਰੀ ਅਤੇ ਫੌਰਨ ਕੀਜ਼ ਨਾਲ, ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ: ਕੌਣ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ ਹੈ, ਕੌਣ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਾਰੋਬਾਰ ਭਰ ਵਿੱਚ ਕੀ ਚੀਜ਼ਾਂ ਤਬਦੀਲ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸਾਂ ਨੇ ਆਪਣੀ ਜਗ੍ਹਾ ਹਾਸਲ ਕੀਤੀ ਕਿਉਂਕਿ ਉਹ ਪੇਸ਼ਗੀ ਅਤੇ ਸੁਰੱਖਿਆ ਦਿੰਦੀਆਂ ਹਨ, ਪਰ ਹਰ ਵర్కਲੋਡ ਲਈ ਉਹ ਸਹੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। SQL ਸਿਸਟਮਾਂ ਦੀਆਂ ਕਈ ਆਲੋਚਨਾਵਾਂ ਅਸਲ ਵਿੱਚ ਇੱਕੇ ਟੂਲ ਨੂੰ ਹਰ ਕੰਮ ਲਈ ਵਰਤਣ ਦੀ ਆਲੋਚਨਾ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਸਕੀਮਾ ਇੱਕ ਠੇਕੇ ਵਾਂਗ ਹੁੰਦਾ ਹੈ: ਟੇਬਲ, ਕਾਲਮ, ਕਿਸਮਾਂ ਅਤੇ constraints ਇਹ ਪਰਿਲੇਖ ਕਰਦੇ ਹਨ ਕਿ “ਵੈਧ ਡੇਟਾ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇਹ ਸਾਂਝੀ ਸਮਝ ਲਈ ਸ਼ਾਨਦਾਰ ਹੈ, ਪਰ ਜਦ ਪ੍ਰੋਡਕਟ ਹਾਲੇ ਵੀ ਵਿਕਸਿਤ ਹੋ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਇਹ ਟੀਮਾਂ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਹਫ਼ਤਾਵਾਰ ਨਵੇਂ ਫੀਲਡ ਜਾਰੀ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ migrations, backfills, ਅਤੇ deployments ਦਾ ਸਹਿਯੋਜਨ ਗੰਢ ਬਣ ਸਕਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਟੇਬਲ ਵੱਡੀਆਂ ਹੋਣ ਜਾਂ ਸਿਸਟਮ 24/7 online ਰਹਿਣੇ ਹੋਣ।
“NoSQL” ਰਿਲੇਸ਼ਨਲ ਵਿਚਾਰ ਦੀ ਨਕਾਰਾਤਮਕਤਾ ਨਹੀਂ ਸੀ, ਬਲਕਿ ਕੁਝ ਖ਼ਾਸ ਦਰਦਬਿੰਦੀਆਂ ਲਈ ਜਵਾਬ ਸੀ:
ਇਨ੍ਹਾਂ ਪ੍ਰਣਾਲੀਆਂ ਨੇ ਕਈ ਵਾਰੀ ਸਖ਼ਤ ਸੰਗਤਤਾ ਜਾਂ ਸਮৃਧ joins ਦੀ ਕੁਰਬਾਨੀ ਦਿੱਤੀ ਤਾਂ ਜੋ ਗਤੀ, ਲਚਕ, ਜਾਂ ਵੰਡ ਵਿਚ ਫਾਇਦਾ ਮਿਲੇ।
ਆਧੁਨਿਕ ਸਟੈਕ ਅਕਸਰ polyglot ਹੁੰਦੇ ਹਨ: ਕੋਰ ਕਾਰੋਬਾਰੀ ਰਿਕਾਰਡਾਂ ਲਈ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ, ਨਾਲ ਹੀ ਇੱਕ ਇਵੈਂਟ ਸਟ੍ਰੀਮ, ਇੱਕ ਸਰਚ ਇੰਡੈਕਸ, ਇੱਕ cache, ਜਾਂ ਕੁੰਝੀ-ਮੁੱਲ/ਦਸਤਾਵੇਜ਼ ਸਟੋਰ analytics ਅਤੇ content ਲਈ। ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਅਕਸਰ ਸਚਾਈ ਦਾ ਸਰੋਤ ਰਹਿੰਦਾ ਹੈ, ਜਦਕਿ ਹੋਰ ਸਟੋਰ ਰੀਡ-ਹੈਵੀ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਕੁਇਰੀਆਂ ਦੀ ਸੇਵਾ ਕਰਦੇ ਹਨ।
ਚੁਣ੍ਹਦੇ ਸਮੇਂ ਧਿਆਨ ਦਿਓ:
ਏਕ ਚੰਗਾ ਡਿਫ਼ੌਲਟ ਹੈ: ਕੋਰ ਡੇਟਾ ਲਈ SQL, ਅਤੇ ਜਦੋਂ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸੀਮਾ ਪਾਰ ਕਰਦਾ ਹੈ, ਤਦ ਨਿਰਧਾਰਤ ਵਿਕਲਪ ਜੋੜੋ।
Codd ਦਾ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਸਿਰਫ਼ ਇਤਿਹਾਸ ਨਹੀਂ—ਇਹ ਅਜਿਹਾ ਹੱਲ ਹੈ ਜੋ ਕਾਰੋਬਾਰੀ ਡੇਟਾ ਨੂੰ ਭਰੋਸੇਯੋਗ, ਬਦਲਣਯੋਗ, ਅਤੇ ਰਿਪੋਰਟ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਭਾਵੇਂ ਤੁਹਾਡੀ ਐਪ ਕਈ ਸਟੋਰੇਜ ਪਰਣਾਲੀਆਂ ਨੂੰ ਮਿਲਾ ਕੇ ਵਰਤੇ, ਰਿਲੇਸ਼ਨਲ ਸੋਚ ਜੋ "systems of record" (orders, invoices, customers, inventory) ਲਈ ਹੈ, ਉਹ ਅਜੇ ਵੀ ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਫ਼ੌਲਟ ਹੈ।
ਆਪਣੇ ਕਾਰੋਬਾਰ ਦੀਆਂ ਅਸਲ-ਦੁਨੀਆਂ ਦੀਆਂ ਨਾਂਵਾਂ (nouns) ਨੂੰ ਟੇਬਲਾਂ ਵਜੋਂ ਮਾਡਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ (Customers, Orders, Payments), ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਰਿਸ਼ਤਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਕੁਝ ਨਿਯਮ ਜੋ ਜ਼ਿਆਦਾਤਰ ਦਰਦ ਰੋਕ ਦਿੰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਇਹ ਨੀਅਮ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਬਦਲ ਰਹੇ ਹੋ, ਤਾਂ ਉਸ ਟੂਲਿੰਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਸਕੀਮਾ ਅਭੀਰੁਚੀ ਅਤੇ ਐਪ ਕੋਡ ਨੂੰ aligned ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰੇ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਚੈਟ ਪ੍ਰਾਂਪਟ ਤੋਂ React + Go + PostgreSQL ਐਪ ਜਨਰੇਟ ਕਰ ਸਕਦੀ ਹੈ, ਜੋ normalized ਸਕੀਮਾ (ਟੇਬਲ, ਕੀਜ਼, ਰਿਸ਼ਤੇ) ਦੀ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਅਤੇ ਇਟਰੈਸ਼ਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ—ਫਿਰ ਵੀ ਜਦ ਤੁਸੀਂ ਪੂਰੀ ਮਾਲਕੀ ਚਾਹੋ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਡੇਟਾ ਮਜ਼ਬੂਤ ਸਹੀਅਤਾ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਪੁੱਛੋ:
ਜੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਵਾਬ "ਹਾਂ" ਹੈ, ਤਾਂ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਆਮਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸਧਾਰਨ ਰਸਤਾ ਹੁੰਦਾ ਹੈ।
“SQL scale ਨਹੀਂ ਕਰ سکتا” ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਆਪਕ ਦਾਅਵਾ ਹੈ। SQL ਸਿਸਟਮ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ scale ਕਰਦੇ ਹਨ (ਇੰਡੈਕਸ, caching, read replicas, ਜਦ ਲੋੜ ਹੋਵੇ ਤਾਂ sharding)। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ modeling ਅਤੇ ਕੁਇਰੀ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਪਿਛਲੇ ਸਮੇਂ ਪ੍ਰੇਰਿਤ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਅਸਲ ਡੇਟਾਬੇਸ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਾਲ।
“ਨਾਰਮਲਾਈਜੇਸ਼ਨ ਸਾਰਾ ਕੁਝ ਧੀਮਾ ਕਰ ਦਿੰਦੀ ਹੈ” ਵੀ ਅਧੂਰਾ ਦਾਅਵਾ ਹੈ। ਨਾਰਮਲਾਈਜੇਸ਼ਨ ਅਸਪਸ਼ਟਤਾਵਾਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ; ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਇੰਡੈਕਸ, ਕੁਇਰੀ ਡਿਜ਼ਾਇਨ, ਅਤੇ ਜਦ ਮੈਜ਼ਰਮੈਂਟ ਦਰਸਾਏ ਤਾਂ ਚੁਣੀ ਗਈ ਡੀਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ।
Codd ਨੇ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝਾ ਠੇਕਾ ਦਿੱਤਾ: ਡੇਟਾ ਨੂੰ ਸਬੰਧਿਤ ਟੇਬਲਾਂ ਵਿੱਚ ਦ੍ਰਿੜਤਾ ਨਾਲ ਰੱਖੋ, ਵੈਲ-ਡਿਫਾਈਨਡ ਓਪਰੇਸ਼ਨਾਂ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਸੋਧੋ, ਅਤੇ constraints ਨਾਲ ਸੁਰੱਖਿਅਤ ਰੱਖੋ। ਇਹ ਠੇਕਾ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਰੋਜ਼ਾਨਾ ਸੌਫਟਵੇਅਰ ਸਾਲਾਂ ਤੱਕ ਵਿਕਸਤ ਹੋ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਇਸ ਸਮਰੱਥਾ ਨੂੰ ਖੋ ਦਿੱਤੇ ਕਿ “ਕੀ ਹੋਇਆ, ਕਦੋਂ, ਅਤੇ ਕਿਉਂ?”
ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਜਾਣਕਾਰੀ ਨੂੰ ਟੇਬਲਾਂ (relations) ਵਜੋਂ ਸੰਭਾਲਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ:
ਇਸਦਾ ਮੁੱਖ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਅਲੱਗ ਟੇਬਲਾਂ ਨੂੰ ਸਾਂਝੇ ਪਹਚਾਨਾਂ ਰਾਹੀਂ ਲਿੰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਜੋ ਹਰ ਤੱਥ ਇੱਕ ਹੀ ਜਗ੍ਹਾ ਤੇ ਰੱਖਿਆ ਜਾਵੇ ਅਤੇ ਰਿਪੋਰਟਾਂ ਅਤੇ ਵਰਕਫਲੋਜ਼ ਲਈ ਵਾਪਸ ਜੋੜਿਆ ਜਾ ਸਕੇ।
ਫਾਈਲ-ਅਧਾਰਤ ਸਿਸਟਮ ਡੇਟਾ ਲੇਆਉਟ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨਾਲ ਬਹੁਤ ਨੇੜੇ ਰੱਖਦੇ ਸਨ। ਇਸ ਨਾਲ ਹੇਠ ਲਿਖੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਉਂਦੀਆਂ ਸਨ:
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਨੇ ਡੇਟਾ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਕਿਸੇ ਇੱਕ ਐਪ ਤੋਂ ਅਲੱਗ ਕੀਤਾ ਅਤੇ ਕ੍ਰਾਸ-ਕੱਟਿੰਗ ਕੁਇਰੀਆਂ ਰੋਜ਼ਮਰਾ ਦੀ ਰੁਟੀਨ ਬਣਾਈਆਂ।
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਕੀ (PK) ਹਰ ਟੇਬਲ ਵਿਖੇ ਹਰੇਕ ਕਤਾਰ ਨੂੰ ਯੂਨੀਕ ਤੌਰ 'ਤੇ ਪਛਾਣਦੀ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਸਥਿਰ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ।
ਵਿਆਵਹਾਰਿਕ ਸੁਝਾਅ:
customer_id) ਨੂੰ ਤਰਜੀਹ ਦਿਓ।ਇੱਕ ਫੌਰਨ ਕੀ (FK) ਉਹ ਕਾਲਮ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਵੈਲ્યુ ਕਿਸੇ ਹੋਰ ਟੇਬਲ ਦੇ ਪ੍ਰਾਇਮਰੀ ਕੀ ਨਾਲ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਰਿਸ਼ਤੇ ਨੂੰ ਉਹਨਾਂ ਦੀਆਂ ਮੁੱਖ ਰਿਕਾਰਡਾਂ ਨੂੰ ਨਕਲ ਕੀਤੇ ਬਿਨਾਂ ਦੱਸਦਾ ਹੈ।
ਉਦਾਹਰਨ ਪੈਟਰਨ:
orders.customer_id references customers.customer_idFK constraints ਨਾਲ database ਇਹ ਰੋਕ ਸਕਦਾ ਹੈ:
ਨਾਰਮਲਾਈਜੇਸ਼ਨ ਦਾ ਮਕਸਦ ਹੈ ਕਿ ਹਰ ਤੱਥ ਨੂੰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਇੱਕ ਵਾਰੀ ਹੀ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ, ਤਾਂ ਜੋ ਗਲਤੀਆਂ ਘੱਟ ਹੋਣ:
ਆਮ ਤੌਰ 'ਤੇ ਮੁੱਖ ਐਂਟਿਟੀਜ਼ ਲਈ ਇੱਕ ਵਧੀਆ ਨਿਸ਼ਾਨ ਹੈ, ਅਤੇ ਕੇਵਲ ਜਦੋਂ ਮੈਜ਼ਰਮੈਂਟ ਦਰਸਾਏ ਤਾਂ ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਡੀਨਾਰਮਲਾਈਜ਼ ਕਰੋ।
ਇੱਕ ਫੀਲਡ, ਇੱਕ ਵੈਲੂ ਦਾ ਨਿਯਮ ਅਨੁਸਾਰ, ਬਹੁ-ਮੁੱਲ ਵਾਲੀਆਂ ਫੀਲਡਾਂ ਨੂੰ ਵਖਰੇ ਟੇਬਲਾਂ ਵਿੱਚ ਰੱਖੋ।
ਜੇ ਤੁਸੀਂ phone1, phone2, phone3 ਵਰਗੀਆਂ ਕਾਲਮਾਂ ਜੋੜ ਰਹੇ ਹੋ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸੰਬੰਧਿਤ ਟੇਬਲ ਵਿੱਚ ਵੰਡੋ:
customer_phones(customer_id, phone_number, type)ਇਸ ਨਾਲ ਫੋਨ ਨੰਬਰ ਲੱਭਣਾ, ਵੈਧਤਾ ਜਾਂ ਅਪਡੇਟ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਅਤੇ “ਗੁੰਮ ਕਾਲਮ” ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਆਉਂਦੀਆਂ।
ਰਿਲੇਸ਼ਨਲ ਬੀਜਗਣਿਤ ਉਹ ਮੂਲ ਹਿੱਸਾ ਹੈ ਜੋ ਰਿਲੇਸ਼ਨਲ ਕੁਇਰੀਆਂ ਦੇ ਪਿੱਛੇ ਦੀ “ਮੰਤ੍ਰਨਾ” ਹੈ:
ਤੁਹਾਨੂੰ ਰੋਜ਼ਾਨਾ relational algebra ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਇਹ ਸਮਝਣਾ SQL ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸਮਝਣ ਅਤੇ joins ਵਿੱਚ ਗਲਤ ਨਤੀਜੇ ਆਉਣ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
SQL ਨੇ ਰਿਲੇਸ਼ਨਲ ਵਿਚਾਰਾਂ ਨੂੰ ਵਰਤੋਂ ਯੋਗ ਬਣਾਇਆ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਘੋਸ਼ਣਾਤਮਕ ਤਰੀਕੇ ਨਾਲ ਸਵਾਲ ਪੂਛਣ ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ: ਤੁਸੀਂ ਨਤੀਜਾ ਵੇਰਵਾ ਕਰਦੇ ਹੋ, ਅਤੇ database ਇੱਕ execution ਪਲਾਨ ਚੁਣਦਾ ਹੈ।
ਅਹੰ ਮਹੱਤਵਪੂਰਨ ਫਾਇਦੇ:
GROUP BY)ਹਾਲਾਂਕਿ SQL ਪੂਰੀ ਤਰ੍ਹਾਂ Codd ਦੀ ਸਿਧਾਂਤਿਕ ਮੌਡਲ ਨਹੀਂ ਹੈ, ਇਹ ਮੂਲ ਕਾਰਜਪ੍ਰਣਾਲੀ—ਰਿਲੇਟਿਡ ਟੇਬਲਾਂ 'ਤੇ ਭਰੋਸੇਯੋਗ ਕੁਇਰੀ—ਕਾਇਮ ਰੱਖਦਾ ਹੈ।
SQL ਕੁਝ ਢੰਗਾਂ ਨਾਲ “ਐਪਲਾਈਡ” ਰਿਲੇਸ਼ਨਲ ਥਿਊਰੀ ਨਾਲ ਵੱਖਰਾ ਹੈ:
NULL ਤਿੰਨ-ਮੁੱਲੀ ਲਾਜ਼ਿਕ (true/false/unknown) ਲਿਆਉਂਦਾ ਹੈ, ਜੋ ਫਿਲਟਰ ਅਤੇ ਜੋਇਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦਾ ਹੈ।ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ NULL ਨੂੰ ਧਿਆਨ ਨਾਲ ਸੰਭਾਲੋ ਅਤੇ ਜਿੱਥੇ ਜ਼ਰੂਰੀ ਹੋ uniqueness ਲਗਾਓ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਉਹ ਵੇਲੇ ਵਰਤੋਂ ਲਈ ਵਧੀਆ ਹਨ ਜਦ ਤੁਹਾਨੂੰ ਸਾਂਝੇ ਕਾਰੋਬਾਰੀ ਰਿਕਾਰਡਾਂ ਲਈ ਮਜ਼ਬੂਤ ਸਹੀਅਤਾ ਦੀ ਲੋੜ ਹੋਵੇ।
ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਚੈੱਕਲਿਸਟ:
ਹਾਂ ਹੋਣ 'ਤੇ, ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸਧਾਰਨ ਰਸਤਾ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਲਚਕੀਲੇ ਡੇਟਾ ਆਕਾਰ, ਬਹੁਤ ਉੱਚ-ਪੈਮਾਨੇ ਤੇ ਵੰਡ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਮੁਹਾਂਡੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ NoSQL ਜਾਂ ਅਨ੍ਹੇ ਸਟੋਰ ਜੋੜੋ—ਪਰ ਹਮੇਸ਼ਾ ਇੱਕ ਸਪਸ਼ਟ ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ ਰੱਖੋ।