ਐਪ ਜਦੋਂ ਮੁੜ ਲਿਖੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਡੇਟਾਬੇਸ ਅਕਸਰ ਦਹਾਕਿਆਂ ਤੱਕ ਰਹਿ ਜਾਂਦੇ ਹਨ। ਜਾਣੋ ਕਿਉਂ ਡੇਟਾ ਅੱਡੀ ਰਹਿੰਦਾ ਹੈ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਹਿੰਗੀਆਂ ਕਿਉਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਅਜੇਹੀ ਸਕੀਮਾ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜਿਹੜੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਿਕਸਿਤ ਹੋ ਸਕੇ।
ਜੇ ਤੁਸੀਂ ਕੁਝ ਸਾਲ ਸੌਫਟਵੇਅਰ ਦੇ ਨਜ਼ਦੀਕ ਕੰਮ ਕੀਤਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਕਹਾਣੀ ਦਰਅਸਲ ਵਾਰ-ਵਾਰ ਦੇਖੀ ਹੋਵੇਗੀ: ਐਪ ਨੂੰ ਰੀਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਮੁੜ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਰੀਬ੍ਰੈਂਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ—ਜਦਕਿ ਡੇਟਾਬੇਸ ਚੁੱਪਚਾਪ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।
ਕਿਸੇ ਕੰਪਨੀ ਨੇ ਡੈਸਕਟੌਪ ਐਪ ਤੋਂ ਵੈੱਬ ਐਪ, ਫਿਰ ਮੋਬਾਈਲ, ਫਿਰ ਨਵੇਂ ਫਰੇਮਵਰਕ ਨਾਲ "v2" ਵਜੋਂ ਬਦਲ ਸਕਦੀ ਹੈ। ਫਿਰ ਵੀ ਗਾਹਕ ਰਿਕਾਰਡ, ਆਰਡਰ, ਇਨਵਾਇਸ ਅਤੇ ਪ੍ਰੋਡਕਟ ਕੈਟਲੌਗ ਅਕਸਰ ਇੱਕੋ ਹੀ ਡੇਟਾਬੇਸ (ਜਾਂ ਉਸਦਾ ਸਿੱਧਾ ਵਾਰਿਸ) ਵਿੱਚ ਹੀ ਰਹਿੰਦੇ ਹਨ, ਕਈ ਵਾਰ ਉਹ ਟੇਬਲਾਂ ਜੋ ਇੱਕ ਦਹਾਕੇ ਪਹਿਲਾਂ ਬਣੀਆਂ ਹੋਣ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਇੰਟਰਫੇਸ ਅਤੇ ਬਿਹੈਵਿਅਰ ਹੈ, ਅਤੇ ਇਹ ਬਦਲਦਾ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਨੂੰ ਬਦਲਣਾ ਅਕਸਰ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਯਾਦ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਬਦਲਣਾ ਖਤਰਨਾਕ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਹ ਇਤਿਹਾਸ ਰੱਖਦਾ ਹੈ ਜਿਸ ਤੇ ਕਾਰੋਬਾਰ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਸਧਾਰਣ ਨਾ-ਟੈਕਨੀਕਲ ਉਦਾਹਰਨ: ਤੁਸੀਂ ਇੱਕ ਦੁਕਾਨ ਦੀ ਨਵੀਂ ਸ਼ੇਲਫ, ਨਵੇਂ ਚੈੱਕਆਊਟ ਕਾਊੰਟਰ, ਨਵੀਂ ਸਾਈਨਬੋਰਡ ਲਗਾ ਕੇ ਦੁਕਾਨ ਦਾ ਨਵੇਂ ਰੂਪ ਦੇ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਇਨਵੈਂਟਰੀ ਰਿਕਾਰਡ ਅਤੇ ਰਸੀਦਾਂ ਨੂੰ ਸੁੱਟਣ ਦੇ। ਨਵੀਨੀਕਰਨ ਐਪ ਹੈ। ਰਿਕਾਰਡ ਡੇਟਾਬੇਸ ਹਨ।
ਇਸ ਪੈਟਰਨ ਨੂੰ ਦੇਖਣ ਮਗਰੋਂ, ਤੁਸੀਂ ਫੈਸਲੇ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਲਓਗੇ:
ਅਗਲੇ ਹਿੱਸਿਆਂ ਵਿੱਚ, ਤੁਸੀਂ ਸਿੱਖੋਗੇ ਕਿ ਡੇਟਾਬੇਸ ਕਿਉਂ ਚਿਪਕ ਜਾਂਦੇ ਹਨ, ਡੇਟਾ ਨੂੰ ਕੋਡ ਤੋਂ ਕਿਉਂ ਦੀਰ ਨਾਲ ਖਿਸਕਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੈਕਟਿਕਲ ਤਰੀਕੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਸਕੀਮਾ ਨੂੰ ਐਸਾ ਬਣਾਉਂਦੇ ਹੋ ਕਿ ਉਹ ਕਈ ਐਪ ਰੀਰਾਈਟਸ ਨੂੰ ਸਹਿਣ ਕਰ ਸਕੇ—ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਹੰਗਾਮਾ ਬਣੇ।
ਐਪਲੀਕੇਸ਼ਨ "ਉਤਪਾਦ" ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਪਰ ਡੇਟਾਬੇਸ ਉਹ ਜਿਗਿਆਸਾ ਹੈ ਜਿੱਥੇ ਉਤਪਾਦ ਯਾਦ ਰੱਖਦਾ ਹੈ ਕਿ ਕੀ ਹੋਇਆ।
ਇੱਕ ਸ਼ੌਪਿੰਗ ਐਪ ਪੰਜ ਵਾਰੀ ਰੀਡਿਜ਼ਾਈਨ ਹੋ ਸਕਦੀ ਹੈ, ਫਿਰ ਵੀ ਗਾਹਕ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਦੀ ਖਰੀਦ ਇਤਿਹਾਸ ਉੱਥੇ ਮਿਲੇਗੀ। ਇੱਕ ਸਪੋਰਟ ਪੋਰਟਲ ਵੈਂਡਰ ਬਦਲ ਸਕਦਾ ਹੈ, ਫਿਰ ਵੀ ਟਿਕਟਾਂ, ਰਿਫੰਡ ਅਤੇ ਕੀ ਵਾਅਦੇ ਕੀਤੇ ਗਏ ਸਨ ਉਹ ਰਿਕਾਰਡ ਬਣੇ ਰਹਿੰਦੇ ਹਨ। ਉਹ ਲਗਾਤਾਰਤਾ ਸਟੋਰ ਕੀਤੀ ਡੇਟਾ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ: ਗਾਹਕ, ਆਰਡਰ, ਇਨਵਾਇਸ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ, ਇਵੈਂਟ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਵਿਚਕਾਰ ਸੰਬੰਧ।
ਜੇ ਕੋਈ ਫੀਚਰ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਯੂਜ਼ਰ ਨਾਰਾਜ਼ ਹੁੰਦੇ ਹਨ। ਪਰ ਜੇ ਡੇਟਾ ਗੁੰਮ ਹੋ ਜਾਵੇ ਤਾਂ ਤੁਸੀਂ ਭਰੋਸਾ, ਆਮਦਨ ਅਤੇ ਕਾਨੂੰਨੀ ਅਧਾਰ ਖੋ ਸਕਦੇ ਹੋ।
ਕੋਈ ਐਪ ਆਮ ਤੌਰ 'ਤੇ ਸਰੋਤ ਨਿਯੰਤਰਣ ਅਤੇ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਤੋਂ ਮੁੜ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ। ਹਕੀਕਤੀ ਇਤਿਹਾਸ ਨਹੀਂ। ਤੁਸੀਂ ਪਿਛਲੇ ਸਾਲ ਦੇ ਭੁਗਤਾਨਾਂ ਨੂੰ "ਫਿਰ ਤੋਂ ਚਲਾ" ਨਹੀਂ ਸਕਦੇ, ਗਾਹਕ ਦੀ ਮਨਜ਼ੂਰੀ ਦੇ ਸਮੇਂ ਦੀ ਸਹੀ ਪ੍ਰਮਾਣਿਕਤਾ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾ ਸਕਦੇ, ਜਾਂ ਯਾਦ ਤੋਂ ਪਿਛਲੇ ਵੇਲੇ ਕੀ ਭੇਜਿਆ ਗਿਆ ਸੀ ਉਹ ਬਿਲਕੁਲ ਦੁਬਾਰਾ ਨਹੀਂ ਤਿਆਰ ਕਰ ਸਕਦੇ। ਅੱਧੂਰੇ ਨੁਕਸ — ਮਿਸਿੰਗ ਟਾਈਮਸਟੈਂਪ, ਅਨਾਥ ਰਿਕਾਰਡ, ਅਸੰਗਤ totals — ਉਤਪਾਦ ਨੂੰ ਅਣਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੇ ਹਨ।
ਅਕਸਰ ਡੇਟਾ ਜਿੰਨਾ ਲੰਮਾ ਟਿਕਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਦੀ ਵਰਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ:
ਇਸ ਲਈ ਟੀਮਾਂ ਡੇਟਾ ਨੂੰ ਇੱਕ ਸੰਪਤੀ ਸਮਝਦੀਆਂ ਹਨ, ਇੱਕ ਪਰਿਣਾਮ ਨਹੀਂ। ਨਵੀਂ ਐਪ ਰੀਰਾਈਟ ਆਮ ਤੌਰ 'ਤੇ ਬਿਹਤਰ UI ਦੇ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਸਾਲਾਂ ਦੀ ਇਤਿਹਾਸਿਕ ਸੱਚਾਈ ਨੂੰ ਨਹੀਂ ਬਦਲਦੀ।
ਸਮਾਂ ਦੇ ਨਾਲ, ਸੰਗਠਨ ਬਿਨਾਂ ਧਿਆਨ ਦਿੱਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਸਾਂਝਾ ਰਿਫਰੈਂਸ ਬਿੰਦੂ ਵਜੋਂ ਪ੍ਰਯੋਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ: ਇਸ ਤੋਂ ਨਿਕਾਲੀਆਂ ਗਈ ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ, ਉੱਪਰ ਬਣੀਆਂ ਡੈਸ਼ਬੋਰਡਾਂ, ਫਾਇਨੈਂਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜੋ ਇਸ ਨਾਲ ਮਿਟੀ ਹੋਈਆਂ, ਅਤੇ "ਜਾਣੀ-ਪਹਚਾਨੀ" ਕੁਇਰੀਆਂ ਜੋ ਮੁੜ-ਮੁੜ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ।
ਇਹੀ ਡੇਟਾਬੇਸ ਲੰਬੀ ਉਮਰ ਦਾ ਭਾਵਨਾਤਮਕ ਕੇਂਦਰ ਹੈ: ਡੇਟਾਬੇਸ ਉਹ ਯਾਦ ਹੋ ਜਾਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਹਰ ਕੋਈ ਨਿਰਭਰ ਕਰਦਾ ਹੈ—ਭਾਵੇਂ ਦੇਖਦੇ ਦੇਖਦੇ ਆਲੇ-ਦੁਆਲੇ ਐਪ ਬਦਲਦਾ ਰਹੇ।
ਆਕਸਰ ਇਕ ਡੇਟਾਬੇਸ ਕਿਸੇ ਇੱਕ ਐਪ ਦਾ "ਮਾਲਕ" ਨਹੀਂ ਹੁੰਦਾ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਕਈ ਉਤਪਾਦਾਂ, ਅੰਦਰੂਨੀ ਟੂਲਾਂ ਅਤੇ ਟੀਮਾਂ ਲਈ ਸਾਂਝਾ ਸ੍ਰੋਤ-ਸਚ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਾਂਝੀ ਨਿਰਭਰਤਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਨਿਭਰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਐਪ ਕੋਡ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਹੀ ਟੇਬਲ ਸੈੱਟ ਅਕਸਰ ਸੇਵਾ ਕਰਦਾ ਹੈ:
ਇਹ ਹਰ ਇੱਕ ਖਪਤਕਾਰ ਵੱਖਰੇ ਭਾਸ਼ਾ ਵਿੱਚ ਬਣੇ ਹੋ ਸਕਦੈ, ਵੱਖਰੇ ਰਿਲੀਜ਼ ਸ਼ੈਡਿਊਲ ਤੇ, ਵਿਕਸਤੀਆਂ ਵੱਲੋਂ ਸੰਭਾਲੇ ਜਾਂਦੇ। ਜਦੋਂ ਕੋਈ ਐਪ ਰੀਰਾਈਟ ਹੁੰਦੀ ਹੈ, ਉਹ ਆਪਣੇ ਕੋਡ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਨੁਕੂਲ ਕਰ ਸਕਦੀ ਹੈ—ਪਰ ਇਸਨੂੰ ਫਿਰ ਵੀ ਉਹੀ ਰਿਕਾਰਡ ਪੜ੍ਹਨ ਅਤੇ ਬਚਾਉਣੇ ਪੈਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਬਾਕੀ ਸਭ ਨਿਰਭਰ ਹਨ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਖੁਦ ਨੂੰ ਇੱਕ ਖਾਸ ਡੇਟਾ ਮਾਡਲ ਨਾਲ "ਬੱਧ" ਲੈਂਦੀਆਂ ਹਨ: ਟੇਬਲ ਨਾਮ, ਕਾਲਮ ਦੇ ਅਰਥ, ਰੇਫਰੰਸ ID, ਅਤੇ ਇਹ ਕਿ ਇੱਕ ਰਿਕਾਰਡ ਕੀ ਦਰਸਾਉਂਦਾ ਹੈ। ਭਾਵੇਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ API ਰਾਹੀਂ ਹੋਵੇ, ਆਮ ਤੌਰ 'ਤੇ API ਅਕਸਰ ਡੇਟਾਬੇਸ ਦੇ ਥੱਲੇ ਲੁਕੇ ਮੌਡਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।
ਇਸ ਲਈ ਡੇਟਾਬੇਸ ਬਦਲਣਾ ਇੱਕ-ਟੀਮ ਦਾ ਫੈਸਲਾ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਸਕੀਮਾ-ਚੇੰਜ ਨਿਕਾਸ, ETL ਜੌਬ, ਰਿਪੋਰਟ ਕੁਇਰੀਆਂ, ਅਤੇ ਡਾਉਨਸਟ੍ਰੀਮ ਸਿਸਟਮਾਂ ਵਿੱਚ ਰਿਪਲ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਮੁੱਖ ਪ੍ਰਾਜੈਕਟ ਰੇਪੋ ਵਿੱਚ ਵੀ ਨਹੀਂ ਹੋ ਸਕਦੇ।
ਜੇ ਤੁਸੀਂ ਕੋਈ ਬੱਗਡ ਫੀਚਰ ਰਿਲੀਜ਼ ਕਰੋ, ਤਾਂ ਤੁਸੀਂ ਉਸਨੂੰ ਰੌਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਾਂਝੇ ਡੇਟਾਬੇਸ ਕਾਂਟਰੈਕਟ ਤੋੜਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬਿਲਿੰਗ, ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਇਕੱਠੇ ਹੀ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਖਤਰਾ ਉਸ ਸਮੇਤ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਗਿਣਤੀ ਦੇ ਨਾਲ ਵੱਧ ਜਾਂਦਾ ਹੈ।
ਇਸੇ ਲਈ "ਅਸਥਾਈ" ਚੋਣਾਂ (ਕਿਸੇ ਕਾਲਮ ਦਾ ਨਾਮ, enum ਦਾ ਇੱਕ ਮੁੱਲ, NULL ਦੀ ਅਜੀਬ ਸਮਝ) ਚਿਪਕੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ: ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਉਨ੍ਹਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਵੇਖੋ blog/schema-evolution-guide.
ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਅਕਸਰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਮੁੜ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ UI ਬਦਲ ਸਕਦੇ ਹੋ, ਇੱਕ ਸੇਵਾ ਬਦਲ ਸਕਦੇ ਹੋ, ਜਾਂ ਇੱਕ ਫੀਚਰ ਨੂੰ API ਦੇ ਪਿੱਛੇ ਨਵਾਂ ਤਰੀਕਾ ਰੱਖ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੱਕ ਓਹੀ ਡੇਟਾਬੇਸ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ, ਤੁਸੀਂ ਡਿਪਲੌਏ ਨੂੰ ਰੋਲ ਬੈਕ ਕਰ ਸਕਦੇ ਹੋ, ਟ੍ਰੈਫਿਕ ਪੁਰਾਣੀ ਮਾਡਿਊਲ ਵੱਲ ਰੂਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਕੋਡ ਨੂੰ ਸਾਇਡ-ਬਾਈ-ਸਾਇਡ ਚਲਾਕੇ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ।
ਡੇਟਾ ਤੁਹਾਨੂੰ ਇਹੀ ਲਚਕੀਲੇਪਣ ਨਹੀਂ ਦਿੰਦਾ। ਡੇਟਾ ਸਾਂਝਾ, ਆਪਸ ਵਿੱਚ ਜੁੜਿਆ ਹੋਇਆ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਹਰ ਸੀਕਿੰਟ ਸਹੀ ਰਹਿਣ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ—"ਅਗਲੇ ਡਿਪਲੌਏ ਤੋਂ ਬਾਅਦ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ" ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਰੈਫੈਕਟਰ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਹੁਕਮਾਂ ਨੂੰ ਬਦਲ ਰਹੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਡੇਟਾ ਮਾਈਗ੍ਰੇਟ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਉਸ ਚੀਜ਼ ਨੂੰ ਬਦਲ ਰਹੇ ਹੋ ਜਿਸ 'ਤੇ ਕਾਰੋਬਾਰ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: ਗਾਹਕ ਰਿਕਾਰਡ, ਲੈਣ-ਦੇਣ, ਆਡਿਟ ਟ੍ਰੇਲ, ਪ੍ਰੋਡਕਟ ਇਤਿਹਾਸ।
ਨਵੀਂ ਸੇਵਾ ਨੂੰ ਕੁਝ ਉਪਭੋਗਤਾਵਾਂ 'ਤੇ ਟੈਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਨਵੀਂ ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਹਰ ਚੀਜ਼ ਨੂੰ ਛੂਹਦੀ ਹੈ: ਮੌਜੂਦਾ ਯੂਜ਼ਰ, ਪੁਰਾਣੇ ਯੂਜ਼ਰ, ਇਤਿਹਾਸਕ ਰੋਜ਼, ਅਨਾਥ ਰਿਕਾਰਡ, ਅਤੇ ਤਿੰਨ ਸਾਲ ਪਹਿਲਾਂ ਕਿਸੇ ਬੱਗ ਵੱਲੋਂ ਬਣਾਏ ਗਏ ਅਜਿਹੇ ਇਕ-ਵਾਰ ਕੰਟੇਨਟ।
ਡੇਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਿਰਫ "export ਅਤੇ import" ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਹਰ ਕਦਮ ਨੂੰ ਤਸਦੀਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਤਸਦੀਕ ਕਰਨ ਲਈ ਸਮਾਂ ਲੱਗਦਾ ਹੈ—ਖਾਸਕਰ ਜਦ ਡੇਟਾ ਸੈੱਟ ਵੱਡਾ ਹੋਵੇ ਅਤੇ ਗਲਤੀ ਦੇ ਨਤੀਜੇ ਉੱਚੇ ਹੋਣ।
ਕੋਡ ਡਿਪਲੌਇਮੈਂਟ ਹੁਣ ਬਹੁਤ ਵਾਰ ਅਤੇ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਡੇਟਾ ਕਟਓਵਰਜ਼ ਇੱਕ ਸਰਜਰੀ ਵਾਂਗ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਨੂੰ ਡਾਊਨਟਾਈਮ ਦੀ ਲੋੜ ਪਏ ਤਾਂ ਤੁਸੀਂ ਕਾਰੋਬਾਰੀ ਓਪਰੇਸ਼ਨ, ਸਹਾਇਤਾ ਅਤੇ ਗਾਹਕ ਉਮੀਦਾਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰ ਰਹੇ ਹੋ। ਨਿਯ ਸਿੱਫ਼ਰ-ਡਾਊਨਟਾਈਮ ਲਈ ਤੁਸੀਂ ਡੂਅਲ-ਰਾਈਟ, ਚੇਂਜ ਡੇਟਾ ਕੈਪਚਰ, ਜਾਂ ਧੀਰੇ ਧੀਰੇ ਰੈਪਲਿਕੇਸ਼ਨ ਕਰ ਰਹੇ ਹੋ—ਉਪਰੰਤ ਇਕ ਯੋਜਨਾ ਜੇ ਨਵਾਂ ਸਿਸਟਮ ਸਿਰੇ-ਨਾਲ ਧੀਮਾ ਜਾਂ ਗਲਤ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਏਗਾ।
ਰੋਲਬੈਕ ਵੀ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਕੋਡ ਰੋਲ ਬੈਕ ਕਰਨਾ ਅਸਾਨ ਹੈ; ਡੇਟਾ ਰੋਲਬੈਕ ਅਕਸਰ ਬੈਕਅੱਪ ਰੀਸਟੋਰ ਕਰਨਾ, ਚੇਂਜਸ ਰੀਪਲੇ ਕਰਨਾ, ਜਾਂ ਕੁਝ ਲਿਖਤਾਂ ਨੇ "ਗਲਤ" ਥਾਂ ਤੇ ਹੋਣ ਦੀ ਸਵੀਕਾਰ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਠੀਕ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਡੇਟਾਬੇਸ ਇਤਿਹਾਸ ਜਮਾਂ ਕਰਦਾ ਹੈ: ਅਜੀਬ ਰਿਕਾਰਡ, ਲੈਗੇਸੀ ਸਥਿਤੀਆਂ, ਅਧੂਰੇ ਮਾਈਗਰੇਟ ਹੋਏ ਰੋਜ਼ ਅਤੇ ਉਹ ਵਰਕਅਰਾਊਂਡ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ। ਇਹ ਐਜ ਕੇਸ ਵਿਕਾਸ ਡੇਟਾਸੇਟ ਵਿੱਚ ਵਿਆਪਕ ਨਹੀਂ ਹੁੰਦੇ, ਪਰ ਅਸਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਤੁਰੰਤ ਸਾਹਮਣੇ ਆ ਜਾਂਦੇ ਹਨ।
ਇਸ ਲਈ ਸੰਗਠਨ ਅक्सर ਕੋਡ ਨੂੰ ਮੁੜ ਲਿਖਣਾ قبول ਕਰ ਲੈਂਦੇ ਹਨ (ਕਈ ਵਾਰੀ), ਜਦਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਠીਕ ਢੰਗ ਨਾਲ ਬਦਲਣਾ ਸਭ ਤੋਂ ਕਠਿਨ ਕੰਮ ਸਮਝਦੇ ਹਨ। ਡੇਟਾਬੇਸ ਸਿਰਫ਼ ਇੱਕ ਨਿਰਭਰਤਾ ਨਹੀਂ—ਇਹ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਚੀਜ਼ ਹੈ ਜਿਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣਾ ਹੁੰਦਾ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਬਦਲਣਾ ਮੁੱਖ ਤੌਰ 'ਤੇ ਨਵੇਂ ਵਿਹਾਰ ਨੂੰ ਜਾਰੀ ਕਰਨ ਬਾਰੇ ਹੁੰਦਾ ਹੈ। ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਡਿਪਲੌਏ ਰੋਲਬੈਕ, ਫੀਚਰ-ਫਲੈਗ ਲਗਾ ਕੇ ਜਾਂ ਫਿਕਸ ਜਲਦੀ ਕਰ ਕੇ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ।
ਸਕੀਮਾ ਬਦਲਣਾ ਵੱਖਰਾ ਹੈ: ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਡੇਟਾ ਲਈ ਨਿਯਮਾਂ ਨੂੰ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਉਹ ਡੇਟਾ ਸਾਲਾਂ ਪੁਰਾਣਾ, ਅਸੰਗਤ, ਜਾਂ ਕਈ ਸੇਵਾਵਾਂ ਅਤੇ ਰਿਪੋਰਟਾਂ ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ।
ਚੰਗੀਆਂ ਸਕੀਮਾਂ ਅਕਸਰ ਫ੍ਰੋਜ਼ਡ ਨਹੀਂ ਰਹਿੰਦੀਆਂ। ਚੁਣੌਤੀ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਇਉਂ ਵਿਕਸਿਤ ਕੀਤਾ ਜਾਵੇ ਕਿ ਇਤਿਹਾਸਕ ਡੇਟਾ ਵੈਧ ਅਤੇ ਵਰਤਣਯੋਗ ਰਹੇ। ਕੋਡ ਨੂੰ ਤੁਸੀਂ "ਰੀਕੰਪਾਇਲ" ਕਰ ਸਕਦੇ ਹੋ; ਡੇਟਾ ਨੂੰ ਨਹੀਂ—ਤੁਸੀਂ ਹਰ ਇੱਕ ਪੁਰਾਣੀ ਕਤਾਰ ਨੂੰ ਅੱਗੇ ਲੈ ਕੇ ਜਾਣਾ ਪੈਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਕਿਨਾਰੇ ਕੇਸ ਵੀ ਹੋ ਸਕਦੇ ਹਨ ਜਿਸਨੂੰ ਕੋਈ ਯਾਦ ਨਹੀਂ ਕਰਦਾ।
ਇਸ ਲਈ ਸਕੀਮਾ ਵਿਕਾਸ ਉਹਨਾਂ ਬਦਲਾਅਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਜੋ ਮੌਜੂਦਾ ਅਰਥਾਂ ਨੂੰ ਬਚਾਇਆ ਰੱਖਣ ਅਤੇ ਮੂੰਹ-ਮੁਹਾਂਦਰਾ ਰੀਰਾਈਟ ਨੂੰ ਮਜ਼ਬੂਰ ਨਾ ਕਰਨ।
ਜੋੜਨ ਵਾਲੇ ਬਦਲਾਅ (ਨਵੇਂ ਟੇਬਲ, ਨਵੇਂ ਕਾਲਮ, ਨਵੇਂ ਇੰਡੈਕਸ) ਆਮ ਤੌਰ 'ਤੇ ਪੁਰਾਣੇ ਕੋਡ ਨੂੰ ਕੰਮ ਕਰਨ ਦੇਣਗੇ ਜਦੋਂ ਕਿ ਨਵਾਂ ਕੋਡ ਨਵੇਂ ਢਾਂਚੇ ਦਾ ਲਾਭ ਲਵੇਗਾ।
ਟੁੱਟਣ ਵਾਲੇ ਬਦਲਾਅ—ਕਾਲਮ ਦਾ ਨਾਮ ਬਦਲਣਾ, ਕਿਸਮ ਬਦਲਣਾ, ਇੱਕ ਫੀਲਡ ਨੂੰ ਕਈ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣਾ, constraints ਨੂੰ ਸਖਤ ਕਰਨਾ—ਅਕਸਰ ਇਹਨਾਂ ਨੂੰ ਆਪਡੇਟ ਕਰਨ ਲਈ ਸਹਿ-ਸੰਯੋਜਿਤ ਅਪਡੇਟਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:
ਚਾਹੇ ਤੁਸੀਂ ਮੁੱਖ ਐਪ ਨੂੰ ਅਪਡੇਟ ਵੀ ਕਰੋ, ਇੱਕ ਭੁੱਲਿਆ ਹੋਇਆ ਰਿਪੋਰਟ ਜਾਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਪੁਰਾਣੇ ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ।
"ਸਿਰਫ ਸਕੀਮਾ ਬਦਲੋ" ਸੁਣਨ ਵਿੱਚ ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਜਦ ਤੱਕ ਤੁਹਾਨੂੰ ਲੱਖਾਂ ਮੌਜੂਦਾ ਕਤਾਰਾਂ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ ਨਾ ਪੈ ਜਦੋਂ ਸਿਸਟਮ ਲਾਈਨ 'ਤੇ ਰਹੇ। ਤੁਹਾਨੂੰ ਸੋਚਣਾ ਪੈਂਦਾ ਹੈ:
NOT NULL ਕਾਲਮਾਂ ਲਈ ਬੈਕਫਿਲ ਕੀਤੀ ਜਾਣALTER ਆਪਰੇਸ਼ਨਾਂ ਦੌਰਾਨ ਲੰਬੇ ਲੌਕ ਜਾਂ ਟਾਇਮਆਉਟ ਤੋਂ ਬਚਣਾਅਕਸਰ ਤੁਸੀਂ ਮਲਟੀ-ਸਟੇਪ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ 'ਤੇ ਅੰਤ ਕਰਦੇ ਹੋ: ਨਵੇਂ ਫੀਲਡ ਜੋੜੋ, ਦੋਹਾਂ 'ਤੇ ਲਿਖੋ, ਬੈਕਫਿਲ ਕਰੋ, ਰੀਡ-ਸਵਿੱਚ ਕਰੋ, ਫਿਰ ਪੁਰਾਣੇ ਫੀਲਡ ਹਟਾਓ।
ਕੋਡ ਬਦਲਾਅ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕਦੇ ਅਤੇ ਇੱਕੱਲੇ ਹੁੰਦੇ ਹਨ; ਸਕੀਮਾ ਬਦਲਾਅ ਦਿਰਘਕਾਲੀ ਅਤੇ ਸਾਂਝੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਵਾਰੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌੜੀ, ਉਹ ਡੇਟਾਬੇਸ ਦੇ ਇਤਿਹਾਸ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਹਰ ਭਵਿੱਖੀ ਸੰਸਕਰਨ ਇਸ ਫੈਸਲੇ ਨਾਲ ਜੀਉਣਾ ਪਵੇਗਾ।
ਐਪ ਫਰੇਮਵਰਕ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਹਨ: ਜੋ ਪੰਜ ਸਾਲ ਪਹਿਲਾਂ "ਮੌਡਰਨ" ਸੀ ਉਹ ਅਜਿਹੇ ਸਪੋਰਟ ਨਹੀਂ ਰਹਿ ਸਕਦਾ। ਡੇਟਾਬੇਸ ਵੀ ਬਦਲਦੇ ਹਨ, ਪਰ ਕਈ ਮੁੱਖ ਵਿਚਾਰ—ਅਤੇ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਕਾਬਲੀਆਂ—ਬਹੁਤ ਧੀਰੇ ਧੀਰੇ ਗੁਜ਼ਰਦੀਆਂ ਹਨ।
SQL ਅਤੇ ਰਿਲੇਸ਼ਨਲ ਧਾਰਣਾਵਾਂ ਦਹਾਕਿਆਂ ਤਕ ਅਸਥਿਰ ਰਹੀਆਂ ਹਨ: ਟੇਬਲ, ਜੋਇਨ, constraints, ਇੰਡੈਕਸ, ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ, ਅਤੇ ਕੁਇਰੀ ਪਲੈਨ। ਵੈਂਡਰ ਫੀਚਰ ਜੋੜਦੇ ਹਨ, ਪਰ ਮੈਨਟਲ ਮਾਡਲ ਜਾਣੂ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਸਥਿਰਤਾ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਨਵੇਂ ਭਾਸ਼ਾ ਵਿੱਚ ਐਪ ਰੀਰਾਈਟ ਕਰਨ ਦੌਰਾਨ ਵੀ ਉਹਨਾਂ ਦੇ ਮੌਜੂਦਾ ਡੇਟਾ ਮਾਡਲ ਅਤੇ ਕੁਇਰੀ ਪਹੁੰਚ ਨੂੰ ਰੱਖਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਨਵੇਂ ਡੇਟਾਬੇਸ ਉਤਪਾਦ ਵੀ ਅਕਸਰ ਇਹ ਜਾਣੂ ਮਾਡਲ ਰੱਖਦੇ ਹਨ—"SQL-ਵਾਂਗ" ਕੁਇਰੀ ਲੇਅਰ, ਰਿਲੇਸ਼ਨਲ-ਸਟਾਈਲ ਜੋਇਨ, ਜਾਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ semantics—ਕਿਉਂਕਿ ਇਹ ਰਿਪੋਰਟਿੰਗ, ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਅਤੇ ਕਾਰੋਬਾਰੀ ਸਵਾਲਾਂ ਨਾਲ ਠੀਕ ਮੈਚ ਕਰਦੇ ਹਨ।
ਮੁੱਢਲੇ ਤੱਤਾਂ ਦੇ ਬਣੇ ਰਹਿਣ ਨਾਲ ਆਸ-ਪਾਸ ਦੀ ਇਕੋਸਿਸਟਮ ਵੀ ਕਈ ਪੀੜ੍ਹੀਆਂ ਤੱਕ ਟਿਕਦੀ ਹੈ:
ਇਹ ਲਗਾਤਾਰਤਾ "ਜਬਰਦਸਤੀ ਰੀਰਾਈਟ" ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਕਿਸੇ ਕੰਪਨੀ ਨੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਐਪ ਫਰੇਮਵਰਕ ਛੱਡ ਦੇਵੇ ਕਿਉਂਕਿ ਭਰਤੀ ਮੁਸ਼ਕਲ ਹੋ ਗਈ ਹੈ ਜਾਂ ਸੁਰੱਖਿਆ ਪੈਚ ਬੰਦ ਹੋ ਗਏ, ਪਰ ਉਹ ਬਹੁਤ ਕਮ ਹੀ SQL ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਵਜੋਂ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਡੇਟਾਬੇਸ ਮਿਆਰ ਅਤੇ ਰਿਵਾਜ਼ ਇੱਕ ਆਮ ਬੇਜ਼ਲਾਈਨ ਬਣਾਉਂਦੇ ਹਨ: SQL ਡਾਇਲੈਕਟ ਇਕੋ ਜਿਹੇ ਨਹੀਂ ਹਨ, ਪਰ ਉਹ ਵੱਧ ਤਰ੍ਹਾਂ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਮਿਲਦੇ ਹਨ ਬਜਾਏ ਬਹੁਤ ਸਾਰੇ ਵੈੱਬ ਫਰੇਮਵਰਕਾਂ ਦੇ। ਇਸ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਡੇਟਾਬੇਸ ਨੂੰ ਸਥਿਰ ਰੱਖਣਾ ਸੁਲਭ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਐਪ ਲੇਅਰ ਵਿਕਸਿਤ ਹੋ ਰਿਹਾ ਹੈ।
ਪ੍ਰਾਯੋਗਿਕ ਪ੍ਰਭਾਵ ਸਧਾਰਣ ਹੈ: ਜਦੋਂ ਟੀਮਾਂ ਐਪ ਰੀਰਾਈਟ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਉਹ ਅਕਸਰ ਆਪਣੇ ਮੌਜੂਦਾ ਡੇਟਾਬੇਸ ਹੁਨਰ, ਕੁਇਰੀ ਆਦਤਾਂ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਅਭਿਆਸ ਰੱਖ ਸਕਦੀਆਂ ਹਨ—ਇਸ ਲਈ ਡੇਟਾਬੇਸ ਇੱਕ ਮਜ਼ਬੂਤ ਬੁਨਿਆਦ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਕਈ ਪੀੜ੍ਹੀਆਂ ਦੇ ਕੋਡ ਤੋਂ ਬਾਹਰ ਜੀਊਂਦਾ ਰਹਿੰਦਾ ਹੈ।
ਅਕਸਰ ਟੀਮ ਇੱਕੋ ਡੇਟਾਬੇਸ 'ਤੇ ਇਸ ਲਈ ਨਹੀਂ ਰਹਿੰਦੀਆਂ ਕਿ ਉਹ ਪਸੰਦ ਕਰਦੇ ਹਨ। ਉਹ ਇਸ ਲਈ ਰਹਿੰਦੇ ਹਨ ਕਿ ਉਹਨੇ ਉਸ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਰੀਤ-ਰਿਵਾਜ ਬਣਾਈ ਹੋਈ ਹੈ—ਅਤੇ ਉਹ ਰਿਵਾਜ ਮਿਹਨਤ ਨਾਲ ਬਣਦੇ ਹਨ।
ਜਦੋਂ ਇੱਕ ਡੇਟਾਬੇਸ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਉਹ ਕੰਪਨੀ ਦੀ "ਹਮੇਸ਼ਾ-ਚਾਲੂ" ਮਸ਼ੀਨਰੀ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਉਹ ਚੀਜ਼ ਹੁੰਦੀ ਹੈ ਜਿਸ ਲਈ ਲੋਕ 2 ਵਜੇ ਰਾਤ ਨੂੰ ਪੇਜ ਕਰਦੇ ਹਨ, ਆਡਿਟਾਂ ਇਸ ਬਾਰੇ ਪੁੱਛਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਨਵੀਂ ਸੇਵਾ ਆਖ਼ਿਰਕਾਰ ਇਸ ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ।
ਸਾਲ ਜਾਂ ਦੋ ਬਾਅਦ, ਟੀਮ ਕੋਲ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਭਰੋਸੇਯੋਗ ਰਿਥਮ ਹੁੰਦਾ ਹੈ:
ਡੇਟਾਬੇਸ ਨੂੰ ਬਦਲਣਾ ਉਨ੍ਹਾਂ ਸਾਰੇ ਨੂੰ ਹਕੀਕਤ ਅਧੀਨ ਦੁਬਾਰਾ ਸਿੱਖਣ ਵਾਂਗ ਹੁੰਦਾ ਹੈ, ਅਸਲੀ ਲੋਡ ਦੇ ਨਾਲ ਅਤੇ ਅਸਲ ਗਾਹਕ ਉਮੀਦਾਂ ਨਾਲ।
ਡੇਟਾਬੇਸ ਕਦੇ "ਸੈੱਟ ਅਤੇ ਭੁੱਲ ਜਾਓ" ਨਹੀਂ ਹੁੰਦੇ। ਸਮੇਂ ਦੇ ਨਾਲ, ਟੀਮ ਇੱਕ ਭਰੋਸੇਯੋਗਤਾ ਗਿਆਨ ਕੈਟਲੌਗ ਬਣਾਂਦੀ ਹੈ:
ਉਹ ਗਿਆਨ ਡੈਸ਼ਬੋਰਡਸ, ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਲੋਕਾਂ ਦੇ ਮਨ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ—ਕਿਸੇ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਹੀਂ। ਐਪ ਕੋਡ ਦੀ ਰੀਰਾਈਟਿੰਗ ਸਾਹਮਣੇ ਰਹਿ ਸਕਦੀ ਹੈ ਜਦੋਂ ਡੇਟਾਬੇਸ ਸਰਵ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਬਦਲਣਾ ਤੁਹਾਨੂੰ ਇਕੱਠੇ ਤੌਰ 'ਤੇ ਬਿਹਾਵਿਓਰ, ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਭਰੋਸਯੋਗਤਾ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ।
ਸੁਰੱਖਿਆ ਅਤੇ ਐਕਸੈੱਸ ਕੰਟਰੋਲ ਕੇਂਦਰੀ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਹੁੰਦੇ ਹਨ। ਰੋਲ, ਪਰਮਿਸ਼ਨ, ਆਡਿਟ ਲੌਗ, ਸੀਕ੍ਰੇਟ ਰੋਟੇਸ਼ਨ, ਐਨਕ੍ਰਿਪਸ਼ਨ ਸੈਟਿੰਗਸ, ਅਤੇ "ਕੌਣ ਕੀ ਪੜ੍ਹ ਸਕਦਾ ਹੈ" ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਨੀਤੀਆਂ ਨਾਲ ਉੱਲਝੇ ਹੁੰਦੇ ਹਨ।
ਡੇਟਾਬੇਸ ਬਦਲਣਾ ਮਤਲਬ ਹੈ ਐਕਸੈੱਸ ਮਾਡਲ ਦੁਬਾਰਾ ਬਣਾਉਣਾ, ਕੰਟਰੋਲ ਦੁਬਾਰਾ ਵੈਰੀਫਾਈ ਕਰਨਾ, ਅਤੇ ਕਾਰੋਬਾਰ ਨੂੰ ਦੁਬਾਰਾ ਸਾਬਤ ਕਰਨਾ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਹਜੇ ਵੀ ਸੁਰੱਖਿਅਤ ਹੈ।
ਓਪਰੇਸ਼ਨਲ ਪਰਿਪੱਕਤਾ ਡੇਟਾਬੇਸ ਨੂੰ ਥਾਂ 'ਤੇ ਰੱਖਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਖਤਰਾ ਘਟਾਉਂਦੀ ਹੈ। ਜੇ ਨਵਾਂ ਡੇਟਾਬੇਸ ਵਧੀਆ ਫੀਚਰ ਵਾਅਦਾ ਕਰੇ, ਪਰ ਪੁਰਾਣੇ ਨੇ ਇੱਕ ਦ੍ਰਿੜ ਇਤਿਹਾਸ ਹੈ: ਉਹ ਉੱਪਟਾਈਮ ਤੇ, ਰਿਕਵਰਏਬਲ ਅਤੇ ਸਮਝਣਯੋਗ ਹੈ ਜਦ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਕਾਰੋਬਾਰ ਦੀ ਇਤਿਹਾਸਕ ਸੱਚਾਈ ਸੰਭਾਲਦਾ ਹੈ (ਗਾਹਕ, ਆਰਡਰ, ਇਨਵਾਇਸ, ਆਡਿਟ ਟ੍ਰੇਲ ਆਦਿ)। ਕੋਡ ਨੂੰ ਮੁੜ ਤਿਆਰ ਕੀਤਾ ਜਾਂ ਸਕਦਾ ਹੈ; ਪਰ ਗੁੰਮ ਜਾਂ ਖਰਾਬ ਹੋਈ ਇਤਿਹਾਸਕ ਜਾਣਕਾਰੀ ਮੁੜ ਬਣਾਉਣਾ ਮੁਸ਼ਕਲ ਹੈ ਅਤੇ ਇਹ ਵਿੱਤੀ, ਕਾਨੂੰਨੀ ਅਤੇ ਭਰੋਸੇ ਨਾਲ ਜੁੜੇ ਮੁੱਦੇ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ।
ਡੇਟਾ ਬਦਲਾਅ ਸਾਂਝੇ ਅਤੇ ਦਿਰਘਕਾਲੀ ਹੁੰਦੇ ਹਨ.
ਇੱਕ ਹੀ ਡੇਟਾਬੇਸ ਅਕਸਰ ਸੱਚਾਈ ਦਾ ਸਾਂਝਾ ਸਰੋਤ ਬਣ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਭਾਵੇਂ ਤੁਸੀਂ ਐਪ ਨੂੰ ਮੁੜ ਲਿਖੋ, ਇਹ ਸਾਰੇ ਖਪਤਕਾਰ ਸਥਿਰ ਟੇਬਲਾਂ, IDs ਅਤੇ ਅਰਥਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੇ ਹਨ।
ਨਰਵਲ ਨਹੀਂ. ਅਕਸਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਇਸ ਤਰ੍ਹਾਂ ਹੋਂਦ ਵਿੱਚ ਆਉਂਦੀ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਦਾ ਠੀਕ-ਠਾਕ ਆਰਥਿਕਾ (contract) ਅਸਥਿਰ ਰਹੇ ਜਦੋਂ ਤੱਕ ਐਪ ਕੰਪੋਨੈਂਟ ਬਦਲੇ ਜਾਂਦੇ ਹਨ.
ਆਮ ਤਰੀਕਾ:
ਅਧਿਕਤਰ ਟੀਮਾਂ ਜੋੜ ਵਧਾਉਣ ਵਾਲੇ ਬਦਲਾਅ ਚਾਹੁੰਦੀਆਂ ਹਨ:
ਇਸ ਨਾਲ ਪੁਰਾਣਾ ਅਤੇ ਨਵਾਂ ਕੋਡ ਇਕੱਠੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤਕ ਤਬਦੀਲੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੋਵੇ।
ਅਸਪਸ਼ਟਤਾ ਕੋਡ ਤੋਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰਹਿ ਜਾਦੀ ਹੈ.
ਪਰੈਕਟਿਕਲ ਕਦਮ:
billing_address_id).NOT NULL, uniqueness, checks).ਅਨੋਖੇ ਰਿਕਾਰਡਾਂ ਦੀ ਉਮੀਦ ਕਰੋ.
ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਕਰੋ:
ਤਸਦੀਕ ਕਰਨ ਵਾਲੇ ਕਦਮ ਸਮੇਤ ਪ੍ਰੋਡਕਸ਼ਨ-ਜਿਹੇ ਡਾਟਾ 'ਤੇ ਟੈਸਟ ਕਰੋ।
ਕੰਪਲਾਇੰਸ ਰਿਕਾਰਡਾਂ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, UI ਨਾਲ ਨਹੀਂ.
ਤੁਸੀਂ ਰੱਖਣ ਅਤੇ ਦੁਬਾਰਾ ਪੇਸ਼ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਹੋ ਸਕਦੇ ਹੋ:
ਫੀਲਡਾਂ ਦਾ ਰੀਸ਼ੇਪ ਜਾਂ ਮਿਟਾਉ traceability, reporting definitions ਜਾਂ auditability ਨੂੰ ਖ਼ਤਰੇ ਵਿੱਚ ਪਾ ਸਕਦਾ ਹੈ — ਭਾਵੇਂ ਐਪ ਬਦਲ ਗਿਆ ਹੋਵੇ।
ਕੰਪੈਟੀਬਿਲਿਟੀ ਛੁਪੇ ਨਿਰਭਰਤਾਵਾਂ ਬਣਾਉਂਦੀ ਹੈ:
ਡਿਪ੍ਰੀਕੇਸ਼ਨ ਨੂੰ ਪ੍ਰੋਡਕਟ ਬਦਲਾਵ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ: ਮਨਸੂਖੀ ਦਾ ਇਰਾਦਾ ਦਸੋ, ਖਪਤਕਾਰਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ ਅਤੇ ਰਿਟਾਇਰਮੈਂਟ ਪਲਾਨ ਨਿਰਧਾਰਿਤ ਕਰੋ।
ਪ੍ਰਾਇਕਟਿਕਲ ਚੈੱਕਲਿਸਟ:
ਇਸ ਨਾਲ ਰੀਰਾਈਟਸ ਰੋਜ਼ਮਰਹਾ ਕਾਰਜ ਬਣ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਖਤਰਨਾਕ ‘ਡੇਟਾ ਰੈਸਕਯੂ’ ਪ੍ਰਾਜੈਕਟ।