ਮੈਨੂੰ ਹਾਲ ਹੀ ਵਿੱਚ ਪਤਾ ਲੱਗਾ ਹੈ ਕਿ Red Hat ਸੈਟੇਲਾਈਟ ਤੋਂ MongoDB ਸਹਿਯੋਗ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ (ਉਹ ਲਾਇਸੈਂਸ ਤਬਦੀਲੀਆਂ ਕਾਰਨ ਕਹਿੰਦੇ ਹਨ)। ਇਸ ਨੇ ਮੈਨੂੰ ਸੋਚਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਕਿਉਂਕਿ ਪਿਛਲੇ ਕੁਝ ਸਾਲਾਂ ਵਿੱਚ ਮੈਂ ਇਸ ਬਾਰੇ ਬਹੁਤ ਸਾਰੇ ਲੇਖ ਦੇਖੇ ਹਨ ਕਿ ਮੋਂਗੋਡੀਬੀ ਕਿੰਨਾ ਭਿਆਨਕ ਹੈ ਅਤੇ ਕਿਸੇ ਨੂੰ ਵੀ ਇਸਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ। ਪਰ ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਮੋਂਗੋਡੀਬੀ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪਰਿਪੱਕ ਉਤਪਾਦ ਬਣ ਗਿਆ ਹੈ। ਕੀ ਹੋਇਆ? ਕੀ ਸਾਰੇ ਨਫ਼ਰਤ ਅਸਲ ਵਿੱਚ ਇੱਕ ਨਵੇਂ DBMS ਦੀ ਸ਼ੁਰੂਆਤੀ ਮਾਰਕੀਟਿੰਗ ਵਿੱਚ ਗਲਤੀਆਂ ਕਾਰਨ ਹਨ? ਜਾਂ ਕੀ ਲੋਕ ਗਲਤ ਥਾਵਾਂ 'ਤੇ ਮੋਂਗੋਡੀਬੀ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ?

ਜੇ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਮੈਂ ਮੋਂਗੋਡੀਬੀ ਦਾ ਬਚਾਅ ਕਰ ਰਿਹਾ ਹਾਂ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਪੜ੍ਹੋ ਬੇਦਾਅਵਾ ਲੇਖ ਦੇ ਅੰਤ 'ਤੇ.

ਨਵਾਂ ਰੁਝਾਨ

ਮੈਂ ਸਾਫਟਵੇਅਰ ਉਦਯੋਗ ਵਿੱਚ ਮੇਰੇ ਕਹਿਣ ਨਾਲੋਂ ਵੱਧ ਸਾਲਾਂ ਤੋਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ, ਪਰ ਮੈਂ ਅਜੇ ਵੀ ਸਾਡੇ ਉਦਯੋਗ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਰੁਝਾਨਾਂ ਦੇ ਇੱਕ ਛੋਟੇ ਜਿਹੇ ਹਿੱਸੇ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਿਹਾ ਹਾਂ। ਮੈਂ 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ਦੇ ਉਭਾਰ ਨੂੰ ਦੇਖਿਆ ਹੈ... ਸੂਚੀ ਬੇਅੰਤ ਹੈ। ਹਰ ਸਾਲ ਨਵੇਂ ਰੁਝਾਨ ਪ੍ਰਗਟ ਹੁੰਦੇ ਹਨ. ਕੁਝ ਤੇਜ਼ੀ ਨਾਲ ਅਲੋਪ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਦੂਸਰੇ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਸਾਫਟਵੇਅਰ ਵਿਕਸਿਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲਦੇ ਹਨ।

ਹਰ ਨਵਾਂ ਰੁਝਾਨ ਇੱਕ ਆਮ ਉਤਸ਼ਾਹ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਲੋਕ ਜਾਂ ਤਾਂ ਬੋਰਡ 'ਤੇ ਛਾਲ ਮਾਰਦੇ ਹਨ, ਜਾਂ ਦੂਜਿਆਂ ਦੁਆਰਾ ਪੈਦਾ ਹੋਏ ਰੌਲੇ ਨੂੰ ਦੇਖਦੇ ਹਨ ਅਤੇ ਭੀੜ ਦਾ ਅਨੁਸਰਣ ਕਰਦੇ ਹਨ। ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਗਾਰਟਨਰ ਦੁਆਰਾ ਕੋਡਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ ਹਾਈਪ ਚੱਕਰ. ਹਾਲਾਂਕਿ ਵਿਵਾਦਪੂਰਨ, ਇਹ ਸਮਾਂ-ਰੇਖਾ ਮੋਟੇ ਤੌਰ 'ਤੇ ਵਰਣਨ ਕਰਦੀ ਹੈ ਕਿ ਤਕਨਾਲੋਜੀਆਂ ਦੇ ਅੰਤ ਵਿੱਚ ਉਪਯੋਗੀ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।

