20 ਨਵੰ 2025·8 ਮਿੰਟ
ਲੈਰੀ ਐਲਿਸਨ ਅਤੇ ਓਰੈਕਲ: ਡੇਟਾਬੇਸ, ਲਾਕ-ਇਨ ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿਕਰੀ
ਡੇਟਾਬੇਸ, ਬਦਲਣ ਦੀ ਲਾਗਤ, ਲਾਇਸੈਂਸਿੰਗ ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿਕਰੀ ਦੀ ਨੀਤੀ ਰਾਹੀਂ ਓਰੈਕਲ ਅਤੇ ਲੈਰੀ ਐਲਿਸਨ ਨੇ ਕਿਵੇਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਦੌਲਤ ਬਣਾਈ — ਸਧਾਰਨ, ਆਮ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਉਂਦਾ ਇਕ ਸਾਰ
ਡੇਟਾਬੇਸ, ਬਦਲਣ ਦੀ ਲਾਗਤ, ਲਾਇਸੈਂਸਿੰਗ ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿਕਰੀ ਦੀ ਨੀਤੀ ਰਾਹੀਂ ਓਰੈਕਲ ਅਤੇ ਲੈਰੀ ਐਲਿਸਨ ਨੇ ਕਿਵੇਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਦੌਲਤ ਬਣਾਈ — ਸਧਾਰਨ, ਆਮ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਉਂਦਾ ਇਕ ਸਾਰ
ਲੈਰੀ ਐਲਿਸਨ ਦਾ ਟਿਕਾਊ-ਦੌਲਤ ਫਾਰਮੂਲਾ ਏਨੇ ਸ਼ਬਦਾਂ 'ਚ ਸਮਾਇਆ ਜਾ ਸਕਦਾ ਹੈ: ਇੱਕ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਡੇਟਾਬੇਸ ਵੇਚੋ, ਇਸ ਨੂੰ ਕਈ ਸਾਲਾਂ ਦੇ ਠੇਕਿਆਂ ਵਿੱਚ ਬੰਨ੍ਹੋ, ਅਤੇ ਐਸਾ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੇਲਜ਼ ਮਸ਼ੀਨ ਬਣਾਓ ਜੋ ਰਹਿਣਾ ਬਦਲਣ ਨਾਲੋਂ ਜਿਆਦਾ ਸੁਰੱਖਿਅਤ ਲੱਗਦਾ ਕਰੇ।
ਇਹ ਕਾਰੋਬਾਰੀ ਕਹਾਣੀ ਹੈ ਕਿ ਓਰੈਕਲ ਕਿਵੇਂ ਬਦਲਣ ਲਈ ਮੁਸ਼ਕਲ ਬਣ ਗਿਆ—ਇਹ ਡੇਟਾਬੇਸ ਦੀਆਂ ਅੰਦਰੂਨੀ ਤਕਨੀਕੀ ਵਿਸਥਾਰਾਂ 'ਤੇ ਡੂੰਘਾ ਟਿਊਟੋਰਿਯਲ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ SQL ਓਪਟਿਮਾਈਜ਼ਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੇ ਤਾਂ ਜੋ ਸਮਝ ਸਕੋ ਕਿ ਓਰੈਕਲ ਕਿਵੇਂ ਦਹਾਕਿਆਂ ਤਕ ਨਕਦੀ ਉਤਪੱਨ ਕਰਨ ਵਾਲੀ ਮਸ਼ੀਨ ਬਣਿਆ।
"ਟਿਕਾਊ" ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਗਾਹਕ ਹਰ ਨਵੀਨੀਕਰਨ 'ਤੇ ਖੁਸ਼ ਹੁੰਦੇ ਸਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਓਰੈਕਲ ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਰੱਖਿਆ ਕਿ ਰੈਵਨਿਊ ਆਮ ਤੌਰ 'ਤੇ ਦੁਹਰਾਉਂਦਾ ਰਹੇ।
ਟਿਕਾਊਪਣ ਇਹਨਾਂ ਰੂਪਾਂ 'ਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ:
ਜਦੋਂ ਇੱਕ ਡੇਟਾਬੇਸ ਬਿਲਿੰਗ, ਇਨਵੈਂਟਰੀ, HR, ਜਾਂ ਟਰੇਡਿੰਗ ਸਿਸਟਮਾਂ ਦੇ ਥੱਲੇ ਹੋਵੇ, ਤਾਂ ਇਹ ਸਿਰਫ ਇੱਕ ਹੋਰ IT ਟੂਲ ਨਹੀਂ ਰਹਿੰਦਾ। ਇਹ ਇੱਕ ਨਿਰਭਰਤਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ ਚਪਕੀਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
1) ਡੇਟਾਬੇਸ ਬੁਨਿਆਦ ਦੇ ਤੌਰ 'ਤੇ। ਓਰੈਕਲ ਨੇ “ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ” ਲੇਅਰ ਤੇ ਧਿਆਨ ਦਿੱਤਾ — ਜਿੱਥੇ ਸਭ ਤੋਂ ਕੀਮਤੀ ਓਪਰੇਸ਼ਨਲ ਡੇਟਾ ਰਹਿੰਦੀ ਹੈ।
2) ਲਾਕ-ਇਨ (ਕਈ ਵਾਰ ਬੇਇਰਾਦੀ)। ਇਹ ਸਿਰਫ ਤਕਨੀਕੀ ਅਨੁਕੂਲਤਾ ਨਹੀਂ, ਬਲਕਿ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਇੰਟੈਗਰੇਸ਼ਨਾਂ, ਟ੍ਰੇਨਿੰਗ ਅਤੇ ਵੇਂਡਰ-ਨਿਰਧਾਰਿਤ ਫੀਚਰ ਵੀ ਹਨ ਜੋ ਸਾਲਾਂ ਵਿੱਚ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ।
3) ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੇਲਜ਼। ਓਰੈਕਲ ਨੇ ਉਪਭੋਗੀ ਐਪ ਵਾਂਗ ਨਹੀਂ ਜਿੱਤਿਆ। ਇਸਨੇ ਪ੍ਰਾਕਿਆਵਾਂ, ਕਾਰਜਕਾਰੀ ਸੰਬੰਧਾਂ, ਅਤੇ ਐਸੇ ਠੇਕੇ ਵਰਤ ਕੇ ਜਿੱਤਿਆ ਜੋ ਰਿਸ਼ਤਾ ਵਧਾਉਂਦੇ।
ਇਹ ਤਿੰਨ ਇਕੱਠੇ ਹੋ ਕੇ ਇੱਕ ਮੁਅੱਤਲ ਪ੍ਰਭਾਵ ਬਣਾਉਂਦੇ ਹਨ: ਹਰ ਨਵਾਂ ਸੌਦਾ ਸਿਰਫ ਇੱਕ ਵਾਰੀ ਦੀ ਵਿਕਰੀ ਨਹੀਂ ਸੀ—ਇਹ ਭਵਿੱਖੀ ਭੁਗਤਾਨਾਂ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦਾ ਸੀ।
ਲੈਰੀ ਐਲਿਸਨ ਸ਼ੁਰੂ ਵਿੱਚ ਕੋਈ ਸੌਫਟਵੇਅਰ ਸਲੇਬ੍ਰਿਟੀ ਨਹੀਂ ਸੀ। ਉਸਦੀ ਸ਼ੁਰੂਆਤੀ ਕਰੀਅਰ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੌਕਰੀਆਂ ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਸਮਝ ਦਾ ਇਕ ਪ੍ਰਯੋਗਸ਼ੀਲ ਮਿਲਾਵਟ ਸੀ ਕਿ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਅਸਲ ਵਿੱਚ ਟੈਕਨੋਲੋਜੀ ਕਿਵੇਂ ਖਰੀਦਦੀਆਂ ਹਨ—ਧੀਮੇ, ਸਾਵਧਾਨ ਅਤੇ ਉਹਨਾਂ ਵਿਕਰੇਤਿਆਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਜੋ ਠੋਸ ਦਿਖਦੇ ਹਨ।
ਓਰੈਕਲ 1977 ਵਿੱਚ (Software Development Laboratories ਦੇ ਨਾਂ ਨਾਲ) ਸ਼ੁਰੂ ਹੋਇਆ ਅਤੇ ਇਸਦਾ ਸਪੱਸ਼ਟ ਧਿਆਨ ਸੀ: ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡਾ ਧਨ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਵੇਚਣ 'ਚ ਹੈ, ਨਾ ਕਿ ਇਕ-ਵਾਰ ਦੀਆਂ ਕਸਟਮ ਪ੍ਰਣਾਲੀਆਂ ਬਣਾਉਣ 'ਚ। ਐਲਿਸਨ ਅਤੇ ਉਸਦੇ ਸਾਥੀਆਂ ਨੇ ਸ਼ੁਰੂਆਤੀ ਹੋਬੀਸਟ ਜਾਂ ਖਪਤਕਾਰੀ ਬਜ਼ਾਰਾਂ ਦੇ ਪਿੱਛੇ ਨਹੀਂ ਭੱਜਿਆ; ਉਹਨਾਂ ਨੇ ਉਹ ਕੰਪਨੀਆਂ ਅਤੇ ਸਰਕਾਰੀ ਏਜੰਸੀਆਂ ਨਿਸ਼ਾਨਾ ਬਣਾਈਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪੇਰੋਲ, ਇਨਵੈਂਟਰੀ, ਬਿਲਿੰਗ ਅਤੇ ਅਕਾਊਂਟਿੰਗ ਚਲਾਉਣ ਲਈ ਸਿਸਟਮਾਂ ਦੀ ਲੋੜ ਸੀ।
ਉਸ ਵੇਲੇ ਕੰਪਿਊਟਿੰਗ ਮੇਨਫ੍ਰੇਮ ਅਤੇ ਕੇਂਦਰੀਕ੍ਰਿਤ ਡੇਟਾ ਦੁਆਰਾ ਪ੍ਰਵਾਨਚੜ੍ਹੀ ਸੀ। ਜਦ ਕਿ ਕਲਾਇੰਟ-ਸਰਵਰ ਹੋਣ ਲੱਗੇ, ਵੱਡੀਆਂ ਫਰਮਾਂ ਦੇ ਅੰਦਰ ਮੂਲ ਧਾਰਨਾ ਇਹ ਸੀ ਕਿ ਸਿਸਟਮ ਲੰਮੇ ਸਮੇਂ ਲਈ ਭਰੋਸੇਯੋਗ, ਆਡਿਟ ਯੋਗ ਅਤੇ ਸਪੋਰਟ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇਹ ਵਾਤਾਵਰਨ ਉਸ ਸੌਫਟਵੇਅਰ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਸੀ ਜੋ ਇੱਕ ਮਿਆਰੀ ਹਿੱਸਾ ਬਣ ਸਕਦਾ ਸੀ—ਜਿਸਦੇ ਆਲੇ-ਦੁਆਲੇ IT ਟੀਮਾਂ ਨਿਰਮਾਣ ਕਰ ਸਕਦੀਆਂ। ਡੇਟਾਬੇਸ ਇਸ ਲਈ ਬਿਲਕੁਲ ਫਿੱਟ ਬੈਠਦੇ ਸਨ: ਉਹ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਥੱਲੇ ਰਹਿੰਦੇ, ਮਹੱਤਵਪੂਰਨ ਡੇਟਾ ਨੂੰ ਛੂੰਹਦੇ, ਅਤੇ ਤਜਰਬੇ ਸਮਰਥਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਨੂੰ ਜਾਇਜ਼ ਬਣਾਉਂਦੇ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਗਾਹਕ ਵਿਅਕਤੀਆਂ ਵਾਂਗ ਨਹੀਂ ਖਰੀਦਦੇ। ਉਹ ਕਮੇਟੀਆਂ, ਪ੍ਰੋਕਿਊਰਮੈਂਟ ਪ੍ਰਕ੍ਰਿਆਵਾਂ ਅਤੇ ਕਈ ਸਾਲਾਂ ਦੀ ਯੋਜਨਾ ਰਾਹੀਂ ਖਰੀਦਦੇ ਹਨ। ਇਹ ਇੱਕ ਵੇਂਡਰ ਨੂੰ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ:
ਇਸਦਾ ਮਾਲੀ ਪ੍ਰੋਫ਼ਾਈਲ ਵੀ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵੱਡਾ ਸੌਦਾ ਸਾਲਾਂ ਦੀ ਉਤਪਾਦ ਕੰਮ ਨੂੰ ਫੰਡ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਐਸੀ ਸੇਲਜ਼ ਮੋਸ਼ਨ ਮੰਗਦਾ ਹੈ ਜੋ ਸੰਬੰਧਾਂ, ਪ੍ਰਮਾਣ ਅਤੇ ਜੋਖਮ ਘਟਾਉਣ 'ਤੇ ਟਿਕਿਆ ਹੋਵੇ।
ਓਰੈਕਲ ਦੀ ਸ਼ੁਰੂਆਤੀ ਸ਼ਰਤ ਸਪੱਸ਼ਟ ਸੀ: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਕੋਰ ਵਿੱਚ ਆਪਣੀ ਜਗ੍ਹਾ ਕਮਾਓ, ਅਤੇ ਤੁਸੀਂ ਸਿਰਫ ਸੌਫਟਵੇਅਰ ਨਹੀਂ ਵੇਚ ਰਹੇ—ਤੁਸੀਂ ਅਪਡੇਟ, ਸਹਾਇਤਾ ਅਤੇ ਅਪਗਰੇਡ ਰਾਹੀਂ ਲਗਾਤਾਰਤਾ ਵੇਚ ਰਹੇ ਹੋ ਜੋ ਜਿਵੇਂ-ਜਿਵੇਂ ਨਿਰਭਰਤਾ ਵਧਦੀ ਹੈ, ਲੋਕ ਭੁਗਤਾਨ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ।
ਡੇਟਾਬੇਸ ਇੱਕ ਕੰਪਨੀ ਦਾ ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ ਹੁੰਦਾ ਹੈ: ਓਥੇ ਹੀ "ਅਧਿਕਾਰਿਕ ਸੱਚ" ਰਹਿੰਦਾ ਹੈ। ਗਾਹਕ ਖਾਤੇ, ਚਲਾਨ, ਇਨਵੈਂਟਰੀ ਗਿਣਤੀ, ਪੇਰੋਲ ਐਂਟਰੀਆਂ, ਸ਼ਿਪਮੈਂਟ ਸਥਿਤੀਆਂ—ਇਹ ਸਿਰਫ ਫਾਇਲਾਂ ਨਹੀਂ ਹਨ। ਇਹ ਕਾਰੋਬਾਰ ਉਹਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਪੈਸੇ ਲੈ ਸਕੇ, ਅਨੁਕੂਲੀਤਾ ਬਰਕਰਾਰ ਰੱਖ ਸਕੇ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਚਲ ਸਕੇ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਸੰਸਥਾਵਾਂ ਹੋਰ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦੀਆਂ—ERP, CRM, ਬਿਲਿੰਗ, ਸਪਲਾਈ ਚੇਨ—ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਵੱਧ-ਵੱਧ ਇੱਕੋ ਥੱਲੇ ਵਾਲੇ ਸਹੀ ਸਰੋਤ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਲੱਗਦੇ ਹਨ। ਜੇ ਡੇਟਾਬੇਸ ਉਪਲਬਧ ਨਾ ਹੋਵੇ, ਤਾਂ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਜੋ ਰਿਕਾਰਡ ਪੜ੍ਹਦੇ ਅਤੇ ਲਿਖਦੇ ਹਨ, ਆਪਣਾ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇਸ ਨਾਲ ਡੇਟਾਬੇਸ ਇੱਕ ਕੇਂਦਰੀ ਨਿਰਭਰਤਾ ਬਣ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ "ਇੱਕ ਹੋਰ IT ਹਿੱਸਾ"।
ਡੇਟਾਬੇਸ ਚਿਪਕਦੀਆਂ ਇਸ ਲਈ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ ਤੁਸੀਂ ਇਕੱਠਾ ਕਰ ਲੈਂਦੇ ਹੋ:
ਬਦਲਣ ਇੱਕ ਸਪ੍ਰੈਡਸ਼ੀਟ ਟੂਲ ਬਦਲਣ ਵਰਗਾ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਹਾਨੂੰ ਵੱਡੀ ਮਾਤਰਾ ਦਾ ਡੇਟਾ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ ਪੈਂਦਾ, ਇਤਿਹਾਸ ਸੰਭਾਲਣਾ ਪੈਂਦਾ, ਆਵਸ਼ਯਕ ਵਰਕਫਲੋਜ਼ ਦੀ ਦੁਬਾਰਾ ਟੈਸਟਿੰਗ ਕਰਨੀ ਪੈਂਦੀ, ਅਤੇ ਅਕਸਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪੈਂਦਾ ਹੈ। ਨਵੇਂ ਵਿਕਲਪ ਸਸਤੇ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਪ੍ਰੋਜੈਕਟ ਰਿਸਕ ਬਚਤ ਤੋਂ ਵੱਡਾ ਹੋ ਸਕਦਾ ਹੈ।
ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਸਿਸਟਮਾਂ ਲਈ, ਡਰ "ਇਕ ਹਫ਼ਤੇ ਲਈ ਥੋੜ੍ਹਾ ਹੌਲੀ" ਦਾ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਉਹ ਡਾਊਨਟਾਈਮ ਹੈ ਜੋ ਆਰਡਰ ਪ੍ਰੋਸੈਸਿੰਗ ਰੋਕ ਦਿੰਦਾ, ਜਾਂ ਡੇਟਾ ਘਾਟਾ ਜੋ ਪੂਰੇ ਤੌਰ 'ਤੇ ਰਿਕਨਸੀਲਾਈਸ਼ਨ, ਰਿਫੰਡ ਅਤੇ ਨਿਯਮਕ ਸਮੱਸਿਆਵਾਂ ਲਿਆਉਂਦਾ ਹੈ।
ਜਦੋਂ ਇੱਕ ਖ਼ਰਾਬ ਦਿਨ ਦੀ ਲਾਗਤ ਮਿਲਿਆ ਉੱਤਰ ਜਾਂ ਭਰੋਸਾ ਖੋਹ ਸਕਦੀ ਹੈ, ਤਾਂ ਖਰੀਦਦਾਰ ਸੰਭਾਲੀ ਹੋਏ ਬਣ ਜਾਂਦੇ ਹਨ। "ਮਜ਼ਬੂਤ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ" ਨਵੇਂ ਅਤੇ ਉਮੀਦਵਾਰ ਉੱਤੇ ਜਿੱਤ ਜਾਂਦਾ ਹੈ।
IT ਵਿਭਾਗਾਂ ਨੂੰ ਸਥਿਰਤਾ 'ਤੇ ਅੰਕਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਨੂੰ ਉਸ ਵੇਂਡਰ ਵੱਲ ਧਕੇਲਦਾ ਹੈ ਜੋ ਲੰਮੇ ਟ੍ਰੈੱਕ ਰਿਕਾਰਡ, ਪੱਕੇ ਟੂਲਿੰਗ, ਅਤੇ ਐਸੇ ਸਪੋਰਟ ਟੀਮਾਂ ਰੱਖਦਾ ਹੈ ਜੋ ਹਰ ਫੇਲਯੂਰ ਮੋਡ ਵੇਖ ਚੁੱਕੇ ਹਨ।
ਜਦੋਂ ਇਹ ਫੈਸਲਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਡੇਟਾਬੇਸ ਬਾਕੀ ਸਟੈਕ ਲਈ ਐਂਕਰ ਬਣ ਜਾਂਦਾ ਹੈ—ਐਪਲੀਕੇਸ਼ਨਾਂ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਬਜਟਾਂ ਨੂੰ ਆਪਣੀ ਕ੍ਰਿਪਾ ਵਿੱਚ ਖਿੱਚਦਾ ਹੋਇਆ।
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਕਾਰੋਬਾਰਿਕ ਡੇਟਾ—ਗਾਹਕ, ਚਲਾਨ, ਸ਼ਿਪਮੈਂਟ—ਨੂੰ ਟੇਬਲਾਂ (ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਵਾਂਗ) ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦਾ ਇਕ ਤਰੀਕਾ ਹੈ, ਜਿਹਨਾਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਫਾਇਲਾਂ ਵਿੱਚ ਖੋਜ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਪ੍ਰਸ਼ਨ ਪੁੱਛਦੇ ਹੋ ਜਿਵੇਂ "30 ਦਿਨ ਤੋਂ ਵੱਧ ਦੇ ਸਾਰੇ ਅਦਾਇਗੀ ਨਾ ਕੀਤੀਆਂ ਚਲਾਨ ਦਿਖਾਓ" ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸੰਤੋਸ਼ਜਨਕ ਜਵਾਬ ਮਿਲਦਾ ਹੈ।
SQL (Structured Query Language) ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਲਈ ਆਮ ਭਾਸ਼ਾ ਸੀ। ਕਿਉਂਕਿ SQL ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਪੜ੍ਹਾਇਆ ਜਾਂਦਾ ਅਤੇ ਵਿਅਾਪਕ ਤੌਰ 'ਤੇ ਸਹਾਇਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਹ ਆਸਾਨ ਲੱਗਦਾ ਕਿ ਡੇਟਾਬੇਸ ਉਤਪਾਦ ਇੱਕ-ਦੂਜੇ ਦੇ ਬਦਲ ਹਨ।
ਪਰ ਅਸਲ ਕੰਪਨੀਆਂ ਵਿੱਚ, ਮਹੱਤਵ صرف ਇਸ ਗੱਲ ਦਾ ਨਹੀਂ ਰਹਿੰਦਾ ਕਿ ਸਿਸਟਮ SQL ਸਮਝਦਾ ਹੈ। ਫਰਕ ਉਹ ਸਭ ਹੁੰਦਾ ਹੈ ਜੋ ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੈ: ਡੇਟਾਬੇਸ ਬਹੁਤ ਲੋਡ ਹੇਠਾਂ ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ, ਕ੍ਰੈਸ਼ ਤੋਂ ਬਾਅਦ ਕਿਵੇਂ ਰਿਕਵਰ ਕਰਦਾ ਹੈ, ਬੈਕਅੱਪ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਨੁਮਤੀਆਂ ਕਿਵੇਂ ਪ੍ਰਬੰਧ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਟੀਮਾਂ ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਕਿਵੇਂ ਕਰਦੀਆਂ ਹਨ।
ਓਰੈਕਲ ਨੇ "SQL ਵੇਚਿਆ" ਨਹੀਂ। ਓਰੈਕਲ ਨੇ ਇਹ ਵਾਅਦਾ ਵੇਚਿਆ ਕਿ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਸਿਸਟਮ ਚੱਲਦੇ ਰਹਿਣਗੇ।
ਭਾਵੇਂ ਕੋਈ ਮੁਕਾਬਲਾਵੀ ਫੀਚਰ ਮਿਲਾ ਲਏ, ਇੱਕ ਡੇਟਾਬੇਸ 'ਤੇ ਮਿਆਰੀਕਰਨ ਦਾ ਫੈਸਲਾ ਟੀਮਾਂ, ਬਜਟ, ਅਤੇ ਸਾਲਾਂ ਦੀਆਂ ਓਪਰੇਸ਼ਨਲ ਆਦਤਾਂ 'ਚ ਫੈਲ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਡੇਟਾਬੇਸ ਰਿਪੋਰਟਿੰਗ, ਇੰਟੈਗਰੇਸ਼ਨਾਂ ਅਤੇ ਕੌਂਪਲਾਇੰਸ ਦਾ ਕੇਂਦਰ ਬਣ ਜਾਵੇ, "ਠੀਕ-ਠਾਕ" ਟੈਕਨੋਲੋਜੀ ਜਿੱਤਣ ਲਈ ਕਾਫੀ ਨਹੀਂ ਰਹਿੰਦੀ।
ਬਜ਼ਾਰ ਵਿੱਚ ਦਬਦਬਾ ਆਮ ਤੌਰ 'ਤੇ ਉਤਪਾਦ ਗੁਣਵੱਤਾ, ਜੋਖਮ ਪ੍ਰਬੰਧਨ, ਅਤੇ ਸੇਲਜ਼ ਅਮਲ ਦੀ ਮਿਲੀ-ਝੁਲੀ ਨਤੀਜਾ ਹੁੰਦੀ ਹੈ—ਕਿਸੇ ਇਕ ਖਾਸ ਕਿਲਰ ਫੀਚਰ ਦੀ ਨਹੀਂ।
ਓਰੈਕਲ ਡੈਵਲਪਰਨਾਂ ਤੋਂ ਇੱਕ ਕਰੈਡਿਟ ਕਾਰਡ ਸੁਆਇਪ ਦੀ ਉਡੀਕ ਕਰਕੇ ਨਹੀਂ ਜਿੱਤਿਆ। ਇਸਨੇ ਸਿੱਖ ਲਿਆ ਕਿ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਖਰੀਦਦੀਆਂ ਹਨ: ਧੀਰੇ, ਸਾਵਧਾਨ, ਅਤੇ ਕਈ ਲੋਕਾਂ ਨਾਲ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪ੍ਰੋਕਿਊਰਮੈਂਟ ਇਕ ਸਮੂਹੀ ਕਾਰਜ ਹੈ। ਇੱਕ ਆਮ ਸੌਦੇ ਵਿੱਚ IT ਨੇਤਾ, ਸੁਰੱਖਿਆ, ਫਾਇਨੈਂਸ, ਲੀਗਲ, ਅਤੇ ਜਿਸ ਬਿਜ਼ਨੇਸ ਯੂਨਿਟ ਨੂੰ ਸਿਸਟਮ ਚਾਹੀਦਾ ਉਹ ਵੀ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇਹ ਲੰਮੇ ਸਮੇਂ, ਸਰਕਾਰੀ ਮੰਗਾਂ, ਅਤੇ ਅੰਦਰੂਨੀ ਰਾਜਨੀਤੀ ਨੂੰ ਲਿਆਉਂਦਾ ਹੈ।
ਓਰੈਕਲ ਨੇ ਇਸ ਹਕੀਕਤ ਵਿੱਚ ਦਿਲ਼ਚਸਪੀ ਲੀ ਕੇ PoC, ਸੰਦਰਭ ਗ੍ਰਾਹਕ ਅਤੇ ਵਿਸਥਾਰਤ ਅਨੁਕੂਲਤਾ ਦਾਵਿਆਂ ਨੂੰ ਅਪنਾਇਆ। ਇੱਕ PoC ਸਿਰਫ ਤਕਨੀਕੀ ਟੈਸਟ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਖਰੀਦ ਦਾ ਜਾਇਜ਼ਾ ਵਜੋਂ ਇਕ ਪ੍ਰਮੁੱਖ ਸਪੋਂਸਰ ਨੂੰ ਹੋਰਾਂ ਨੂੰ ਮਨਾਉਣ ਲਈ ਇਕ ਢੰਗ ਹੁੰਦਾ ਹੈ।
ਓਰੈਕਲ ਨੇ ਪਾਰੰਪਰਿਕ ਖਾਤਾ-ਆਧਾਰਤ ਵਿਕਰੀ ਬਣਾਈ: ਸਮਰਪਿਤ ਪ੍ਰਤੀਨਿਧ, ਨਾਮਿਤ ਖਾਤੇ, ਅਤੇ ਤਿਮਾਹੀ ਕਾਰੋਬਾਰੀ ਸਮੀਖਿਆਵਾਂ ਦੀ ਲਏਕ ਸੀ।
ਮਕਸਦ ਸਿਰਫ ਪਹਿਲੇ ਠੇਕੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਨਹੀਂ ਸੀ; ਇਹ ਅਗਲੇ ਪ੍ਰਾਜੈਕਟ ਲਈ ਡੀਫਾਲਟ ਡੇਟਾਬੇਸ ਚੋਣ ਬਣ ਜਾਣਾ ਸੀ। CIO ਜਾਂ ਡੇਟਾਬੇਸ ਟੀਮ ਨਾਲ ਭਰੋਸਾ ਬਜਟਾਂ, ਰੀਓਰਗ ਅਤੇ ਅਲਪਕਾਲੀਣ ਉਤਪਾਦ ਅਸੰਤੋਸ਼ ਤੋਂ ਵੀ ਲੰਬੇ ਸਮੇਂ ਲਈ ਰਹਿ ਸਕਦਾ ਹੈ।
ਸਪੋਰਟ ਠੇਕੇ, ਡੀਬੀਏ/ਡਿਵੈਲਪਰ ਸਰਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਸਿਸਟਮ ਇੰਟੀਗਰੇਟਰ ਮੋਮੈਂਟਮ ਬਣਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਇੱਕ ਕੰਪਨੀ ਨੇ ਟ੍ਰੇਨ ਕੀਤੇ ਕਰਮਚਾਰੀ, ਮਨਜ਼ੂਰ ਕੀਤੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਇੱਕ ਭਾਗੀਦਾਰ ਜੋ Oracle ਨੂੰ ਅੰਦਰੋਂ-ਬਾਹਰ ਜਾਣਦਾ ਹੈ, ਤਬ ਵਿਕਰੇਤ ਨੂੰ ਬਦਲਣਾ ਇਹੋ ਜਿਹਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜਿਵੇਂ ਜੋਖਮ ਵਧਾ ਰਹੇ ਹੋ।
ਭਾਗੀਦਾਰ ਵੀ RFPs ਵਿੱਚ ਕੀ ਸਿਫਾਰਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਕਿਹੜੀਆਂ ਹੁਨਰ ਉਪਲਬਧ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਪਲੇਟਫਾਰਮ "ਸੁਰੱਖਿਅਤ" ਮੰਨੇ ਜਾਂਦੇ ਹਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਨਵੀਨੀਕਰਨ ਨਵੇਂ ਲੋਗੋ ਤੋਂ ਜ਼ਿਆਦਾ ਮਤਲਬ ਰੱਖ ਸਕਦੇ ਹਨ। ਜੇ ਓਰੈਕਲ ਕੋਰ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵਿ:ਭੇਦ ਹੋਣ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਸਾਲਾਨਾ ਨਵੀਨੀਕਰਨ ਇੱਕ ਬਿਜ਼ਨੇਸ-ਕੰਟਿਨਿਊਟੀ ਨਿਰਣੈ ਬਣ ਜਾਂਦਾ ਹੈ, ਨਾਂ ਕਿ ਇੱਕ ਨਵਾਂ ਮੁਲਾਂਕਣ। ਇਹ ਉਹ ਵੇਲਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੀਮਤ, ਆਡਿਟ ਸਿਧਾਂਤ, ਅਤੇ ਠੇਕੇ ਦੀ ਸੰਰਚਨਾ ਵਰਤੋਂ ਅਤੇ ਉਤਪਾਦ ਫੀਚਰਾਂ ਦੋਹਾਂ ਨੂੰ ਆਕਾਰ ਦਿੰਦੇ ਹਨ。
(ਉਸ ਲੀਵਰਜ ਦੀ ਮਕੈਨਿਕਸ ਦੇ ਲਈ, ਵੇਖੋ /blog/how-lock-in-works.)
ਵੇਂਡਰ ਲਾਕ-ਇਨ ਲਈ ਮਾਲ਼ਕਾਨਾ ਇਰਾਦਾ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਇਹ ਇਕ ਵਿਕਰੇਤਾ ਦੇ ਉਤਪਾਦ 'ਤੇ ਵਧਦੀ ਨਿਰਭਰਤਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਣ ਦੀ ਲਾਗਤ ਵਧਦੀ ਹੈ। ਕੋਰ ਸਿਸਟਮ ਵਾਂਗ ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ, ਇਹ ਜੋੜ ਬਹੁਤ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਐਪਲੀਕੇਸ਼ਨ, ਰਿਪੋਰਟਿੰਗ, ਸੁਰੱਖਿਆ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਓਪਰੇਸ਼ਨ ਦੇ ਥੱਲੇ ਆਉਂਦਾ ਹੈ।
ਤਕਨੀਕੀ ਲਾਕ-ਇਨ ਤਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਸਿਸਟਮ ਉਹ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋਂਦੀਆਂ ਹਨ ਜੋ ਹੋਰ ਥਾਂ ਤੇ ਆਸਾਨੀ ਨਾਲ ਨਕਲ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ। ਡੇਟਾਬੇਸਾਂ ਵਿੱਚ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਫੀਚਰਾਂ (ਖਾਸ SQL ਐਕਸਟੈਂਸ਼ਨ, ਪ੍ਰਦਰਸ਼ਨ ਹਿੰਟ, ਕਲੱਸਟਰਿੰਗ ਤਰੀਕੇ), ਵੇਂਡਰ-ਖਾਸ ਟੂਲਿੰਗ, ਅਤੇ ਐਪ/ਮਿਡਲਵੇਅਰ ਨਾਲ ਘਣੀ ਇੰਟੈਗਰੇਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
ਭਾਵੇਂ "ਇਹ ਸਿਰਫ SQL ਹੈ", ਹਕੀਕਤ ਵਿੱਚ ਡਿਪਲੋਇਮੈਂਟ ਸਟੈਕ ਵਿੱਚ ਸਟੋਰਡ ਪ੍ਰੋਸੀਜਰ, ਟ੍ਰਿਗਰ, ਬੈਕਅੱਪ ਸਕ੍ਰਿਪਟ, ਮਾਨੀਟਰਿੰਗ ਏਜੰਟ ਅਤੇ ਕਸਟਮ ਕਨੇਕਟਰ ਆਦਿ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਇਹ ਸਟੈਕ ਕਿਸੇ ਇੱਕ ਡੇਟਾਬੇਸ ਲਈ ਟਿਊਨ ਹੋਵੀ, ਓਨਾ ਹੀ ਸਾਫ਼ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ।
ਆਪਰੇਸ਼ਨਲ ਲਾਕ-ਇਨ ਲੋਕਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬਾਰੇ ਹੈ। ਟੀਮਾਂ ਕਿਸੇ ਖਾਸ ਪਲੇਟਫਾਰਮ 'ਤੇ ਟ੍ਰੇਨ ਹੁੰਦੀਆਂ ਹਨ, ਇੱਕ ਖਾਸ ਸਰਟੀਫਿਕੇਸ਼ਨ ਰਾਹ ਪਕੜਦੀਆਂ ਹਨ, ਅਤੇ ਐਸੇ ਰਨਬੁੱਕ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਵਿਹਿਵਾਰ—ਜਿਵੇਂ ਫੇਲਓਵਰ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ, ਅਪਗਰੇਡ ਕਿਵੇਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਸਧਾਰਨ ਪ੍ਰਦਰਸ਼ਨ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ—ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੁੰਦੇ ਹਨ।
ਸਮੇਂ ਦੇ ਨਾਲ, ਕੌਂਪਲਾਇੰਸ ਅਤੇ ਆਡਿਟ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਵੀ ਡੇਟਾਬੇਸ-ਵਿਸ਼ੇਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ: ਐਕਸੇਸ ਕੰਟਰੋਲ, ਇਨਕ੍ਰਿਪਸ਼ਨ ਸੰਰਚਨਾਵਾਂ, ਰੀਟੇਨਸ਼ਨ ਨੀਤੀਆਂ, ਅਤੇ ਘਟਨਾ ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਦਮ। ਵੇਂਡਰ ਬਦਲਣਾ ਫਿਰ ਮਤਲਬ ਹੋ ਜਾਦਾ ਹੈ ਸਟਾਫ਼ ਨੂੰ ਦੁਬਾਰਾ ਟ੍ਰੇਨ ਕਰਨਾ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਲਿਖਣਾ ਅਤੇ ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵੈਰੀਫਾਈ ਕਰਨਾ।
ਸੰਝੌਤੀਗਤ ਲਾਕ-ਇਨ ਬਦਲਣ ਦੀ ਲਾਗਤ ਨੂੰ ਕੈਲੰਡਰ ਤੱਕ ਬਦੀਨ ਕਰ ਦਿੰਦਾ ਹੈ। ਕਈ ਸਾਲਾਂ ਦੇ ਟਰਮ, ਬੰਡਲਡ ਸਪੋਰਟ ਢਾਂਚੇ, ਨਵੀਨੀਕਰਨ ਚੱਕਰ ਅਤੇ ਸਾਰਥਕ-ਵਿਆਪਕ ਸਮਝੌਤੇ "ਅਸੀਂ ਅਗਲੇ ਕਵਾਰਟਰ ਵਿੱਚ ਬਦਲਾਂਗੇ" ਨੂਂ ਅਸੰਭਵ ਬਣਾ ਸਕਦੇ ਹਨ।
ਸਪੋਰਟ ਇੱਕ ਵੱਡਾ ਲੀਵਰ ਹੈ: ਜਦੋਂ ਮੈੱਜਰ ਸਿਸਟਮ ਵੈਂਡਰ ਸਹਾਇਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਤਾੰ ਛੱਡਣਾ ਇੱਕ ਨਵੇਂ ਓਪਰੇਸ਼ਨਲ ਜੋਖਮ ਵਰਗਾ ਲੱਗ ਸਕਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਜੇ ਠੇਕੇ ਵਿੱਚ ਕਠੋਰ ਵਰਤੋਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਅਤੇ ਸਜ਼ਾਵਾਂ ਹਨ ਜੋ ਅੰਸ਼ਕਤ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਔਖਾ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।
ਓਰੈਕਲ ਦੀ ਖਾਈ ਸਿਰਫ ਤਕਨੀਕੀ ਨਹੀਂ ਸੀ; ਇਹ ਆਰਥਿਕ ਸੀ—ਲਾਇਸੈਂਸਿੰਗ ਮਾਡਲਾਂ ਰਾਹੀਂ ਬਣਾਈ ਗਈ ਜੋ ਡੇਟਾਬੇਸ ਨੂੰ ਬਜਟਾਂ ਵਿੱਚ ਉੱਤੇ ਜ਼ੋਰ ਦੇਂਦੇ।
ਓਰੈਕਲ ਲਾਇਸੈਂਸਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਸਾਦੇ ਇਕਾਈਆਂ ਵਿੱਚ ਵੇਚੀ ਜਾਂਦੀ ਹੈ:
ਮੁੱਖ ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ਜਦੋਂ ਡੇਟਾਬੇਸ ਕੇਂਦਰੀ ਬਣ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਵਾਧਾ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਮੀਟਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਵਧਾਉਂਦਾ—ਵੱਧ ਕੋਰ, ਵੱਧ ਉਪਭੋਗਤਾ, ਜਾਂ ਵੱਧ ਫੀਚਰ।
ਜਦੋਂ ਪ੍ਰਾਈਸਿੰਗ ਵਿੱਚ ਕਈ ਨੋਬ ਹੁੰਦੇ ਹਨ—ਮੈਟਰਿਕਸ, ਛੂਟਾਂ, ਉਤਪਾਦ ਉਪਯੋਗ ਅਧਿਕਾਰ—ਤਾਂ ਗੱਲਬਾਤ ਉਸ ਪਾਰਟੀ ਵੱਲ ਝੁਕਦੀ ਹੈ ਜੋ ਨਿਯਮਾਂ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਸਮਝਦੀ ਹੈ।
ਜਟਿਲਤਾ ਗਾਹਕਾਂ ਲਈ ਕੁੱਲ ਲਾਗਤ ਦੀ ਅਨੇਕ ਸਾਲਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ ਮੁਸ਼ਕਲ ਕਰ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਉਹ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਜਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਵਿੱਚ ਅਸਮਰਥ ਰਹਿ ਜਾਂਦੇ ਹਨ।
ਓਰੈਕਲ (ਬਹੁਤ ਸਾਰੇ ਵੱਡੇ ਵੇਂਡਰਾਂ ਵਾਂਗ) ਲਾਇਸੈਂਸ ਸਮੀਖਿਆਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿ ਗਾਹਕ ਆਪਣੀ ਸਮਝੌਤਾ-ਸ਼ਰਤਾਂ ਦੇ ਅੰਦਰ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ। ਨਿਰਪੱਖ ਤੌਰ 'ਤੇ ਕੀਤਾ ਗਿਆ, ਆਡਿਟ ਦੋਹਾਂ ਪੱਖਾਂ ਦੀ ਸੁਰੱਖਿਆ ਕਰ ਸਕਦਾ ਹੈ।
ਵਾਸਤਵ ਵਿੱਚ, ਆਡਿਟ ਇੱਕ ਆਰਥਿਕ ਜੋਖਮ ਵੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਜੇ ਵਰਤੋਂ ਨੂੰ ਵੱਧ-ਤਾਸੀਰ ਨਾਲ ਵੇਖਿਆ ਜਾਵੇ ਤਾਂ ਗਾਹਕ ਨੂੰ ਤੁਰੰਤ ਲਾਇਸੈਂਸ ਸਹੀ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ।
ਸਾਲਾਨਾ ਸਪੋਰਟ ਨਵੀਨੀਕਰਨ—ਅਕਸਰ ਲਾਇਸੈਂਸ ਦਾ ਇੱਕ ਪ੍ਰਤੀਸ਼ਤ—ਨਵੀ ਵਿਕਰੀਆਂ ਧੀਮੀਆਂ ਹੋਣ 'ਤੇ ਵੀ ਥਿਰ ਰੇਵੇਨਿਊ ਬਣਾਉਂਦੇ ਰਹਿੰਦਾ ਹੈ। ਅਪਗਰੇਡ ਅਤੇ ਨਵੀਆਂ ਐਡੀਸ਼ਨਸ ਇੱਕ ਹੋਰ ਲੀਵਰ ਬਣ ਜਾਂਦੀਆਂ ਹਨ: ਗਾਹਕ ਸਹੀ, ਅਨੁਕੂਲ, ਅਤੇ ਸਪੋਰਟਡ ਰਹਿਣ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ, ਜੋ ਦੁਹਰਾਊ ਚੱਕਰ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ।
ਓਰੈਕਲ ਨੂੰ ਮੁਕਾਬਲਾ ਕਦੇ ਘੱਟ ਨਹੀਂ ਮਿਲਿਆ। ਜੋ ਅਜੀਬ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਕਿੰਨੀ ਵਾਰ ਗਾਹਕ ਵਿਕਲਪਾਂ ਦੀ ਮੁਲਾਂਕਣ ਕਰਦੇ—ਅਤੇ ਫਿਰ ਵੀ ਨਵੀਨੀਕਰਨ ਕਰ ਲੈਂਦੇ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ, IBM ਸਪੱਠਿਕ ਦੁਸ਼ਮਣ ਸੀ: DB2 ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਬਹੁਤ-ਸਾਰੇ ਕਾਰਯਭਾਰ ਕਰ ਰਿਹਾ ਸੀ। ਓਰੈਕਲ ਦਾ ਦਾਅਵਾ ਪੋਰਟੇਬਿਲਿਟੀ ਅਤੇ ਹਾਰਡਵੇਅਰ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸੀ, ਜੋ ਉਦੋਂ ਕੀਮਤੀ ਸੀ ਜਦੋਂ ਕੰਪਨੀਆਂ IBM ਮੇਨਫ੍ਰੇਮ ਤੋਂ ਬਾਹਰ ਵੱਧ ਰਹੀਆਂ ਸਨ।
1990 ਅਤੇ 2000 ਦੇ ਦਹਾਕਿਆਂ ਵਿੱਚ, Microsoft SQL Server ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਿਆ, ਖ਼ਾਸ ਕਰਕੇ ਡਿਪਾਰਟਮੈਂਟਲ ਅਤੇ ਮਿਡ-ਮਾਰਕੀਟ ਸਿਸਟਮਾਂ ਲਈ ਜੋ ਸਾਦਗੀ ਅਤੇ ਘੱਟ ਕੀਮਤ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਸਨ। ਬਹੁਤ ਵਾਰ ਇਹ "ਠੀਕ-ਠਾਕ" ਸੀ, ਅਤੇ ਨਵੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਵਾਸਤਵ ਵਿੱਚ ਕਾਫ਼ੀ ਸੀ।
ਫਿਰ ਓਪਨ ਸੋর্স ਗੰਭੀਰ ਕੰਮ ਲਈ ਯੋਗ ਹੋ ਗਿਆ। MySQL ਵੈੱਬ ਵਰਕਲੋਡਾਂ 'ਤੇ ਹਾਕਮ ਬਣਿਆ; PostgreSQL ਉਹ ਟਿਕਾਣਾ ਬਣਿਆ ਜਿੱਥੇ ਟੀਮਾਂ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗਰੇਡ ਫੀਚਰ ਚਾਹੁੰਦੀਆਂ ਪਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਲਾਇਸੈਂਸਿੰਗ ਨਹੀਂ ਚਾਹੁੰਦੀਆਂ।
ਡੇਟਾਬੇਸਾਂ ਨੂੰ ਅਲੱਗ ਨਹੀਂ ਖਰੀਦਿਆ ਜਾਂਦਾ। ਉਹ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਰਿਪੋਰਟਿੰਗ, ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਵਾਂ, ਕੌਂਪਲਾਇੰਸ-ਸਾਈਨ-ਆਫ ਅਤੇ ਵੇਂਡਰ ਸੰਬੰਧਾਂ ਵਿੱਚ ਲਪੇਟੇ ਜਾਂਦੇ ਹਨ।
ਲਾਇਸੈਂਸ ਫੀਸ 'ਤੇ ਬਚਤ ਵਾਸਤਵ ਵਿੱਚ ਮੌਜੂਦ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਅਕਸਰ ਐਪਲੀਕੇਸ਼ਨ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰਨ, ਸਟਾਫ਼ ਨੂੰ ਦੁਬਾਰਾ ਟ੍ਰੇਨ ਕਰਨ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਜੋਖਮ ਨੂੰ ਸਹਨ ਕਰਨ ਦੀ ਲਾਗਤ ਨਾਲ ਤੋਲਣ 'ਤੇ ਛੋਟਾ ਪੈ ਜਾਂਦੀ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਲਈ, ਡੇਟਾਬੇਸ ਉਹ ਸਿਸਟਮ ਹੈ ਜੋ ਕੰਮ ਕਰਨ 'ਤੇ ਘੱਟ ਦਿਖਾਈ ਦਿੰਦਾ ਅਤੇ ਨਾ ਕੰਮ ਕਰਨ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਦੋਸ਼ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਕਰਕੇ ਫੈਸਲਾ ਕਰਨ ਵਾਲੇ ਰੁਕਾਵਟ ਵਾਲੇ ਹੁੰਦੇ ਹਨ: ਉਹ ਜਿਆਦਾ ਭੁਗਤਾਨ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ ਬਜਾਏ ਉਸ ਟੀਮ ਲਈ ਹੋਣ ਵਾਲੀ ਜਿੰਮੇਵਾਰੀ ਲਈ ਜਿਸਨੇ "ਬਿਲਿੰਗ ਤੋੜ ਦਿੱਤੀ"।
ਡਾਟਾ ਨੂੰ ਹਿਲਾਉਣਾ ਸਿਰਫ ਪਹਿਲਾ ਕਦਮ ਹੈ। ਸਟੋਰਡ ਪ੍ਰੋਸੀਜਰ, SQL ਡਾਇਲੈਕਟ ਫਰਕ, ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ, ਬੈਕਅੱਪ/ਰੀਸਟੋਰ ਰੁਟੀਨ, ਮਾਨੀਟਰਿੰਗ, ਤੀਸਰੇ-ਪੱਖ ਟੂਲਿੰਗ, ਅਤੇ ਵੇਂਡਰ-ਸਰਟੀਫਾਇਡ ਐਪਲੀਕੇਸ਼ਨ ਇਨ੍ਹਾਂ ਸਭ ਦਾ ਨਿਰਭਰ ਹੋਣਾ Oracle-ਖਾਸ ਵਿਹਿਵਾਰ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ। ਠੇਕਿਆਂ ਅਤੇ ਆਡਿਟ ਇਤਿਹਾਸ ਵੀ ਘਿਸਟਣ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਨੇ ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਬਣਾਇਆ ਜਿਸ ਵਿੱਚ ਘੱਟ ਨੋਬ ਹੁੰਦੇ ਹਨ: AWS RDS/Aurora, Azure SQL, ਅਤੇ Google Cloud SQL (ਨਾਲ Spanner) ਖਾਸ ਕਰਕੇ ਤਕਨੀਕੀ DBA ਕੰਮ ਦੀ ਲੋੜ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ "ਪਰਖੋ" ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਇਹ ਅਸਲ ਮੁਕਾਬਲਾ ਹੈ—ਫੀਚਰਾਂ ਦੇ ਬਦਲੇ, ਬਦਲਣ ਦੀ ਲਾਗਤ ਘਟਾਉਣ ਬਾਰੇ।
ਓਰੈਕਲ ਨੇ ਆਪਣੀ ਪਾਸੇ-ਆਵਣ ਦੀ ਜਵਾਬੀ ਰਣਨੀਤੀ ਦਿਖਾਈ ਹੈ: ਆਪਣੀਆਂ ਮੈਨੇਜਡ ਸੇਵਾਵਾਂ ਨੂੰ ਧੱਕਾ ਦੇ ਕੇ ਅਤੇ ਦਲੀਲ ਦੇ ਕੇ ਕਿ ਓਰੈਕਲ 'ਤੇ ਚਲਾਉਣਾ ਅਜੇ ਵੀ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਸਥਾਨ ਹੈ।
ਓਰੈਕਲ ਇੱਕ ਡੇਟਾਬੇਸ ਕੰਪਨੀ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ, ਪਰ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ "ਇੱਕ ਡੇਟਾਬੇਸ" ਅਲੱਗ ਤੌਰ 'ਤੇ ਨਹੀਂ ਖਰੀਦਦੀਆਂ। ਉਹ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਨੂੰ ਖਰੀਦਦੀਆਂ ਹਨ ਜੋ ਫਾਇਨੈਂਸ, HR, ਸੇਲਜ਼ ਅਤੇ ਓਪਰੇਸ਼ਨ ਚਲਾਉਂਦੇ ਹਨ—ਅਤੇ ਉਹ ਸਿਸਟਮ ਡੇਟਾਬੇਸ ਲੇਅਰ ਲਈ ਲਗਾਤਾਰ ਮੰਗ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਇੱਕ ਆਮ ਨਮੂਨਾ ਹੈ ਕਿ ਮੌਜੂਦਾ ਪ੍ਰੋਡਕਟ ਦੀਟੈਲ ਨੂੰ ਵਧਾਉਣਾ ਦੁਆਰਾ ਕਾਇਮ ਐਪਲੀਕੇਸ਼ਨ ਵੇਂਡਰਾਂ ਨੂੰ ਖਰੀਦ ਕੇ, ਫਿਰ ਉਹ ਵਿਆਪਕ ਪੋਰਟਫੋਲਿਓ ਇੱਕੋ ਮੁੱਖ ਖਰੀਦਦਾਰਾਂ ਨੂੰ ਵੇਚਣਾ। ਇਕ ਇੱਕ-ਉਤਪਾਦ ਦੇ ਪ੍ਰਤੀ ਹਰੇਕ ਸੌਦੇ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਦੀ ਥਾਂ, ਵੇਂਡਰ ਕਈ ਮੋਡੀਊਲਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਜਿਹੜੇ ਇੱਕ ਪ੍ਰੋਕਿਊਰਮੈਂਟ ਮੋਸ਼ਨ ਵਿੱਚ ਫਿੱਟ ਹੋ ਜਾਂਦੇ ਹਨ: ਇੱਕ ਠੇਕਾ, ਇੱਕ ਖਾਤਾ ਟੀਮ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਪਸੰਦੀਦਾ ਟੈਕਨੀਕਲ ਸਟੈਕ।
ਓਰੈਕਲ ਨੇ ਸਮੇਂ ਦੇ ਨਾਲ ਅਧਿਗ੍ਰਹਣਾਂ ਰਾਹੀਂ ERP (enterprise resource planning) ਅਤੇ CRM ਵਰਗੀਆਂ ਬਿਜ਼ਨਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਆਪਣੀ ਕੈਟਾਲੌਗ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ, ਮਿਡਲਵੇਅਰ ਅਤੇ ਹੋਰ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਉਤਪਾਦਾਂ ਦੇ ਨਾਲ। ਇਹ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਸਿਲਕੀ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ, ਪਰ ਇਹ ਇਹ ਬਦਲ ਜਾਂਦਾ ਹੈ ਕਿ ਗਾਹਕ ਕਿਸ ਤਰ੍ਹਾਂ ਇੱਕ ਵੇਂਡਰ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ: "ਕੀ ਅਸੀਂ ਆਪਣੀਆਂ ਕੋਰ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਇਕ ਪ੍ਰੋਵਾਈਡਰ 'ਤੇ ਸਟੈਂਡਰਡਾਈਜ਼ ਕਰ ਸਕਦੇ ਹਾਂ?" ਇੱਕ ਜ਼ਿੰਮੇਵਾਰ ਸਵਾਲ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਕੋਈ ਕੰਪਨੀ ਆਪਣੇ ਨਰਮ-ਵੇਅਰ ਸਟੈਕ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ, ਤਦ ਡੇਟਾਬੇਸ ਇੱਕ ਅਲੱਗ ਲਾਈਨ ਆਈਟਮ ਨਾਂ ਰਹਿ ਕੇ ਇੱਕ ਸਮਵੀਤ ਨਿਰਭਰਤਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇ ERP ਡਿਪਲੋਇਮੈਂਟ Oracle Database 'ਤੇ ਡਿਜ਼ਾਈਨ, ਟੈਸਟ ਅਤੇ ਸਪੋਰਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਪ੍ਰੋਕਿਊਰਮੈਂਟ ਚੋਣ ਅਕਸਰ ਡੇਟਾਬੇਸ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਰੱਖਣੀ ਹੁੰਦੀ ਹੈ।
ਇਹ ਗਤੀਵਿਧੀ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਪੂਲ-ਥਰੂ: ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਵਿਕਰੀ ਡੇਟਾਬੇਸ ਦੀ ਵਿਕਰੀ (ਅਤੇ ਨਵੀਨੀਕਰਨ) ਦੀ ਸੰਭਾਵਨਾ ਵਧਾ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਭਰੋਸੇਯੋਗਤਾ, ਸਹਾਇਤਾ ਦੀਆਂ ਹੱਦਾਂ, ਅਤੇ ਅਪਗਰੇਡ ਯੋਜਨਾ ਸੁਲਝੀ ਹੋਵੇ ਤਾਂ ਹਿੱਸੇ ਮਿਲ ਕੇ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ।
ਬਨਡਲਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਕਈ ਉਤਪਾਦਾਂ ਨੂੰ ਇਕੱਠੇ ਪੈਕੇਜ ਕਰਨ—ਵਪਾਰਕ ਜਾਂ ਓਪਰੇਸ਼ਨਲ ਰੂਪ ਵਿੱਚ—ਤਾਂ ਕਿ ਇੱਕੋ ਵੇਂਡਰ ਤੋਂ ਵੱਧ ਖਰੀਦਣਾ ਵੱਖ-ਵੱਖ ਵਿਕਲਪਾਂ ਨੂੰ ਜੋੜਨ ਨਾਲੋਂ ਆਸਾਨ ਲੱਗੇ।
ਪਲੇਟਫਾਰਮ ਰਣਨੀਤੀ ਲੰਬੇ ਸਮੇਂ ਵਾਲੀ ਵਰਜਨ ਹੈ: ਸਾਂਝੇ ਆਈਡੀ ਮੈਨੇਜਮੈਂਟ, ਮਾਨੀਟਰਿੰਗ ਟੂਲ, ਇੰਟੇਗਰੇਸ਼ਨ ਕਨੈਕਟਰ, ਅਤੇ ਮਿਆਰੀਕ੍ਰਿਤ ਡਿਪਲੋਇਮੈਂਟ ਪੈਟਰਨ।
ਖਰੀਦਦਾਰਾਂ ਲਈ ਫਾਇਦਾ ਘੱਟ ਵਿਕਰੇਤਿਆਂ ਅਤੇ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ। ਵਪਰੀ-ਸਲਾਹ ਇਹ ਹੈ ਕਿ ਹਰ ਵਧੀਕ ਪਰਤ ਭਵਿੱਖ ਵਿੱਚ ਬਦਲਣ ਦੀ ਲਾਗਤ ਵਧਾ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ, ਮਿਡਲਵੇਅਰ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇੱਕ ਜੁੜੇ ਹੋਏ ਸਿਸਟਮ ਵਾਂਗ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ।
ਦਹਾਕਿਆਂ ਲਈ, ਓਰੈਕਲ ਇੱਕ ਸਧਾਰਨ ਪੈਟਰਨ 'ਤੇ ਫਲੇ: ਇੱਕ ਵੱਡੀ ਅੱਗੇ-ਭੁਗਤਾਨ ਲਾਇਸੈਂਸ ਵੇਚੋ, ਫਿਰ ਸਾਲਾਨਾ ਸਪੋਰਟ ਬਟੋਰੋ। ਕਲਾਉਡ ਕਮਪਿਊਟਿੰਗ ਨੇ ਉਸ ਲਹਿਜੇ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਰੱਖਿਆ। ਗਾਹਕ ਪਰਮਾਪਤ ਰਹਿਤ ਸੋਫਟਵੇਅਰ ਦੇ ਕੀਮਤ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ ਖਰੀਦਦੇ, ਉਹ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਅਤੇ ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ ਕਲਾਉਡ ਪ੍ਰੋਵਾਇਡਰਾਂ ਤੋਂ ਕਿਰਾਏ 'ਤੇ ਲੈ ਸਕਦੇ ਹਨ—ਅਕਸਰ ਤੇਜ਼ ਪ੍ਰੋਕਿਊਰਮੈਂਟ, ਆਸਾਨ ਸਕੇਲਿੰਗ, ਅਤੇ ਮਹੀਨੇ-ਬਨਾਮ-ਮਹੀਨੇ ਖਰਚਾਂ ਨਾਲ।
ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਨੇ ਜਿਸ ਦੇਣ-ਨਿਆਂਚਾਲੂ ਵਾਤਾਵਰਨ 'ਤੇ ਨਿਯੰਤਰਣ ਕੀਤਾ, ਉਹ ਬਦਲ ਦਿੱਤਾ। ਜੇ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਕਿਸੇ ਹੋਰ ਦੇ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ 'ਤੇ ਚਲ ਰਿਹਾ ਹੈ—ਅਤੇ ਮੁਕਾਬਲੇ ਵਾਲੇ ਡੇਟਾਬੇਸ ਇੱਕ ਕਲਿਕ 'ਤੇ ਉਪਲਬਧ ਹਨ—ਤਾਂ ਪ੍ਰਾਈਸਿੰਗ ਸ਼ਕਤੀ ਅਤੇ ਨਵੀਨੀਕਰਨ ਹਥਿਆਰ ਕਮਜ਼ੋਰ ਹੋ ਸਕਦੇ ਹਨ।
ਕਲਾਉਡ ਅਪਣਾਉਣ ਨਾਲ ਫਾਇਨੈਂਸ ਟੀਮਾਂ ਨੂੰ ਵੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਖ਼ਰਚਾਂ ਵੱਲ ਧੱਕਿਆ ਗਿਆ, ਜਿਸ ਨਾਲ ਵੱਡੇ ਲਾਇਸੈਂਸ ਡੀਲਾਂ ਨੂੰ ਜਸਟਿਫਾਈ ਕਰਨਾ ਔਖਾ ਹੋ ਗਿਆ।
ਓਰੈਕਲ ਨੇ ਇੱਕੋ ਸਮੇਂ ਦੋ ਗਤੀਵਿਧੀਆਂ ਤੇ ਧੱਕਾ ਦਿੱਤਾ:
ਖਰੀਦਦਾਰਾਂ ਲਈ, ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ ਖ਼ਰਚਾਂ ਘਟਾਉਣਗੇ: ਪੈਚਿੰਗ ਅਤੇ ਬੈਕਅੱਪ ਆਟੋਮੇਟ ਹੁੰਦੇ ਹਨ, HA ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਬਣਦਾ ਹੈ, ਅਤੇ ਸਮਰੱਪਤਾ ਬਿਨਾ ਲੰਮੇ ਹਾਰਡਵੇਅਰ ਚੱਕਰਾਂ ਦੇ ਸਕੇਲਿੰਗ ਕਰ ਸਕਦੀ ਹੈ।
ਭਾਵੇਂ ਲਾਇਸੈਂਸ ਆਰਥਿਕਤਾ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਵੱਲ ਵੱਧੇ, ਇਹ ਤਾਂਲ-ਮੇਚ ਕਰਨ ਯੋਗ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਡਾਊਨਟਾਈਮ ਜੋਖਮ ਘਟਾਉਂਦਾ ਅਤੇ ਅੰਦਰੂਨੀ ਟੀਮਾਂ ਨੂੰ ਆਜ਼ਾਦ ਕਰਦਾ ਹੈ।
ਕੋਈ ਵੀ ਵੱਡੀ ਕੰਪਨੀ ਇਕੋ ਸਮੇਂ ਸਭ ਕੁਝ ਨਹੀਂ ਮੂਵ ਕਰਦੀ। ਆਮ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਿਤ Oracle ਵਰਕਲੋਡ ਸਾਲਾਂ ਤੱਕ ਆਨ-ਪ੍ਰੇਮ ਰਹਿ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਨਵੇਂ ਸਿਸਟਮ ਕਲਾਉਡ ਵਿੱਚ ਬਣਾਏ ਜਾਂਦੇ ਹਨ—ਕਦੇ OCI 'ਤੇ Oracle, ਕਦੇ ਹੋਰ ਕਲਾਉਡ 'ਤੇ, ਅਕਸਰ ਇਨਟੀਗਰੇਸ਼ਨ ਗਲੂ ਨਾਲ।
ਇਸ ਮਿਲੀ-ਝੁਲੀ ਦੁਨੀਆ ਵਿੱਚ, ਓਰੈਕਲ ਦਾ ਲਕੜਾ ਸਿੱਧਾ ਹੈ: ਜਿੱਥੇ ਵੀ ਗਾਹਕ ਚਲੇ, ਡੀਫਾਲਟ ਡੇਟਾਬੇਸ ਬਣੇ ਰਹੋ।
ਲਾਕ-ਇਨ ਹਮੇਸ਼ਾਂ ਵੈਂਡਰ ਦੁਆਰਾ ਰਚਿਆ ਚਾਲ ਨਹੀਂ ਹੁੰਦਾ; ਇਹ ਅਕਸਰ ਸਮੇਂ ਦੀ ਕਮੀ 'ਚ ਕੀਤੇ ਸਹੀ ਲਗਦੇ ਚੋਣਾਂ ਦਾ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ। ਲਕੜੀ ਇਹ ਨਹੀਂ ਕਿ "ਕਦੇ ਕਮਿਟ ਨਾ ਕਰੋ"—ਇਹ ਹੈ ਖੁੱਲ੍ਹੀ ਅੱਖਾਂ ਨਾਲ ਕਮਿਟ ਕਰੋ ਅਤੇ ਇੱਕ ਐਕਜ਼ਿਟ ਯੋਜਨਾ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਭੁਗਤ ਸਕੋ।
ਦਸਤਖਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਛੋਟੀ "ਭਵਿੱਖ ਮਾਈਗ੍ਰੇਸ਼ਨ" ਵਰਕ ਆਉਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਅਸਲ ਪ੍ਰੋਜੈਕਟ ਵਾਂਗ ਕੀਮਤ ਕਰੋ।
ਛੋਟੇ ਠੇਕੇ ਕਲਾਜ਼ ਬੜੀਆਂ ਸਵਿੱਚਿੰਗ ਲਾਗਤ ਬਣਾਉ ਸਕਦੇ ਹਨ।
ਧਿਆਨ ਦਿਓ: ਨਵੀਨੀਕਰਨ ਦੀਆਂ ਸ਼ਰਤਾਂ, ਸਪੋਰਟ ਕੀਮਤ ਵੱਧਣਾ, ਅਤੇ ਆਡਿਟ ਭਾਸ਼ਾ (ਕੀ ਆਡਿਟ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ, ਨੋਟਿਸ ਪੀਰੀਅਡ, ਅਤੇ ਵਰਤੋਂ ਕਿਵੇਂ ਮਾਪੀ ਜਾਂਦੀ ਹੈ)। ਇਹ ਵੀ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਡਿਪਲੋਇਮੈਂਟ ਮਾਡਲ—ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ, ਕੰਟੇਨਰ, DR, ਅਤੇ dev/test—ਠੇਕੇ ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।
ਬੈਚਮਾਰਕਿੰਗ ਵਰਤੋਂ ਕਰੋ ਤਾਂ ਜੋ ਬਰਾਬਰ ਲੋਡਾਂ 'ਤੇ ਵਿਕਲਪਾਂ ਤੁਲਨਾ ਕੀਤੀਆਂ ਜਾ ਸਕਣ, ਨਾ ਕਿ ਮਾਰਕੀਟਿੰਗ ਨੰਬਰਾਂ 'ਤੇ। ਲਾਇਸੈਂਸਾਂ ਨੂੰ ਹਾਲ ਦੀ ਵਰਤੋਂ ਅਤੇ ਨੇੜਲੇ ਵਿਕਾਸ ਲਈ ਸਮਾਨ ਰੱਖੋ, ਨਾ ਕਿ ਸਭਤੋਂ ਵੱਡੇ ਪੈਮਾਨੇ ਉਤੇ।
ਵਰਤੋਂ ਪਾਰਦਰਸ਼ੀਤਾ ਲਈ ਜ਼ੋਰ ਦਿਓ: ਸਪਸ਼ਟ ਮੈਟਰਿਕਸ, ਰਿਪੋਰਟਿੰਗ ਤੱਕ ਪਹੁੰਚ, ਅਤੇ ਸਵੈ-ਆਡਿਟ ਕਰਨ ਦਾ ਹੱਕ।
ਜੇ ਤੁਹਾਨੂੰ ਲਾਗਤ ਦਾ ਅੰਦਾਜ਼ਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਆਪਣੇ ਵਿਆਪਕ ਵੈਂਡਰ ਖਰਚ ਯੋਜਨਾ ਅਤੇ ਅੰਦਰੂਨੀ ਚਾਰਜਬੈਕ ਨਾਲ ਜੋੜੋ (ਦੇਖੋ /pricing)।
ਇੱਕ ਆਧੁਨਿਕ ਮੋੜ ਇਹ ਹੈ ਕਿ ਟੀਮਾਂ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਇਕੱਠਾ ਕਰ ਸਕਦੀਆਂ ਹਨ। vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਨੂੰ ਇਕ ਸਧਾਰਨ ਚੈਟ ਇੰਟਰਫੇਸ ਤੋਂ веб ਐਪ (React), ਬੈਕਐਂਡ (Go + PostgreSQL), ਅਤੇ ਮੋਬਾਈਲ (Flutter) ਬਣਾਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦੇ ਹਨ—ਅਕਸਰ ਦਿਨਾਂ ਵਿੱਚ।
ਉਸ ਤੇਜ਼ੀ ਦੀ ਤਾਕਤ ਹੈ, ਪਰ ਉਹੀ ਸਿਧਾਂਤ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਲਚਕੀਲਾ ਰੱਖਦਾ ਹੈ। ਪ੍ਰਯੋਗਿਕ "ਅਕਸਮਾਤ-ਲਾਕ-ਇਨ-ਰੋਕਥਾਮ" ਫੀਚਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ, ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ ਵਿਕਲਪ। (Koder.ai ਇਹਨਾਂ ਨੂੰ ਸਹਾਰਤਾਹੈ, ਅਤੇ ਇੱਕ ਯੋਜਨਾ ਮੋਡ ਵੀ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵੱਡਾ ਕੋਡ ਸਤਹ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜਾਂ ਦੀ ਨਕਸ਼ਾ ਛਾਨ ਸਕੋ।)
ਓਰੈਕਲ ਦੀ ਕਹਾਣੀ ਸਿਰਫ "ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਨੂੰ ਸੌਫਟਵੇਅਰ ਵੇਚੋ" ਨਹੀਂ ਹੈ। ਇਹ ਇਸ ਦੀ ਇੱਕ ਕੇਸ ਅਧਿਐਨ ਹੈ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਇੱਕ ਉਤਪਾਦ ਇੱਕ ਸੰਸਥਾ ਦਾ ਸਥਾਈ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ—ਅਤੇ ਆਖਿਰਕਾਰ ਉਹ ਟਿਕਾਊ ਅਰਥ ਸ਼ਕਤੀ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਓਰੈਕਲ ਨੇ "ਇਹ ਇਕ ਚੰਗੀ-ਹੋਣ ਵਾਲੀ ਚੀਜ਼" ਹੋ ਕੇ ਜਿੱਤਿਆ ਨਹੀਂ। ਡੇਟਾਬੇਸ ਉਹ ਥਾਂ ਬਣ ਗਿਆ ਜਿੱਥੇ ਨਿ:ਸ਼ਚਿਤ ਡੇਟਾ ਰਹਿੰਦਾ ਸੀ, ਅਤੇ ਕਾਰੋਬਾਰ ਉਸ ਹਕੀਕਤ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਵਰਤਿਆ ਗਿਆ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੰਪਨੀ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਵੈਜ ਖੋਜੋ ਜੋ:
ਚੇਤਾਵਨੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਕੇਂਦਰੀ ਤੁਸੀਂ ਹੋ, ਉਤਨਾ ਹੀ ਜ਼ਿਆਦਾ ਭਰੋਸਾ ਕਮਾਉਣਾ ਲਾਜਮੀ ਹੈ। ਜੇ ਗਾਹਕ ਮਹਿਸੂਸ ਕਰਨ ਕਿ ਉਹ ਫਸ ਰਹੇ ਹਨ ਬਿਨਾਂ ਲਗਾਤਾਰ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕੀਤੇ, ਤਾਂ ਉਹ ਤੁਹਾਨੂੰ ਆਖਿਰਕਾਰ ਬਾਹਰ ਕੱਢਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਲੈਣਗੇ।
ਓਰੈਕਲ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਵਧੀਆ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕਾਰੋਬਾਰ ਅਕਸਰ ਨਵੀਨੀਕਰਨ ਮਸ਼ੀਨ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਸਦੀਵੀ "ਨਵੇਂ ਲੋਗੋ" ਮਸ਼ੀਨਾਂ। ਉੱਚ ਬਦਲਣ ਲਾਗਤਾਂ ਰੈਵਨਿਊ ਨੂੰ ਸਥਿਰ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਸਭ ਤੋਂ ਵਧੀਆ ਸਿਗਨਲ ਇਹ ਹੈ ਕਿ ਗਾਹਕ ਵਿਕਲਪ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਨਵੀਨੀਕਰਨ ਕਰਨਾ ਚੁਣਦੇ ਹਨ।
ਖੋਜੋ:
ਲਾਕ-ਇਨ ਸਿਰਫ ਤਕਨੀਕੀ ਨਹੀਂ—ਇਹ ਆਪਰੇਸ਼ਨਲ ਅਤੇ ਸੰਝੌਤੀਗਤ ਵੀ ਹੈ। ਲਚਕ ਲਈ ਬੇਹਤਰ ਸਮਾਂ ਉਹ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਮਜਬੂਤ ਸਥਿਤੀ ਹੈ।
ਪ੍ਰਾਇਗਮੈਟਿਕ ਕਦਮ:
ਓਰੈਕਲ ਨੇ ਅਸਲ ਮੁੱਲ ਦਿੱਤਾ: ਭਰੋਸੇਯੋਗਤਾ, ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਕਾਰੋਬਾਰ ਚਲਾਉਣ ਦਾ ਇੱਕ ਮਿਆਰੀ ਤਰੀਕਾ। ਲਾਗਤ ਉਹਨਾਂ ਵੇਲੇ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਨਿਰਭਰਤਾ negotiated ਸ਼ਕਤੀ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ ਜਾਂ ਬਦਲਾਅ ਨੂੰ ਸੌਂਚਣ ਵਿੱਚ ਰੁਕਾਵਟ ਆਉਂਦੀ ਹੈ।
ਆਧੁਨਿਕ ਸਬਕ ਇਹ ਹੈ ਕਿ ਲੰਬੇ-ਸਮੇਂ ਦੇ ਰਿਸ਼ਤੇ ਉਸ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਲਗਾਤਾਰ ਮੁੱਲ ਦਿਖਾਉਂਦੇ ਰਹੋ—ਤੇ ਗਾਹਕਾਂ ਨੂੰ ਵਿਕਾਸ ਦਾ ਰਾਸਤਾ ਵੀ ਦਿਓ। ਇਹੋ ਤਰੀਕੇ ਨਾਲ ਤੁਸੀਂ ਲੰਬੇ ਸਮੇਂ ਦੇ ਸੰਬੰਧ ਬਣਾਉਗੇ ਬਿਨਾਂ ਲੰਬੇ ਸਮੇਂ ਦੀ ਨਫ਼ਰਤ ਪੈਦਾ ਕੀਤੇ।
"ਟਿਕਾਉ" ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਕਾਰੋਬਾਰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਬਣਿਆ ਹੋਇਆ ਹੈ ਕਿ ਆਮਦਨ ਮੁੜ-ਮੁੜ ਆਉਂਦੀ ਰਹੇ — ਭਾਵੇਂ ਗਾਹਕ ਹਰ ਨਵੀਨੀਕਰਨ ਵਿੱਚ ਖੁਸ਼ ਨਾ ਹੋਣ।
ਲੈਰੀ ਐਲਿਸਨ ਅਤੇ ਓਰੈਕਲ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਟਿਕਾਊਪਨ ਦੇ ਸਤਰ ਸ਼ਾਮਲ ਸਨ:
ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਉਨ੍ਹਾਂ ਸਿਸਟਮਾਂ ਦੇ ਥੱਲੇ ਬੈਠਦਾ ਹੈ ਜੋ ਕਾਰੋਬਾਰ ਚਲਾਉਂਦੇ ਹਨ: ਬਿਲਿੰਗ, ਪੇਰੋਲ, ਇਨਵੈਂਟਰੀ, ਟ੍ਰੇਡਿੰਗ, ਅਨੁਸੂਚਨਾ ਰਿਪੋਰਟਿੰਗ।
ਜਦੋਂ ਡੇਟਾਬੇਸ ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਆਊਟੇਜ ਜਾਂ ਡੇਟਾ ਘਾਟਾ ਵਿਅਾਪਾਰਕ ਅਤੇ ਨਿਯਮਕ ਜੋਖਮ ਪੈਦਾ ਕਰਦੇ ਹਨ — ਇਸ ਲਈ ਖਰੀਦਦਾਰ ਨਵੇਂ ਹੋਣ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਸਥਿਰਤਾ ਅਤੇ ਸਾਬਤ ਸਹਾਇਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ।
ਅਸਲ ਵਿੱਚ ਨਹੀਂ। SQL ਇੱਕ ਮਿਆਰੀ ਭਾਸ਼ਾ ਹੈ, ਪਰ ਉਦੋਂਤਾ ਸੰਸਥਾਵਾਂ "ਸਿੰਟੈਕਸ" ਨਹੀਂ ਖਰੀਦਦੀਆਂ — ਉਹ ਨਤੀਜੇ ਖਰੀਦਦੀਆਂ ਹਨ: ਉਪਲਬਧਤਾ, ਰਿਕਵਰੀ, ਭਾਰ ਥੱਲੇ ਪ੍ਰਦਰਸ਼ਨ, ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ, ਟੂਲਿੰਗ ਅਤੇ ਸਹਾਇਤਾ।
ਦੋ ਉਤਪਾਦ SQL "ਗੱਲਬਾਤ" ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਨਮਾਇਕੀ ਤੌਰ 'ਤੇ ਬਹੁਤ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ:
ਸਵਿੱਚਿੰਗ ਲਾਗਤ ਸਮੇਂ ਦੇ ਨਾਲ ਜੋੜੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਆਮ ਸਰੋਤ ਸ਼ਾਮਲ ਹਨ:
ਬਦਲਣ ਦਾ ਖ਼ਤਰਾ ਅਕਸਰ ਬਚਤ ਨਾਲੋਂ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਭਾਵੇਂ ਵਿਕਲਪ ਸਸਤੇ ਹੋਣ।
ਓਰੈਕਲ ਕੰਮ ਦੀ ਟੀਮਾਂ ਅਤੇ ਲੰਬੇ ਪ੍ਰੋਕਿਊਰਮੈਂਟ ਚੱਕਰਾਂ ਲਈ ਵਿਕਦੀ ਸੀ ਅਤੇ ਖਾਤਿਆਂ ਨੂੰ ਲੰਬੇ-ਮਿਆਦੀ ਰਿਸ਼ਤੇ ਵਾਂਗ ਸੰਭਾਲਦੀ ਸੀ।
ਆਮ ਤਰਕੀਬਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਸਨ:
ਕਈ ਵਾਰ ਨਵੀਨਤਾ ਦੀ ਥਾਂ ਬਿਜ਼ਨੇਸ-ਕੰਟਿਨਿਊਟੀ ਨਿਰਣੈ ਹੁੰਦਾ ਹੈ।
ਜੇ ਡੇਟਾਬੇਸ ਮੁੱਖ ਕਰਯਾਂ ਨੂੰ ਸਹਾਰਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਨਵੀਨੀਕਰਨ ਇੱਕ ਕਾਰੋਬਾਰੀ ਜਾਰੀ ਰੱਖਣ ਦਾ ਫੈਸਲਾ ਬਣ ਜਾਂਦਾ ਹੈ — ਨਵੀਂ ਖਰੀਦਦੀ ਚਰਚਾ ਨਹੀਂ। ਇਹ ਗੱਲ ਮੁਲਾਂਕਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ ਅਤੇ ਗੱਲ-ਬਾਤ ਨੂੰ "ਕੀ ਖਰੀਦਣਾ ਚਾਹੀਦਾ ਹੈ?" ਤੋਂ "ਕੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਾਂ?" ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ, ਜੋ ਕਿ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
ਇਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਮੁੱਲ ਨਿਰਧਾਰਨ, ਆਡਿਟ ਧਾਰਾਂ, ਅਤੇ ਸਹਾਇਤਾ ਨੀਤੀਆਂ ਵੱਡਾ ਪ੍ਰਭਾਵ ਪਾਂਦੀਆਂ ਹਨ।
ਤਿੰਨ ਪਰਤਾਂ ਅਕਸਰ ਇਕ-ਦੂਜੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੀਆਂ ਹਨ:
ਜੇ ਤੁਸੀਂ ਮਕੈਨਿਕਸ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪੋਸਟ /blog/how-lock-in-works ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੀ ਹੈ।
ਓਰੈਕਲ ਦੀ ਖਾਈ ਸਿਰਫ ਤਕਨੀਕੀ ਨਹੀਂ ਸੀ — ਇਹ مالی ਵੀ ਸੀ। ਲਾਇਸੈਂਸਿੰਗ ਮਾਡਲ ਉਹਨਾਂ ਬਜਟਾਂ ਵਿੱਚ ਡੇਟਾਬੇਸ ਨੂੰ ਜ਼ਿਆਦਾ ਜੋੜ ਦਿੰਦੇ ਸਨ।
ਆਮ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਲੈਵਰ:
ਜਦੋਂ ਮੁੱਲ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਨੋਬ ਹੁੰਦੇ ਹਨ, ਗਾਹਕਾਂ ਲਈ ਕੁੱਲ ਲਾਗਤ ਦਾ ਮਾਡਲ ਬਣਾਉਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵਿਕਲਪਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਆਡਿਟ (ਲਾਇਸੈਂਸ ਰੀਵਿਊ) ਇਕ ਚੈੱਕ ਹੁੰਦਾ ਹੈ ਕਿ ਵਰਤੋਂ/contracts ਸ਼ਰਤਾਂ ਦੇ ਅਨੁਸਾਰ ਹੈ ਜਾਂ ਨਹੀਂ।
ਵਾਸਤਵ ਵਿੱਚ ਇਸਦੇ ਨਤੀਜੇ ਇਹ ਹੋ ਸਕਦੇ ਹਨ:
ਟੀਮਾਂ ਖਤਰਾ ਘਟਾਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਡਿਪਲੋਇਮੈਂਟ ਟਰੈਕ ਰੱਖਦੀਆਂ, ਮੈਟਰਿਕ ਪਰਿਭਾਸ਼ਾਵਾਂ ਸਮਝਦੀਆਂ, ਅਤੇ ਸਪਸ਼ਟ ਅੰਦਰੂਨੀ ਵਰਤੋਂ ਰਿਪੋਟਿੰਗ ਰੱਖਦੀਆਂ ਹਨ।
ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਨਹੀਂ — ਕਲਾਉਡ ਲਾਕ-ਇਨ ਦੀ ਆਕਾਰ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਪਰ ਖਤਮ ਨਹੀਂ ਕਰਦਾ।
ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ ਓਪਰੇਸ਼ਨਲ ਭਾਰ ਘਟਾ ਸਕਦੇ ਹਨ (ਪੈਚਿੰਗ, ਬੈਕਅੱਪ, HA ਆਟੋਮੇਟ), ਪਰ ਤੁਸੀਂ ਹਾਲਾਂਕਿ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਜਾਰੀ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ:
ਅਨੇਕ ਸੰਸਥਾਵਾਂ ਸਾਲਾਂ ਤੱਕ ਹਾਈਬ੍ਰਿਡ ਰਿਹਾ ਕਰਦੀਆਂ ਹਨ — ਆਂ-ਪ੍ਰੇਮ Oracle, ਹੋਰ ਕਲਾਉਡ 'ਤੇ Oracle, ਜਾਂ ਮਿਸ਼ਰਤ ਪੈਟਰਨ।