ਡਾਟਾਬੇਸ ਕੀ ਹੈ? ਐਪ ਬਣਾਉਣ ਵਾਲਿਆਂ ਲਈ ਗਾਈਡ

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

ਜਦੋਂ ਤੁਸੀਂ ਏਆਈ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

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

ਡਾਟਾਬੇਸ ਉਹ ਥਾਂ ਵੀ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਅਹਿਮ ਫੈਸਲੇ ਰਹਿੰਦੇ ਹਨ, ਭਾਵੇਂ ਤੁਸੀਂ ਇਹ ਜਾਣੋ ਜਾਂ ਨਾ:

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

ਤੁਹਾਨੂੰ ਡਾਟਾਬੇਸ ਖੁਦ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਪਰ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਸਮਝਣ ਨਾਲ ਤੁਸੀਂ ਆਪਣਾ ਡਾਟਾ ਸਾਫ਼ ਦੱਸ ਸਕਦੇ ਹੋ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਜਲਦੀ ਫੜ ਸਕਦੇ ਹੋ।

ਰੋਜ਼ਾਨਾ ਦੀ ਮਿਸਾਲ

ਇੱਕ ਛੋਟੇ ਦਫ਼ਤਰ ਦੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚਲਾਈ ਜਾਂਦੀ ਫਾਈਲਿੰਗ ਅਲਮਾਰੀ ਦੀ ਕਲਪਨਾ ਕਰੋ।

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

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

ਇੱਕ ਕੰਮ ਦੀ ਮਿਸਾਲ: ਇੱਕ ਸੈਲੂਨ ਬੁਕਿੰਗ ਐਪ

ਮੰਨ ਲਓ ਤੁਸੀਂ ਕਿਸੇ ਏਆਈ ਨੂੰ ਹੇਅਰ ਸੈਲੂਨ ਲਈ ਬੁਕਿੰਗ ਸਾਈਟ ਬਣਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹੋ। ਇੱਕ ਠੀਕ ਡਾਟਾਬੇਸ ਵਿੱਚ ਚਾਰ ਟੇਬਲ ਹੋਣਗੇ।

services

staff

customers

bookings

bookings ਟੇਬਲ ਨੂੰ ਵੇਖੋ। ਇਹ ਹਰ ਬੁਕਿੰਗ ਵਿੱਚ Lena ਦਾ ਨਾਮ ਅਤੇ ਫ਼ੋਨ ਨੰਬਰ ਨਹੀਂ ਨਕਲ ਕਰਦਾ; ਇਹ customer_id = 101 ਸੰਭਾਲਦਾ ਹੈ। ਜੇ Lena ਆਪਣਾ ਫ਼ੋਨ ਨੰਬਰ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਉਹ ਇੱਕ ਥਾਂ 'ਤੇ ਬਦਲਦਾ ਹੈ ਅਤੇ ਹਰ ਬੁਕਿੰਗ ਨਵਾਂ ਨੰਬਰ ਦਿਖਾਉਂਦੀ ਹੈ। ਇਹ ਰਿਲੇਸ਼ਨਲ ਡਾਟਾਬੇਸ ਦਾ ਮੂਲ ਵਿਚਾਰ ਹੈ: ਹਰ ਤੱਥ ਇੱਕ ਵਾਰ ਸੇਵ ਕਰੋ, ਅਤੇ ਉਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ।

ਉਹੀ ਢਾਂਚਾ ਕੰਮ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:

• “ਸ਼ੁੱਕਰਵਾਰ ਨੂੰ Omar ਲਈ ਕਿਹੜੇ ਸਲਾਟ ਖਾਲੀ ਹਨ?” ਉਸ ਦਿਨ ਦੀਆਂ Omar ਦੀਆਂ ਬੁਕਿੰਗਾਂ ਵੇਖੋ।
• “ਇਸ ਮਹੀਨੇ ਕਲਰ ਅਪੌਇੰਟਮੈਂਟਾਂ ਨੇ ਕਿੰਨੀ ਕਮਾਈ ਕੀਤੀ?” ਬੁਕਿੰਗਾਂ ਨੂੰ ਸੇਵਾਵਾਂ ਨਾਲ ਜੋੜੋ ਅਤੇ ਕੀਮਤਾਂ ਜੋੜੋ।
• “ਕਿਹੜੇ ਗਾਹਕ 90 ਦਿਨਾਂ ਤੋਂ ਬੁੱਕ ਨਹੀਂ ਕੀਤਾ?” ਗਾਹਕਾਂ ਦੀ ਆਖਰੀ ਬੁਕਿੰਗ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

ਆਮ ਸ਼ਬਦਾਂ ਦੀ ਵਿਆਖਿਆ

ਡਾਟਾਬੇਸਾਂ ਦੀਆਂ ਕਿਸਮਾਂ

ਲਗਭਗ ਹਰ ਚੀਜ਼ ਲਈ ਜੋ ਕੋਈ ਸੰਸਥਾਪਕ ਜਾਂ ਛੋਟਾ ਕਾਰੋਬਾਰ ਪਹਿਲਾਂ ਬਣਾਉਂਦਾ ਹੈ, ਰਿਲੇਸ਼ਨਲ ਡਾਟਾਬੇਸ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਹੈ।