ਪਰ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਇੱਕ ਨਵੀਂ ਨਵੀਨਤਾ ਪ੍ਰਗਟ ਹੁੰਦੀ ਹੈ (ਜਾਂ ਇੱਕ ਦੂਜੀ ਆ ਰਹੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਸ ਕੇਸ ਵਿੱਚ) ਸਿਰਫ ਇੱਕ ਖਾਸ ਲਾਗੂ ਕਰਨ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। NoSQL ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਹਾਈਪ ਨੂੰ ਮੋਂਗੋਡੀਬੀ ਦੇ ਉਭਾਰ ਅਤੇ ਮੌਸਮੀ ਵਾਧੇ ਦੁਆਰਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰੇਰਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਮੋਂਗੋਡੀਬੀ ਨੇ ਇਸ ਰੁਝਾਨ ਨੂੰ ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤਾ: ਅਸਲ ਵਿੱਚ, ਵੱਡੀਆਂ ਇੰਟਰਨੈਟ ਕੰਪਨੀਆਂ ਨੂੰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਆਉਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਗਈਆਂ, ਜਿਸ ਨਾਲ ਗੈਰ-ਸੰਬੰਧੀ ਡੇਟਾਬੇਸ ਦੀ ਵਾਪਸੀ ਹੋਈ। ਸਮੁੱਚੀ ਲਹਿਰ ਗੂਗਲ ਦੇ ਬਿਗਟੇਬਲ ਅਤੇ ਫੇਸਬੁੱਕ ਦੇ ਕੈਸੈਂਡਰਾ ਵਰਗੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਈ, ਪਰ ਇਹ ਮੋਂਗੋਡੀਬੀ ਸੀ ਜੋ ਸਭ ਤੋਂ ਮਸ਼ਹੂਰ ਅਤੇ ਪਹੁੰਚਯੋਗ NoSQL ਡੇਟਾਬੇਸ ਲਾਗੂਕਰਨ ਬਣ ਗਿਆ ਜਿਸ ਤੱਕ ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰਾਂ ਦੀ ਪਹੁੰਚ ਸੀ।

ਨੋਟ: ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ ਕਿ ਮੈਂ ਕਾਲਮਨਰ ਡੇਟਾਬੇਸ, ਕੁੰਜੀ/ਮੁੱਲ ਸਟੋਰਾਂ, ਜਾਂ ਆਮ NoSQL ਪਰਿਭਾਸ਼ਾ ਦੇ ਅਧੀਨ ਆਉਂਦੇ ਹੋਰ ਕਈ ਕਿਸਮਾਂ ਦੇ ਡੇਟਾ ਸਟੋਰਾਂ ਦੇ ਨਾਲ ਦਸਤਾਵੇਜ਼ ਡੇਟਾਬੇਸ ਨੂੰ ਉਲਝਾ ਰਿਹਾ ਹਾਂ। ਅਤੇ ਤੁਸੀਂ ਸਹੀ ਹੋ। ਪਰ ਉਸ ਸਮੇਂ ਹਫੜਾ-ਦਫੜੀ ਦਾ ਰਾਜ ਸੀ। ਹਰ ਕੋਈ NoSQL ਦਾ ਜਨੂੰਨ ਹੈ, ਇਹ ਹਰ ਕੋਈ ਬਣ ਗਿਆ ਹੈ ਬਿਲਕੁਲ ਜ਼ਰੂਰੀ ਹੈ, ਹਾਲਾਂਕਿ ਕਈਆਂ ਨੇ ਵੱਖ-ਵੱਖ ਤਕਨਾਲੋਜੀਆਂ ਵਿੱਚ ਅੰਤਰ ਨਹੀਂ ਦੇਖਿਆ। ਬਹੁਤ ਸਾਰੇ ਲਈ, MongoDB ਬਣ ਗਿਆ ਹੈ ਨਾਲ ਸਮਾਨਾਰਥੀ NoSQL।

ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਨੇ ਇਸ 'ਤੇ ਜ਼ੋਰ ਦਿੱਤਾ. ਇੱਕ ਯੋਜਨਾ ਰਹਿਤ ਡੇਟਾਬੇਸ ਦਾ ਵਿਚਾਰ ਜੋ ਕਿਸੇ ਵੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਜਾਦੂਈ ਤੌਰ 'ਤੇ ਸਕੇਲ ਕਰਦਾ ਹੈ ਕਾਫ਼ੀ ਪਰਤੱਖ ਸੀ। 2014 ਦੇ ਆਸ-ਪਾਸ, ਅਜਿਹਾ ਲਗਦਾ ਸੀ ਕਿ ਹਰ ਜਗ੍ਹਾ ਜਿੱਥੇ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ ਜਿਵੇਂ ਕਿ MySQL, Postgres ਜਾਂ SQL ਸਰਵਰ ਨੇ MongoDB ਡੇਟਾਬੇਸ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ। ਜਦੋਂ ਇਹ ਪੁੱਛਿਆ ਗਿਆ ਕਿ ਕਿਉਂ, ਤੁਸੀਂ "ਇਹ ਵੈੱਬ ਦਾ ਪੈਮਾਨਾ ਹੈ" ਤੋਂ ਵਧੇਰੇ ਵਿਚਾਰਸ਼ੀਲ "ਮੇਰਾ ਡੇਟਾ ਬਹੁਤ ਢਿੱਲੀ ਢੰਗ ਨਾਲ ਢਾਂਚਾਗਤ ਹੈ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਸਕੀਮਾ ਦੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੈ" ਦਾ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

ਇਹ ਯਾਦ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਮੋਂਗੋਡੀਬੀ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਡੇਟਾਬੇਸ, ਰਵਾਇਤੀ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਨਾਲ ਕਈ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ:

• ਸਖਤ ਸਕੀਮ: ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡਾਟਾਬੇਸ ਦੇ ਨਾਲ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਡਾਟਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਜਾਂ ਤਾਂ ਡੇਟਾ ਦੇ ਬੇਤਰਤੀਬੇ "ਫੁਟਕਲ" ਕਾਲਮਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਬਣਾਉਣ, ਉੱਥੇ ਡੇਟਾ ਦੇ ਬਲੌਬਸ ਨੂੰ ਹਿਲਾ ਦੇਣ, ਜਾਂ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਈ.ਏ.ਵੀ...ਇਸ ਸਭ ਦੀਆਂ ਮਹੱਤਵਪੂਰਨ ਕਮੀਆਂ ਹਨ।
• ਸਕੇਲਿੰਗ ਵਿੱਚ ਮੁਸ਼ਕਲ: ਜੇਕਰ ਇੰਨਾ ਜ਼ਿਆਦਾ ਡੇਟਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਸਰਵਰ 'ਤੇ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਮੋਂਗੋਡੀਬੀ ਨੇ ਇਸ ਨੂੰ ਕਈ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਸਕੇਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਵਿਧੀਆਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕੀਤੀ ਹੈ।
• ਗੁੰਝਲਦਾਰ ਸਰਕਟ ਸੋਧ: ਕੋਈ ਪਰਵਾਸ ਨਹੀਂ! ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਨੂੰ ਬਦਲਣਾ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ (ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਹੁੰਦਾ ਹੈ)। ਮੋਂਗੋਡੀਬੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬਹੁਤ ਸਰਲ ਬਣਾਉਣ ਦੇ ਯੋਗ ਸੀ। ਅਤੇ ਇਸਨੇ ਇਸਨੂੰ ਇੰਨਾ ਆਸਾਨ ਬਣਾ ਦਿੱਤਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਰਕਟ ਨੂੰ ਅੱਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ ਜਿਵੇਂ ਤੁਸੀਂ ਜਾਂਦੇ ਹੋ ਅਤੇ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ।
• ਰਿਕਾਰਡਿੰਗ ਪ੍ਰਦਰਸ਼ਨ: MongoDB ਪ੍ਰਦਰਸ਼ਨ ਵਧੀਆ ਸੀ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਮੋਂਗੋਡੀਬੀ ਦੀ ਆਊਟ-ਆਫ-ਦ-ਬਾਕਸ ਸੰਰਚਨਾ, ਜਿਸ ਲਈ ਇਸਦੀ ਅਕਸਰ ਆਲੋਚਨਾ ਕੀਤੀ ਜਾਂਦੀ ਸੀ, ਨੇ ਕੁਝ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰਦਰਸ਼ਨ ਨੰਬਰ ਦਿਖਾਏ।

ਸਾਰੇ ਜੋਖਮ ਤੁਹਾਡੇ 'ਤੇ ਹਨ

