07 ਅਗ 2025·8 ਮਿੰਟ
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਨੇ ਕਿਵੇਂ ਕਾਰੋਬਾਰੀ ਐਪਸ ਦਾ ਬੈਕਬੋਨ ਬਣਿਆ
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸਾਂ ਦੀ ਸਾਫ਼ ਇਤਿਹਾਸ—Codd ਅਤੇ SQL ਤੋਂ ਲੈ ਕੇ ACID ਅਤੇ ERP ਤੱਕ—ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਉਂ ਇਹ ਜਿਆਦਾਤਰ ਕਾਰੋਬਾਰੀ ਐਪਸ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ ਅਤੇ ਕਿੱਥੇ ਇਹ ਅਸਫਲ ਹੁੰਦੇ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸਾਂ ਦੀ ਸਾਫ਼ ਇਤਿਹਾਸ—Codd ਅਤੇ SQL ਤੋਂ ਲੈ ਕੇ ACID ਅਤੇ ERP ਤੱਕ—ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਉਂ ਇਹ ਜਿਆਦਾਤਰ ਕਾਰੋਬਾਰੀ ਐਪਸ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ ਅਤੇ ਕਿੱਥੇ ਇਹ ਅਸਫਲ ਹੁੰਦੇ ਹਨ।
"ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨ" ਉਹ ਕੋਈ ਵੀ ਸਿਸਟਮ ਹੈ ਜੋ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਕਾਰਜ ਚਲਾਉਂਦਾ ਹੈ: ਆਰਡਰ ਲੈਣਾ, ਇਨਵਾਇਸ ਜਾਰੀ ਕਰਨਾ, ਗਾਹਕ ਟਰੈਕ ਕਰਨਾ, ਇਨਵੈਂਟਰੀ ਮੈਨੇਜ ਕਰਨਾ, ਵੇਂਡਰਾਂ ਨੂੰ ਭੁਗਤਾਨ ਕਰਨਾ ਅਤੇ ਪਿਛਲੇ ਹਫ਼ਤੇ (ਜਾਂ ਅੱਜ ਸਵੇਰੇ) ਜੋ ਕੁਝ ਹੋਇਆ ਉਸ ਦੀ ਰਿਪੋਰਟਿੰਗ। ਚਾਹੇ ਇਹ ERP ਸਿਸਟਮ ਹੋਵੈ ਜੋ ਖਰੀਦਦਾਰੀ ਅਤੇ ਫਾਇਨੈਂਸ ਸੰਭਾਲਦਾ ਹੈ ਜਾਂ CRM ਸਾਫਟਵੇਅਰ ਜੋ ਸੇਲਜ਼ ਦੀ ਗਤਿਵਿਧੀ ਨੇ ਸੰਗਠਿਤ ਕਰਦਾ ਹੈ, ਇਹਨਾਂ ਐਪਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਲੋੜ ਚਾਹੀਦੀ ਹੈ: ਨੰਬਰ ਅਤੇ ਰਿਕਾਰਡ ਹਕੀਕਤ ਨਾਲ ਮੈਚ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਟੇਬਲਾਂ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ—ਸੋਚੋ ਕਠੋਰ ਨਿਯਮਾਂ ਵਾਲੀਆਂ spreadsheets। ਹਰ ਟੇਬਲ ਵਿੱਚ ਕਤਾਰਾਂ (ਰਿਕਾਰਡ) ਅਤੇ ਕਾਲਮ (ਫੀਲਡ ਜਿਵੇਂ ਗਾਹਕ ਨਾਮ, ਆਰਡਰ ਦੀ ਤਾਰੀਖ, ਜਾਂ ਕੀਮਤ) ਹੁੰਦੇ ਹਨ। ਟੇਬਲਾਂ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਕੁੰਜੀਆਂ ਰਾਹੀਂ ਜੁੜਦੀਆਂ ਹਨ: Customers ਟੇਬਲ ਵਿੱਚ ਗਾਹਕ ID ਨੂੰ Orders ਟੇਬਲ ਰਾਹੀਂ ਰੇਫਰੈਂਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਜੋ ਸਿਸਟਮ ਜਾਣ ਸਕੇ ਕਿ ਕਿਹੜੇ ਆਰਡਰ ਕਿਸ ਗਾਹਕ ਦੇ ਹਨ।
ਇਹ ਢਾਂਚਾ ਸਧਾਰਨ ਲਗਦਾ ਹੈ, ਪਰ ਇਹ ਤਾਕਤਵਰ ਹੈ: ਇਹ ਕਾਰੋਬਾਰੀ ਐਪ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਾਟਾ ਸੁਗੰਢੀ ਰੱਖਣ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇਸਨੂੰ ਛੂਹ ਰਹੀਆਂ ਹੋਣ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਕੁਝ Praktical ਕਾਰਨਾਂ ਕਰਕੇ ਮਿਆਰੀ ਨਿਰਦੇਸ਼ ਬਣ ਗਏ:
ਰਿਲੇਸ਼ਨਲ ਸਿਸਟਮਾਂ ਦੀਆਂ ਕੁਝ ਖਾਸ ਤਾਕਤਾਂ ਹਨ—ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਡੇਟਾ ਇੰਟੇਗ੍ਰਿਟੀ ਅਤੇ ਭਰੋਸੇਯੋਗ ਲੈਨਦੇਨ—ਪਰ ਉਨ੍ਹਾਂ ਦੀਆਂ ਕੁਝ ਸੁਝਾਵਾਂ ਵੀ ਹਨ ਲਚਕੀਲੇਪਣ ਅਤੇ ਸਕੇਲਿੰਗ ਵਿੱਚ। ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਉਹ ਕਿਵੇਂ classic OLTP ਕੰਮ ਲਈ ਚੰਗੇ ਹਨ, ਕਿੱਥੇ ਵਿਕਲਪ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ managed cloud ਡੇਟਾਬੇਸ ਅਤੇ ਨਵੀਆਂ ਡੇਟਾ ਲੋੜਾਂ ਨਾਲ ਕੀ ਬਦਲ ਰਿਹਾ ਹੈ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਆਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਜਿਆਦਾਤਰ ਕਾਰੋਬਾਰੀ ਡੇਟਾ ਫਾਈਲਾਂ ਦੇ ਪੈਚਵਰਕ ਵਿੱਚ ਰਹਿੰਦਾ ਸੀ: ਸਾਂਝੇ ਡ੍ਰਾਈਵਾਂ 'ਤੇ spreadsheets, ਐਕਾਊਂਟਿੰਗ ਟੂਲਾਂ ਤੋਂ exported flat text ਫਾਈਲਾਂ ਅਤੇ ਵੇਂਡਰ ਜਾਂ ਇਨ-ਹਾਊਸ ਡਿਵੈਲਪਰਾਂ ਵੱਲੋਂ ਬਣੇ ਕਸਟਮ ਫਾਰਮੇਟ।
ਇਹ ਛੋਟੀ ਕੰਪਨੀ ਲਈ ਅਤੇ ਜਦੋਂ ਸਿਰਫ ਕੁਝ ਲੋਕਾਂ ਨੂੰ ਐਕਸੈਸ ਚਾਹੀਦਾ ਸੀ ਤਾਂ ਚੱਲਦਾ ਸੀ। ਪਰ ਜਦੋਂ ਸੇਲਜ਼, ਫਾਇਨੈਂਸ ਅਤੇ ਓਪਰੇਸ਼ਨ ਇੱਕੋ ਜਾਣਕਾਰੀ 'ਤੇ ਨਿਰਭਰ ਹੋ ਗਏ, ਫਾਈਲ-ਆਧਾਰਤ ਸਟੋਰੇਜ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਸਾਹਮਣੇ ਆਈਆਂ।
ਕਈ ਸੰਗਠਨਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਸੀ:
ਸਭ ਤੋਂ ਵੱਡੀ ਸਮੱਸਿਆ ਸਿਰਫ਼ ਅਸਵਿਧਾ ਨਹੀਂ ਸੀ—ਇਹ ਭਰੋਸਾ ਸੀ। ਨਕਲ ਕੀਤਾ ਡੇਟਾ ਹਰ ਜਗ੍ਹਾ ਸੀ: ਇਕੋ ਗਾਹਕ ਤਿੰਨ ਵਾਰੀ ਹਲਕੇ ਤਫ਼ਾਅਤਾਂ ਨਾਲ ਨਾਂ, ਠਿਕਾਣਾ ਜਾਂ ਭੁਗਤਾਨ ਦੀਆਂ ਸ਼ਰਤਾਂ ਨਾਲ ਨਜ਼ਰ ਆ ਸਕਦਾ ਸੀ।
ਅਪਡੇਟ ਇਕਸਾਰ ਨਹੀਂ ਸਨ ਕਿਉਂਕਿ ਇਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਸੀ ਕਿ ਲੋਕ ਹਰ ਨਕਲ ਨੂੰ ਯਾਦ ਰੱਖ ਕੇ ਬਦਲਣ। ਇੱਕ ਨਵਾਂ ਫ਼ੋਨ ਨੰਬਰ sales spreadsheet ਵਿੱਚ ਅਪਡੇਟ ਹੋ ਸਕਦਾ ਸੀ ਪਰ billing ਵਿੱਚ ਨਹੀਂ, ਜਿਸ ਕਾਰਨ ਭੁਗਤਾਨ ਜਾਂ ਸ਼ਿਪਮੈਂਟ ਦਿੱਲੇ ਹੋ ਸਕਦੇ ਸਨ।
ਰਿਪੋਰਟਿੰਗ ਮੁਸ਼ਕਲ ਸੀ ਕਿਉਂਕਿ ਫਾਈਲਾਂ ਓਹ ਸਵਾਲ ਨਹੀਂ ਪੁੱਛਣ ਲਈ ਬਣੀਆਂ ਜਿਵੇਂ “ਕਿਹੜੇ ਗਾਹਕ overdue ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸ਼ੁਰੂ ਹੋਏ ਆਰਡਰ ਵੀ ਹਨ?” ਜਵਾਬ ਮੁਅੱਥਕ ਮੈਨੁਅਲ ਖੋਜ, ਲੰਮੇ spreadsheet ਫਾਰਮੂਲੇ ਜਾਂ ਕਸਟਮ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਮਿਲਦਾ ਜੋ ਫਾਈਲ ਲੇਆਊਟ ਬਦਲਣ 'ਤੇ ਟੁੱਟ ਜਾਂਦੇ।
ਫਾਈਲ concurrent edits ਨੂੰ ਚੰਗਾ handle ਨਹੀਂ ਕਰਦੀਆਂ। ਦੋ ਲੋਕ ਇੱਕੋ ਰਿਕਾਰਡ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਤਾਂ ਉਹ ਇਕ ਦੂਜੇ ਨੂੰ ਓਵਰਰਾਇਟ ਕਰ ਸਕਦੇ ਸਨ, ਅਤੇ ਫਾਈਲ ਨੂੰ "ਲਾਕ" ਕਰਨਾ ਅਕਸਰ ਬਾਕੀ ਸਾਰਿਆਂ ਲਈ ਰੁਕਾਵਟ ਹੁੰਦਾ ਸੀ। ਨੈਟਵਰਕ 'ਤੇ ਫਾਈਲਾਂ ਵੱਧਣ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਵੀ ਘਟਦਾ ਸੀ।
ਕੰਪਨੀਆਂ ਨੂੰ ਇੱਕ ਸਾਂਝਾ source of truth ਚਾਹੀਦਾ ਸੀ ਜਿਸ ਵਿੱਚ ਨਿਯਮ ਹੋਣ (ਤاکہ ਡੇਟਾ ਵੈਧ ਰਹੇ) ਅਤੇ ਭਰੋਸੇਯੋਗ ਅਪਡੇਟ ਹੋਣ (ਤਾਂ ਜੋ ਬਦਲਾਅ ਜਾਂ ਤਾਂ ਪੂਰਾ ਹੋਵੇ ਜਾਂ ਨਹੀਂ ਹੋਵੇ)। ਇਹ ਦਬਾਅ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਲਈ ਮੰਚ ਸੈਟ ਕਰਦਾ ਸੀ—ਅਤੇ “ਲਿਖਤਾਂ ਵਿੱਚ ਡੇਟਾ” ਤੋਂ “ਮੈਨੇਜਡ ਸਿਸਟਮ ਵਜੋਂ ਡੇਟਾ” ਵੱਲ ਦਾ ਬਦਲਾਅ।
1970 ਵਿੱਚ, IBM ਦੇ ਸ਼ੋਧਕਰਤਾ Edgar F. “Ted” Codd ਨੇ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤਾ—ਇਹ ਐਸਾ ਖ਼ਿਆਲ ਸੀ ਜਿਸ ਨੇ ਕੰਪਨੀਆਂ ਦੇ ਡੇਟਾ ਸਟੋਰ ਕਰਨ ਅਤੇ ਵਰਤਣ ਦੇ ਢੰਗ ਨੂੰ ਬਦਲ ਦਿੱਤਾ। ਬ੍ਰੇਕਥਰੂ ਕੋਈ ਨਵਾਂ ਸਟੋਰੇਜ ਡਿਵਾਈਸ ਜਾਂ ਤੇਜ਼ ਕੰਪਿਊਟਰ ਨਹੀਂ ਸੀ—ਇਹ ਡੇਟਾ ਬਾਰੇ ਸੋਚਣ ਦਾ ਇੱਕ ਸਧਾਰਨ ਢੰਗ ਸੀ ਤਾਂ ਜੋ ਇਸਨੂੰ ਮੁਹੱਈਆ ਅਤੇ ਸੰਗਠਿਤ ਰੱਖਿਆ ਜਾ ਸਕੇ ਜਿਵੇਂ ਕਾਰੋਬਾਰ ਦੀਆਂ ਲੋੜਾਂ ਬਦਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਦੇ ਕੇਂਦਰ ਵਿੱਚ ਇੱਕ ਸਧਾਰਣ ਸੰਕਲਪ ਹੈ: ਜਾਣਕਾਰੀ ਨੂੰ relations ਵਿੱਚ ਆਯੋਜਿਤ ਕਰੋ, ਜੋ ਅੱਜਕੱਲ੍ਹ ਲੋਕਾਂ ਵੱਲੋਂ ਆਮ ਤੌਰ 'ਤੇ ਟੇਬਲਾਂ ਵਜੋਂ ਸਮਝੀ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਟੇਬਲ ਵਿੱਚ ਕਤਾਰਾਂ (ਰਿਕਾਰਡ) ਅਤੇ ਕਾਲਮ (ਫੀਲਡ) ਹੁੰਦੇ ਹਨ। ਗਾਹਕ ਇੱਕ ਟੇਬਲ ਵਿੱਚ, ਇਨਵਾਇਸਾਂ ਦੂਜੇ ਵਿੱਚ, ਉਤਪਾਦ ਤੀਜੇ ਵਿੱਚ।
ਇਸਦੀ ਤਾਕਤ ਸਿਰਫ ਟੇਬਲ ਫਾਰਮੈਟ ਨਹੀਂ ਸੀ—ਉਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਨਿਯਮ ਸਨ:
ਇਹ ਢਾਂਚਾ ਡੇਟਾ ਨੂੰ ਵੈਧਤਾ ਨਾਲ ਬਰਕਰਾਰ ਰੱਖਣਾ, ਇੱਕੱਠਾ ਕਰਨਾ ਅਤੇ ਗਲਤੀ ਨਾਲ ਟਕਰਾਅ ਘੱਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਪਹਿਲਾਂ ਦੇ ਸਿਸਟਮ ਅਕਸਰ ਬਿਜ਼ਨਸ ਨਿਯਮ ਅਤੇ ਡੇਟਾ ਫਾਰਮੇਟ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਹੀ "ਬੇਕ" ਕਰ ਦਿੰਦੇ ਸਨ। ਜੇ ਤੁਸੀਂ ਸੋਫਟਵੇਅਰ ਬਦਲਿਆ ਤਾਂ ਫਾਈਲਾਂ ਦੇ ਪੜ੍ਹਨ ਦਾ ਢੰਗ ਟੁੱਟ ਸਕਦਾ ਸੀ। ਜੇ ਤੁਸੀਂ ਫਾਇਲ ਫਾਰਮੇਟ ਬਦਲਿਆ ਤਾਂ ਤੁਹਾਨੂੰ ਸੋਫਟਵੇਅਰ ਦਾ ਹਿੱਸਾ ਮੁੜ ਲਿਖਣਾ ਪੈਂਦਾ।
ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਇੱਕ ਸਾਫ ਵੱਖਰਾ ਕਰਦਾ ਹੈ: ਡੇਟਾਬੇਸ ਡੇਟਾ ਅਤੇ ਉਸਦੀ ਅਖੰਡਤਾ ਨੂੰ ਮੈਨੇਜ ਕਰਦਾ ਹੈ; ਐਪਲੀਕੇਸ਼ਨਾਂ ਪਰਿਭਾਸ਼ਿਤ ਓਪਰੇਸ਼ਨਾਂ ਰਾਹੀਂ ਡੇਟਾ ਮੰਗਦੀਆਂ ਹਨ ਅਤੇ ਅਪਡੇਟ ਕਰਦੀਆਂ ਹਨ।
ਇਹ ਵੱਖਰਾ ਕਰਨ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਕਾਰੋਬਾਰ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ। ਕੀਮਤਾਂ ਦੇ ਨਿਯਮ ਬਦਲਦੇ ਹਨ, ਗਾਹਕ ਫੀਲਡ ਵਿਕਸਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਦੀਆਂ ਲੋੜਾਂ ਵੱਧਦੀਆਂ ਹਨ। ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਨਾਲ ਕਈ ਬਦਲਾਵ ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਜਾਂ ਕਵੇਰੀਜ਼ ਵਿੱਚ ਹੋ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਪੂਰੇ ਐਪ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਏ।
ਜਦੋਂ ਡੇਟਾ ਟੇਬਲਾਂ ਵਿੱਚ ਇੱਕਸਾਰ ਨਿਯਮਾਂ ਨਾਲ ਸਟੋਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਜ਼ਿਆਦਾ ਪੋਰਟਬਲ ਅਤੇ ਟਿਕਾਊ ਬਣ ਜਾਂਦਾ ਹੈ:
ਇਸੇ ਲਈ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਲਈ ਕੁਦਰਤੀ ਫਿੱਟ ਬਣ ਗਿਆ: ਇਸਨੇ ਗੰਦਾਗੀ, ਐਪ-ਖ਼ਾਸ ਡੇਟਾ ਨੂੰ ਇੱਕ ਵਿਵਸਥਿਤ ਸਿਸਟਮ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜੋ ਵੱਧਦੇ ਅਤੇ ਬਦਲਦੇ ਸਾਲਾਂ ਰਾਹੀਂ ਜੀਊ ਸਕਦਾ ਹੈ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਕਾਰੋਬਾਰਾਂ ਵਿੱਚ ਭਰੋਸਾ ਕਮਾ ਲਏ ਕਿਉਂਕਿ ਉਹ ਡੇਟਾ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ "ਪਹਚਾਣ" ਦਿੰਦੇ ਹਨ ਅਤੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਜੋੜਨ ਦਾ ਨਿਯੰਤ੍ਰਿਤ ਤਰੀਕਾ ਮੁਹੱਈਆ ਕਰਦੇ ਹਨ। ਉਹ ਪਛਾਣ就是 ਕੁੰਜੀ—ਅਤੇ ਜੁੜਨ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਹਨ ਰਿਸ਼ਤੇ।
ਇੱਕ ਪ੍ਰਾਈਮੇਰੀ ਕੀ ਟੇਬਲ ਦੀ ਇੱਕ ਕਤਾਰ ਨੂੰ ਯੂਨੀਕਲੀ ਪਛਾਣਦੀ ਹੈ। Customers ਟੇਬਲ ਵਿੱਚ ਇਹ ਹੋ ਸਕਦੀ ਹੈ CustomerID।
Customers(CustomerID, Name, Email)Orders(OrderID, CustomerID, OrderDate, Total)ਇੱਥੇ, CustomerID ਗਾਹਕ ਦੀ ਸਥਿਰ ਪਛਾਣ ਹੈ—ਇਹ ਕੋਈ ਬਦਲਣ ਵਾਲੀ ਚੀਜ਼ (ਜਿਵੇਂ ਨਾਂ) ਨਹੀਂ ਹੁੰਦੀ ਜਾਂ ਕੋਈ ਜੋ ਯੂਨੀਕ ਨਾ ਹੋਵੇ (ਜਿਵੇਂ ईਮੇਲ)।
ਫੌਰਿਨ ਕੀ ਇੱਕ ਫੀਲਡ ਹੁੰਦੀ ਹੈ ਜੋ ਦੂਜੇ ਟੇਬਲ ਦੀ ਪ੍ਰਾਈਮੇਰੀ ਕੀ ਨੂੰ ਰੇਫਰੈਂਸ ਕਰਦੀ ਹੈ। Orders ਵਿੱਚ CustomerID Customers.CustomerID ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਇਸ ਢਾਂਚੇ ਨਾਲ ਹਰ ਆਰਡਰ ਵਿੱਚ ਗਾਹਕ ਦੇ ਵੇਰਵੇ ਕੋਪੀਆਂ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਵਾਰੀ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਆਰਡਰ ਸਹੀ ਗਾਹਕ ਨਾਲ ਜੋੜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਟੇਬਲ ਕਿਵੇਂ ਜੁੜੇ ਹਨ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ join ਕਰਕੇ ਆਮ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਲੈ ਸਕਦੇ ਹੋ:
ਤੁਸੀਂ ਜੋابات ਕਵੇਰੀ ਸਮੇਂ ਮਿਲਦੇ ਹੋਏ ਪੋਰੇ ਨਤੀਜੇ ਪੈ ਸਕਦੇ ਹੋ ਬਜਾਏ ਇੱਕੋ ਤਥਿਆ ਨੂੰ ਕਈ ਥਾਵਾਂ 'ਤੇ ਰੱਖਣ ਦੇ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ referential integrity ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਨ: ਇੱਕ ਆਰਡਰ ਐਸਾ ਗਾਹਕ ਰੇਫਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੋ ਮੌਜੂਦ ਨਾ ਹੋਵੇ। ਇਹ ਔਰਫੈਨ ਰਿਕਾਰਡਾਂ (ਉਸ ਆਰਡਰ ਲਈ ਜੋ ਕਿਸੇ ਵੀ ਮਾਨਯੋਗ ਗਾਹਕ ਨੂੰ ਨਹੀਂ ਜੋੜਦਾ) ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਇਨ੍ਹਾਂ ਟੁੱਟੇ ਸਬੰਧਾਂ ਨੂੰ ਛੱਡਣ ਵਾਲੀਆਂ ਅਚਾਨਕ ਡਿਲੀਟਾਂ ਨੂੰ ਬਲੌਕ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਕੁੰਜੀਆਂ, ਰਿਸ਼ਤੇ ਅਤੇ ਇੰਟੇਗ੍ਰਿਟੀ ਨਿਯਮ ਲੱਗੇ ਹੋਣ, ਰਿਪੋਰਟਾਂ ਅਤੇ ਆਪਰੇਸ਼ਨਾਂ ਵਿੱਚ ਅੰਤਰ ਘਟ ਜਾਂਦਾ ਹੈ। ਟੋਟਲ ਕਾਪੀ ਹੋਣ ਕਾਰਨ ਨਹੀਂ ਹਿਲਦੇ, ਅਤੇ ਸਹਾਇਤਾ ਟੀਮਾਂ "ਰਹੱਸਮਈ ਗਲਤੀਆਂ" ਦੀ ਭੇਟ ਘੱਟ ਸਮਾਂ ਲੈਂਦੀਆਂ ਹਨ ਜੋ ਗਾਇਬ ਜਾਂ ਮਿਲਦੇ-ਜੁਲਦੇ IDs ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ।
Normalization ਅਸਲ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਉਣਾ ਹੈ ਤਾਂ ਜੋ ਇਕੋ ਤੱਥ ਕਈ ਥਾਵਾਂ 'ਤੇ ਨਾ ਰੱਖਿਆ ਜਾਵੇ। ਇਹ ਡਿਜ਼ਾਈਨ ਅਭਿਆਸ ਹੈ ਜੋ ਇਕੋ ਜਾਣਕਾਰੀ ਨੂੰ ਕਈ ਕਾਪੀਆਂ ਵਿੱਚ ਰੱਖਣ ਤੋਂ ਬਚਾਉਂਦਾ—ਕਿਉਂਕਿ ਹਰ ਕਾਪੀ ਇੱਕ ਹੋਰ ਮੌਕਾ ਹੈ ਕਿ ਉਹ ਸਿੰਕ ਤੋਂ ਹਟ ਸਕੇ।
ਕਲਪੋ ਕਿ ਇੱਕ ਕਾਰੋਬਾਰੀ ਐਪ ਆਰਡਰ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਜੇ ਹਰ ਆਰਡਰ ਰਿਕਾਰਡ ਵਿੱਚ ਗਾਹਕ ਦਾ ਪੂਰਾ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ ਸ਼ਾਮਿਲ ਹੈ, ਤਾਂ ਉਹ ਪਤਾ ਬਾਰ-ਬਾਰ ਦੁਹਰਾਇਆ ਜਾਵੇਗਾ। ਜਦੋਂ ਗਾਹਕ ਦਾ ਪਤਾ ਬਦਲੇ, ਕਿਸੇ ਨੂੰ ਹਰ ਪੁਰਾਣੇ ਅਤੇ ਭਵਿੱਖੀ ਆਰਡਰ ਰਿਕਾਰਡ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਪਵੇਗਾ (ਜਾਂ ਐਪ ਨੂੰ ਇਹ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਪਵੇਗਾ ਕਿ ਕਿਹੜੀਆਂ ਕਤਾਰਾਂ ਅਪਡੇਟ ਹੋਣ)। ਇੱਕ ਵੀ ਚੁੱਕੀ ਗਈ ਕਤਾਰ ਨਾਲ ਰਿਪੋਰਟਾਂ 'ਤੇ ਇੱਕੋ ਗਾਹਕ ਲਈ ਦੋ ਵੱਖ-ਵੱਖ ਸਚਾਈ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ।
Normalization ਦੇ ਨਾਲ, ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਗਾਹਕ ਦਾ ਪਤਾ ਇੱਕ ਵਾਰੀ Customers ਟੇਬਲ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਫਿਰ ਹਰ ਆਰਡਰ CustomerID ਰਾਹੀਂ ਉਸਨੂੰ ਰੇਫਰ ਕਰਦਾ ਹੈ। ਹੁਣ ਇੱਕ ਜਗ੍ਹਾ 'ਤੇ ਅਪਡੇਟ ਕਰਨ ਨਾਲ ਸਾਰਿਆਂ 'ਤੇ ਅਸਰ ਪੈਂਦਾ ਹੈ।
ਕੁਝ ਬਿਲਡਿੰਗ ਬਲਾਕ ਜ਼ਿਆਦਾਤਰ ਕਾਰੋਬਾਰੀ ਸਿਸਟਮਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦੇਂਦੇ ਹਨ:
order_status ਜਿਸ ਵਿੱਚ “Pending,” “Shipped,” “Cancelled”)। ਇਹ ਟਾਈਪੋ ਘਟਾਉਂਦੇ ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਕਰਦੇ ਹਨ।OrderItems ਟੇਬਲ ਉਹਨਾਂ ਨੂੰ ਸੁਚੱਜੇ ਤਰੀਕੇ ਨਾਲ ਜੋੜਦੀ ਹੈ।ਜ਼ਿਆਦਾ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀਪਣ ਵਧਾਉਂਦੀ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਟੇਬਲਾਂ ਅਤੇ ਜ਼ਿਆਦਾ joins ਹੋ ਸਕਦੇ ਹਨ। ਅਧਿਕ ਨਾਰਮਲਾਈਜ਼ ਕਰਨ ਨਾਲ ਕੁਝ ਕੁਏਰੀਆਂ ਲਿਖਣ ਲਈ ਔਖੇ ਅਤੇ ਚਲਾਉਣ ਵਿੱਚ ਹੌਲੀ ਹੋ ਸਕਦੀਆਂ ਹਨ—ਇਸ ਲਈ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ "ਸਾਫ਼ ਢਾਂਚਾ" ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਲੋੜਾਂ ਦੇ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸਾਂ ਨੇ ਸਿਰਫ ਡੇਟਾ ਨੂੰ ਸੁਗੰਢੀ ਤਰ੍ਹਾਂ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ—ਉਨ੍ਹਾਂ ਨੇ ਉਹਨੂੰ ਇੱਕ ਆਮ ਤਰੀਕੇ ਨਾਲ ਪੁੱਛਣਯੋਗ ਵੀ ਬਣਾਇਆ। SQL (Structured Query Language) ਨੇ ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਦਿੱਤੀ ਤਾਂ ਜੋ ਉਹ ਟੇਬਲਾਂ ਵਿੱਚੋਂ ਜਵਾਬ ਬਿਨਾਂ ਹਰ ਨਵੀਂ ਰਿਪੋਰਟ ਲਈ ਕਸਟਮ ਪ੍ਰੋਗਰਾਮ ਬਣਾਉਣ ਦੇ ਲੈ ਸਕਣ।
SQL ਦੇ ਵਿਆਪਕ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਡੇਟਾ ਕੁਐਰੀ ਕਰਨਾ ਅਕਸਰ ਵੇਂਡਰ-ਖ਼ਾਸ ਕਮਾਂਡਾਂ ਜਾਂ ਇੱਕ-ਵਾਰ ਦੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਹੁੰਦਾ ਸੀ ਜੋ ਸਿਰਫ ਕੁਝ ਲੋਕ ਸਮਝਦੇ ਸਨ। ਇੱਕ ਮਿਆਰੀ ਕੁਐਰੀ ਭਾਸ਼ਾ ਨੇ ਇਹ ਬਦਲ ਦਿੱਤਾ। ਵਿਸ਼ਲੇਸ਼ਕ, ਡਿਵੈਲਪਰ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਟੂਲ ਸਾਰਿਆਂ ਨੇ ਇੱਕੋ ਭਾਸ਼ਾ ਗੱਲ-ਬਾਤ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ।
ਇਸ ਮਿਆਰੀਕਰਨ ਨਾਲ ਟੀਮਾਂ ਵਿਚਕਾਰ friction ਘਟਿਆ। ਇਕ ਫਾਇਨੈਂਸ ਲਈ ਲਿਖੀ ਕੁਐਰੀ operations ਵੱਲੋਂ ਵਰਤੀ ਜਾ ਸਕਦੀ ਸੀ। ਇੱਕ ਰਿਪੋਰਟਿੰਗ ਟੂਲ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸਾਂ ਨਾਲ ਘੱਟ ਬਦਲਾਅ ਨਾਲ ਜੁੜ ਸਕਦਾ ਸੀ। ਸਮੇਂ ਦੇ ਨਾਲ, SQL ਹੁਨਰ ਨੌਕਰੀਆਂ ਅਤੇ ਉਦਯੋਗਾਂ ਵਿੱਚ transferable ਹੋ ਗਏ—ਜਿਸ ਨਾਲ ਇਹ ਹੋਰ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਿਆ।
SQL ਆਪਣੀ ਤਾਂਯਾਰੀ ਵਜੋਂ ਉਹਨਾਂ ਵਾਸਤੇ ਫ਼ਾਇਦੇਮੰਦ ਹੈ ਜੋ ਹਕੀਕਤ ਵਿੱਚ ਕਾਰੋਬਾਰੀ ਸਵਾਲ ਹਨ:
ਇਹ ਨਿਯਮਤ ਪ੍ਰਸ਼ਨ ਮੂਲ ਤੌਰ 'ਤੇ ਫਿਲਟਰਿੰਗ, ਗਰੁੱਪਿੰਗ, ਅਤੇ ਕੁਨੈਕਟ ਕੀਤੇ ਡੇਟਾ ਦੇ ਜੁੜਨ ਬਾਰੇ ਹਨ—ਬਿਲਕੁਲ ਉਸੇ ਕੰਮ ਲਈ ਜਿਸਨੂੰ SQL ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ।
ਜਿਵੇਂ ਜਿਵੇਂ SQL ਆਮ ਹੋਇਆ, ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕ ecosystem ਬਣੀ: BI ਡੈਸ਼ਬੋਰਡ, ਨਿਯਤ ਰਿਪੋਰਟ, spreadsheet ਕਨੈਕਟਰ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਡੇਟਾ ਵేర్-ਹਾਊਸ ਅਤੇ ETL ਟੂਲ। ਭਾਵੇਂ ਕਈ ਕੰਪਨੀਆਂ ਨੇ ਵਿਸ਼ੇਸ਼ਤ.analytics ਸਿਸਟਮ ਜੋੜੇ, SQL ਅਕਸਰ operational ਡੇਟਾ ਅਤੇ ਫੈਸਲਾ ਲੈਣ ਵਿੱਚ ਸੇਤੂ ਵਜੋਂ ਰਹਿੰਦਾ — ਕਿਉਂਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਉਹ ਭਾਸ਼ਾ ਸੀ ਜਿਸ 'ਤੇ ਹਰ ਕੋਈ ਭਰੋਸਾ ਕਰਦਾ ਸੀ।
ਜਦੋਂ ਕੋਈ ਕਾਰੋਬਾਰੀ ਐਪ "ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ" ਹੁੰਦਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲ ਸਕਦਾ—ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਪੈਸਾ, ਇਨਵੈਂਟਰੀ ਅਤੇ ਗਾਹਕ ਦੀਆਂ ਵਚਨਾਂ ਸ਼ਾਮਿਲ ਹੋਣ।
ਕਲਪੋ ਇੱਕ ਆਨਲਾਈਨ ਆਰਡਰ:
ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਸਾਰੇ ਅਪਡੇਟ ਇੱਕ ਯੂਨਿਟ ਵਜੋਂ ਸੰਬੰਧਿਤ ਹਨ। ਜੇ ਕੁਝ ਅਧੂਰਾ ਰਹਿ ਜਾਂਦਾ (ਭੁਗਤਾਨ ਰੱਦ, ਸਿਸਟਮ crash, out-of-stock), ਡੇਟਾਬੇਸ ਰੋਲਬੈਕ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਆਪਣੀਆਂ ਫਾਇਲਾਂ ਨੂੰ ਸਾਫ਼ ਰਹਿਤੇ ਹੋ — ਕੋਈ “ਭੁਗਤਾਨ ਹੋ ਗਿਆ ਪਰ ਆਰਡਰ ਨਹੀਂ” ਜਾਂ ਨੈਗਟਿਵ ਸਟਾਕ ਨਹੀਂ।
ਕਾਰੋਬਾਰ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਪਲੇਟਫਾਰਮ ACID ਵਿਹਾਰ ਸਪੋਰਟ ਕਰਦੇ ਹਨ—ਪ੍ਰਿਕਾਰ ਦੇ ਸਧਾਰਨ ਨਿਯਮ ਜੋ ਮੁੱਖ ਰਿਕਾਰਡਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੱਖਦੇ ਹਨ:
ਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਵਿੱਚ, ਕਈ ਲੋਕ ਇਕੱਠੇ ਕੰਮ ਕਰਦੇ ਹਨ: sales reps quotes ਬਣਾਉਂਦੇ, ਵਅਰਹਾਊਸ ਸਟਾਫ਼ ਪਿਕ ਕਰਦਾ, ਫਾਇਨੈਂਸ ਬੁੱਕ ਬੰਦ ਕਰਦਾ, ਸਪੋਰਟ ਰੀਫੰਡ ਜਾਰੀ ਕਰਦਾ। ਬਿਨਾਂ ਮਜ਼ਬੂਤ concurrency ਕੰਟਰੋਲ ਦੇ, ਦੋ ਲੋਕ ਇੱਕੋ ਆਖਰੀ ਆਈਟਮ ਵੇਚ ਸਕਦੇ ਹਨ ਜਾਂ ਇਕ ਦੂਜੇ ਦੀਆਂ ਐਡੀਟਸ ਓਵਰਰਾਇਟ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਡੇਟਾ ਇੰਟੈਗ੍ਰਿਟੀ ਪ੍ਰਯੋਗਿਕ ਨਤੀਜਾ ਹੈ: ਫਾਇਨੈਂਸ ਟੋਟਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਇਨਵੈਂਟਰੀ ਗਿਣਤੀ ਅਸਲਤਾ ਨਾਲ ਮਿਲਦੀ ਹੈ, ਅਤੇ ਕੰਪਲਾਇੰਸ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਇਹ ਦਰਜ ਰਹਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਕਦੋਂ ਅਤੇ ਕਿਵੇਂ ਬਦਲਿਆ ਗਿਆ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ RDBMS ਆਮ ਤੌਰ 'ਤੇ "system of record" ਡੇਟਾ ਲਈ ਡਿਫੌਲਟ ਚੋਣ ਬਣੇ ਰਹਿੰਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਕਾਰੋਬਾਰੀ ਐਪਾਂ ਦਾ ਲੱਖਾ ਇਹ ਨਹੀਂ ਹੁੰਦਾ ਕਿ "ਪਿਛਲੇ ਤਿਮਾਹੀ ਵਿੱਚ ਕੀ ਹੋਇਆ?" ਹਰ ਵਾਰੀ ਜਦੋਂ ਕੋਈ ਬਟਨ ਦਬਾਏ। ਓਹਨਾਂ ਦਾ ਮਕਸਦ ਸਧਾਰਣ, ਬਾਰੰਬਾਰ ਕੰਮ ਕਰਨਾ ਹੈ: ਇਕ ਇਨਵਾਇਸ ਬਣਾਉਣਾ, ਸ਼ਿਪਮੈਂਟ ਸਥਿਤੀ ਅਪਡੇਟ ਕਰਨਾ, ਇਨਵੈਂਟਰੀ ਰਿਜਰਵ ਕਰਨਾ, ਜਾਂ ਭੁਗਤਾਨ ਦਰਜ ਕਰਨਾ। ਇਹ ਨਮੂਨਾ ਕਿਹਾ ਜਾਂਦਾ ਹੈ OLTP (Online Transaction Processing)—ਕਈ ਛੋਟੇ ਪੜ੍ਹਨ/ਲਿਖਣ ਕਾਰਜ ਕਈ ਯੂਜ਼ਰਾਂ ਵੱਲੋਂ ਧੁਪ ਵਿੱਚ।
OLTP ਵਿੱਚ ਲਕਸ਼ ਤੇਜ਼, ਇਕਸਾਰ ਇੰਟਰਐਕਸ਼ਨ ਹੁੰਦੇ ਹਨ: “ਇਸ ਗਾਹਕ ਨੂੰ ਲੱਭੋ,” “ਇਹ ਲਾਈਨ ਆਈਟਮ ਜੋੜੋ,” “ਇਸ ਆਰਡਰ ਨੂੰ ਪੇਡ ਮਾਰਕ ਕਰੋ।” ਕੁਏਰੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾ ਦੇ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ ਨੂੰ ਛੂਹਦੀਆਂ ਹਨ ਅਤੇ ਜਲਦੀ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ।
ਵਿਸ਼ਲੇਸ਼ਣ ਵਰਕਲੋਡ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: ਘੱਟ ਕੁਐਰੀਆਂ ਪਰ ਉਹ ਭਾਰੀ ਹੁੰਦੀਆਂ ਹਨ—ਏਗਰੀਗੇਸ਼ਨ, ਲੰਮੇ ਸਕੈਨ ਅਤੇ ਵੱਡੇ ਰੇਂਜ 'ਤੇ joins। ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਗਠਨ OLTP ਨੂੰ RDBMS ਵਿੱਚ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਵੱਖਰੇ ਸਿਸਟਮ ਜਾਂ ਰੀਪਲਿਕਾਸ ਵਰਤਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਦੈਨੀਕ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸ্লੋ ਨਾ ਕੀਤਾ ਜਾਵੇ।
ਇੱਕ ਇੰਡੈਕਸ ਇੱਕ ਟੇਬਲ ਲਈ ਸਾਰਣੀ-ਸੂਚਕ ਵਾਂਗ ਹੈ। customer_id = 123 ਲੱਭਣ ਲਈ ਬਿਨਾਂ ਹਰ ਕਤਾਰ ਨੂੰ ਸਕੈਨ ਕਰਨ ਦੇ, ਡੇਟਾਬੇਸ ਸਿੱਧਾ ਮੈਚਿੰਗ ਕਤਾਰਾਂ 'ਤੇ ਜਾ ਸਕਦਾ ਹੈ।
ਟਰੇਡ-ਆਫ: ਇੰਡੈਕਸਾਂ ਨੂੰ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ। ਹਰ insert/update ਲਈ ਇੱਕ ਜਾਂ ਵਧੇਰੇ ਇੰਡੈਕਸ ਵੀ ਅਪਡੇਟ ਹੋ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਬਹੁਤੇ ਇੰਡੈਕਸ ਲਿਖਣ ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਸਟੋਰੇਜ ਵਧਾ ਸਕਦੇ ਹਨ। ਕਲਾ ਇਹ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਇੰਡੀਕਸ ਕਰੋ ਜੋ ਤੁਸੀਂ ਸਭ ਤੋਂ ਵੱਧ ਖੋਜਦੇ ਅਤੇ join ਕਰਦੇ ਹੋ।
ਜਿਵੇਂ ਹੀ ਡੇਟਾ ਅਤੇ ਟਰਾਫਿਕ ਵਧਦੇ ਹਨ, ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਕਵੇਰੀ ਪਲੇਨਿੰਗ (ਕੁਐਰੀ ਨੂੰ ਚਲਾਉਣ ਦੇ ਮੁਕਾਬਲੇ ਵਿੱਚ ਕੁशल ਰਸਤਾ ਚੁਨਣਾ), ਕੰਸਟਰੇਂਟ (ਡੇਟਾ ਨੂੰ ਵੈਧ ਰੱਖਣਾ) ਅਤੇ ਐਸੀਓਪੀਰੇਸ਼ਨਲ ਟੂਲ ਜਿਵੇਂ ਬੈਕਅੱਪ ਅਤੇ point-in-time recovery ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ। ਇਹ "ਬੋਰਿੰਗ" ਫੀਚਰ ਅਕਸਰ ਉਹਨਾਂ ਗੱਲਾਂ ਹਨ ਜੋ ਦੈਨੀਕ ਸਿਸਟਮਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੱਖਦੇ ਹਨ ਜਦੋਂ ਉਹ ਵਧ ਰਹੇ ਹੁੰਦੇ ਹਨ।
ਫਿਲਟਰ/ਜੋਇਨ 'ਤੇ missing index ਸਭ ਤੋਂ ਕਲਾਸਿਕ ਸਮੱਸਿਆ ਹੈ: 10k ਕਤਾਰਾਂ 'ਤੇ ਤੇਜ਼ ਪੰਨਾ 10M 'ਤੇ ਸਲੋ ਹੋ ਸਕਦਾ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਪੈਟਰਨ ਵੀ ਮਹੁੱਤਵਪੂਰਨ ਹਨ। N+1 ਕੁਐਰੀਜ਼ (ਇਕ ਕੰਮਸੂਚੀ ਲਈ ਇੱਕ ਕੁਐਰੀ, ਫਿਰ ਹਰ ਆਈਟਮ ਲਈ ਇੱਕ ਕੁਐਰੀ ਹੋਰ) ਡੇਟਾਬੇਸ ਨੂੰ ਓਵਰਹੈਲਮ ਕਰ ਸਕਦੇ ਹਨ। ਅਤੇ ਬੇਵਜਹ ਬਹੁਤੇ ਟੇਬਲ join ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਬੇਕਾਰ ਕੰਮ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਕੁਐਰੀਆਂ ਨੂੰ ਮਕਸਦ ਭਰਿਆ ਰੱਖਣਾ ਅਤੇ ਉਤਪਾਦਨ-ਨੁਮਾ ਡੇਟਾ ਨਾਲ ਅੰਕੜੇ ਮਾਪਣਾ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਫਾਇਦੇ ਦਿੰਦਾ ਹੈ।
ERP ਅਤੇ CRM ਨੇ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸਾਂ ਨੂੰ ਸਿਰਫ਼ ਲੋਕਪ੍ਰਿਯ ਹੋਣ ਕਰਕੇ ਨਹੀਂ ਗ੍ਰਹਿ ਕੀਤਾ—ਉਹਨਾਂ ਨੂੰ ਉਹ consistency ਚਾਹੀਦੀ ਸੀ ਜੋ ਟੇਬਲਾਂ, ਕੁੰਜੀਆਂ ਅਤੇ ਰਿਸ਼ਤਿਆਂ ਤਿਆਰ ਕਰਨ ਲਈ ਬਣਾਏ ਗਏ ਨਿਯਮ ਮੁਹੱਈਆ ਕਰਦੇ ਹਨ।
ਅਧਿਕাংশ ਮੁੱਖ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਢਾਂਚਾਬੱਧ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਹੁੰਦੀਆਂ ਹਨ: ਇੱਕ ਗਾਹਕ ਆਰਡਰ ਕਰਦਾ ਹੈ, ਇੱਕ ਇਨਵਾਇਸ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਭੁਗਤਾਨ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਚੀਜ਼ਾਂ ਚੁਣੀਆਂ, ਭੇਜੀਆਂ ਅਤੇ ਵਾਪਸ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਹਰ ਕਦਮ ਕੁਦਰਤੀ ਰੂਪ ਨਾਲ ਐਹੇ ਐਨਟਿਟੀਜ਼ ਨੂੰ ਟੇਬਲਾਂ ਵਿੱਚ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ—ਗਾਹਕ, ਉਤਪਾਦ, ਇਨਵਾਇਸ, ਭੁਗਤਾਨ, ਕਰਮਚਾਰੀ, ਸਥਾਨ।
ਰਿਲੇਸ਼ਨਲ ਡਿਜ਼ਾਈਨ ਨਾਲ ਵੀ ਅੰਤਰ-ਜਾਂਚ ਸਧਾਰਣ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਇਨਵਾਇਸ ਮੌਜੂਦ ਗਾਹਕ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਹੋ ਸਕਦਾ; ਇੱਕ ਸ਼ਿਪਮੈਂਟ ਲਾਈਨ ਇੱਕ ਅਸਲੀ ਉਤਪਾਦ ਨੂੰ ਰੇਫਰ ਕਰੇ; ਇੱਕ ਭੁਗਤਾਨ ਇੱਕ ਇਨਵਾਇਸ ਨਾਲ ਜੋੜਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ERP ਸਿਸਟਮ (ਫਾਇਨੈਂਸ, ਪ੍ਰੋ큐ਰਮੈਂਟ, ਇਨਵੈਂਟਰੀ) ਅਤੇ CRM ਸਾਫਟਵੇਅਰ (ਅਕਾਊਂਟਸ, contacts, opportunities, support cases) ਇਨ੍ਹਾਂ "ਇਹ ਇਸ ਨਾਲ ਜੁੜਨਾ ਚਾਹੀਦਾ ਹੈ" ਨਿਯਮਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਟੀਮਾਂ ਦੇ ਵਿਚਕਾਰ ਰਿਕਾਰਡ ਸੰਗਠਿਤ ਰਹਿਣ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਸੰਸਥਾਵਾਂ ਵਧੀਆਂ, ਉਨ੍ਹਾਂ ਨੂੰ ਚੋਣ ਦਾ ਸਾਹਮਣਾ ਹੋਇਆ:
ਕੋਈ ਵੀ ਤਰੀਕਾ ਹੋਵੇ, ਸਪਸ਼ਟ ਸਕੀਮਾਂ ਤੋਂ ਲਾਭ ਮਿਲਦਾ ਹੈ: ਜਦੋਂ ਫੀਲਡ ਅਤੇ ਰਿਸ਼ਤੇ ਸਪੱਸ਼ਟ ਹਨ, ਗਾਹਕ ID, ਉਤਪਾਦ ਕੋਡ ਅਤੇ ਅਕਾਊਂਟਿੰਗ ਡਾਇਮੈਨਸ਼ਨ ਨੂੰ ਸਿੰਕ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਬਿਨਾਂ ਹਮੇਸ਼ਾ ਮੈਨੁਅਲ ਫਿਕਸਾਂ ਦੇ।
ਜਦੋਂ ERP ਅਤੇ CRM ਵੇਂਡਰਾਂ ਨੇ ਰਿਲੇਸ਼ਨਲ ਨੀਵਾਂ ਅਪਣਾਇਆ, ਕਾਰੋਬਾਰਾਂ ਨੇ ਹੁਨਰਾਂ ਵਿੱਚ ਪੋਰਟੇਬਿਲਿਟੀ ਪ੍ਰਾਪਤ ਕੀਤੀ। SQL ਜਾਣਨ ਵਾਲਾ ਇਕ ਵਿਸ਼ਲੇਸ਼ਕ ਰਿਕਰੂਟ ਕਰਨਾ ਅਤੇ ਆਪਰੇਸ਼ਨ ਟੀਮ ਨੂੰ ਮਿਆਰੀ ਰਿਪੋਰਟ ਚਲਾਉਣ ਸਿਖਾਉਣਾ ਪ੍ਰੋਪਾਈਟਰੀ ਟੂਲ ਸਿਖਾਉਣ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਬਹੁਤ ਆਸਾਨ ਹੋ ਗਿਆ।
ਇਹ ਮਿਆਰੀਕਰਨ ਲੰਬੇ ਸਮੇਂ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦੀ: ਘੱਟ ਕਸਟਮ ਡੇਟਾ ਐਕਸਟ੍ਰੈਕਟ, ਜ਼ਿਆਦਾ reusable ਰਿਪੋਰਟਿੰਗ ਪੈਟਰਨ ਅਤੇ ਐਡਮਿਨ, ਕੰਸਲਟੈਂਟ ਅਤੇ ਅੰਦਰੂਨੀ ਟੀਮਾਂ ਵਿੱਚ ਸਧਾਰਨ ਹੈਂਡਆਫ। ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਲਈ ਇਹੀ ਗੱਲ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਨੂੰ ਤਕਨੀਕੀ ਚੋਣ ਤੋਂ ਔਪਰੇਸ਼ਨਲ ਡਿਫੌਲਟ ਵਿੱਚ ਬਦਲ ਅਤੇ ਬਣਾਉਂਦੀ ਗਈ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ صرف ਡੇਟਾ ਮਾਡਲ ਲਈ ਹੀ ਨਹੀਂ ਜਿੱਤਿਆ—ਉਹ ਇਸ ਲਈ ਵੀ ਫਿੱਟ ਸੀ ਕਿ ਓਪਰੇਸ਼ਨਲ ਤਰੀਕੇ ਜਿਵੇਂ ਨਿਯਮਤ ਬੈਕਅੱਪ, ਯੂਜ਼ਰ ਰੋਲ, ਸਿਸਟਮ ਕੈਟਲੌਗ, ਲੌਗ ਅਤੇ ਸੰਦ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਉਪਲਬਧ ਰਹੇ। ਇਹਨਾਂ ਨਾਲ ਕਾਰੋਬਾਰੀ ਡੇਟਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਰੱਖਣਾ ਪ੍ਰਾਇਕਟਿਕਲ ਹੋਇਆ।
ਇੱਕ ਕਾਰੋਬਾਰੀ ਡੇਟਾਬੇਸ ਉਸਦੀ recovery ਸਮਰੱਥਾ ਦੇ ਬਰਾਬਰ ਹੀ ਭਰੋਸੇਯੋਗ ਹੁੰਦੀ ਹੈ। RDBMS ਟੂਲਸ ਨੇ পূਙਪੂਰਕ ਬੈਕਅੱਪ, ਇੰਕਰੀਮੈਂਟਲ ਬੈਕਅੱਪ ਅਤੇ transaction logs ਰਾਹੀਂ point-in-time recovery ਵਰਗੇ ਪੈਟਰਨ ਨੂੰ ਮਿਆਰੀਕૃત ਕੀਤਾ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਟੀਮਾਂ ਰੀਸਟੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਪੜਚੋਲ ਕਰ ਸਕਦੀਆਂ, ਉਹਨਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰ ਸਕਦੀਆਂ ਅਤੇ ਘਟਨਾਵਾਂ ਦੌਰਾਨ ਦੁਹਰਾਈਆਂ—ਜੋ ਕਿ payroll, invoicing, inventory ਅਤੇ customer records ਲਈ ਨਿੰਮਾਨਕ ਹੈ।
ਮਾਨੀਟਰਿੰਗ ਵੀ ਹਮੇਸ਼ਾ ਦੇ ਓਪਰੇਸ਼ਨ ਦਾ ਹਿੱਸਾ ਬਣ ਗਿਆ: ਸਟੋਰੇਜ ਵਾਧਾ, ਸਲੋ ਕੁਐਰੀਜ਼, ਲਾਕ contention ਅਤੇ replication ਹੇਲਥ ਦੀ ਟ੍ਰੈਕਿੰਗ। ਜਦੋਂ ਸਮੱਸਿਆਵਾਂ ਮਾਪਣਯੋਗ ਹੁੰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਵੀ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਅਕਸਰ RDBMS ਪਲੇਟਫਾਰਮਾਂ ਨੇ access control ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਫੀਚਰ ਬਣਾਇਆ। ਸਾਂਝੇ ਪਾਸਵਰਡ ਦੇਣ ਦੇ ਬਜਾਏ, admins accounts ਬਣਾ ਸਕਦੇ, ਉਨ੍ਹਾਂ ਨੂੰ roles ਵਿੱਚ ਰੱਖ ਸਕਦੇ, ਅਤੇ ਡੇਟਾਬੇਸ, ਟੇਬਲ ਜਾਂ ਕਈ ਸਿਸਟਮਾਂ 'ਤੇ permissions ਦੇ ਸਕਦੇ ਹਨ।
ਦੋ ਗਵਰਨੈਂਸ ਮੂਲ ਬੁਨਿਆਦੀਆਂ:'
ਇਹ ਢਾਂਚਾ ਕੰਪਲਾਇੰਸ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਰੋਜ਼ਾਨਾ ਕੰਮ ਨੂੰ ਇੱਕ ਲਗਾਤਾਰ exception ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਣ ਦੇ।
RDBMS auditing—ਲੌਗ, ਸਿਸਟਮ ਟੇਬਲਾਂ ਅਤੇ ਕੁਝ ਸਿਸਟਮਾਂ ਦੀ ਬਿਲਟ-ਇਨ audit ਵਿਸ਼ੇਸ਼ਤਾ ਰਾਹੀਂ—ਇਹ ਪੁੱਛਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ "ਕਿਸ ਨੇ ਕੀ ਬਦਲਿਆ, ਅਤੇ ਕਦੋਂ?"। ਇਹ troubleshooting, ਸੁਰੱਖਿਆ ਜਾਂਚ ਅਤੇ ਨਿਯਮਤ ਵਰਕਫ਼ਲੋਜ਼ ਲਈ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ।
ਚੇਂਜ ਪਾਸੇ, ਪੱਕੇ ਟੀਮਾਂ ਪੁਨਰਾਵਰਤ migration 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੀਆਂ ਹਨ: ਸਕ੍ਰਿਪਟ ਕੀਤੇ ਸਕੀਮਾ ਬਦਲਾਵ ਜੋ version control ਵਿੱਚ review ਹੁੰਦੇ ਹਨ ਅਤੇ ਵਾਤਾਵਰਣਾਂ 'ਚ ਇੱਕਸਾਰ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਮਨਜ਼ੂਰੀਆਂ ਅਤੇ ਰੋਲਬੈਕ ਯੋਜਨਾਵਾਂ ਨਾਲ, ਇਸ ਨਾਲ ਰਾਤ ਦੇ ਵੇਲੇ ਹੋਣ ਵਾਲੀਆਂ "ਹੌਟ ਫਿਕਸ" ਦੀ ਰਿਸਕ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ ਜੋ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਰਿਪੋਰਟਿੰਗ ਜਾਂ ਇੰਟਿਗਰੇਸ਼ਨਾਂ ਨੂੰ ਕਰਪਟ ਕਰ ਸਕਦੀ ਹੈ।
ਪ੍ਰਸ਼ਾਸਨ ਅਭਿਆਸ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਪੈਟਰਨ ਬਣ ਗਏ ਜੋ ਕਾਰੋਬਾਰਾਂ ਲਈ ਮਿਆਰੀਕृत ਹੋ ਸਕਦੇ ਹਨ: replication redundancy ਲਈ, failover high availability ਲਈ, ਅਤੇ disaster recovery ਵਿਵਸਥਾਵਾਂ ਜੋ ਮੰਨ ਕੇ ਚਲਦੀਆਂ ਹਨ ਕਿ ਪੂਰਾ ਡੇਟਾ ਸੈਂਟਰ (ਜਾਂ ਕਲਾਊਡ ਰੀਜਨ) ਕੀਹਿ ਵਖਰੀ ਤਰ੍ਹਾਂ ਖ਼ਤਮ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਓਪਰੇਸ਼ਨਲ ਬਿਲਡਿੰਗ ਬਲਾਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਨੂੰ ਮੁੱਖ ਸਿਸਟਮ ਲਈ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਬਣਾਉਂਦੇ ਹਨ।
ਕਲਾਊਡ ਸੇਵਾਵਾਂ ਨੇ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਕੀਤਾ—ਪਰ ਉਨ੍ਹਾਂ ਨੇ ਟੀਮਾਂ ਵੱਲੋਂ ਚਲਾਉਣ ਦਾ ਤਰੀਕਾ ਬਦਲ ਦਿੱਤਾ। ਸਰਵਰ ਖਰੀਦਣ, ਡੇਟਾਬੇਸ ਸੌਫਟਵੇਅਰ ਇੰਸਟਾਲ ਕਰਨ ਅਤੇ maintain ਕਰਨ ਦੀ ਥਾਂ, ਬਹੁਤ ਕੰਪਨੀਆਂ ਹੁਣ managed RDBMS ਵਰਤਦੀਆਂ ਹਨ ਜਿੱਥੇ ਪ੍ਰੋਵਾਈਡਰ ਬਹੁਤ ਸਾਰਾ ਓਪਰੇਸ਼ਨਲ ਕੰਮ ਸੰਭਾਲਦਾ ਹੈ।
Managed ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ automated ਬੈਕਅੱਪ, point-in-time restore (ਗਲਤੀ ਤੋਂ ਪਿਛਲੇ ਪਲ 'ਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਵਾਪਸ ਲੈ ਜਾਣਾ), ਬਿਲਟ-ਇਨ patching, ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ ਕਾਰੋਬਾਰਾਂ ਲਈ ਇਸਦਾ ਮਤਲਬ ਹੈ ਘੱਟ ਲੇਟ-ਰਾਤ ਵਾਪਸੀ ਅਭਿਆਸ ਅਤੇ ਜ਼ਿਆਦਾ ਪੇਸ਼ਗੀ disaster ਤਿਆਰੀ।
ਸਕੇਲਿੰਗ ਵੀ ਲਚਕੀਲੀ ਹੋ ਗਈ। ਅਕਸਰ ਤੁਸੀਂ CPU, memory, ਅਤੇ storage ਕੁਝ ਸੈਟਿੰਗਾਂ ਨਾਲ ਵਧਾ ਸਕਦੇ ਹੋ ਬਜਾਏ ਹਾਰਡਵੇਅਰ ਮਾਈਗਰੇਸ਼ਨ ਦੇ। ਕੁਝ ਪਲੇਟਫਾਰਮ read scaling ਨੂੰ ਸਪੋਰਟ ਕਰਦੇ ਹਨ—read replicas ਜੋ ਰਿਪੋਰਟਿੰਗ ਡੈਸ਼ਬੋਰਡਾਂ ਅਤੇ ਭਾਰੀ ਖੋਜਾਂ ਨੂੰ order entry ਜਾਂ ਕਸਟਮਰ ਸਹਾਇਤਾ ਨੂੰ ਸਲੋ ਨਾ ਕਰਨ ਦਿੰਦੇ।
Replication ਦਾ ਮਤਲਬ ਹੈ ਡੇਟਾਬੇਸ ਦੀਆਂ ਨਕਲਾਂ ਨੂੰ ਸਿੰਕ ਰੱਖਣਾ। High availability replication ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ downtime ਘਟਾਉਣ ਲਈ: ਜੇ_primary_ ਡੇਟਾਬੇਸ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ standby takeover ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਉਹ ਸਿਸਟਮਾਂ ਲਈ ਮੱਤਵਪੂਰਨ ਹੈ ਜੋ ਭੁਗਤਾਨ ਲੈਂਦੇ ਰਹਿਣ, ਸ਼ਿਪਮੈਂਟ ਦਰਜ ਕਰਦੇ ਰਹਿਣ ਜਾਂ ਇਨਵੈਂਟਰੀ ਅਪਡੇਟ ਕਰਦੇ ਰਹਿਣ ਤਾਂ ਕਿ ਕਿਸੇ ਤਰ੍ਹਾਂ ਦੀ ਫੇਲਅਰ ਦੇ ਬਾਵਜੂਦ ਕਾਰੋਬਾਰ ਚੱਲਦਾ ਰਹੇ।
ਜਿਵੇਂ ਕਾਰੋਬਾਰ ਵਿਸ਼ਵ ਭਰ ਦੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਰਵ ਕਰਦੇ ਹਨ, latency ਇੱਕ ਅਸਲ ਕਾਰੋਬਾਰੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦੀ ਹੈ: ਜਿੱਥੇ ਗਾਹਕ ਦੂਰ ਹੁੰਦਾ ਹੈ, ਉਥੇ ਹਰ ਬੇਨਤੀ ਸਲੋ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ। ਉਦੋਂ-ਇੱਕੋ ਸਮੇਂ, microservices ਅਤੇ event-driven ਸਿਸਟਮ ਇੱਕ "ਵੱਡੇ ਐਪ" ਨੂੰ ਕਈ ਛੋਟੇ ਸਰਵਿਸਾਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਡੇਟਾ ਲੋੜਾਂ ਅਤੇ ਰਿਲੀਜ਼ ਚੱਕਰ ਹੁੰਦੇ ਹਨ।
ਕਈ ਟੀਮ RDBMS ਨੂੰ ਮੁੱਖ ਰਿਕਾਰਡ ਲਈ ਰੱਖਦੀਆਂ ਹਨ (ਗਾਹਕ, ਇਨਵਾਇਸ, ਬਕਾਇਆ) ਅਤੇ ਖਾਸ ਕੰਮਾਂ ਲਈ ਹੋਰ ਟੂਲ ਜੁੜਦੇ ਹਨ—search engines ਤੇਜ਼ ਟੈਕਸਟ ਖੋਜ ਲਈ, caches ਤੇਜ਼ੀ ਲਈ, ਜਾਂ analytics warehouses ਵੱਡੀ ਰਿਪੋਰਟਿੰਗ ਲਈ। ਇਸ ਨਾਲ ਡੇਟਾ ਇੰਟੈਗ੍ਰਿਟੀ ਜਿੱਥੇ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉਥੇ ਰਹਿੰਦੀ ਹੈ ਪਰ ਨਵੇਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਇੰਟਿਗਰੇਸ਼ਨ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
For more on consistency, see transactions and ACID.
ਅਮਲ ਵਿੱਚ, ਇਹ ਵੀ ਇਹੀ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅੰਦਰੂਨੀ ਟੂਲ ਕਿਵੇਂ ਬਣਾਏ ਜਾਂਦੇ ਹਨ। ਪਲੇਟਫਾਰਮਾਂ ਵਾਂਗ Koder.ai relational core + modern app ਦੇ ਰਸਤੇ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੇ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ web apps (React), backends (Go), ਅਤੇ PostgreSQL-backed systems of record ਵੱਲ vibe-code ਕਰ ਸਕਦੇ ਹੋ—ਫਿਰ snapshots ਅਤੇ rollback ਨਾਲ schema, migrations, ਜਾਂ workflows ਬਦਲਣ ਤੇ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਇটারేట్ ਕਰ ਸਕਦੇ ਹੋ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਹਰ ਵਰਕਲੋਡ ਲਈ ਬੇਮਿਸਾਲ ਨਹੀਂ ਹਨ। ਉਨ੍ਹਾਂ ਦੀ ਤਾਕਤ—ਮਜ਼ਬੂਤ ਢਾਂਚਾ, ਇਕਸਾਰਤਾ, ਅਤੇ ਪੇਸ਼ਗੀ ਨਿਯਮ—ਉਹੀ ਸਮਾਂ ਇੱਕ ਸੀਮਿਤਤਾ ਵੀ ਬਣ ਸਕਦੀ ਹੈ ਜਦੋਂ ਡੇਟਾ ਜਾਂ ਵਰਤੋਂ ਨਮੂਨਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਟੇਬਲਾਂ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ।
ਕੁਝ ਸਥਿਤੀਆਂ RDBMS ਮਾਡਲ ਦੇ ਖ਼ਿਲਾਫ਼ ਦਬਾਉਂਦੀਆਂ ਹਨ:
NoSQL ਸਿਸਟਮ ਲੋਕਪ੍ਰਿਯ ਹੋਏ ਕਿਉਂਕਿ ਉਹ ਅਕਸਰ ਲਚੀਲਾ ਡੇਟਾ ਸਹਾਰਦੇ ਅਤੇ ਹੋਰ-ਹੋਰ ਮੁਸ਼ਕਿਲਾਂ 'ਤੇ ਮੱਦਦ ਕਰਦੇ—ਉਦਾਹਰਨ ਲਈ schema evolution ਤੇਜ਼ ਕਰਨਾ ਅਤੇ ਹਾਰਜ਼ਾਂਟਲ ਸਕੇਲਿੰਗ ਸਧਾਰਨ ਬਣਾਉਣਾ। ਬਹੁਤ ਸਾਰੇ NoSQL ਡੇਟਾਬੇਸ ਕੁਝ consistency ਗਾਰੰਟੀਜ਼ ਜਾਂ query ਸਮਰਥਾ ਘਟਾ ਕੇ ਬਦਲੇ ਵਿੱਚ ਤੇਜ਼ ਲਿਖਤਾਂ ਜਾਂ ਆਸਾਨ ਵੰਡ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ—ਜੋ ਕੁਝ ਉਤਪਾਦਾਂ, ਵਿਸ਼ਲੇਸ਼ਣ ਪਾਈਪਲਾਈਨ ਜਾਂ high-volume event capture ਲਈ ਲਾਭਦਾਇਕ ਹੈ।
ਆਧੁਨਿਕ ਕਾਰੋਬਾਰੀ ਸਟੈਕ ਮਿਲੇ ਹੋਏ ਪਹੁੰਚੀ ਦਿਖਾਉਂਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਪੈਸਾ, ਆਰਡਰ, ਇਨਵੈਂਟਰੀ, ਗਾਹਕ ਅਕਾਊਂਟ ਜਾਂ ਕੋਈ ਵੀ ਚੀਜ਼ ਟਰੈਕ ਕਰ ਰਹੇ ਹੋ ਜੋ ਸਪਸ਼ਟ ਨਿਯਮ ਅਤੇ ਭਰੋਸੇਯੋਗ ਅਪਡੇਟਾਂ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ, ਤਾਂ RDBMS ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਸ਼ੁਰੂਆਤ ਹੈ। ਵਿਕਲਪਾਂ ਨੂੰ ਉਸ ਵੇਲੇ ਵਰਤੋ ਜਦੋਂ ਵਰਕਲੋਡ ਸੱਚਮੁੱਚ ਉਹਨਾਂ ਦੀ ਮੰਗ ਕਰਦਾ ਹੋ—ਨਾ ਕਿ ਸਿਰਫ਼ ਇਨ੍ਹਾਂ ਦੀ ਚਾਪਲੂਸੀ ਲਈ।
ਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਗਾਹਕਾਂ, ਆਰਡਰਾਂ, ਇਨਵਾਇਸਾਂ, ਭੁਗਤਾਨਾਂ ਅਤੇ ਇਨਵੈਂਟਰੀ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਇੱਕ ਇਕੋ source of truth ਚਾਹੀਦੀ ਹੁੰਦੀ ਹੈ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਇਸ ਲਈ ਬਣੇ ਹਨ ਕਿ ਜਦੋਂ ਕਈ ਯੂਜ਼ਰ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇਕੱਠੇ ਪੜ੍ਹਦੀਆਂ ਅਤੇ ਲਿਖਦੀਆਂ ਹਨ ਤਾਂ ਰਿਕਾਰਡ ਇਕਸਾਰ ਰਹਿਣ — ਤਾਂ ਜੋ ਰਿਪੋਰਟਾਂ ਆਪਰੇਸ਼ਨਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ ਅਤੇ ‘ਅੰਦਾਜ਼ੇ’ ਘਟਦੇ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਡੇਟਾ ਨੂੰ ਟੇਬਲਾਂ (ਕਤਾਰਾਂ ਅਤੇ ਕਾਲਮ) ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹਨ ਅਤੇ ਲੋਐੜਾਂ ਲਗਾਉਂਦੇ ਹਨ।
ਟੇਬਲਾਂ Orders.CustomerID ਵਰਗੀਆਂ ਕੁੰਜੀਆਂ ਰਾਹੀਂ ਜੁੜਦੀਆਂ ਹਨ ਜੋ Customers.CustomerID ਨੂੰ ਰੇਫਰੈਂਸ ਕਰਦੀਆਂ ਹਨ — ਇਸ ਤਰ੍ਹਾਂ ਡੇਟਾਬੇਸ ਬਿਨਾਂ ਕਾਪੀ ਕੀਤੇ ਸਬੰਧਿਤ ਰਿਕਾਰਡ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ।
ਫਾਈਲ-ਆਧਾਰਤ ਸਟੋਰੇਜ ਤਦ ਤੱਕ ਕੰਮ ਕਰਦਾ ਸੀ ਜਦੋਂ ਕੰਪਨੀ ਛੋਟੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕੁਝ ਲੋਕ ਹੀ ਡੇਟਾ ਵਰਤਦੇ ਹਨ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਉਂਦੀਆਂ ਸਨ:
ਇਹੀ ਕਾਰਨ ਸੀ ਕਿ ਕਾਰੋਬਾਰਾਂ ਨੇ ਸਾਂਝੇ, ਨਿਯਮਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਣ ਵਾਲਾ ਡੇਟਾ ਚਾਹਿਆ।
ਪ੍ਰਾਈਮੇਰੀ ਕੀ ਇੱਕ ਕਤਾਰ ਲਈ ਇਕ ਯੂਨੀਕ ਅਤੇ ਸਥਿਰ ਪਛਾਣ ਹੈ (ਉਦਾਹਰਨ ਲਈ CustomerID).
ਫੌਰਿਨ ਕੀ ਹੋਰ ਟੇਬਲ ਦੀ ਪ੍ਰਾਈਮੇਰੀ ਕੀ ਦਾ ਰੇਫਰੈਂਸ ਹੁੰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ Orders.CustomerID -> Customers.CustomerID).
ਇਨ੍ਹਾਂ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ ਅਤੇ “ਰਹੱਸਮਈ ਲਿੰਕ” ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ।
Referential integrity ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਸਹੀ ਸਬੰਧਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।
ਅਮਲ ਵਿੱਚ ਇਹ ਫਾਇਦੇ ਦਿੰਦਾ ਹੈ:
Normalization ਡੇਟਾ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ ਤਾਂ ਜੋ ਇਕੋ ਜਾਣਕਾਰੀ ਕਈ ਥਾਵਾਂ 'ਤੇ ਨਾ ਰਹੇ।
ਸਧਾਰਨ ਉਦਾਹਰਣ: ਕਿਸੇ ਗਾਹਕ ਦਾ ਪਤਾ Customers ਵਿੱਚ ਇਕ ਵਾਰੀ ਸਟੋਰ ਕਰੋ ਅਤੇ ਆਰਡਰ CustomerID ਰਾਹੀਂ ਉਸਨੂੰ ਰੇਫਰ ਕਰਨ। ਇਸ ਨਾਲ ਇੱਕ ਅੱਪਡੇਟ ਸਾਰਿਆਂ ਲਈ ਲਾਗੂ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਡਰਿਫਟ ਘੱਟ ਹੁੰਦੀ ਹੈ।
SQL ਨੇ ਕਾਰੋਬਾਰਾਂ ਲਈ ਡੇਟਾ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ 'ਚ ਪੁੱਛਣਯੋਗ ਬਣਾਇਆ।
ਇਹ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਹਰ ਰੋਜ਼ ਦੇ ਪ੍ਰਸ਼ਨਾਂ ਲਈ ਉਚਿਤ ਹੈ ਜਿਵੇਂ:
ਇਸ ਸਾਂਝੇ ਭਾਸ਼ਾ ਨੇ ਟੂਲ ecoystem ਨੂੰ ਵੀ ਉਭਾਰਿਆ: BI ਡੈਸ਼ਬੋਰਡ, ETL ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਟੂਲ ਸਭ SQL 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਲੱਗੇ।
ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਕਈ ਅਪਡੇਟਾਂ ਨੂੰ ਇਕੱਠੇ ਇਕ ਇਕਾਈ ਵਜੋਂ ਦੇਖਦਾ ਹੈ — ਸੋਚੋ ਇਕ ਆਨਲਾਈਨ ਆਰਡਰ:
ਜੇ ਕੁਝ ਅਧੂਰਾ ਰਹਿ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਡੇਟਾਬੇਸ ਰੋਲਬੈਕ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਸਿਸਟਮ ਸਾਫ ਰਹੇ।
ACID ਦੇ ਸਿਧਾਂਤ (Atomic, Consistent, Isolated, Durable) ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਇਹ ਭਰੋਸਾ ਦਿੰਦੇ ਹਨ ਕਿ ਮੁੱਖ ਰਿਕਾਰਡ ਸਹੀ ਅਤੇ ਮਜ਼ਬੂਤ ਰਹਿਣਗੇ।
OLTP (Online Transaction Processing) ਉਹ ਨਮੂਨਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਕਾਰੋਬਾਰੀ ਐਪਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ, ਤੇਜ਼ ਪੜ੍ਹਨ/ਲਿਖਣ ਕਾਰਜ ਜੋ ਘੁੰਮਦੇ ਰਹਿੰਦੇ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਇਸ ਲਈ ਚੰਗੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਇੰਡੈਕਸ, concurrency control ਅਤੇ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਕਵੈਰੀ ਐਗਜ਼ਿਕਿਊਸ਼ਨ ਦਿੰਦੇ ਹਨ — ਜਿਸ ਨਾਲ ਹਰੇਕ ਦੈਨੀਕ ਕਾਰਜ (checkout, invoicing, updates) ਭਰੋਸੇਯੋਗ ਰਹਿੰਦੇ ਹਨ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਮੁਸ਼ਕਲ ਸਥਿਤੀਆਂ ਵਿੱਚ ਘੱਟ ਅਨੁਕੂਲ ਹੋ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ:
NoSQL ਸਿਸਟਮ ਇਸ ਲਈ ਉਭਰੇ ਕਿ ਉਹ ਲਚੀਲਾ ਸਕੀਮਾ ਅਤੇ ਹਾਰਡਵੇਅਰ-ਅਨੁਕੂਲ ਸਕੇਲਿੰਗ ਦੇਣ ਵਿੱਚ ਸਹਾਇਕ ਹਨ।
ਅਕਸਰ ਅੱਜਕੱਲ੍ਹ ਦੇ ਸਟੈਕ “ਬਿਹਤਰ ਦੋਹਾਂ” ਰਾਹ ਫ਼ੋਲੋ ਕਰਦੇ ਹਨ: RDBMS ਕੋਰ ਲਈ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਕੰਮਾਂ ਲਈ ਹੋਰ ਸਟੋਰ ਵਰਤੇ ਜਾਂਦੇ ਹਨ (search, cache, analytics)।