ਡਾਟਾਬੇਸ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ ਕਿੱਥੇ ਬੈਠਦਾ ਹੈ

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

ਇਹ ਵਿਚਲਾ ਕਦਮ ਬਹੁਤ ਅਹਿਮ ਹੈ। ਜੇ ਬਰਾਊਜ਼ਰ ਸਿੱਧਾ ਪੂਰੀ ਪਹੁੰਚ ਨਾਲ ਡਾਟਾਬੇਸ ਨੂੰ ਕਵੈਰੀ ਕਰ ਸਕਦਾ, ਤਾਂ ਕੋਈ ਵੀ ਡਿਵੈਲਪਰ ਟੂਲ ਖੋਲ੍ਹ ਕੇ ਸਭ ਕੁਝ ਪੜ੍ਹ ਸਕਦਾ ਸੀ।

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਗਲਤਫਹਿਮੀਆਂ

• ਡਾਟਾ ਸਿਰਫ਼ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਰੱਖਣਾ। ਬਰਾਊਜ਼ਰ ਸਟੋਰੇਜ (ਜਿਵੇਂ localStorage) ਇੱਕ ਡਿਵਾਈਸ ਅਤੇ ਇੱਕ ਬਰਾਊਜ਼ਰ 'ਤੇ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਕਿਸੇ ਯਾਦ ਰੱਖੇ ਫਿਲਟਰ ਲਈ ਠੀਕ ਹੈ, ਆਰਡਰਾਂ ਲਈ ਨਹੀਂ।
• ਸਭ ਕੁਝ ਇੱਕ ਟੇਬਲ ਵਿੱਚ ਠੂਸਣਾ। ਇੱਕ ਇੱਕਲਾ “bookings” ਟੇਬਲ ਜਿਸ ਵਿੱਚ ਹਰ ਰੋਅ ਵਿੱਚ ਗਾਹਕ ਦਾ ਨਾਮ, ਫ਼ੋਨ ਅਤੇ ਸੇਵਾ ਦੀ ਕੀਮਤ ਨਕਲ ਹੋਵੇ, ਜਲਦੀ ਹੀ ਅਸਮਿਲ ਹੋ ਜਾਂਦਾ ਹੈ।
• ਪਾਸਵਰਡ ਸਾਦੇ ਟੈਕਸਟ ਵਿੱਚ ਸੇਵ ਕਰਨਾ। ਪਾਸਵਰਡ ਹੈਸ਼ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਦੇ ਵੀ ਪੜ੍ਹਨ ਯੋਗ ਰੂਪ ਵਿੱਚ ਨਹੀਂ। ਵੇਖੋ ਆਥੈਂਟੀਕੇਸ਼ਨ ਕੀ ਹੈ।
• ਡਾਟੇ 'ਤੇ ਕੋਈ ਨਿਯਮ ਨਾ ਹੋਣਾ। ਲੋੜੀਂਦੇ ਖੇਤਰਾਂ ਅਤੇ ਵਿਲੱਖਣਤਾ ਦੇ ਨਿਯਮਾਂ ਤੋਂ ਬਿਨਾਂ, ਤੁਹਾਨੂੰ ਬਿਨਾਂ ਤਾਰੀਖ ਵਾਲੀਆਂ ਬੁਕਿੰਗਾਂ ਅਤੇ ਦੁਹਰਾਏ ਗਾਹਕ ਮਿਲਣਗੇ।
• ਮਿਟਾਉਣ ਬਾਰੇ ਨਾ ਸੋਚਣਾ। ਤੈਅ ਕਰੋ ਕਿ ਗਾਹਕ ਮਿਟਾਉਣ ਨਾਲ ਉਸ ਦੀਆਂ ਬੁਕਿੰਗਾਂ ਮਿਟਣ, ਰਹਿਣ, ਜਾਂ ਰੋਕ ਦਿੱਤਾ ਜਾਵੇ।
• ਤਜਰਬੇ ਲਈ ਅਸਲ ਡਾਟੇ ਦੀ ਵਰਤੋਂ। ਜੋਖਮ ਵਾਲੀਆਂ ਤਬਦੀਲੀਆਂ ਪਹਿਲਾਂ ਕਿਸੇ ਸੁਰੱਖਿਅਤ ਥਾਂ 'ਤੇ ਅਜ਼ਮਾਓ, ਅਤੇ ਬੈਕਅੱਪ ਰੱਖੋ।
• ਸਪਰੈੱਡਸ਼ੀਟ ਨੂੰ ਹਮੇਸ਼ਾ ਲਈ ਡਾਟਾਬੇਸ ਮੰਨਣਾ। ਸਪਰੈੱਡਸ਼ੀਟ ਸ਼ੁਰੂਆਤ ਲਈ ਵਧੀਆ ਹਨ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਇੱਕੋ ਵੇਲੇ ਯੂਜ਼ਰਾਂ ਅਤੇ ਪਰਮਿਸ਼ਨਾਂ ਨਾਲ ਦਿੱਕਤ ਆਉਂਦੀ ਹੈ। ਵੇਖੋ ਸਪਰੈੱਡਸ਼ੀਟ ਨੂੰ ਐਪ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ।