ਮੋਂਗੋਡੀਬੀ ਦੇ ਸੰਭਾਵੀ ਲਾਭ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਨ, ਖਾਸ ਤੌਰ 'ਤੇ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕੁਝ ਵਰਗਾਂ ਲਈ। ਜੇ ਤੁਸੀਂ ਉਪਰੋਕਤ ਸੂਚੀ ਨੂੰ ਸੰਦਰਭ ਨੂੰ ਸਮਝੇ ਬਿਨਾਂ ਅਤੇ ਅਨੁਭਵ ਤੋਂ ਬਿਨਾਂ ਪੜ੍ਹਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਪ੍ਰਭਾਵ ਮਿਲ ਸਕਦਾ ਹੈ ਕਿ ਮੋਂਗੋਡੀਬੀ ਸੱਚਮੁੱਚ ਇੱਕ ਕ੍ਰਾਂਤੀਕਾਰੀ ਡੀਬੀਐਮਐਸ ਹੈ। ਸਿਰਫ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਉੱਪਰ ਸੂਚੀਬੱਧ ਲਾਭ ਕਈ ਚੇਤਾਵਨੀਆਂ ਦੇ ਨਾਲ ਆਏ ਸਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਹੇਠਾਂ ਦਿੱਤੇ ਗਏ ਹਨ।

ਨਿਰਪੱਖ ਹੋਣ ਲਈ, ਕੋਈ ਵੀ 10gen/MongoDB Inc. ਇਹ ਨਹੀਂ ਕਹੇਗਾ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ ਸੱਚ ਨਹੀਂ ਹਨ, ਇਹ ਸਿਰਫ਼ ਸਮਝੌਤਾ ਹਨ।

• ਗੁੰਮ ਹੋਏ ਲੈਣ-ਦੇਣ: ਲੈਣ-ਦੇਣ ਬਹੁਤ ਸਾਰੇ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ (ਸਾਰੇ ਨਹੀਂ, ਪਰ ਜ਼ਿਆਦਾਤਰ) ਦੀ ਇੱਕ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾ ਹਨ। ਲੈਣ-ਦੇਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਪ੍ਰਮਾਣੂ ਤੌਰ 'ਤੇ ਕਈ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹੋ ਕਿ ਡੇਟਾ ਇਕਸਾਰ ਰਹੇ। ਬੇਸ਼ੱਕ, ਇੱਕ NoSQL ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ, ਲੈਣ-ਦੇਣ ਇੱਕ ਇੱਕਲੇ ਦਸਤਾਵੇਜ਼ ਦੇ ਅੰਦਰ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਸਿਮੈਂਟਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਦੋ-ਪੜਾਅ ਪ੍ਰਤੀਬੱਧਤਾ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਕਾਰਜਕੁਸ਼ਲਤਾ ਆਪਣੇ ਆਪ ਨੂੰ ਲਾਗੂ ਕਰਨੀ ਪਵੇਗੀ... ਜੋ ਕਿ ਇੱਕ ਮੁਸ਼ਕਲ ਅਤੇ ਸਮਾਂ ਬਰਬਾਦ ਕਰਨ ਵਾਲਾ ਕੰਮ ਹੋ ਸਕਦਾ ਹੈ। ਅਕਸਰ ਤੁਹਾਨੂੰ ਇਹ ਅਹਿਸਾਸ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕੋਈ ਸਮੱਸਿਆ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਅਵੈਧ ਸਥਿਤੀਆਂ ਵਿੱਚ ਨਹੀਂ ਦੇਖਦੇ ਕਿਉਂਕਿ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਪ੍ਰਮਾਣੂਤਾ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਨੋਟ: ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਨੇ ਮੈਨੂੰ ਦੱਸਿਆ ਕਿ MongoDB 4.0 ਨੇ ਪਿਛਲੇ ਸਾਲ ਲੈਣ-ਦੇਣ ਦੀ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਸੀ, ਪਰ ਕੁਝ ਸੀਮਾਵਾਂ ਦੇ ਨਾਲ। ਲੇਖ ਤੋਂ ਪ੍ਰਾਪਤੀ ਉਹੀ ਰਹਿੰਦੀ ਹੈ: ਮੁਲਾਂਕਣ ਕਰੋ ਕਿ ਤਕਨਾਲੋਜੀ ਤੁਹਾਡੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪੂਰਾ ਕਰਦੀ ਹੈ।
• ਰਿਲੇਸ਼ਨਲ ਅਖੰਡਤਾ ਦਾ ਨੁਕਸਾਨ (ਵਿਦੇਸ਼ੀ ਕੁੰਜੀਆਂ): ਜੇਕਰ ਤੁਹਾਡੇ ਡੇਟਾ ਵਿੱਚ ਸਬੰਧ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਹੋਵੇਗਾ। ਇੱਕ ਡੇਟਾਬੇਸ ਹੋਣਾ ਜੋ ਇਹਨਾਂ ਸਬੰਧਾਂ ਦਾ ਸਤਿਕਾਰ ਕਰਦਾ ਹੈ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਲਵੇਗਾ ਅਤੇ ਇਸਲਈ ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮਰ.
• ਡਾਟਾ ਬਣਤਰ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੀ ਘਾਟ: ਸਖ਼ਤ ਸਕੀਮਾਂ ਕਈ ਵਾਰ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਜੇ ਸਮਝਦਾਰੀ ਨਾਲ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਉਹ ਚੰਗੇ ਡੇਟਾ ਢਾਂਚੇ ਲਈ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਵਿਧੀ ਵੀ ਹਨ। ਮੋਂਗੋਡੀਬੀ ਵਰਗੇ ਦਸਤਾਵੇਜ਼ ਡੇਟਾਬੇਸ ਸ਼ਾਨਦਾਰ ਸਕੀਮਾ ਲਚਕਤਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਪਰ ਇਹ ਲਚਕਤਾ ਡੇਟਾ ਨੂੰ ਸਾਫ਼ ਰੱਖਣ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਦੇਖਭਾਲ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਡੇਟਾ ਦੇ ਖਾਤੇ ਲਈ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਲਿਖੋਗੇ ਜੋ ਤੁਹਾਡੇ ਦੁਆਰਾ ਉਮੀਦ ਕੀਤੇ ਫਾਰਮ ਵਿੱਚ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਅਕਸਰ ਸਾਡੀ ਕੰਪਨੀ ਸਧਾਰਨ ਥ੍ਰੈਡ ਵਿੱਚ ਕਹਿੰਦੇ ਹਾਂ... ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਿਸੇ ਦਿਨ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾਵੇਗਾ, ਪਰ ਡੇਟਾ ਹਮੇਸ਼ਾ ਲਈ ਜੀਵਿਤ ਰਹੇਗਾ। ਨੋਟ: ਮੋਂਗੋਡੀਬੀ ਸਕੀਮਾ ਜਾਂਚ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ: ਇਹ ਲਾਭਦਾਇਕ ਹੈ, ਪਰ ਉਹੀ ਗਾਰੰਟੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਜਿਵੇਂ ਕਿ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਹੈ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਸਕੀਮਾ ਜਾਂਚ ਨੂੰ ਜੋੜਨਾ ਜਾਂ ਬਦਲਣਾ ਸੰਗ੍ਰਹਿ ਵਿੱਚ ਮੌਜੂਦਾ ਡੇਟਾ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਇਹ ਯਕੀਨੀ ਕਰਨਾ ਤੁਹਾਡੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਨਵੀਂ ਸਕੀਮਾ ਦੇ ਅਨੁਸਾਰ ਡੇਟਾ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹੋ। ਆਪਣੇ ਲਈ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਇਹ ਤੁਹਾਡੀਆਂ ਲੋੜਾਂ ਲਈ ਕਾਫੀ ਹੈ।
• ਮੂਲ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ / ਟੂਲ ਈਕੋਸਿਸਟਮ ਦਾ ਨੁਕਸਾਨ: SQL ਦਾ ਆਗਮਨ ਇੱਕ ਪੂਰਨ ਕ੍ਰਾਂਤੀ ਸੀ ਅਤੇ ਉਦੋਂ ਤੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲਿਆ ਹੈ। ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਭਾਸ਼ਾ ਹੈ, ਪਰ ਇਹ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਵੀ ਹੈ। JSON ਟੁਕੜਿਆਂ ਵਾਲੀ ਇੱਕ ਨਵੀਂ ਭਾਸ਼ਾ ਵਿੱਚ ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਉਹਨਾਂ ਲੋਕਾਂ ਦੁਆਰਾ ਪਿੱਛੇ ਵੱਲ ਇੱਕ ਵੱਡਾ ਕਦਮ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ SQL ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਤਜਰਬਾ ਹੈ। ਟੂਲਸ ਦਾ ਇੱਕ ਪੂਰਾ ਬ੍ਰਹਿਮੰਡ ਹੈ ਜੋ SQL ਡੇਟਾਬੇਸ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ, IDEs ਤੋਂ ਲੈ ਕੇ ਰਿਪੋਰਟਿੰਗ ਟੂਲਸ ਤੱਕ। SQL ਦਾ ਸਮਰਥਨ ਨਾ ਕਰਨ ਵਾਲੇ ਡੇਟਾਬੇਸ 'ਤੇ ਜਾਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਡਾਟਾ ਨੂੰ SQL ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨਾ ਪਵੇਗਾ, ਜੋ ਤੁਹਾਡੇ ਸੋਚਣ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ।

ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਜੋ ਮੋਂਗੋਡੀਬੀ ਵੱਲ ਮੁੜੇ ਹਨ, ਅਸਲ ਵਿੱਚ ਵਪਾਰ-ਆਫਸ ਨੂੰ ਨਹੀਂ ਸਮਝ ਸਕੇ, ਅਤੇ ਅਕਸਰ ਇਸਨੂੰ ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾ ਸਟੋਰ ਦੇ ਰੂਪ ਵਿੱਚ ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਮੁੱਖ ਤੌਰ 'ਤੇ ਡੁਬਕੀ ਮਾਰਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਆਉਣਾ ਅਕਸਰ ਅਵਿਸ਼ਵਾਸ਼ਯੋਗ ਤੌਰ 'ਤੇ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਸੀ।

ਕੀ ਵੱਖਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ?

ਹਰ ਕੋਈ ਸਿਰ ਤੋਂ ਪਹਿਲਾਂ ਛਾਲ ਨਹੀਂ ਮਾਰਦਾ ਅਤੇ ਹੇਠਾਂ ਨਹੀਂ ਮਾਰਦਾ। ਪਰ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੇ ਮੋਂਗੋਡੀਬੀ ਨੂੰ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ ਜਿੱਥੇ ਇਹ ਸਿਰਫ਼ ਫਿੱਟ ਨਹੀਂ ਸੀ - ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਉਣ ਵਾਲੇ ਕਈ ਸਾਲਾਂ ਤੱਕ ਇਸਦੇ ਨਾਲ ਰਹਿਣਾ ਪਵੇਗਾ। ਜੇ ਇਹਨਾਂ ਸੰਸਥਾਵਾਂ ਨੇ ਕੁਝ ਸਮਾਂ ਬਿਤਾਇਆ ਹੁੰਦਾ ਅਤੇ ਆਪਣੀ ਤਕਨਾਲੋਜੀ ਵਿਕਲਪਾਂ ਦੁਆਰਾ ਵਿਧੀਪੂਰਵਕ ਸੋਚਿਆ ਹੁੰਦਾ, ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਵੱਖੋ-ਵੱਖਰੀਆਂ ਚੋਣਾਂ ਕਰ ਸਕਦੇ ਸਨ।

ਸਹੀ ਤਕਨਾਲੋਜੀ ਦੀ ਚੋਣ ਕਿਵੇਂ ਕਰੀਏ? ਤਕਨਾਲੋਜੀ ਮੁਲਾਂਕਣ ਲਈ ਇੱਕ ਯੋਜਨਾਬੱਧ ਢਾਂਚਾ ਬਣਾਉਣ ਲਈ ਕਈ ਕੋਸ਼ਿਸ਼ਾਂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ "ਸਾਫਟਵੇਅਰ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਤਕਨਾਲੋਜੀਆਂ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਲਈ ਫਰੇਮਵਰਕ" и "ਸਾਫਟਵੇਅਰ ਤਕਨਾਲੋਜੀਆਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਫਰੇਮਵਰਕ", ਪਰ ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਇਹ ਬੇਲੋੜੀ ਜਟਿਲਤਾ ਹੈ।

ਬਹੁਤ ਸਾਰੀਆਂ ਤਕਨੀਕਾਂ ਦਾ ਸਿਰਫ਼ ਦੋ ਬੁਨਿਆਦੀ ਸਵਾਲ ਪੁੱਛ ਕੇ ਸਮਝਦਾਰੀ ਨਾਲ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਮੱਸਿਆ ਉਹਨਾਂ ਲੋਕਾਂ ਨੂੰ ਲੱਭਣ ਦੀ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ, ਜਵਾਬ ਲੱਭਣ ਲਈ ਸਮਾਂ ਕੱਢਣ ਅਤੇ ਪੱਖਪਾਤ ਦੇ ਬਿਨਾਂ.

ਜੇਕਰ ਤੁਹਾਨੂੰ ਕਿਸੇ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਨਵੇਂ ਟੂਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਬਿੰਦੀ.

ਪ੍ਰਸ਼ਨ 1: ਮੈਂ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ?

ਜੇਕਰ ਤੁਹਾਨੂੰ ਕਿਸੇ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਨਵੇਂ ਟੂਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਬਿੰਦੀ. ਹੱਲ ਲੱਭਣ ਅਤੇ ਫਿਰ ਸਮੱਸਿਆ ਦੀ ਖੋਜ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ. ਜਦੋਂ ਤੱਕ ਤੁਹਾਨੂੰ ਅਜਿਹੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ ਜਿਸ ਨੂੰ ਨਵੀਂ ਤਕਨਾਲੋਜੀ ਤੁਹਾਡੀ ਮੌਜੂਦਾ ਤਕਨਾਲੋਜੀ ਨਾਲੋਂ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਹੱਲ ਕਰਦੀ ਹੈ, ਇੱਥੇ ਚਰਚਾ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸ ਤਕਨਾਲੋਜੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹੋ ਕਿਉਂਕਿ ਤੁਸੀਂ ਦੂਜਿਆਂ ਨੂੰ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਦੇਖਿਆ ਹੈ, ਤਾਂ ਵਿਚਾਰ ਕਰੋ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ ਪੁੱਛੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਉਹ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਕਿਸੇ ਤਕਨਾਲੋਜੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ ਦੂਸਰੇ ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ, ਚੁਣੌਤੀ ਇਹ ਸਮਝ ਰਹੀ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਉਹੀ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋ।

