CQRS (ਕਮਾਂਡ ਅਤੇ ਕੁਐਰੀ ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੀ ਵੰਡ) ਡਾਟਾ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਮਾਡਲ ਨੂੰ ਡਾਟਾ ਪੜ੍ਹਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਮਾਡਲ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਲਿਖਣ ਵਾਲਾ ਪੱਖ ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ; ਪੜ੍ਹਨ ਵਾਲਾ ਪੱਖ ਜਾਣਕਾਰੀ ਨੂੰ ਦਿਖਾਉਣ ਜਾਂ ਲੱਭਣ ਲਈ ਵਿਵਸਥਿਤ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਨ ਲਈ, ਸਿਨੇਮਾ ਦੀ ਟਿਕਟ ਬੁੱਕ ਕਰਨ ਲਈ ਸੀਟ ਦੀ ਉਪਲਬਧਤਾ ਜਾਂਚਣੀ ਪੈਂਦੀ ਹੈ। ਟਿਕਟਾਂ ਦੀ ਸੂਚੀ ਲਈ ਫ਼ਿਲਮ ਦਾ ਨਾਮ, ਸ਼ੋਅ ਦਾ ਸਮਾਂ ਅਤੇ ਸੀਟ ਦੀ ਥਾਂ ਚਾਹੀਦੀ ਹੈ। ਇਨ੍ਹਾਂ ਕੰਮਾਂ ਵਿੱਚ ਉਹੀ ਡਾਟਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਵੱਖਰੀ ਪ੍ਰਕਿਰਿਆ ਚਾਹੀਦੀ ਹੈ।
ਦੋਵੇਂ ਮਾਡਲ ਇੱਕੋ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਰਹਿ ਸਕਦੇ ਹਨ ਅਤੇ ਡਾਟਾਬੇਸ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹਨ। CQRS ਲਈ ਦੋ ਡਾਟਾਬੇਸ, ਕਤਾਰ ਜਾਂ Event Sourcing ਲਾਜ਼ਮੀ ਨਹੀਂ ਹਨ।
ਜਦੋਂ ਗਾਹਕ ਸੀਟ ਚੁਣਦਾ ਹੈ, ਬੇਨਤੀ ਲਿਖਣ ਵਾਲੇ ਪੱਖ ਨੂੰ ਜਾਂਦੀ ਹੈ। ਪ੍ਰਣਾਲੀ ਬੁਕਿੰਗ ਜਾਂਚਦੀ ਅਤੇ ਸੰਭਾਲਦੀ ਹੈ; ਢੁੱਕਵੀਆਂ ਡਾਟਾ ਪਾਬੰਦੀਆਂ ਵਾਲੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਨੂੰ ਦੋ ਗਾਹਕਾਂ ਵੱਲੋਂ ਇੱਕੋ ਸ਼ੋਅ ਲਈ ਇੱਕੋ ਸੀਟ ਬੁੱਕ ਕਰਨ ਤੋਂ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ। ਲਿਖਣ ਦਾ ਕੰਮ ਸਫਲ ਹੋਣ 'ਤੇ ਗਾਹਕ ਨੂੰ ਪੁਸ਼ਟੀ ਮਿਲਦੀ ਹੈ।
ਜਦੋਂ ਗਾਹਕ “ਮੇਰੀਆਂ ਟਿਕਟਾਂ” ਖੋਲ੍ਹਦਾ ਹੈ, ਪੜ੍ਹਨ ਵਾਲਾ ਪੱਖ ਫ਼ਿਲਮਾਂ ਦੇ ਨਾਮਾਂ, ਸ਼ੋਅ ਦੇ ਸਮਿਆਂ ਅਤੇ ਸੀਟਾਂ ਵਾਲੀ ਸੂਚੀ ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਬੁਕਿੰਗ ਦੇ ਨਿਯਮ ਬਦਲੇ ਬਿਨਾਂ ਇਸ ਦੀ ਪੇਸ਼ਕਾਰੀ ਬਦਲ ਸਕਦੀ ਹੈ।
ਜੇ ਕੁਐਰੀਆਂ ਬਹੁਤ ਸਰੋਤ ਖਪਾਉਣ ਲੱਗਣ, ਤਾਂ ਪ੍ਰਣਾਲੀ ਉਹ ਵੇਰਵੇ ਪਹਿਲਾਂ ਹੀ ਜੋੜ ਕੇ ਇੱਕ ਵੱਖਰੀ ਪੜ੍ਹਨ ਵਾਲੀ ਟੇਬਲ ਰੱਖ ਸਕਦੀ ਹੈ। ਜੇ ਉਹ ਟੇਬਲ ਅਸਿੰਕ੍ਰੋਨਸ ਤਰੀਕੇ ਨਾਲ ਅੱਪਡੇਟ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਨਵੀਂ ਟਿਕਟ ਤੁਰੰਤ ਨਹੀਂ ਦਿਸ ਸਕਦੀ; ਸੂਚੀ ਤਾਜ਼ਾ ਕਰਦਿਆਂ ਇੰਟਰਫੇਸ ਨੂੰ ਸਫਲ ਬੁਕਿੰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਾਇਮ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ।
CQRS ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਅੱਪਡੇਟਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਹੋਣ ਪਰ ਸਕ੍ਰੀਨਾਂ ਜਾਂ ਰਿਪੋਰਟਾਂ ਨੂੰ ਬਹੁਤ ਵੱਖਰੀ ਪੇਸ਼ਕਾਰੀ ਚਾਹੀਦੀ ਹੋਵੇ। ਇਹ ਪੂਰੀ ਪ੍ਰਣਾਲੀ ਦੀ ਥਾਂ ਸਿਰਫ਼ ਟਿਕਟ ਬੁਕਿੰਗ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕਦਾ ਹੈ।
ਜਿਹੜੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਸਿਰਫ਼ ਸਧਾਰਨ ਰਿਕਾਰਡ ਬਣਾਉਂਦੀਆਂ, ਪੜ੍ਹਦੀਆਂ, ਅੱਪਡੇਟ ਕਰਦੀਆਂ ਅਤੇ ਮਿਟਾਉਂਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਮਾਡਲ ਵਿਕਸਿਤ ਕਰਨਾ ਅਕਸਰ ਸੌਖਾ ਹੁੰਦਾ ਹੈ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