ਆਪਣੇ ਏਆਈ ਬਿਲਡਰ ਤੋਂ ਕੀ ਮੰਗਣਾ ਹੈ

• “ਇਹ ਡਾਟਾ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਨਹੀਂ, ਡਾਟਾਬੇਸ ਵਿੱਚ ਸੇਵ ਕਰੋ। ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀਆਂ ਟੇਬਲਾਂ ਬਣਾਓਗੇ।”
• “ਸਕੀਮਾ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਟੇਬਲ ਵਜੋਂ ਵਿਖਾਓ: ਹਰ ਟੇਬਲ, ਉਸਦੇ ਕਾਲਮ ਅਤੇ ਉਹ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ।”
• “ਇੱਕ ਗਾਹਕ ਦੀਆਂ ਕਈ ਬੁਕਿੰਗਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ; ਹਰ ਬੁਕਿੰਗ ਦੀ ਬਿਲਕੁਲ ਇੱਕ ਸੇਵਾ ਅਤੇ ਇੱਕ ਸਟਾਫ਼ ਮੈਂਬਰ ਹੋਵੇ।”
• “ਗਾਹਕਾਂ ਲਈ ਈਮੇਲ ਲਾਜ਼ਮੀ ਅਤੇ ਵਿਲੱਖਣ ਬਣਾਓ।”
• “ਇੱਕੋ ਸਟਾਫ਼ ਮੈਂਬਰ ਦੀਆਂ ਦੋ ਬੁਕਿੰਗਾਂ ਨੂੰ ਓਵਰਲੈਪ ਨਾ ਹੋਣ ਦਿਓ।”
• “ਸਿਰਫ਼ ਲੌਗਇਨ ਕੀਤਾ ਮਾਲਕ ਸਾਰੀਆਂ ਬੁਕਿੰਗਾਂ ਪੜ੍ਹ ਸਕੇ; ਗਾਹਕ ਸਿਰਫ਼ ਆਪਣੀਆਂ ਵੇਖ ਸਕਣ। ਇਹ ਸਰਵਰ 'ਤੇ ਲਾਗੂ ਕਰੋ।”
• “ਜਦੋਂ ਮੈਂ ਕੋਈ ਸੇਵਾ ਮਿਟਾਵਾਂ, ਤਾਂ ਪੁਰਾਣੀਆਂ ਬੁਕਿੰਗਾਂ ਨਾ ਮਿਟਾਓ; ਇਸਦੀ ਬਜਾਏ ਸੇਵਾ ਨੂੰ ਅਕਿਰਿਆਸ਼ੀਲ ਚਿੰਨ੍ਹਤ ਕਰੋ।”

Mythex ਵਿੱਚ ਡਾਟਾਬੇਸ

ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਡਾਟਾ ਸੇਵ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ Mythex ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਸਮਰਪਿਤ Postgres ਡਾਟਾਬੇਸ ਜੋੜਦਾ ਹੈ। ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਪੁੱਛ ਸਕਦੇ ਹੋ ("ਵੇਟਲਿਸਟ ਸਾਈਨ-ਅੱਪ ਡਾਟਾਬੇਸ ਵਿੱਚ ਸੇਵ ਕਰੋ") ਜਾਂ /database ਕਮਾਂਡ ਵਰਤ ਸਕਦੇ ਹੋ। ਕਨੈਕਸ਼ਨ ਦੇ ਵੇਰਵੇ ਆਪਣੇ ਆਪ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਏਜੰਟ ਟੇਬਲ ਬਣਾਉਂਦਾ ਹੈ। ਡਾਟਾਬੇਸ ਪੰਜ ਮਿੰਟ ਦੀ ਬੇਕਾਰੀ ਤੋਂ ਬਾਅਦ ਸੌਂ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਬੇਨਤੀ 'ਤੇ ਜਾਗਦਾ ਹੈ। ਪ੍ਰਕਾਸ਼ਿਤ ਵਰਤੋਂ ਦਾ ਬਿੱਲ ਉਸ ਸਮੇਂ ਦਾ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਉਹ ਜਾਗਿਆ ਸੀ, ਅਤੇ ਉਹ ਉਸੇ ਕ੍ਰੈਡਿਟ ਬੈਲੰਸ ਤੋਂ ਕੱਟਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਬਣਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ Free ਅਤੇ Pro ਦੋਵਾਂ 'ਤੇ ਉਪਲਬਧ ਹੈ। ਵੇਰਵਿਆਂ ਲਈ ਡਾਟਾਬੇਸ ਡੌਕਸ ਵੇਖੋ, ਅਤੇ ਡਾਟਾ-ਅਧਾਰਤ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂਆਂ ਲਈ ਐਪ ਟੈਮਪਲੇਟ ਵੇਖੋ।

ਸਵਾਲ