ਪ੍ਰਸ਼ਨ 2: ਮੈਂ ਕੀ ਗੁਆ ਰਿਹਾ ਹਾਂ?

ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇੱਕ ਹੋਰ ਔਖਾ ਸਵਾਲ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਪੁਰਾਣੀ ਅਤੇ ਨਵੀਂ ਤਕਨਾਲੋਜੀ ਦੋਵਾਂ ਦੀ ਚੰਗੀ ਸਮਝ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਕਦੇ-ਕਦੇ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਇੱਕ ਨਵੇਂ ਨੂੰ ਉਦੋਂ ਤੱਕ ਨਹੀਂ ਸਮਝ ਸਕਦੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਣਾਇਆ ਜਾਂ ਉਸ ਅਨੁਭਵ ਵਾਲਾ ਕੋਈ ਵਿਅਕਤੀ ਨਹੀਂ ਹੈ।

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਵੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਸ ਸਾਧਨ ਦੇ ਮੁੱਲ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਸੰਭਵ ਨਿਵੇਸ਼ ਬਾਰੇ ਸੋਚਣਾ ਸਮਝਦਾਰੀ ਵਾਲਾ ਹੈ। ਅਤੇ ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਨਿਵੇਸ਼ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਫੈਸਲੇ ਨੂੰ ਉਲਟਾਉਣਾ ਕਿੰਨਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ?

ਲੋਕ ਹਮੇਸ਼ਾ ਸਭ ਕੁਝ ਬਰਬਾਦ ਕਰ ਦਿੰਦੇ ਹਨ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਨਿਰਪੱਖਤਾ ਨਾਲ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਇੱਕ ਗੱਲ ਯਾਦ ਰੱਖੋ: ਤੁਹਾਨੂੰ ਮਨੁੱਖੀ ਸੁਭਾਅ ਨਾਲ ਲੜਨਾ ਪਵੇਗਾ. ਤਕਨਾਲੋਜੀ ਦੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਮੁਲਾਂਕਣ ਲਈ ਬਹੁਤ ਸਾਰੇ ਬੋਧਾਤਮਕ ਪੱਖਪਾਤ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਦੂਰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਇੱਥੇ ਕੁਝ ਕੁ ਹਨ:

• ਬਹੁਮਤ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਦਾ ਪ੍ਰਭਾਵ - ਹਰ ਕੋਈ ਉਸ ਬਾਰੇ ਜਾਣਦਾ ਹੈ, ਪਰ ਉਸ ਨਾਲ ਲੜਨਾ ਅਜੇ ਵੀ ਮੁਸ਼ਕਲ ਹੈ. ਬਸ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤਕਨਾਲੋਜੀ ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੀਆਂ ਅਸਲ ਲੋੜਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।
• ਨਵੀਨਤਾ ਪ੍ਰਭਾਵ — ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਉਹਨਾਂ ਤਕਨਾਲੋਜੀਆਂ ਨੂੰ ਘੱਟ ਸਮਝਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਉਹਨਾਂ ਨੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਕੰਮ ਕੀਤਾ ਹੈ ਅਤੇ ਨਵੀਂ ਤਕਨਾਲੋਜੀ ਦੇ ਲਾਭਾਂ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਹੈ। ਇਹ ਸਿਰਫ਼ ਪ੍ਰੋਗਰਾਮਰ ਹੀ ਨਹੀਂ, ਹਰ ਕੋਈ ਇਸ ਬੋਧਾਤਮਕ ਪੱਖਪਾਤ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ।
• ਸਕਾਰਾਤਮਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਪ੍ਰਭਾਵ - ਅਸੀਂ ਇਹ ਦੇਖਣ ਲਈ ਹੁੰਦੇ ਹਾਂ ਕਿ ਉੱਥੇ ਕੀ ਹੈ ਅਤੇ ਜੋ ਗੁੰਮ ਹੈ ਉਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੇ ਹਾਂ। ਨਵੀਨਤਾ ਪ੍ਰਭਾਵ ਦੇ ਨਾਲ ਜੋੜਨ 'ਤੇ ਇਹ ਹਫੜਾ-ਦਫੜੀ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਨਾ ਸਿਰਫ ਨਵੀਂ ਤਕਨਾਲੋਜੀ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਦਿੰਦੇ ਹੋ, ਸਗੋਂ ਇਸ ਦੀਆਂ ਕਮੀਆਂ ਨੂੰ ਵੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹੋ.

