SQLite ਦੁਨੀਆ ਭਰ ਦੀਆਂ ਐਪਾਂ, ਬਰਾਊਜ਼ਰਾਂ ਅਤੇ ਡਿਵਾਈਸਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਇਸਦਾ ਐਮਬੈਡਡ ਤੇ ਸਰਵਰ-ਭਿੰਨ ਡਿਜ਼ਾਈਨ ਸਾਦਗੀ, ਭਰੋਸੇਯੋਗਤਾ, ਤੇਜ਼ੀ, ਪੋਰਟੇਬਿਲਟੀ — ਅਤੇ ਕੁਝ ਸੀਮਾਵਾਂ ਦਿੰਦਾ ਹੈ। ਇਹ ਜਾਣੋ ਕਿ ਕਿਉਂ ਇਹ ਚੋਣ ਜਿੱਤਦੀ ਰਹਿੰਦੀ ਹੈ।
SQLite ਇੱਕ ਛੋਟਾ ਡੇਟਾਬੇਸ ਇੰਜਣ ਹੈ ਜੋ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਵਜੋਂ ਪੈਕੇਜ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਸਨੂੰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਲਿੰਕ ਕਰਦੀ ਹੈ—ਇੱਕ ਫੀਚਰ ਵਾਂਗ ਜੋ ਤੁਸੀਂ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਕੋਈ ਸਰਵਿਸ ਜੋ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ। ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਵੱਖਰੇ ਡੇਟਾਬੇਸ ਮਸ਼ੀਨ ਨਾਲ ਗੱਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਹਾਡੀ ਐਪ ਇੱਕ ਸਿੰਗਲ ਡੇਟਾਬੇਸ ਫਾਇਲ (ਆਮ ਤੌਰ 'ਤੇ app.db ਵਰਗਾ) ਨੂੰ ਡਿਸਕ 'ਤੇ ਪੜ੍ਹਦੀ ਅਤੇ ਲਿਖਦੀ ਹੈ।
ਉਹ “ਇਹ ਸਿਰਫ਼ ਇਕ ਫਾਇਲ ਹੈ” ਵਾਲਾ ਵਿਚਾਰ ਇਸ ਦੀ ਖਿੱਚ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੈ। ਡੇਟਾਬੇਸ ਫਾਇਲ ਵਿੱਚ ਟੇਬਲ, ਇੰਡੈਕਸ ਅਤੇ ਡਾਟਾ ਹੁੰਦੇ ਹਨ, ਅਤੇ SQLite ਪਿੱਠ-ਪਿੱਛੇ ਕਠਿਨ ਕੰਮ ਨਿਭਾਉਂਦਾ ਹੈ—ਕੁਐਰੀਆਂ, ਕੰਸਟ੍ਰੇਨਟ ਅਤੇ ACID ਟਰਾਂਜ਼ੈਕਸ਼ਨ।
ਕਲਾਇਂਟ-ਸਰਵਰ ਡੇਟਾਬੇਸ (ਜਿਵੇਂ PostgreSQL ਜਾਂ MySQL) ਨਾਲ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ:
SQLite ਨਾਲ, ਡੇਟਾਬੇਸ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਸੈਸ ਦੇ ਅੰਦਰ ਚਲਦਾ ਹੈ। ਕੋਈ ਵੱਖਰਾ ਸਰਵਰ ਇੰਸਟਾਲ, ਸ਼ੁਰੂ ਜਾਂ ਸਿਹਤਮੰਦ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਤੁਹਾਡੀ ਐਪ SQLite ਦੀ API ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ, ਅਤੇ SQLite ਸਿੱਧਾ ਲੋਕਲ ਫਾਇਲ ਨੂੰ ਪੜ੍ਹਦਾ/ਲਿਖਦਾ ਹੈ।
ਲੋਕ ਅਕਸਰ SQLite ਨੂੰ “ਸਰਵਰਲੀਸ” ਵਜੋਂ ਵਰਨਣ ਕਰਦੇ ਹਨ। ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਕਲਾਉਡ ਵਿੱਚ ਸਰਵਰਾਂ ਤੋਂ ਬਿਨਾਂ ਚੱਲਦਾ ਹੈ—ਇਹ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਲਈ ਇੱਕ ਵੱਖਰਾ ਡੇਟਾਬੇਸ ਸਰਵਰ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਚਲਾਉਂਦੇ।
SQLite ਬੇਨਤੀ ਤੋਂ ਬਿਨਾ ਬਹੁਤ ਸਾਰੇ ਦੈਨਿਕ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਚੁਪ-ਚਾਪ ਆ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਬਹੁਤ ਆਸਾਨ ਹੈ ਪੈਕੇਜ ਕਰਨ ਲਈ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੈ:
ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦ SQLite ਚੁਣਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਸਿੱਧਾ ਡਿਫੌਲਟ ਹੈ: ਤੇਜ਼, ਸਥਿਰ ਅਤੇ ਜ਼ੀਰੋ-ਕੰਫਿਗਰੇਸ਼ਨ।
SQLite ਕਈ ਸਿੰਗਲ-ਯੂਜ਼ਰ ਐਪਸ, ਐਮਬੈਡਡ ਡਿਵਾਈਸ, ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਮੋਡਰੇਟ ਲਿਖਤ ਸਮਕਾਲਤਾ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਲਈ ਸ਼ਾਨਦਾਰ ਚੋਣ ਹੈ। ਪਰ ਇਹ ਹਰ ਸਕੇਲਿੰਗ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ ਨੂੰ ਇੱਕੋ-ਇੱਕੇ ਡੇਟਾਬੇਸ 'ਤੇ ਇਕੱਠੇ ਲਿਖਣਾ ਪੈਂਦਾ ਹੋਵੇ।
ਮੁੱਖ ਨਿੱਕਾਸ: SQLite ਸਮਰੱਥਾ ਵਿੱਚ “ਛੋਟਾ” ਨਹੀਂ ਹੈ—ਇਹ ਓਪਰੇਸ਼ਨਲ ਝੰਜਟ ਵਿੱਚ ਛੋਟਾ ਹੈ। ਇਸੀ ਲਈ ਲੋਕ ਇਸਨੂੰ ਲਗਾਤਾਰ ਚੁਣਦੇ ਹਨ।
SQLite ਨੂੰ ਦੋ ਸ਼ਬਦਾਂ ਨਾਲ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ ਜੋ ਬਜ਼ਵਰਡੀ ਲੱਗ ਸਕਦੇ ਹਨ: ਐਮਬੈਡਡ ਅਤੇ ਸਰਵਰਲੀਸ। SQLite ਵਿੱਚ ਦੋਹਾਂ ਦੇ ਵਿਸ਼ੇਸ਼ (ਅਤੇ ਕਾਰਗਰ) ਅਰਥ ਹਨ।
SQLite ਉਹ ਚੀਜ਼ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਪਿੱਛੇ ਰੱਖ ਕੇ ਚਲਾਉਂਦੇ ਹੋ ਜਿਵੇਂ PostgreSQL ਜਾਂ MySQL। ਇਹ ਇੱਕ ਸਾਫਟਵੇਅਰ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜਿਸਨੂੰ ਤੁਹਾਡੀ ਐਪ ਲਿੰਕ ਕਰਦੀ ਹੈ ਅਤੇ ਸਿੱਧਾ ਵਰਤਦੀ ਹੈ।
ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਡਾਟਾ ਪੜ੍ਹਨਾ ਜਾਂ ਲਿਖਣਾ ਹੋਵੇ, ਇਹ ਉਸੇ ਪ੍ਰੋਸੈਸ ਦੇ ਅੰਦਰ SQLite ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ। ਕੋਈ ਵੱਖਰਾ ਡੇਟਾਬੇਸ ਡੈਮਨ ਨਹੀਂ ਹੈ ਜਿਸਨੂੰ ਸ਼ੁਰੂ, ਨਿਗਰਾਨੀ, ਪੈਚ ਜਾਂ ਰੀਸਟਾਰਟ ਕਰਨਾ ਪਏ। ਤੁਹਾਡੀ ਐਪ ਅਤੇ ਡੇਟਾਬੇਸ ਇੰਜਣ ਇਕਠੇ ਰਹਿੰਦੇ ਹਨ।
SQLite ਦਾ “ਸਰਵਰਲੀਸ” ਇਸ ਗੱਲ ਦਾ ਨਿਸ਼ਾਨਾ ਹੈ ਕਿ ਇਹ ਉਹਨਾਂ "ਕਲਾਉਡ ਸਰਵਰਲੀਸ" ਪ੍ਰਡਕਟਾਂ ਵਰਗਾ ਨਹੀਂ ਹੈ ਜੋ ਹੋਸਟ ਕੀਤੇ ਸਰਵਰਾਂ ਨੂੰ ਉਪਯੋਗ ਕਰਦੇ ਹਨ—ਉਹਨਾਂ ਵਿਚ ਵੀ ਸਰਵਰ ਹੁੰਦੇ ਹਨ, ਸਿਰਫ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਮੈਨੇਜ ਨਹੀਂ ਕਰਦੇ।
ਕਲਾਇਂਟ-ਸਰਵਰ ਡੇਟਾਬੇਸਾਂ ਵਿੱਚ, ਤੁਹਾਡਾ ਕੋਡ SQL ਟੀਸੀਪੀ 'ਤੇ ਸ਼ੇਅਰ ਕਰ ਕੇ ਦੂਜੇ ਪ੍ਰੋਸੈਸ ਨੂੰ ਭੇਜਦਾ ਹੈ। SQLite ਵਿੱਚ, ਤੁਹਾਡਾ ਕੋਡ ਲਾਇਬ੍ਰੇਰੀ ਕਾਲਾਂ ਰਾਹੀਂ SQL ਜਾਰੀ ਕਰਦਾ ਹੈ (ਅਕਸਰ ਜ਼ੁਬਾਨ ਬਾਈਂਡਿੰਗ ਦੁਆਰਾ), ਅਤੇ SQLite ਡੇਟਾਬੇਸ ਫਾਇਲ ਨੂੰ ਡਿਸਕ 'ਤੇ ਪੜ੍ਹਦਾ/ਲਿਖਦਾ ਹੈ।
ਨਤੀਜਾ: ਕੋਈ ਨੈੱਟਵਰਕ ਹੋਪ ਨਹੀਂ, ਕੋਈ ਕਨੈਕਸ਼ਨ ਪੂਲ ਸੈਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ, ਅਤੇ ਕੁਝ ਘਟੀਆਂ ਫੇਲ੍ਹਰ ਮੋਡ (ਜਿਵੇਂ “DB ਹੋਸਟ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ”) ਘਟ ਜਾਂਦੇ ਹਨ।
ਕਈ ਉਤਪਾਦਾਂ ਲਈ, “ਐਮਬੈਡਡ + ਸਰਵਰਲੀਸ” ਦਾ ਅਰਥ ਘੱਟ ਹਿਲਦੇ-ਡੁੱਲਦੇ ਹਿੱਸੇ:
ਇਹ ਸਧਾਰਣਤਾ SQLite ਦੇ ਹਰ ਜਗ੍ਹਾ ਹੋਣ ਦਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ—ਅਜੇ ਵੀ ਜਦੋਂ ਟੀਮ ਭਾਰੀ ਚੋਇਸ ਕਰ ਸਕਦੀ ਹੋਵੇ।
SQLite ਦਾ ਸਭ ਤੋਂ ਘੱਟ ਮਾਪਿਆ ਗਿਆ ਫਾਇਦਾ ਸਭ ਤੋਂ ਸਧਾਰਣ ਵੀ ਹੈ: ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਇੱਕ ਫਾਇਲ ਹੈ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨਾਲ ਸਫਰ ਕਰਦੀ ਹੈ। ਕੋਈ ਵੱਖਰਾ ਸਰਵਰ ਪ੍ਰੋਵੀਜ਼ਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ, ਕੋਈ ਪੋਰਟ ਖੋਲ੍ਹਣੇ ਦੀ ਲੋੜ ਨਹੀਂ, ਕੋਈ ਯੂਜ਼ਰ ਖਾਤੇ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਅਤੇ "ਕੀ ਡੇਟਾਬੇਸ ਚੱਲ ਰਿਹਾ ਹੈ?" ਦੀ ਚੈੱਕਲਿਸਟ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਕੰਮ ਨਹੀਂ ਰੁਕਦਾ।
ਕਲਾਇੰਟ-ਸਰਵਰ ਡੇਟਾਬੇਸ ਨਾਲ, ਐਪ ਭੇਜਣ ਦਾ ਮਤਲਬ Infrastruktur ਭੇਜਣਾ ਵੀ ਹੋ ਸਕਦਾ ਹੈ: DB ਇੰਸਟੈਂਸ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਮਾਨੀਟਰਨਿੰਗ, ਕ੍ਰੇਡੈਂਸ਼ੀਅਲ ਅਤੇ ਸਕੇਲਿੰਗ ਯੋਜਨਾ। SQLite ਨਾਲ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸ਼ੁਰੂਆਤੀ .db ਫਾਇਲ ਪੈਕੇਜ ਕਰਦੇ ਹੋ (ਜਾਂ ਪਹਿਲੀ ਚਲਾਉਂਦੀਆਂ ਬਣਾਉਂਦੇ ਹੋ) ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਉਸ ਤੇ ਸਿਧਾ ਪੜ੍ਹਦੀ/ਲਿਖਦੀ ਹੈ।
ਅੱਪਡੇਟ ਵੀ ਆਸਾਨ ਹੋ ਸਕਦੇ ਹਨ। ਨਵਾਂ ਟੇਬਲ ਜਾਂ ਇੰਡੈਕਸ ਦੀ ਲੋੜ? ਤੁਸੀਂ ਇੱਕ ਐਪ ਅੱਪਡੇਟ ਭੇਜਦੇ ਹੋ ਜੋ ਲੋਕਲ ਫਾਇਲ ਉਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਂਦਾ ਹੈ। ਕਈ ਉਤਪਾਦਾਂ ਲਈ, ਇਹ ਇੱਕ ਬਹੁ-ਕਦਮ ਰੋਲਆਉਟ ਨੂੰ ਇੱਕ ਹੀ ਰਿਲੀਜ਼ ਆਰਟੀਫੈਕਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
“ਇਕ ਫਾਈਲ ਭੇਜੋ” ਮਾਡਲ ਉਹ ਵੇਲੇ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਵਾਤਾਵਰਣ ਸੀਮਿਤ ਜਾਂ ਵਿਤਰਿਤ ਹੁੰਦਾ ਹੈ:
ਡੇਟਾਬੇਸ ਫਾਇਲ ਦੀ ਨਕਲ ਕਰਨਾ ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਇਹ ਹੋ ਸਕਦਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ। ਐਪ ਲਿਖ ਰਹੀ ਹੋਂਦ ਵਿੱਚ ਇੱਕ ਸਧਾਰਣ ਫਾਇਲ ਕਾਪੀ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੁੰਦੀ। SQLite ਦੇ ਬੈਕਅਪ ਮਿਕੈਨਿਜ਼ਮ ਵਰਤੋ (ਜਾਂ ਇੱਕ ਸਥਿਰ ਸਨੇਪਸ਼ਾਟ ਯਕੀਨੀ ਬਣਾਓ) ਅਤੇ ਬੈਕਅੱਪ ਕਿਸੇ ਟਿਕਾਊ ਜਗ੍ਹਾ 'ਤੇ ਰੱਖੋ।
ਕਿਉਂਕਿ ਕੋਈ ਸਰਵਰ ਟਿਊਨ ਕਰਨ ਜਾਂ ਦੇਖਭਾਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ, ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਓਪਰੇਸ਼ਨਲ ਝੰਜਟ ਤੋਂ ਬਚ ਜਾਂਦੀਆਂ ਹਨ: DB ਸਰਵਿਸ ਪੈਚ ਕਰਨਾ, ਕਨੈਕਸ਼ਨ ਪੂਲ ਮੈਨੇਜ ਕਰਨਾ, ਕ੍ਰੇਡੈਂਸ਼ੀਅਲ ਰੋਟੇਟ ਕਰਨਾ, ਰੇਪਲਿਕਾਸ ਨੂੰ ਸਹੀ ਰੱਖਣਾ ਆਦਿ। ਫਿਰ ਵੀ ਤੁਹਾਨੂੰ ਅੱਛੀ ਸਕੀਮਾ ਡਿਜ਼ਾਈਨ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ ਰਹਿੰਦੀ ਹੈ—ਪਰ “ਡੇਟਾਬੇਸ ਓਪਰੇਸ਼ਨਜ਼” ਦਾ ਫੁੱਟਪਰਿੰਟ ਛੋਟਾ ਹੁੰਦਾ ਹੈ।
SQLite ਦੀ ਲੋਕਪਰੀyata ਸਿਰਫ਼ ਸੁਵਿਧਾ ਬਾਰੇ ਨਹੀਂ। ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਕਿ ਲੋਕ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਉਹ ਇਹ ਹੈ ਕਿ ਇਹ “ਸੋਫਿਸਟੀਕੇਟেড” ਫੀਚਰਾਂ ਤੋਂ ਵੱਧ, ਸਹੀਤਾ ਨੂੰ ਪਹਿਲ ਦਿੱਤੀ ਹੈ। ਕਈ ਐਪਸ ਲਈ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਕ ਡੇਟਾਬੇਸ ਫੀਚਰ ਸਧਾਰਣ ਹੈ: ਡਾਟਾ ਨਾ ਗੁੰਮ ਹੋਵੇ ਜਾਂ ਕਰਪਟ ਨਾ ਹੋਵੇ।
SQLite ACID ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਸਪੋਰਟ ਕਰਦਾ ਹੈ, ਜੋ ਸੰਖੇਪ ਵਿੱਚ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ “ਜਦ ਗਲਤ ਹੋਵੇ ਤਾਂ ਵੀ ਤੁਹਾਡਾ ਡਾਟਾ ਸਹੀ ਰਹੇਗਾ।”
SQLite ਇੱਕ ਜਰਨਲ ਵਰਤ ਕੇ ਕਰੈਸ਼ ਸੁਰੱਖਿਆ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ—ਇੱਕ ਸੇਫਟੀ ਨੈੱਟ ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਬਦਲਣ ਵਾਲਾ ਹੈ ਤਾਂ ਕਿ ਇਹ ਸਾਫ਼-ਸੁਥਰਾ ਰੀਕਵਰੀ ਕਰ ਸਕੇ।
ਦੋ ਆਮ ਮੋਡ ਜੋ ਤੁਸੀਂ ਸੁਣੋਗੇ:
ਤੁਹਾਨੂੰ ਅੰਦਰੂਨੀ ਕੰਮਕਾਜ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ—ਮੁੱਖ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ SQLite ਨਿਰੰਤਰ ਅਤੇ ਪੇਸ਼ਗੀਯੋਗ ਰੀਕਵਰੀ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ।
ਕਈ ਐਪਸ ਨੂੰ ਕਸਟਮ ਕਲัสਟਰਿੰਗ ਜਾਂ ਐਕਸੋਟਿਕ ਡੇਟਾ ਕਿਸਮਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਉਹਨਾਂ ਨੂੰ ਸਹੀ ਰਿਕਾਰਡ, ਸੁਰੱਖਿਅਤ ਅੱਪਡੇਟ ਅਤੇ ਇਹ ਭਰੋਸਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਰੈਸ਼ ਡਾਟਾ ਨੂੰ ਚੁੱਪਚਾਪ ਕਰਪਟ ਨਹੀਂ ਕਰੇਗਾ। SQLite ਦਾ ਇੰਟੀਗ੍ਰਿਟੀ 'ਤੇ ਫੋਕਸ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ ਇਹ ਉਤਪਾਦਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ “ਸਧਾਰਨ ਅਤੇ ਸਹੀ” "ਦਿਖਾਵਟੀ ਅਤੇ ਜਟਿਲ" ਤੋਂ ਵਧੀਆ ਹੈ।
SQLite ਅਕਸਰ “ਤੁਰੰਤ” ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡੀ ਐਪ ਡੇਟਾਬੇਸ ਨਾਲ ਇਨ-ਪ੍ਰੋਸੈਸ ਗੱਲਬਾਤ ਕਰਦੀ ਹੈ। ਕੋਈ ਵੱਖਰਾ ਡੇਟਾਬੇਸ ਸਰਵਰ ਨਹੀਂ ਜਿਸਨੂੰ ਕਨੈਕਟ ਕਰਨਾ ਹੋਵੇ, ਕੋਈ TCP ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ, ਕੋਈ ਨੈੱਟਵਰਕ ਲੈਟੈਂਸੀ ਨਹੀਂ। ਇੱਕ ਕੁਐਰੀ ਸਿਰਫ਼ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਹੈ ਜੋ ਲੋਕਲ ਫਾਇਲ ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ (ਅਕਸਰ OS ਪੇਜ਼ ਕੈਸ਼ ਦੀ ਮਦਦ ਨਾਲ), ਇਸ ਲਈ "SQL ਚਲਾਓ" ਅਤੇ "ਰੋਜ਼ ਵਾਪਸ ਲੈਓ" ਵਿਚਕਾਰ ਦਾ ਸਮਾਂ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਛੋਟਾ ਹੋ ਸਕਦਾ ਹੈ।
ਕਈ ਉਤਪਾਦਾਂ ਲਈ, ਵਰਕਲੋਡ ਜ਼ਿਆਦਾਤਰ ਪੜ੍ਹਨ ਤੇ ਆਧਾਰਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਲਿਖਤ ਹੌਲੀ-ਹੌਲੀ ਹੁੰਦੀ ਹੈ: ਐਪ ਸਟੇਟ ਲੋਡ ਕਰਨਾ, ਸਰਚ, ਫਿਲਟਰ, ਸੋਰਟ ਅਤੇ ਛੋਟੇ-ਤੋਂ-ਮੱਧਮ ਟੇਬਲਾਂ ਵਿੱਚ ਜੋਇਨ। SQLite ਇਨ੍ਹਾਂ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਹੈ। ਇਹ ਇਨਡੈਕਸਡ ਲੁੱਕਅੱਪ, ਤੇਜ਼ ਰੇਂਜ ਸਕੈਨ ਅਤੇ ਜਦ ਡਾਟਾ ਲੋਕਲ ਸਟੋਰੇਜ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ ਤਾਂ ਤੇਜ਼ ਐਗਰੀਗੇਸ਼ਨ ਕਰ ਸਕਦਾ ਹੈ।
ਮੋਡਰੇਟ ਲਿਖਤ ਵਰਕਲੋਡ ਵੀ ਚੰਗੇ ਫਿਟ ਹਨ—ਸੋਚੋ ਯੂਜ਼ਰ ਪREFERENCES, ਬੈਕਗ੍ਰਾਊਂਡ ਸਿੰਕ ਕਿਊਜ਼, ਕੈਸ਼ ਕੀਤੇ API ਜਵਾਬ, ਇਵੈਂਟ ਲੌਗ, ਜਾਂ ਲੋਕਲ-ਫਰਸਟ ਡੇਟਾ ਸਟੋਰ ਜੋ ਬਾਅਦ ਵਿੱਚ ਚੇਂਜਜ਼ ਮਿਲਾਉਂਦਾ ਹੈ।
SQLite ਦਾ ਟਰੇਡ-ਆਫ਼ ਲਿਖਤਾਂ 'ਤੇ ਸਮਕਾਲਤਾ ਹੈ। ਇਹ ਕਈ ਰੀਡਰਾਂ ਨੂੰ ਸਹਾਰਦਾ ਹੈ, ਪਰ ਲਿਖਤਾਂ ਲਈ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਕਿ ਡੇਟਾਬੇਸ ਕਨਸਿਸਟੈਂਟ ਰਹੇ। ਭਾਰੀ ਸਮਕਾਲੀ ਲਿਖਤਾਂ (ਕਈ ਥਰੇਡ/ਪ੍ਰੋਸੈਸ ਇਕੱਠੇ ਅਪਡੇਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼) ਦੇ ਦੌਰਾਨ, ਤੁਸੀਂ ਲਾਕ ਕਨਟੈਂਸ਼ਨ, ਰੀਟ੍ਰਾਈਜ਼ ਜਾਂ "database is busy" ਗਲਤੀਆਂ ਵੇਖ ਸਕਦੇ ਹੋ ਜੇ ਤੁਸੀਂ හැਰ-ਚੀਜ਼ ਟਿਊਨ ਨਾ ਕਰੋ ਜਾਂ ਐਕਸੈਸ ਪੈਟਰਨ ডিজ਼ਾਇਨ ਨਾ ਕਰੋ।
ਜੇ ਕੁਐਰੀਆਂ ਬੁਰੇ ਤਰੀਕੇ ਨਾਲ ਬਣੀਆਂ ਹਨ ਤਾਂ SQLite "ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਤੇਜ਼" ਨਹੀਂ ਹੈ। ਇਨਡੈਕਸ, ਚੁਣinda WHERE ਕਲੌਜ਼, ਫ਼ੁਲ-ਟੇਬਲ ਸਕੈਨ ਤੋਂ ਬਚਣਾ, ਅਤੇ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਨੂੰ ਢੰਗ ਨਾਲ ਸਕੋਪ ਕਰਨਾ ਸਭ ਫ਼ਰਕ ਪਾਅਉਂਦੇ ਹਨ। ਇਸਨੂੰ ਇੱਕ ਅਸਲ ਡੇਟਾਬੇਸ ਵਾਂਗ ਵਰਤੋ—ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਹੈ।
SQLite ਦੀ ਸਭ ਤੋਂ ਵਿਲੱਖਣ ਖਾਸੀਅਤ ਵੀ ਸਭ ਤੋਂ ਸਧਾਰਣ ਹੈ: ਤੁਹਾਡਾ ਪੂਰਾ ਡੇਟਾਬੇਸ ਇੱਕ ਫਾਇਲ ਹੈ (ਅਤਿਰਿਕਤ ਸਾਈਡਕਾਰ ਫਾਇਲਾਂ ਜਿਵੇਂ WAL ਜਰਨਲ ਹੋ ਸਕਦੀਆਂ ਹਨ)। ਉਸ ਫਾਇਲ ਵਿੱਚ ਸਕੀਮਾ, ਡਾਟਾ, ਇੰਡੈਕਸ—ਸਭ ਕੁਝ ਹੁੰਦਾ ਹੈ।
ਕਿਉਂਕਿ ਇਹ "ਸਿਰਫ਼ ਇੱਕ ਫਾਇਲ" ਹੈ, ਪੋਰਟੇਬਿਲਟੀ ਡਿਫੌਲਟ ਬਣ ਜਾਂਦੀ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਕਾਪੀ ਕਰ ਸਕਦੇ ਹੋ, ਬੱਗ ਰਿਪੋਰਟ ਲਈ ਲਗਾ ਸਕਦੇ ਹੋ, ਟੀਮ-ਮੇਟ ਨਾਲ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ (ਜਦ ਢੰਗ ਨਾਲ ਸੁਲੂਕ ਕੀਤਾ ਜਾਵੇ), ਜਾਂ ਮਸ਼ੀਨਾਂ ਦਰਮਿਆਨ ਬਿਨਾਂ ਸਰਵਰ ਸੈੱਟਅੱਪ ਦੇ ਅਸਾਨੀ ਨਾਲ ਹਿਲਾ ਸਕਦੇ ਹੋ।
SQLite ਲਗਭਗ ਹਰ ਮੁੱਖ ਪਲੇਟਫਾਰਮ 'ਤੇ ਚੱਲਦਾ ਹੈ: Windows, macOS, Linux, iOS, Android ਅਤੇ ਅਨੇਕ ਐਮਬੈਡਡ ਵਾਤਾਵਰਣ। ਇਹ ਦੇਰਘੜੀ ਸਥਿਰਤਾ ਨਾਲ ਵੀ ਜੋੜਿਆ ਹੋਇਆ ਹੈ: SQLite ਪਿੱਛੇ ਮੁੜ-ਮਿਲਾਪ ਵਿੱਚ ਬਹੁਤ ਸੰਭਾਲੂ ਹੈ, ਇਸ ਲਈ ਸਾਲਾਂ ਪਹਿਲਾਂ ਬਣਾਈ ਗਈ ਫਾਇਲ ਆਮ ਤੌਰ 'ਤੇ ਨਵੇਂ ਵਰਜ਼ਨਾਂ ਨਾਲ ਵੀ ਖੀਲੀ ਅਤੇ ਪੜ੍ਹੀ ਜਾ ਸਕਦੀ ਹੈ।
ਇਕ-ਫਾਇਲ ਮਾਡਲ ਟੈਸਟਿੰਗ ਵਿੱਚ ਵੀ ਇੱਕ ਸ਼ਕਤੀ ਹੈ। ਇੱਕ ਜਾਨੀ-ਪਛਾਣ ਵਾਲਾ ਡੇਟਾਸੈੱਟ ਯੂਨਿਟ ਟੈਸਟ ਲਈ ਚਾਹੀਦਾ? ਇੱਕ ਛੋਟੀ SQLite ਫਾਇਲ ਨੂੰ ਚੈਕ ਇਨ ਕਰੋ (ਜਾਂ ਟੈਸਟ ਦੌਰਾਨ ਬਣਾਉ), ਅਤੇ ਹਰ ਡਿਵੈਲਪਰ ਅਤੇ CI ਨੌਕ ਹਰ ਵਾਰ ਇੱਕੋ ਹੀ ਬੇਸਲਾਈਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਗ੍ਰਾਹਕ ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾਉਣਾ ਹੈ? DB ਫਾਇਲ ਮੰਗੋ (ਠੀਕ ਪ੍ਰਾਈਵੇਸੀ ਦੇ ਨਾਲ) ਅਤੇ ਤੁਸੀਂ ਲੋਕਲ ਤੌਰ 'ਤੇ ਸਮੱਸਿਆ ਨੂੰ ਰਿਪਲੈ ਕਰ ਸਕਦੇ ਹੋ—“ਕੇਵਲ ਉਨ੍ਹਾਂ ਦੇ ਸਰਵਰ 'ਤੇ ਹੀ ਹੁੰਦਾ ਹੈ” ਵਾਲੀ ਗੱਲ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।
ਉਹ ਪੋਰਟੇਬਿਲਟੀ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ: ਜੇ ਫਾਇਲ ਹਟ ਜਾਂ ਕਰਪਟ ਹੋ ਜਾਏ ਤਾਂ ਤੁਸੀਂ ਡਾਟਾ ਗੁਵਾ ਸਕਦੇ ਹੋ। SQLite ਡੇਟਾਬੇਸ ਨੂੰ ਕਿਸੇ ਮਹੱਤਵਪੂਰਣ ਐਪ ਐਸੈੱਟ ਵਾਂਗ ਰੱਖੋ:
SQLite ਨੂੰ ਅਪਨਾਉਣਾ ਆਸਾਨ ਹੈ ਹਿੱਸਾ ਇਸ ਕਰਕੇ ਵੀ ਹੈ ਕਿ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ੋਮ ਦੀ ਸ਼ੁਰੂਆਤ ਨਹੀਂ ਕਰੋ। ਇਹ ਕਈ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਬਿਲਟ ਹੈ, ਆਮ ਲੈਂਗਵੇਜ ਰਨਟਾਈਮ ਨਾਲ ਸ਼ਿਪ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਵਾਤਾਵਰਣਾਂ 'ਚ “ਨਿਰਵਿਕਾਰ” ਸਮਰੱਥਾ ਹੁੰਦੀ ਹੈ—ਉਹੀ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਇੱਕ ਐਪ ਵਿੱਚ ਐਮਬੈਡ ਕਰਨ ਲਈ ਚਾਹੁੰਦੇ ਹੋ।
ਜਿਆਦਾਤਰ ਸਟੈਕਸ ਪਹਿਲਾਂ ਤੋਂ ਹੀ SQLite ਲਈ ਚੰਗਾ ਰਸਤਾ ਰੱਖਦੇ ਹਨ:
sqlite3 standard library), Go (mattn/go-sqlite3), Java (JDBC ਡਰਾਈਵਰ), .NET (Microsoft.Data.Sqlite), PHP (PDO SQLite), Node.js (better-sqlite3, sqlite3).ਇਹ ਵਿਆਪਕਤਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿਉਂਕਿ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਜਾਣਪਛਾਣ ਪੈਟਰਨ ਵਰਤ ਸਕਦੀ ਹੈ—ਮਾਈਗ੍ਰੇਸ਼ਨ, ਕੁਐਰੀ ਬਿਲਡਰ, ਕਨੈਕਸ਼ਨ ਮੈਨੇਜਮੈਂਟ—ਬਿਨਾਂ ਨਿਰਾਲੇ ਪਲੰਬਿੰਗ ਬਣਾਉਣ ਦੇ।
SQLite ਦੀ ਟੂਲਿੰਗ ਅਸਤਿਤਵ ਵਿੱਚ ਅਸਾਨ ਹੈ। sqlite3 CLI ਨਾਲ ਤੁਸੀਂ ਟੇਬਲ ਦੇਖ ਸਕਦੇ ਹੋ, ਕੁਐਰੀ ਚਲਾ ਸਕਦੇ ਹੋ, ਡੇਟਾ ਡੰਪ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ CSV ਇੰਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ। ਵਿਜ਼ੂਅਲ ਐਕਸਪਲੋਰੇਸ਼ਨ ਲਈ ਬਰਾਊਜ਼ਰ-ਆਧਾਰਿਤ ਅਤੇ ਡੈਸਕਟਾਪ ਵਿਊਅਰ (ਉਦਾਹਰਨ ਵਜੋਂ SQLiteStudio ਜਾਂ DB Browser for SQLite) ਗੈਰ-ਸਪੈਸ਼ਲਿਸਟਾਂ ਨੂੰ ਫਟਾਫਟ ਡਾਟਾ ਵੇਰੀਫਾਈ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਡਿਲਿਵਰੀ ਪਾਸੇ, ਪ੍ਰਮੁੱਖ ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੂਲ ਆਮ ਤੌਰ 'ਤੇ SQLite ਨੂੰ ਆਊਟ-ਆਫ-ਦ-ਬੌਕਸ ਸਪੋਰਟ ਕਰਦੇ ਹਨ: Rails migrations, Django migrations, Flyway/Liquibase, Alembic, ਅਤੇ Prisma Migrate ਸਭ ਸਕੀਮਾ ਬਦਲਾਅ ਨੂੰ ਦੁਹਰਾਏ ਜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਉਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਕਿਉਂਕਿ SQLite ਇੰਨਾ ਵਿਆਪਕ ਹੈ, ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: ਲਾਇਬ੍ਰੇਰੀਆਂ ਬੈਟਲ-ਟੈਸਟਡ ਹੁੰਦੀਆਂ ਹਨ, ਐਡਜ ਕੇਸ ਦਸਤਾਵੇਜ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕਮਿਊਨਟੀ ਉਦਾਹਰਣਾਂ ਬਹੁਤ ਹਨ। ਇਹ ਲੋਕਪਰੀyata ਹੋਰ ਸਹਾਇਤਾ ਲਿਆਉਂਦੀ ਹੈ, ਜੋ ਅਪਨਾਣਾ ਹੋਰ ਵੀ ਆਸਾਨ ਕਰਦਾ ਹੈ।
ਕਿਸੇ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ, ਆਪਣੇ ਸਟੈਕ ਲਈ ਸਰਗਰਮ maintained ਡਰਾਈਵਰ/ORM ਐਡਾਪਟਰ ਪ੍ਰਿਫਰ ਕਰੋ, ਤੇ ਸਮਕਾਲਤਾ ਵਰਤਾਵ, ਬਾਈਂਡਿੰਗ ਸਪੋਰਟ, ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਰਤੋਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਚੰਗੀ-ਸਮਰਥਤ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਅਕਸਰ ਸਵਚਲਤਾ ਅਤੇ ਇੱਕ ਸਫ਼ਲ ਰੋਲਆਉਟ ਵਿੱਚ ਫ਼ਰਕ ਪੈਦਾ ਕਰਦੀ ਹੈ।
SQLite ਸਮਝਣਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਵੇਖੋ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ: ਓਥੇ ਜਿੱਥੇ ਇੱਕ ਪੂਰਾ ਡੇਟਾਬੇਸ ਸਰਵਰ ਲਾਗਤ, ਜਟਿਲਤਾ, ਅਤੇ ਫੇਲ੍ਹਰ ਮੋਡ ਲਿਆਉਂਦਾ।
ਕਈ ਮੋਬਾਈਲ ਐਪਸ ਨੂੰ ਯੂਜ਼ਰ ਸੈਸ਼ਨ, ਕੈਸ਼ਡ ਸਮੱਗਰੀ, ਨੋਟਸ, ਜਾਂ "ਬਾਅਦ ਵਿੱਚ ਅੱਪਲੋਡ ਕਰਨ ਲਈ" ਕਤਾਰਾਂ ਦੀ ਭਰੋਸੇਯੋਗ ਲੋਕਲ ਸਟੋਰਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। SQLite ਫਿੱਟ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਕ-ਫਾਇਲ ਡੇਟਾਬੇਸ ਹੈ ਜਿਸਦੇ ਕੋਲ ACID ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਹਾਡਾ ਡਾਟਾ ਕਰੈਸ਼, ਨੀਵੀਂ ਬੈਟਰੀ ਬੰਦ, ਅਤੇ ਸੁਖੜੀ-ਬੰਦ-ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਅਦ ਵੀ ਬਚ ਜਾਂਦਾ ਹੈ।
ਇਹ ਖ਼ਾਸ ਕਰਕੇ ਆਫਲਾਈਨ-ਪਹਿਲਾਂ ਅਤੇ ਲੋਕਲ-ਪਹਿਲਾਂ ਐਪਸ ਵਿੱਚ ਮਜ਼ਬੂਤ ਹੈ: ਹਰ ਬਦਲਾਅ ਲੋਕਲ ਤੌਰ 'ਤੇ ਲਿਖੋ, ਫਿਰ ਜਦ ਪਹੁੰਚ ਹੋਵੇ ਸਿੰਕ ਕਰੋ। ਲਾਭ ਸਿਰਫ਼ ਆਫਲਾਈਨ ਸਹਾਇਤਾ ਨਹੀਂ—UI ਤੇਜ਼ ਹੁੰਦੀ ਹੈ ਅਤੇ ਰਵਾਇਆ ਪੇਸ਼ਗੀਯੋਗ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪੜ੍ਹਨ/ਲਿਖਨ ਡਿਵਾਈਸ ਤੇ ਹੀ ਰਹਿੰਦੇ ਹਨ।
ਡੈਸਕਟਾਪ ਸਾਫਟਵੇਅਰ ਅਕਸਰ ਇਕ ਐਸਾ ਡੇਟਾਬੇਸ ਚਾਹੁੰਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਤੋਂ ਕਿਸੇ ਕਾਨਫਿਗਰੇਸ਼ਨ ਦੀ ਮੰਗ ਨਾ ਕਰੇ। ਇੱਕ ਸਿੰਗਲ SQLite ਫਾਇਲ ਭੇਜ ਕੇ (ਜਾਂ ਪਹਿਲੀ ਚਲਾਣ 'ਤੇ ਬਣਾਕੇ) ਇੰਸਟਾਲੇਸ਼ਨ ਸਧਾਰਨ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਬੈਕਅੱਪ ਜਾਣਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ: ਇੱਕ ਫਾਇਲ ਕਾਪੀ ਕਰੋ।
ਲੇਖਾ-ਜੋਖਾ ਟੂਲ, ਮੀਡੀਆ ਮੈਨੇਜਰ, ਅਤੇ ਹਲਕੇ CRM-ਸਟਾਈਲ ਸਿਸਟਮ ਵਰਗੀਆਂ ਐਪਸ ਡਾਟਾ ਨੂੰ ਐਪ ਕੋਲ ਰੱਖਦਿਆਂ ਪ੍ਰਦਰਸ਼ਨ ਵਧਾਉਂਦੀਆਂ ਹਨ ਅਤੇ "ਕੀ ਡੇਟਾਬੇਸ ਸਰਵਰ ਚੱਲ ਰਿਹਾ ਹੈ?" ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਦੀਆਂ ਹਨ।
ਡਿਵੈਲਪਰ ਟੂਲ ਅਤੇ ਐਪਸ ਜਿੱਥੇ ਹਿਸਟਰੀ, ਇੰਡੈਕਸ ਅਤੇ ਮੈਟਾਡੇਟਾ ਲਈ ਸੰਰਚਿਤ ਸਟੋਰੇਜ ਚਾਹੀਦੀ ਹੈ, ਉੱਥੇ SQLite ਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਇਥੇ ਲੋਕਪ੍ਰිය ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਥਿਰ, ਪੋਰਟੇਬਿਲ ਅਤੇ ਵੱਖਰੇ ਪ੍ਰੋਸੈਸ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦਾ।
ਰਾਊਟਰ, ਕਿਓਸਕ, ਪੋਇੰਟ-ਅਫ-ਸੇਲ ਟਰਮੀਨਲ, ਅਤੇ IoT ਗੇਟਵੇਅਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਕਨਫਿਗਰੇਸ਼ਨ, ਲੌਗ ਅਤੇ ਛੋਟੇ ਡੇਟਾਸੈੱਟ ਲੋਕਲ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰਦੇ ਹਨ। SQLite ਦੀ ਛੋਟੀ ਫੁੱਟਪ੍ਰਿੰਟ ਅਤੇ ਫਾਇਲ-ਅਧਾਰਿਤ ਪੋਰਟੇਬਿਲਟੀ ਇਸਨੂੰ ਤਿਆਰ ਅਤੇ ਅਪਡੇਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।
ਡਿਵੈਲਪਰ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ, ਲੋਕਲ ਡਿਵੈਲਪਮੈਂਟ ਡੀਬੀ ਅਤੇ ਟੈਸਟ ਫਿਕਸਚਰ ਲਈ SQLite ਵਰਤਦੇ ਹਨ। ਇਹ ਜ਼ੀਰੋ-ਸੈਟਅਪ, ਆਸਾਨ ਰੀਸੈੱਟ ਕਰਨ ਯੋਗ, ਅਤੇ ਨਿਰਣਾਇਕ ਹੈ—ਫਾਇਦੇ ਜੋ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਅਤੇ ਭਰੋਸੇਯੋਗ CI ਦੌੜਾਂ ਵਿੱਚ ਤਬਦੀਲ ਹੁੰਦੇ ਹਨ।
ਇਹ ਉਹ ਪੈਟਰਨ ਵੀ ਹੈ ਜੋ Koder.ai ਨਾਲ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਵਰਤਦੀਆਂ ਹਨ: ਟੀਮਾਂ SQLite ਨਾਲ ਤੇਜ਼ ਲੋਕਲ ਇਟਰੇਸ਼ਨ ਲਈ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ (ਜਾਂ ਸਿੰਗਲ-ਟੇਨੈਂਟ ਡਿਪਲോਇਮੈਂਟ), ਫਿਰ ਜਦ ਲੋੜ ਹੋਵੇ ਤਾਂ ਬਰਪਾ ਕਰਨ ਲਈ ਜੇਨੇਰੇਟ ਕੀਤਾ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਕੇ PostgreSQL ਵੱਲ ਵੱਧ ਜਾਂਦੀਆਂ ਹਨ। "ਸਧਾਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਜਦੋ ਜਰੂਰੀ ਹੋ ਤਦ ਮਾਈਗ੍ਰੇਟ ਕਰੋ" workflow ਸ਼ੁਰੂਆਤੀ ਡਿਲਿਵਰੀ ਤੇਜ਼ ਰੱਖਦਾ ਹੈ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਕੋਨੇ 'ਚ ਬੰਨ੍ਹ ਦੇਣ ਦੇ।
SQLite ਲੋਕਲ ਸਟੋਰੇਜ ਲਈ ਸ਼ਾਨਦਾਰ ਹੈ, ਪਰ ਇਹ ਸਾਰੇ ਹੱਲਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਆਪਣੇ ਵਰਕਲੋਡ ਅਤੇ ਟੀਮ ਦੇ ਓਪਰੇਸ਼ਨਲ ਜਰੂਰਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਫੈਸਲਾ ਕਰੋ—ਹਪ ਟਰੈਂਡ ਦੇ ਆਧਾਰ 'ਤੇ ਨਹੀਂ।
SQLite ਕਈ ਰੀਡਰਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੈਂਡਲ ਕਰ ਲੈਂਦੀ ਹੈ, ਪਰ ਲਿਖਤਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ ਜਾਂ ਪ੍ਰੋਸੈਸ ਇਕੱਠੇ ਡੇਟਾ ਚੇਂਜ ਕਰ ਰਹੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ ਤੋਂ—ਤਾਂ client-server ਡੇਟਾਬੇਸ (ਜਿਵੇਂ PostgreSQL ਜਾਂ MySQL) ਜ਼ਿਆਦਾ ਉਚਿਤ ਹੋ ਸਕਦਾ ਹੈ।
ਆਮ ਸੁਝਾਅ ਇਹ ਹੈ: "ਲੈਪਟਾਪ ਤੇ ਸਭ ਕੁਝ ਠੀਕ ਚੱਲਦਾ ਹੈ" ਪਰ ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਤੁਹਾਨੂੰ ਟਾਈਮਆਉਟ, ਲਾਕ ਕਨਟੈਂਸ਼ਨ ਜਾਂ ਲਿਖਤਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕਤਾਰਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ।
SQLite ਬਹੁਤ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਵੱਖਰਾ ਵਰਕਲੋਡ ਲਈ ਅਨੁਕੂਲ ਹੈ: ਜਿਆਦਾਤਰ ਪੜ੍ਹਨ ਅਤੇ ਮੋਡਰੇਟ ਰੇਟ ਦੀਆਂ ਲਿਖਤਾਂ। ਜੇ ਤੁਹਾਡਾ ਸਿਸਟਮ ਉੱਚ-ਫ੍ਰਿਕਵੈਂਸੀ ਇನ್-ਸਰਟ/ਅਪਡੇਟ (ਮੇਟ੍ਰਿਕਸ ਇੰਜੈਸ਼ਨ, ਇਵੈਂਟ ਸਟ੍ਰੀਮ, ਜੌਬ ਕਿਊਜ਼, ਉੱਚ-ਵਾਲਿਊਮ ਲੌਗ) ਕਰਦਾ ਹੈ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਪੈਰਲੇਲ ਲਿਖਤ ਉਮੀਦ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਸਰਵਰ ਡੀਬੀ ਆਮ ਤੌਰ 'ਤੇ ਦਰੁਸਤ ਤੌਰ 'ਤੇ ਸਕੇਲ ਹੋਵੇਗਾ।
ਇਹ ਸਿਰਫ਼ “ਗਤੀ” ਦੀ ਗੱਲ ਨਹੀਂ—ਇਹ ਲੇਟੈਂਸੀ ਦੀ ਸਥਿਰਤਾ ਬਾਰੇ ਵੀ ਹੈ: ਲਿਖਤਾਂ ਦੇ ਬਰਸਟ ਨਾਲ ਹੋਰ ਲਿਖਤਾਂ ਬਲੌਕ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਪੂਰੀ ਸਿਸਟਮ ਵਿੱਚ ਟੇਲ-ਲੈਟੈਂਸੀ ਬਣ ਸਕਦੀ ਹੈ ਜੋ ਹਿੱਸੇਦਾਰਾਂ ਨੂੰ ਸਮਝਾਉਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਕੇਂਦਰੀ ਡੇਟਾਬੇਸ ਜਿਸਨੂੰ ਨੈੱਟਵਰਕ 'ਤੇ ਸਾਂਝਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਰੋਲ-ਆਧਾਰਿਤ ਪਹੁੰਚ, ਆਡੀਟ ਟਰੇਲ, ਕੇਂਦਰੀ ਬੈਕਅੱਪ ਅਤੇ ਗਵਰਨੈਂਸ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ SQLite ਸੰਭਵਤ: ਗਲਤ ਟੂਲ ਹੈ। ਤੁਸੀਂ ਇਕ SQLite ਫਾਇਲ ਨੈੱਟਵਰਕ ਸ਼ੇਅਰ 'ਤੇ ਰੱਖ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਲਾਕਿੰਗ ਸਮੱਸਿਆਵਾਂ ਲਿਆਉਂਦਾ ਹੈ।
ਇੱਕ ਸਰਵਰ ਡੇਟਾਬੇਸ ਚਮਕਦਾ ਹੈ ਜਦ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ:
ਦੋ ਸਵਾਲ ਪੁੱਛੋ:
ਜੇ ਇਮਾਨਦਾਰ ਉੱਤਰ "ਕਈ ਲਿਖਣ ਵਾਲੇ" ਅਤੇ "ਕੇਂਦਰੀ ਗਵਰਨੈਂਸ" ਵੱਲ ਵਾਰ ਕਰਦੇ ਹਨ, ਤਾਂ client-server ਡੇਟਾਬੇਸ ਚੁਣਨਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਬੇਕਾਰ—ਅਕਸਰ ਇਹ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸੌਖਾ ਰਾਹ ਹੁੰਦਾ ਹੈ।
SQLite ਅਤੇ PostgreSQL ਜਾਂ MySQL ਵਰਗੇ ਡੇਟਾਬੇਸ ਦੋਹਾਂ ਟੇਬਲ ਸਟੋਰ ਅਤੇ SQL ਚਲਾਉ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਵੱਖ-ਵੱਖ ਤਰ੍ਹਾਂ ਦੇ ਸਮੱਸਿਆਵਾਂ ਲਈ ਬਣੇ ਹਨ।
SQLite ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਸੈਸ ਦੇ ਅੰਦਰ ਚਲਦਾ ਹੈ। ਤੁਹਾਡਾ ਕੋਡ SQLite ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਅਤੇ SQLite ਸਿੱਧਾ ਇੱਕ ਲੋਕਲ ਡੇਟਾਬੇਸ ਫਾਇਲ ਨੂੰ ਪੜ੍ਹਦਾ/ਲਿਖਦਾ ਹੈ।
ਇੱਕ ਕਲਾਇਂਟ-ਸਰਵਰ ਡੇਟਾਬੇਸ ਵੱਖਰੇ ਸਰਵਿਸ ਵਜੋਂ ਚੱਲਦਾ ਹੈ। ਤੁਹਾਡੀ ਐਪ ਨੈੱਟਵਰਕ ਰਾਹੀਂ (ਏਨੇ ਵੀ ਹੋ ਸਕਦਾ ਹੈ localhost) ਕਨੈਕਟ ਕਰਦੀ ਹੈ, ਕੁਐਰੀਜ਼ ਭੇਜਦੀ ਹੈ, ਅਤੇ ਸਰਵਰ ਸਟੋਰੇਜ, ਸਮਕਾਲਤਾ, ਯੂਜ਼ਰ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਵਰਕ ਵੇਖਦਾ ਹੈ।
ਇੱਕ ਭਾਰਾ ਫਰਕ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੈਕਟਿਕਲ ਟਰੇਡ-ਆਫ਼ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।
SQLite ਨਾਲ, ਡਿਪਲੋਇਮੈਂਟ ਬਿਨਾਂ ਬਹੁਤ ਕੁਝ ਦੇ ਹੋ ਸਕਦਾ ਹੈ: ਇੱਕ ਬਾਇਨਰੀ ਅਤੇ ਇੱਕ ਫਾਇਲ। ਕੋਈ ਪੋਰਟ, ਕੋਈ ਕ੍ਰੇਡੈਂਸ਼ੀਅਲ, ਕੋਈ ਸਰਵਰ ਅੱਪਗਰੇਡ ਨਹੀਂ—ਯਾਦ ਰੱਖੋ, ਇਹ ਡੈਸਕਟਾਪ, ਮੋਬਾਈਲ, ਏਜ ਅਤੇ ਲੋਕਲ-ਫਰਸਟ ਉਤਪਾਦਾਂ ਲਈ ਵੱਡਾ ਮਫ਼ਤਦ ਹੈ।
ਕਲਾਇੰਟ-ਸਰਵਰ ਡੇਟਾਬੇਸ ਉਸ ਵੇਲੇ ਚਮਕਦਾ ਹੈ ਜਦ ਤੁਹਾਨੂੰ ਕੇਂਦਰੀ ਪ੍ਰਬੰਧਨ ਦੀ ਲੋੜ ਹੋਵੇ: ਕਈ ਐਪਸ ਅਤੇ ਯੂਜ਼ਰ ਇਕੋ ਡੇਟਾਬੇਸ ਨੂੰ ਹਿੱਟ ਕਰ ਰਹੇ ਹੋਣ, ਬਰੀਕ-ਬਰੀਕ ਪਹੁੰਚ ਵਿਵਸਥਾ, ਆਨਲਾਈਨ ਬੈਕਅਪ, ਰੀਡ ਰੈਪਲਿਕਾ, ਅਤੇ ਮਜਬੂਤ ਨਿਗਰਾਨੀ।
SQLite ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਰਾਹਾਂ ਨਾਲ ਸਕੇਲ ਕਰਦਾ ਹੈ:
ਕਲਾਇੰਟ-ਸਰਵਰ ਡੇਟਾਬੇਸ ਸਾਂਝੇ ਵਰਕਲੋਡ ਲਈ ਅਸਾਨੀ ਨਾਲ ਸਕੇਲ ਹੁੰਦੇ ਹਨ ਰੇਪਲਿਕੇਸ਼ਨ, ਪਾਰਟੀਸ਼ਨਿੰਗ ਅਤੇ ਪੂਲਿੰਗ ਰਾਹੀਂ।
ਚੁਣੋ SQLite ਜੇ ਤੁਸੀਂ ਲੋਕਲ ਡਾਟਾ, ਘੱਟ ਓਪਸ ਅਤੇ ਇੱਕ ਇਕਾਈ ਐਪ ਇੱਥੇ-ਲਿਖਤ ਚਾਹੁੰਦੇ ਹੋ।
ਚੁਣੋ ਕਲਾਇੰਟ-ਸਰਵਰ DB ਜੇ ਤੁਹਾਨੂੰ ਕਈ ਸਾਉਰਸ ਤੋਂ ਸਮਕਾਲੀ ਲਿਖਤ, ਨੈੱਟਵਰਕ ਐਕਸੈੱਸ, ਕੇਂਦਰੀ ਗਵਰਨੈਂਸ ਜਾਂ ਬਿਲਟ-ਇਨ ਉਪਲਬਧਤਾ ਦੀ ਲੋੜ ਹੈ।
ਜੇ ਤੁਹਾਨੂੰ ਪਛਾਣ ਨਹੀਂ ਹੋ ਰਹੀ, ਤਾਂ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਲਈ SQLite ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਇੱਕ ਸਾਫ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਾਹ (ਸਕੀਮਾ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਐਕਸਪੋਰਟ/ਇੰਪੋਰਟ) ਰੱਖੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ PostgreSQL ਤੱਕ ਜਾਣਾ ਆਸਾਨ ਰਹੇ (ਦਿੱਖ: blog/migrating-from-sqlite).
SQLite ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਖੁਸ਼ੀ-ਖੁਸ਼ੀ ਚੱਲ ਸਕਦਾ ਹੈ—ਪਰ ਇਸਨੂੰ ਇੱਕ ਅਸਲ ਡੇਟਾਬੇਸ ਵਾਂਗ ਵਰਤੋ, ਨਾ ਕਿ "ਇੱਕ ਅਸਥਾਇੀ ਫਾਇਲ"। ਕੁਝ ਆਦਤਾਂ ਭਾਰੀ ਅੰਤਰ ਪੈਂਦਾ ਹੈ:
SQLite ਕਈ ਪੜ੍ਹਨ-ਲਿਖਨ ਸਮਰਥਾ ਸਪੋਰਟ ਕਰਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਮੇਂ ਇੱਕ ਲਿਖਤ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਐਪ ਲਈ ਠੀਕ ਹੈ ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਧਿਆਨ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਲਿਖਤ ਟਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਨੂੰ ਛੋਟੇ ਅਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ: ਸਭ ਕੰਮ ਪਹਿਲਾਂ ਆਪਣੀ ਐਪ ਵਿੱਚ ਕਰੋ, ਫਿਰ ਇੱਕ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਖੋਲ੍ਹੋ, ਲਿਖੋ ਅਤੇ ਫੌਰਨ ਕਮੇਟ ਕਰੋ। ਨੈੱਟਵਰਕ ਕਾਲਾਂ, ਯੂਜ਼ਰ ਇੰਪੁੱਟ ਜਾਂ ਹੌਲੀ ਲੂਪ ਦੌਰਾਨ ਲਾਕ ਰੱਖਣ ਤੋਂ ਬਚੋ। ਬੈਕਗ੍ਰਾਊਂਡ ਜੋਬਜ਼ ਲਈ ਲਿਖਤਾਂ ਕਤਾਰਬੱਧ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਇੰਟਰਐਕਟਿਵ ਰੀਕਵੇਸਟਾਂ ਨੂੰ ਬਲੌਕ ਨਾ ਕਰਨ।
Write-Ahead Logging (WAL) ਇਹ ਤਰੀਕਾ ਬਦਲਦਾ ਹੈ ਕਿ SQLite ਬਦਲਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਦਰਜ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਰੀਡਰ ਅਕਸਰ ਲਿਖਤ ਦੇ ਦੌਰਾਨ ਵੀ ਪੜ੍ਹ ਸਕਣ। ਕਈ ਐਪਸ—ਖ਼ਾਸ ਕਰਕੇ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਰੀਡ ਅਤੇ ਕਦੀਆਂ-ਕਦੀਆਂ ਲਿਖਤ ਹੁੰਦੀ ਹੈ—WAL ਨਾਲ "database is locked" ਫਿਕਰ ਘੱਟ ਅਤੇ throughput ਵਧਦਾ ਵੇਖਦੇ ਹਨ।
WAL ਜਾਦੂ ਨਹੀਂ ਹੈ: ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਇੱਕ ਲਿਖਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਡਿਸਕ 'ਤੇ ਵਾਧੂ WAL ਫਾਇਲਾਂ ਦਾ ਹਿਸਾਬ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਰ ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਪ੍ਰਯੋਗਕਾਰੀ ਡਿਫੌਲਟ ਹੈ।
ਭਾਵੇਂ SQLite ਇਕ-ਫਾਇਲ ਹੈ, ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ ਬੈਕਅਪ ਰਣਨੀਤੀ ਚਾਹੀਦੀ ਹੈ। ਬੇਪਰਵਾਹ ਫਾਇਲ ਨਕਲ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ; ਇੱਕ ਸਥਿਰ ਰਾਜ-ਪਾਲਣ ਯਕੀਨੀ ਬਣਾਓ (ਖ਼ਾਸ ਕਰਕੇ ਲੋਡ ਹੇਠਾਂ)।
ਇਸੇ ਤਰ੍ਹਾਂ, ਸਕੀਮਾ ਬਦਲਾਅ ਨੂੰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨਾਲ ਮੈਨੇਜ ਕਰੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਜ਼ਨ ਕੀਤਾ ਰੱਖੋ, ਡਿਪਲੋਇਮੈਂਟ ਦੌਰਾਨ ਆਟੋਮੈਟਿਕ ਚਲਾਓ, ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਰੋਲਬੈਕ/ਫਾਰਵਰ ਪਾਥ ਟੈਸਟ ਕਰੋ।
ਸਟੇਜਿੰਗ ਅਤੇ ਆਟੋਮੇਟਡ ਟੈਸਟਾਂ ਵਿੱਚ ਉਹੀ ਸਕੀਮਾ, ਇੰਡੈਕਸ ਅਤੇ ਅਹੰਕਾਰਪੂਰਨ ਸੈਟਿੰਗ (ਜਿਵੇਂ ਜਰਨਲ ਮੋਡ) ਵਰਤੋ। ਬਹੁਤ ਸਾਰੀਆਂ SQLite "ਹੈਰਾਨੀਆਂ" ਕੇਵਲ ਡਾਟਾ ਆਕਾਰ ਵੱਧਣ ਜਾਂ ਸਮਕਾਲਤਾ ਵਧਣ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ—ਇਸ ਲਈ ਸਿਰਫ਼UNIT TEST ਨਹੀਂ, ਬਲਕਿ ਲੋਡ-ਟੈਸਟ ਹਕੀਕਤੀ ਵਰਕਲੋਡ ਨਾਲ ਕਰੋ।
SQLite ਹਰ ਜਗ੍ਹਾ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਇਹ ਡਾਟਾ ਸਟੋਰ ਕਰਨਾ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਵਰਤਣ ਵਾਂਗ ਅਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਇਕ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਚਲਾਉਣ। ਤੁਸੀਂ ਇੱਕ ਪਰਖਿਆ ਹੋਇਆ SQL ਇੰਜਣ, ACID ਟਰਾਂਜ਼ੈਕਸ਼ਨ, ਅਤੇ ਮੈਚੂਅਰ ਟੂਲਿੰਗ ਪਾਉਂਦੇ ਹੋ—ਕੋਈ ਡੇਟਾਬੇਸ ਸਰਵਰ ਪ੍ਰੋਵਿਜ਼ਨ, ਯੂਜ਼ਰ ਮੈਨੇਜਮੈਂਟ, ਜਾਂ ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ ਦੀ ਚਿੰਤਾ ਕੀਤੇ ਬਿਨਾਂ।
ਸਰਵਜਨੀਕ ਰੂਪ ਵਿੱਚ, SQLite "ਸਿਰਫ਼ ਕੰਮ ਕਰਦੀ" ਹੈ:
SQLite ਉੱਚ ਲਿਖਤ ਸਮਕਾਲਤਾ ਜਾਂ ਨੈਟਵਰਕ 'ਤੇ ਕੇਂਦਰੀ, ਬਹੁ-ਯੂਜ਼ਰ ਪਹੁੰਚ ਲਈ ਬਣਾਇਆ ਨਹੀਂ ਗਿਆ। ਬਹੁਤ ਸਾਰੇ ਪਾਠਕ ਇਕੱਠੇ ਹੀ ਪੁੱਠਰ ਲਿਖਦੇ ਹੋਏ ਉੱਪਰ-ਉੱਤੇ ਹੋਣਾ ਅਤੇ ਇੱਕ ਫਾਈਲ ਸਾਂਝੇ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਤਾਂ ਇੱਕ client-server ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੁੰਦਾ ਹੈ।
ਪਹਿਲਾਂ ਆਪਣੇ ਵਰਕਲੋਡ ਦਾ ਵਰਣਨ ਕਰੋ—ਫਿਰ ਸਭ ਤੋਂ ਸਧਾਰਣ ਔਜ਼ਾਰ ਚੁਣੋ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਜ਼ਿਆਦਾਤਰ ਲੋਕਲ, ਸਿੰਗਲ-ਯੂਜ਼ਰ, ਜਾਂ "ਲੋਕਲ-ਫਰਸਟ" ਹੈ, ਤਾਂ SQLite ਅਕਸਰ ਉਚਿਤ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੇ ਸਮਕਾਲੀ ਲਿਖਤਾਂ ਜਾਂ ਇੱਕ ਬੜੀ ਸਾਂਝੀ ਡੇਟਾਸੈੱਟ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ PostgreSQL ਵਰਗਾ ਸਰਵਰ ਡੇਟਾਬੇਸ ਚੁਣੋ।
ਜੇ ਪਹਿਲੇ ਚਾਰ ਦੇ ਉੱਤਰ "ਹਾਂ" ਹਨ ਅਤੇ ਆਖਰੀ ਦਾ ਜਵਾਬ "ਨਹੀਂ" ਹੈ, ਤਾਂ SQLite ਮਜ਼ਬੂਤ ਡਿਫੌਲਟ ਹੈ।
SQLite ਇੱਕ ਐਮਬੈਡਡ ਡੇਟਾਬੇਸ ਇੰਜਣ ਹੈ: ਇਹ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਸੈਸ ਦੇ ਅੰਦਰ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਵਾਂਗ ਚਲਦਾ ਹੈ। ਤੁਹਾਡੀ ਐਪ ਇੱਕ ਇਕ-ਫਾਇਲ ਡੇਟਾਬੇਸ (ਉਦਾਹਰਨ ਵਜੋਂ app.db) ਨੂੰ ਸਿਦھا ਡਿਸਕ 'ਤੇ ਪੜ੍ਹਦੀ ਅਤੇ ਲਿਖਦੀ ਹੈ—ਕੋਈ ਵੱਖਰਾ DB ਸਰਵਿਸ ਇੰਸਟਾਲ ਜਾਂ ਮੈਨੇਜ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ।
SQLite ਲਈ “ਸਰਵਰਲੀਸ” ਦਾ ਮਤਲਬ ਏਹ ਹੈ ਕਿ ਕੋਈ ਵੱਖਰਾ ਡੇਟਾਬੇਸ ਸਰਵਰ ਪ੍ਰੋਸੈਸ ਨਹੀਂ। ਇਹ ਏਸਦਾ ਮਤਲਬ ਨਹੀਂ ਕਿ ਇਹ “ਕਲਾਉਡ ਵਿੱਚ ਬਿਨਾਂ ਸਰਵਰਾਂ ਦੇ” ਚੱਲਦਾ ਹੈ। ਤੁਹਾਡੀ ਐਪ ਇਨ-ਪ੍ਰੋਸੈਸ SQLite ਦੀ API ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ, ਅਤੇ SQLite ਸਟੋਰੇਜ ਇੱਕ ਲੋਕਲ ਫਾਇਲ ਵਿੱਚ ਹੈਂਡਲ ਕਰਦਾ ਹੈ।
ਆਮ طور 'ਤੇ ਤੁਸੀਂ ਕੁਝ ਪ੍ਰੋਵਾਇਜ਼ਨ ਨਹੀਂ ਕਰਦੇ: ਆਪਣੀ ਐਪ ਨਾਲ ਸ਼ੁਰੂਆਤੀ .db ਫਾਇਲ ਪੈਕੇਜ ਕਰੋ (ਜਾਂ ਪਹਿਲੀ ਚਲਾਉਂਦੀਆਂ create ਕਰੋ), ਫਿਰ ਐਪ ਅੱਪਡੇਟਾਂ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਓ। ਇਹ ਆਮਤੌਰ 'ਤੇ ਇਕ ਬਹੁ-ਕਦਮ ਵਾਲੀ ਢਾਂਚਾਗਤ ਰੋਲਆਉਟ ਨੂੰ ਇੱਕ ਹੀ ਰਿਲੀਜ਼ ਆਰਟੀਫੈਕਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਹਾਂ। SQLite ACID ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਕਰੈਸ਼ ਜਾਂ ਬਿਜਲੀ ਚੱਲ ਜਾਣ ਵਾਲੀ ਸਥਿਤੀ ਵਿੱਚ ਆਧੇ-ਪੂਰੇ ਲਿਖਤ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
SQLite ਸੁਰੱਖਿਆ ਲਈ ਇੱਕ ਜਰਨਲ ਵਰਤਦਾ ਹੈ ਤਾਂ ਜੋ ਵਿੱਘਟਨ ਤੋਂ ਬਾਅਦ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਰਿਕਵਰ ਕਰ ਸਕੇ।
ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰੋਡਕਸ਼ਨ ਐਪਸ WAL ਚੁਣਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ "database is locked" ਦੀ ਪ੍ਰਸ਼ਨੀ ਘੱਟ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਇਸ ਲਈ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਨ-ਪ੍ਰੋਸੈਸ ਹੈ: ਕੁਐਰੀਜ਼ ਨੈੱਟਵਰਕ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਲੋਕਲ ਡਿਸਕ ਅਤੇ OS ਪੇਜ਼ ਕੈਸ਼ ਮਦਦ ਨਾਲ, ਬਹੁਤ ਸਾਰੇ ਰੀਡ-ਭਾਰ ਵਾਲੇ ਵਰਕਲੋਡ (ਸਰਚ, ਫਿਲਟਰ, ਇਨਡੈਕਸ ਖੋਜ) ਬਹੁਤ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ—ਖ਼ਾਸ ਕਰ ਕੇ ਡੈਸਕਟਾਪ, ਮੋਬਾਈਲ ਅਤੇ ਲੋਕਲ-ਫਰਸਟ ਐਪ ਲਈ।
SQLite ਕਈ ਰੀਡਰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ, ਪਰ ਲਿਖਤਾਂ ਨੂੰ ਫਾਇਲ ਨੂੰ ਸਹੀ ਰੱਖਣ ਲਈ ਸਹਿਯੋਗ ਨਾਲ ਲਿਖਣਾ ਪੈਂਦਾ ਹੈ। ਜਦੋਂ ਭਾਰੀ ਸਮਕਾਲੀ ਲਿਖਤ ਹੋਵੇ ਤਾਂ ਲਾਕ ਕਨਟੈਂਸ਼ਨ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ database is busy / database is locked ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਆ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਲਈ ਲਿਖਤਾਂ ਨੂੰ ਸੀਰੀਆਲਾਈਜ਼ ਅਤੇ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਛੋਟੇ ਰੱਖੋ।
ਜਦੋਂ ਕਈ ਮਸ਼ੀਨਾਂ/ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਡੇਟਾਬੇਸ 'ਤੇ ਲਿਖਣਾ ਹੋਵੇ ਜਾਂ ਤੁਸੀਂ ਕੇਂਦਰਿਤ ਗਵਰਨੈਂਸ, ਆਡੀਟਿੰਗ ਅਤੇ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ SQLite ਸਹੀ ਚੋਣ ਨਹੀਂ ਹੈ।
ਇਸ ਸਥਿਤੀ 'ਚ ਇੱਕ client-server ਡੇਟਾਬੇਸ (ਜਿਵੇਂ PostgreSQL/MySQL) ਜਿਆਦਾ ਮੂਲਾਂਕਣੀ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ।
ਡੇਟਾਬੇਸ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਐਪ ਡੇਟਾ ਵਾਂਗੋ ਵਰਤੋ:
ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਲੋਕਲ, ਸਿੰਗਲ-ਯੂਜ਼ਰ ਜਾਂ ਘੱਟ ਲਿਖਤ ਹੋਵੇ ਤਾਂ SQLite ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਸਾਫ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਾਹ ਰੱਖੋ।
ਅਮਲੀ ਟਿੱਪਸ: