SQL vs NoSQL: ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਕਿਹੜਾ ਡੇਟਾਬੇਸ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ?

SQL ਡੇਟਾਬੇਸ (ਜਿਨ੍ਹਾਂ ਨੂੰ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਡੇਟਾ ਨੂੰ ਟੇਬਲਾਂ ਵਿੱਚ ਰੱਖਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਢਾਂਚਾ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ, ਕਤਾਰਾਂ ਅਤੇ ਕਾਲਮਾਂ ਵਿੱਚ, ਅਤੇ ਸੰਬੰਧਤ ਟੇਬਲਾਂ ਨੂੰ ਆਪਸ ਵਿੱਚ ਜੋੜਦੇ ਹਨ। ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਨੂੰ SQL ਭਾਸ਼ਾ ਨਾਲ ਪੁੱਛਗਿੱਛ ਕਰਦੇ ਹੋ। Postgres, MySQL ਅਤੇ SQLite ਇਸ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਹਨ। NoSQL ਡੇਟਾਬੇਸ ਡੇਟਾ ਰੱਖਣ ਦੇ ਹੋਰ ਤਰੀਕੇ ਵਰਤਦੇ ਹਨ, ਜਿਵੇਂ ਡਾਕਿਊਮੈਂਟ, ਕੀ-ਵੈਲਿਊ ਜੋੜੇ, ਵਾਈਡ ਕਾਲਮ ਜਾਂ ਗ੍ਰਾਫ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਵਧੇਰੇ ਲਚਕਦਾਰ ਢਾਂਚਾ ਦਿੰਦੇ ਹਨ। MongoDB, Redis, DynamoDB ਅਤੇ Firestore ਇਸ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਬਿਜ਼ਨਸ ਐਪਾਂ ਲਈ SQL ਡੇਟਾਬੇਸ ਸਮਝਦਾਰੀ ਵਾਲਾ ਡਿਫਾਲਟ ਹੈ; NoSQL ਖਾਸ ਕੰਮਾਂ ਵਿੱਚ ਚਮਕਦਾ ਹੈ।

AI ਨਾਲ ਬਣਾਉਂਦੇ ਸਮੇਂ ਇਹ ਚੋਣ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ

ਡੇਟਾਬੇਸ ਐਪ ਦਾ ਇੱਕ ਸਭ ਤੋਂ ਔਖਾ ਹਿੱਸਾ ਹੈ ਜਿਸ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੈ। ਸਕ੍ਰੀਨਾਂ ਇੱਕ ਦੁਪਹਿਰ ਵਿੱਚ ਨਵੀਆਂ ਬਣ ਸਕਦੀਆਂ ਹਨ; ਸਾਲਾਂ ਦਾ ਗਾਹਕ ਡੇਟਾ ਕਿਸੇ ਹੋਰ ਕਿਸਮ ਦੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲਿਜਾਣਾ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਹੈ।

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

• ਸਮਝਣਾ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਕਿਹੋ ਜਿਹਾ ਦਿਖਦਾ ਹੈ ਅਤੇ ਕੀ ਉਹ ਉਨ੍ਹਾਂ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਪੁੱਛੋਗੇ ("ਮਹੀਨੇ ਅਨੁਸਾਰ ਉਤਪਾਦ ਅਨੁਸਾਰ ਆਮਦਨ")।
• ਪਲੇਟਫਾਰਮ ਚੋਣਾਂ ਨੂੰ ਪਰਖਣਾ। ਕੁਝ ਪਲੇਟਫਾਰਮ ਡਾਕਿਊਮੈਂਟ ਡੇਟਾਬੇਸ 'ਤੇ ਬਣੇ ਹਨ, ਕੁਝ ਰਿਲੇਸ਼ਨਲ 'ਤੇ। ਹਰ ਇੱਕ ਦੀ ਆਮ ਉਦਾਹਰਣ ਲਈ Supabase ਬਨਾਮ Firebase ਦੇਖੋ।
• ਲਾਕ-ਇਨ ਤੋਂ ਬਚਣਾ। SQL ਇੱਕ ਸਾਂਝਾ ਮਿਆਰ ਹੈ, ਇਸ ਲਈ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿਚਕਾਰ ਲਿਜਾਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

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

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

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

ਅਸਲ ਫ਼ਰਕ

"NoSQL" ਇੱਕ ਚੀਜ਼ ਨਹੀਂ ਹੈ। ਮੁੱਖ ਕਿਸਮਾਂ:

ਇੱਕ ਕੰਮ ਕੀਤੀ ਮਿਸਾਲ: ਇੱਕੋ ਦੁਕਾਨ ਦਾ ਡੇਟਾ, ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ

ਇੱਕ ਛੋਟੀ ਔਨਲਾਈਨ ਦੁਕਾਨ ਲਓ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਗਾਹਕ ਅਤੇ ਉਸ ਦੇ ਆਰਡਰ ਹਨ।

SQL (ਰਿਲੇਸ਼ਨਲ): ਡੇਟਾ ਟੇਬਲਾਂ ਵਿੱਚ ਵੰਡਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ID ਰਾਹੀਂ ਜੁੜਿਆ ਹੋਇਆ ਹੈ।

-- customers: id=1, name='Lena Ortiz'
-- orders:    id=101, customer_id=1, total=42.00
--            id=103, customer_id=1, total=25.00

SELECT c.name, SUM(o.total)
FROM customers c JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

ਜੇ Lena ਆਪਣੀ ਈਮੇਲ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਉਹ ਇੱਕ ਥਾਂ 'ਤੇ ਬਦਲਦੀ ਹੈ। "ਇਸ ਮਹੀਨੇ ਹਰ ਗਾਹਕ ਦੀ ਕੁੱਲ ਵਿਕਰੀ" ਇੱਕ ਹੀ ਪੁੱਛਗਿੱਛ ਹੈ।

NoSQL (ਡਾਕਿਊਮੈਂਟ): ਉਸ ਦੇ ਆਰਡਰ ਉਸ ਦੇ ਡਾਕਿਊਮੈਂਟ ਦੇ ਅੰਦਰ ਰਹਿ ਸਕਦੇ ਹਨ।

{
  "_id": "cust_1",
  "name": "Lena Ortiz",
  "email": "lena@example.com",
  "orders": [
    { "id": 101, "total": 42.00, "items": ["Green tea"] },
    { "id": 103, "total": 25.00, "items": ["Teapot"] }
  ]
}

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

ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਸਭ ਤੋਂ ਵੱਧ ਕਿਹੜਾ ਪੈਟਰਨ ਵਰਤਦੀ ਹੈ।

ਚੋਣ ਕਿਵੇਂ ਕਰੀਏ

ਇੱਕ ਰਿਲੇਸ਼ਨਲ SQL ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ ਡਿਫਾਲਟ ਹੁੰਦਾ ਹੈ ਜੇ:

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

ਇੱਕ NoSQL ਡੇਟਾਬੇਸ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਯੋਗ ਹੈ ਜੇ:

• ਤੁਹਾਨੂੰ ਤੇਜ਼ ਕੈਸ਼ ਜਾਂ ਸੈਸ਼ਨ ਸਟੋਰ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੇ Redis ਆਮ ਹੈ, ਅਕਸਰ ਇੱਕ SQL ਡੇਟਾਬੇਸ ਨਾਲ-ਨਾਲ।
• ਤੁਹਾਡੇ ਰਿਕਾਰਡ ਗਿਣਤੀ ਵਿੱਚ ਬਹੁਤ ਵੱਡੇ, ਸਧਾਰਨ ਅਤੇ ਸੁਤੰਤਰ ਹਨ, ਜਿਵੇਂ ਇਵੈਂਟ ਲੌਗ ਜਾਂ ਸੈਂਸਰ ਰੀਡਿੰਗ।
• ਤੁਸੀਂ ਕਿਸੇ ਇੱਕ 'ਤੇ ਬਣੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਹੋ, ਜਿਵੇਂ Firebase ਦਾ Firestore, ਅਤੇ ਇਸ ਦੇ ਰੀਅਲ-ਟਾਈਮ ਫੀਚਰ ਹੀ ਮੁੱਖ ਖਿੱਚ ਹਨ।

ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਾਂ ਦੋਵੇਂ ਵਰਤਦੀਆਂ ਹਨ: SQL ਮੁੱਖ ਸਰੋਤ ਵਜੋਂ, ਅਤੇ NoSQL ਸਟੋਰ ਕੈਸ਼ਿੰਗ ਜਾਂ ਕਿਸੇ ਖਾਸ ਫੀਚਰ ਲਈ।

ਮੁੱਖ ਸ਼ਬਦ

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

• "NoSQL ਦਾ ਮਤਲਬ ਹੈ ਕੋਈ ਸਕੀਮਾ ਨਹੀਂ।" ਤੁਹਾਡੇ ਡੇਟਾ ਦੀ ਸ਼ਕਲ ਹਮੇਸ਼ਾ ਹੁੰਦੀ ਹੈ। NoSQL ਵਿੱਚ ਡੇਟਾਬੇਸ ਇਸ ਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
• "SQL ਸਕੇਲ ਨਹੀਂ ਹੁੰਦਾ।" ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਬਹੁਤ ਵੱਡੀਆਂ ਸੇਵਾਵਾਂ ਚਲਾਉਂਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਐਪਾਂ ਕਦੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਹੱਦਾਂ ਦੇ ਨੇੜੇ ਵੀ ਨਹੀਂ ਪਹੁੰਚਦੀਆਂ।
• "NoSQL ਹਮੇਸ਼ਾ ਤੇਜ਼ ਹੈ।" ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਪੈਟਰਨਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਲਈ ਇਹ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਕਈ ਟੇਬਲਾਂ ਨੂੰ ਕੱਟਣ ਵਾਲੀ ਰਿਪੋਰਟ ਹੋਰ ਹੌਲੀ ਹੋ ਸਕਦੀ ਹੈ।
• "ਇੱਕ ਵਾਰ ਚੁਣੋ ਤਾਂ ਹਮੇਸ਼ਾ ਲਈ ਚੁਣਿਆ।" ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਾਂ ਦੋਵੇਂ ਮਿਲਾਉਂਦੀਆਂ ਹਨ। ਅਤੇ Postgres ਵਰਗੇ SQL ਡੇਟਾਬੇਸ JSON ਵੀ ਸਟੋਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਕੁਝ ਲਚਕਦਾਰ ਫੀਲਡਾਂ ਲਈ NoSQL ਦੀ ਲੋੜ ਨਹੀਂ।
• "NoSQL ਦਾ ਮਤਲਬ ਹੈ ਤੁਸੀਂ SQL ਨਹੀਂ ਵਰਤ ਸਕਦੇ।" ਨਾਮ ਆਮ ਤੌਰ 'ਤੇ "not only SQL" ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੁਝ NoSQL ਉਤਪਾਦ SQL ਵਰਗੀਆਂ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾਵਾਂ ਦਿੰਦੇ ਹਨ।

ਆਪਣੇ AI ਬਿਲਡਰ ਤੋਂ ਕੀ ਪੁੱਛੋ

• "ਇਹ ਐਪ ਕਿਹੜਾ ਡੇਟਾਬੇਸ ਵਰਤਦੀ ਹੈ, ਅਤੇ ਮੇਰੇ ਡੇਟਾ ਲਈ ਇਹ ਕਿਉਂ ਢੁਕਵਾਂ ਹੈ?"
• "ਟੇਬਲਾਂ ਜਾਂ ਕਲੈਕਸ਼ਨਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਸੰਬੰਧਾਂ ਦਾ ਖਾਕਾ ਬਣਾਓ।"
• "ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਮੈਨੂੰ ਕਿਹੜੀਆਂ ਰਿਪੋਰਟਾਂ ਚਾਹੀਦੀਆਂ ਹੋਣਗੀਆਂ? ਕੀ ਇਹ ਡੇਟਾਬੇਸ ਉਨ੍ਹਾਂ ਦਾ ਆਸਾਨੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ?"
• "ਜੇ ਕੁਝ ਫੀਲਡ ਸੱਚਮੁੱਚ ਲਚਕਦਾਰ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਦੂਜਾ ਡੇਟਾਬੇਸ ਜੋੜਨ ਦੀ ਬਜਾਏ Postgres ਵਿੱਚ JSON ਵਜੋਂ ਰੱਖੋ।"
• "ਕੈਸ਼ ਸਿਰਫ਼ ਤਾਂ ਜੋੜੋ ਜੇ ਅਸੀਂ ਮਾਪੀ ਹੋਈ ਗਤੀ ਦੀ ਸਮੱਸਿਆ ਦੇਖੀ ਹੋਵੇ।"

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

Mythex ਹਰ ਉਸ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਇੱਕ ਸਮਰਪਿਤ Postgres ਡੇਟਾਬੇਸ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਇਸ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਐਪ ਨੂੰ ਲੋੜ ਪੈਣ 'ਤੇ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਚੈਟ ਵਿੱਚ ਪੁੱਛ ਕੇ, ਜਾਂ /database ਕਮਾਂਡ ਨਾਲ (Database)। ਇਹ ਜ਼ਿਆਦਾਤਰ ਬਿਜ਼ਨਸ ਐਪਾਂ ਲਈ ਢੁਕਵਾਂ ਹੈ: ਯੂਜ਼ਰ, ਬੁਕਿੰਗ, ਆਰਡਰ ਅਤੇ ਰਿਪੋਰਟਾਂ। ਜੇ ਤੁਹਾਨੂੰ ਕਿਸੇ ਖਾਸ ਬਾਹਰੀ ਸੇਵਾ ਦੀ ਲੋੜ ਹੈ, ਜਿਵੇਂ ਹੋਸਟਡ ਡਾਕਿਊਮੈਂਟ ਡੇਟਾਬੇਸ, ਤਾਂ ਏਜੰਟ ਅਜਿਹਾ ਕੋਡ ਲਿਖ ਸਕਦਾ ਹੈ ਜੋ ਉਸ ਨਾਲ ਜੁੜੇ, ਅਤੇ ਕੁੰਜੀਆਂ ਤੁਸੀਂ ਪ੍ਰੋਜੈਕਟ ਸੀਕ੍ਰੇਟ ਵਜੋਂ ਰੱਖਦੇ ਹੋ। ਭਾਸ਼ਾ ਬਾਰੇ ਹੋਰ ਜਾਣਨ ਲਈ, SQL ਕੀ ਹੈ ਪੜ੍ਹੋ।

ਸਵਾਲ