ਉਦੇਸ਼ ਮੁਲਾਂਕਣ ਆਸਾਨ ਨਹੀਂ ਹੈ, ਪਰ ਅੰਤਰੀਵ ਬੋਧਾਤਮਕ ਪੱਖਪਾਤ ਨੂੰ ਸਮਝਣਾ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਤਰਕਸੰਗਤ ਫੈਸਲੇ ਲੈਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ।

ਸੰਖੇਪ

ਜਦੋਂ ਵੀ ਕੋਈ ਨਵੀਨਤਾ ਪ੍ਰਗਟ ਹੁੰਦੀ ਹੈ, ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਦਿੱਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ:

• ਕੀ ਇਹ ਸਾਧਨ ਅਸਲ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ?
• ਕੀ ਅਸੀਂ ਵਪਾਰ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਦੇ ਹਾਂ?

ਜੇਕਰ ਤੁਸੀਂ ਭਰੋਸੇ ਨਾਲ ਇਹਨਾਂ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ ਹੋ, ਤਾਂ ਕੁਝ ਕਦਮ ਪਿੱਛੇ ਹਟ ਕੇ ਸੋਚੋ।

ਤਾਂ ਕੀ ਮੋਂਗੋਡੀਬੀ ਵੀ ਸਹੀ ਚੋਣ ਸੀ? ਬੇਸ਼ੱਕ ਹਾਂ; ਜਿਵੇਂ ਕਿ ਜ਼ਿਆਦਾਤਰ ਇੰਜੀਨੀਅਰਿੰਗ ਤਕਨਾਲੋਜੀਆਂ ਦੇ ਨਾਲ, ਇਹ ਬਹੁਤ ਸਾਰੇ ਕਾਰਕਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਾਲਿਆਂ ਵਿੱਚੋਂ, ਕਈਆਂ ਨੇ ਮੋਂਗੋਡੀਬੀ ਤੋਂ ਲਾਭ ਉਠਾਇਆ ਹੈ ਅਤੇ ਅਜਿਹਾ ਕਰਨਾ ਜਾਰੀ ਰੱਖਿਆ ਹੈ। ਉਹਨਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੇ ਅਜਿਹਾ ਨਹੀਂ ਕੀਤਾ, ਮੈਂ ਉਮੀਦ ਕਰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਹਾਈਪ ਚੱਕਰ ਵਿੱਚੋਂ ਲੰਘਣ ਬਾਰੇ ਇੱਕ ਕੀਮਤੀ ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਦਰਦਨਾਕ ਸਬਕ ਨਹੀਂ ਸਿੱਖਿਆ ਹੈ।

ਬੇਦਾਅਵਾ

ਮੈਂ ਸਪੱਸ਼ਟ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਮੇਰਾ MongoDB ਨਾਲ ਨਾ ਤਾਂ ਪਿਆਰ ਹੈ ਅਤੇ ਨਾ ਹੀ ਨਫ਼ਰਤ ਵਾਲਾ ਰਿਸ਼ਤਾ। ਸਾਡੇ ਕੋਲ ਇਸ ਕਿਸਮ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਮੋਂਗੋਡੀਬੀ ਸਭ ਤੋਂ ਅਨੁਕੂਲ ਹੈ। ਮੈਨੂੰ ਪਤਾ ਹੈ ਕਿ 10gen/MongoDB Inc. ਪਹਿਲਾਂ ਬਹੁਤ ਬੋਲਡ ਸੀ, ਅਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟਸ ਨੂੰ ਸੈੱਟ ਕਰਨਾ ਅਤੇ ਕਿਸੇ ਵੀ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇੱਕ ਵਿਆਪਕ ਹੱਲ ਵਜੋਂ ਹਰ ਥਾਂ (ਖਾਸ ਕਰਕੇ ਹੈਕਾਥਨ ਵਿੱਚ) MongoDB ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਨਾ। ਇਹ ਸ਼ਾਇਦ ਇੱਕ ਬੁਰਾ ਫੈਸਲਾ ਸੀ. ਪਰ ਇਹ ਇੱਥੇ ਵਰਣਿਤ ਪਹੁੰਚ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ: ਤਕਨਾਲੋਜੀ ਦੇ ਸਤਹੀ ਮੁਲਾਂਕਣ ਦੇ ਨਾਲ ਵੀ ਇਹ ਸਮੱਸਿਆਵਾਂ ਬਹੁਤ ਜਲਦੀ ਖੋਜੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਸਰੋਤ: www.habr.com