6 SQL JOINs ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਣੇ ਚਾਹੀਦੇ (ਸਰਲ, ਸਪਸ਼ਟ ਉਦਾਹਰਨਾਂ)

Q: ਸਧੇ ਅੰਗ ਵਿੱਚ SQL JOIN ਕੀ ਹੈ?

SQL ਦੋ (ਜਾਂ ਵੱਧ) ਟੇਬਲਾਂ ਦੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਇੱਕ ਨਤੀਜੇ ਸੈੱਟ ਵਿੱਚ ਜੋੜਦਾ ਹੈ, ਜਿੱਥੇ ਸੰਬੰਧਤ ਕਾਲਮ ਮਿਲਦੇ ਹਨ—ਅਕਸਰ ਇੱਕ primary key ਨੂੰ foreign key ਨਾਲ ਜੋੜ ਕੇ (ਉਦਾਹਰਨ ਵਜੋਂ ). ਇਹ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ normalized ਟੇਬਲਾਂ ਨੂੰ ਰਿਪੋਰਟਾਂ, ਆਡੀਟਾਂ ਜਾਂ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰਦੇ ਹੋ।

Q: ਜੇ ਮੇਰੇ ਡੇਟਾਬੇਸ ਵਿੱਚ FULL OUTER JOIN ਸਪੋਰਟ ਨਹੀਂ ਹੁੰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ?

ਕੁਝ ਡੇਟਾਬੇਸ (ਖਾਸ ਕਰਕੇ MySQL ਅਤੇ SQLite) ਸਿੱਧੇ ਨੂੰ ਸਹਾਇਤਾ ਨਹੀਂ ਦਿੰਦੇ। ਇੱਕ ਆਮ ਵਰਕਅਰਾਉਂਡ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਦੋ ਕੁਏਰੀਆਂ ਨੂੰ ਜੋੜੋ: - - ਅਤੇ payments ਪਾਸੇ ਜਿਹੜੇ ਰਿਕਾਰਡ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਉਹਨਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ ਅਕਸਰ ਇਹ (ਜਾਂ ਨਾਲ ਧਿਆਨ) ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦੋਹਾਂ “left-only” ਅਤੇ “right-only” ਰਿਕਾਰਡ ਰੱਖ ਸਕੋ।

ਲੌਗ ਇਨ ਸ਼ੁਰੂ ਕਰੋ

SQL JOINs ਕੀ ਹਨ ਤੇ ਤੁਸੀਂ ਇਹ ਕਿਉਂ ਵਰਤਦੇ ਹੋ

SQL JOIN ਤੁਹਾਨੂੰ ਦੋ (ਜਾਂ ਵੱਧ) ਟੇਬਲਾਂ ਦੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਇੱਕ ਨਤੀਜੇ ਵਿੱਚ ਮਿਲਾ ਕੇ ਵੇਖਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਬਹੁਤ ਵਾਰੀ ਇੱਕ ਸੰਬੰਧਿਤ ਕਾਲਮ — ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ID — ਦੇ ਆਧਾਰ 'ਤੇ।

JOINs ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਅਧਿਕਤਰ ਅਸਲ ਡੇਟਾਬੇਸ ਸੂਚਨਾ ਨੂੰ ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ ਵਿੱਚ ਤੋੜ ਕੇ ਰੱਖਦੇ ਹਨ ਤਾਂ ਕਿ ਇੱਕੋ ਹੀ ਜਾਣਕਾਰੀ ਬਾਰ-ਬਾਰ ਨਾਂ ਲਿਖਨੀ ਪਏ। ਉਦਾਹਰਨ ਵਜੋਂ, ਗਾਹਕ ਦਾ ਨਾਮ customers ਟੇਬਲ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ ਉਸਦੇ ਖਰੀਦ orders ਵਿੱਚ ਹੁੰਦੇ ਹਨ। JOINs ਉਹ ਤਰੀਕਾ ਹਨ ਜਿਹੜੇ ਤੁਹਾਨੂੰ ਜਵਾਬ ਲੱਭਣ ਲਈ ਇਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਮੁੜ ਜੋੜਨ ਦਿੰਦੇ ਹਨ।

ਇਸ ਲਈ JOINs ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਹਰ ਜਗ੍ਹਾ ਵਰਤੀ ਜਾਂਦੀਆਂ ਹਨ:

ਗਾਹਕ ਦੇ ਨਾਂ, ਆਰਡਰ ਟੋਟਲ ਅਤੇ ਭੁਗਤਾਨ ਦੀ ਹਾਲਤ ਵਾਲੀ sales ਰਿਪੋਰਟ ਬਣਾਉਣਾ
ਉਹ ਗਾਹਕ ਲੱਭਣਾ ਜਿਨ੍ਹਾਂ ਨੇ ਅਜੇ ਤੱਕ ਆਰਡਰ ਨਹੀਂ ਕੀਤਾ
ਅਜਿਹੇ ਮੈਚ-ਰਿਕਾਰਡਾਂ ਦੀ ਆਡੀਟ ਕਰਨਾ, ਜਿਵੇਂ ਆਰਡਰ ਬਿਨਾਂ ਭੁਗਤਾਨ
ਕਈ ਸਬੰਧਿਤ ਰਿਕਾਰਡਾਂ ਤੋਂ “ਇੱਕ ਕਤਾਰ ਪ੍ਰਤੀ ਗਾਹਕ” ਦੇ ਸੰਖੇਪ ਤਿਆਰ ਕਰਨਾ

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

ਜੇ ਤੁਸੀਂ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੇ ਉੱਪਰ ਪ੍ਰੋਡਕਟ ਬਣਾ ਰਹੇ ਹੋ (ਡੈਸ਼ਬੋਰਡ, ਐਡਮਿਨ ਪੈਨਲ, ਇੰਟਰਨਲ ਟੂਲ, ਕਸਟਮਰ ਪੋਰਟਲ), JOINs ਉਹੀ ਹਨ ਜੋ “ਕੱਚੀਆਂ ਟੇਬਲਾਂ” ਨੂੰ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਵਿਊਜ਼ ਵਿੱਚ ਬਦਲਦੇ ਹਨ। Platforms ਜਿਵੇਂ Koder.ai (ਜੋ chat ਤੋਂ React + Go + PostgreSQL ਐਪਜ ਬਣਾਉਂਦਾ ਹੈ) ਵੀ ਸਹੀ ਲਿਸਟ ਪੇਜ, ਰਿਪੋਰਟ ਅਤੇ reconciliation ਸਕ੍ਰੀਨਾਂ ਲਈ JOIN ਮੁੱਢ-ਸਿਧਾਂਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ—ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਲਾਜ਼ਮਤ ਨਹੀਂ ਗੁੰਮ ਹੁੰਦੀ, ਭਾਵੇਂ ਡਿਵੈਲਪਮੈਂਟ ਤੇਜ਼ ਹੋਵੇ।

ਉਹ 6 JOIN ਕਿਸਮਾਂ ਜੋ ਤੁਸੀਂ ਵੱਧਤਰੀਨ ਵਰਤੋਂ ਕਰੋਗੇ

ਇਹ ਗਾਈਡ ਛੇ JOINs 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦੀ ਹੈ ਜੋ ਰੋਜ਼ਾਨਾ SQL ਕੰਮ ਦਾ ਵੱਧਾ ਹਿੱਸਾ ਕਵਰ ਕਰਦੇ ਹਨ:

INNER JOIN: ਸਿਰਫ ਉਹੀ ਕਤਾਰਾਂ ਜੋ ਦੋਹਾਂ ਟੇਬਲਾਂ ਵਿੱਚ ਮਿਲਦੀਆਂ ਹਨ ("ਮੈਨੂੰ ਪੁਸ਼ਟੀ ਹੋਏ ਰਿਸ਼ਤੇ ਦਿਖਾਓ")।
LEFT JOIN: ਖੱਬੇ ਟੇਬਲ ਦੀ ਹਰ ਕਤਾਰ ਰੱਖੋ, ਅਤੇ ਸੱਜੇ ਪਾਸੇ ਤੋਂ ਜੇ ਮਿਲ ਸਕੇ ਤਾਂ ਡੇਟਾ ਜੋੜੋ ("ਗਾਇਬ ਸੰਬੰਧੀ ਡੇਟਾ ਸ਼ਾਮਲ ਕਰੋ")।
RIGHT JOIN: LEFT JOIN ਦਾ ਅੱਡਾ-ਆਇਨਾ (ਕੁਝ ਘੱਟ ਆਮ, ਪਰ ਪੜ੍ਹਨ ਦੀ ਸ਼ੈਲੀ ਤੇ ਨਿਰਭਰ)।
FULL OUTER JOIN: ਦੋਹਾਂ ਟੇਬਲਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਰੱਖੋ, ਜਿੱਥੇ ਮੁਕਾਬਲਾ ਹੋ ਸਕੇ ਉੱਥੇ ਮਿਲਾ ਦਿਓ (reconciliation ਅਤੇ gap-finding ਲਈ ਬਹੁਤ ਵਧੀਆ)।
CROSS JOIN: ਕਤਾਰਾਂ ਦੇ ਸਾਰੇ ਸੰਯੋਜਨ ਤਿਆਰ ਕਰੋ (ਕੈਲੰਡਰ, ਸੈਨੇਰਿਓ, ਜਾਂ ਟੈਸਟ ਡੇਟਾ ਬਣਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ—ਪਰ ਗਲਤ ਵਰਤੋਂ ਆਸਾਨ ਹੈ)।
SELF JOIN: ਟੇਬਲ ਨੂੰ ਆਪਣੇ ਆਪ ਨਾਲ ਜੋੜੋ (employee/manager ਵਰਗੀਆਂ הירਾਰਕੀਜ਼ ਲਈ ਬਹੁਤ ਲਾਹੇਵੰਦ)।

ਸਰਗਰਮੀ 'ਤੇ ਇੱਕ ਛੋਟਾ ਨੋਟ

JOIN syntax ਬਹੁਤ ਜ਼ਿਆਦਾ SQL ਡੇਟਾਬੇਸਾਂ (PostgreSQL, MySQL, SQL Server, SQLite) ਵਿੱਚ ਸਮਾਨ ਹੁੰਦੀ ਹੈ। ਕੁਝ ਫਰਕ ਹੋ ਸਕਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ FULL OUTER JOIN ਸਮਰਥਨ ਅਤੇ ਕੁਝ ਏਜ-ਕੇਸ ਵਿਵਹਾਰਾਂ 'ਤੇ—ਪਰ ਅਸਲੀ ਧਾਰਣਾ ਅਤੇ ਮੁੱਖ ਨਮੂਨੇ ਆਮ ਤੌਰ 'ਤੇ ਅਨੁਵਾਦ ਲਾਇਕ ਹਨ।

ਅਸੀਂ ਜਿਹੜੀਆਂ ਉਦਾਹਰਨ ਟੇਬਲਾਂ ਵਰਤਾਂਗੇ (customers, orders, payments)

JOIN ਉਦਾਹਰਣਾਂ ਨੂੰ ਸਧਾਰਨ ਰੱਖਣ ਲਈ, ਅਸੀਂ ਤਿੰਨ ਛੋਟੀ ਟੇਬਲਾਂ ਵਰਤਾਂਗੇ ਜੋ ਆਮ ਵਰਲਡ ਸੈਟਅਪ ਦਰਸਾਉਂਦੀਆਂ ਹਨ: customers ਆਰਡਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਆਰਡਰਾਂ ਦੇ ਭੁਗਤਾਨ ਹੋ ਸਕਦੇ ਹਨ (ਜਾਂ ਨਹੀਂ ਵੀ)।

ਇੱਕ ਨੋਟ: ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਨਮੂਨਾ ਟੇਬਲਾਂ 'ਚ ਸਿਰਫ ਕੁਝ ਕਾਲਮ ਦਿਖਾਏ ਗਏ ਹਨ, ਪਰ ਕੁਝ ਕੁਏਰੀਆਂ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਫੀਲਡਾਂ (ਜਿਵੇਂ order_date, created_at, status, ਜਾਂ paid_at) ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਤਾ ਕਿ ਆਮ ਪੈਟਰਨ ਦਿਖਾਏ ਜਾ ਸਕਣ। ਉਹਨਾਂ ਕਾਲਮਾਂ ਨੂੰ ਉਤਪਾਦਨ ਸਕੀਮਾਂ ਵਿੱਚ ਆਮ ਫੀਲਡਾਂ ਵਜੋਂ ਸਮਝੋ।

1) customers

Primary key: customer_id

customer_id	name
1	Ava
2	Ben
3	Chen
4	Dia

2) orders

Primary key: order_id
Foreign key: customer_id → customers.customer_id

order_id	customer_id	order_total
101	1	50
102	1	120
103	2	35
104	5	70

ਧਿਆਨ ਦਿਓ order_id = 104 customer_id = 5 ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ customers ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਇਹ “ਗਾਇਬ ਮੈਚ” ਇਹ ਵੇਖਣ ਲਈ ਉਪਯੋਗੀ ਹੈ ਕਿ LEFT, RIGHT ਅਤੇ FULL OUTER JOIN ਕਿਵੇਂ ਵਿਹਾਰ ਕਰਦੇ ਹਨ।

3) payments

Primary key: payment_id
Foreign key: order_id → orders.order_id

payment_id	order_id	amount
9001	101	50
9002	102	60
9003	102	60
9004	999	25

ਇੱਥੇ ਦੋ ਮਹੱਤਵਪੂਰਨ ਸਿਖਲਾਈ ਵਾਲੀਆਂ ਗੱਲਾਂ ਹਨ:

order_id = 102 ਦੇ ਦੋ payment rows ਹਨ (split payment). ਜਦੋਂ ਤੁਸੀਂ orders ਨੂੰ payments ਨਾਲ join ਕਰੋਗੇ, ਉਹ order ਦੋ ਵਾਰੀ ਦਿਖੇਗਾ—ਇਹ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ duplicates ਲੋਕਾਂ ਨੂੰ ਆਸ਼ਚਰਜ ਵਿੱਚ ਪਾ ਸਕਦੇ ਹਨ।
payment_id = 9004 order_id = 999 ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ orders ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਇਹ ਇਕ ਹੋਰ “unmatched” ਮਾਮਲਾ ਬਣਾਉਂਦਾ ਹੈ।

JOIN ਕਰਨ 'ਤੇ ਕੀ ਉਮੀਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ

Matching rows: ਉਦਾਹਰਨ ਲਈ, customer 1 ↔ orders 101/102; order 101 ↔ payment 9001.
Unmatched rows: ਉਦਾਹਰਨ ਲਈ, customer 3 ਅਤੇ 4 ਦੇ ਕੋਈ orders ਨਹੀਂ; order 104 ਦਾ ਕੋਈ customer ਨਹੀਂ; payment 9004 ਦਾ ਕੋਈ order ਨਹੀਂ।
Duplicates: orders ਨੂੰ payments ਨਾਲ join ਕਰਨ 'ਤੇ order 102 ਦੁਹਰਾਇਆ ਜਾਵੇਗਾ ਕਿਉਂਕਿ ਇਸਦੇ ਦੋ ਸੰਬੰਧਿਤ payments ਹਨ।

INNER JOIN: ਸਿਰਫ ਮੈਚ ਹੋਈਆਂ ਕਤਾਰਾਂ ਰੱਖੋ

INNER JOIN ਸਿਰਫ ਉਹੀ ਕਤਾਰਾਂ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਦੋਹਾਂ ਟੇਬਲਾਂ ਵਿੱਚ ਮੈਚ ਹੋਵੇ। ਜੇ ਕਿਸੇ ਗਾਹਕ ਦਾ ਕੋਈ ਆਰਡਰ ਨਹੀਂ, ਤਾਂ ਉਹ ਨਤੀਜੇ ਵਿੱਚ ਨਹੀਂ ਆਉਣਾ। ਜੇ ਕੋਈ ਆਰਡਰ ਕਿਸੇ ਮੌਜੂਦ ਗਾਹਕ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ (ਖ਼ਰਾਬ ਡੇਟਾ), ਉਹ ਵੀ ਨਤੀਜੇ ਤੋਂ ਬਾਹਰ ਰਹੇਗਾ।

ਬੁਨਿਆਦੀ ਪੈਟਰਨ

ਤੁਸੀਂ ਇੱਕ “ਖੱਬੀ” ਟੇਬਲ ਚੁਣਦੇ ਹੋ, ਇੱਕ “ਸੱਜੀ” ਟੇਬਲ ਨੂੰ join ਕਰਦੇ ਹੋ, ਅਤੇ ON ਕਲਾਸ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਜੁੜਦੇ ਹੋ।

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.order_date
FROM customers c
INNER JOIN orders o
  ON o.customer_id = c.customer_id;

ਮੁੱਖ ਵਿਚਾਰ ON o.customer_id = c.customer_id ਲਾਈਨ ਹੈ: ਇਹ SQL ਨੂੰ ਦਸਦੀ ਹੈ ਕਿ ਕਿਵੇਂ ਕਤਾਰਾਂ ਸੰਬੰਧਿਤ ਹਨ।

ਅਮਲ ਵਾਲਾ ਉਦਾਹਰਨ: ਉਹ ਗਾਹਕ ਜਿਨ੍ਹਾਂ ਨੇ ਆਰਡਰ ਦਿੱਤਾ

ਜੇ ਤੁਸੀਂ ਉਹ ਗਾਹਕਾਂ ਦੀ ਲਿਸਟ ਚਾਹੁੰਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਨੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਆਰਡਰ ਦਿੱਤਾ (ਅਤੇ ਆਰਡਰ ਵੇਰਵੇ), ਤਾਂ INNER JOIN ਕੁਜ਼ੀ-ਛੁਟੀ ਚੋਣ ਹੈ:

SELECT
  c.name,
  o.order_id,
  o.total_amount
FROM customers c
INNER JOIN orders o
  ON o.customer_id = c.customer_id
ORDER BY o.order_id;

ਇਹ ਵਰਤੋਂਗੀਆਂ ਚੀਜ਼ਾਂ ਜਿਵੇਂ “order follow-up email ਭੇਜੋ” ਜਾਂ “revenue per customer ਗਣਨਾ” ਲਈ ਮਦਦਗਾਰ ਹੈ (ਜਦੋਂ ਤੁਸੀਂ ਸਿਰਫ ਖਰੀਦਦਾਰਾਂ 'ਤੇ ਧਿਆਨ ਦੇ ਰਹੇ ਹੋ)।

ਆਮ ਗਲਤੀ: JOIN ਸ਼ਰਤ ਗੁੰਨੀ ਜਾਂ ਅਸਪਸ਼ਟ ਹੋਣਾ

ਜੇ ਤੁਸੀਂ ON ਸ਼ਰਤ ਭੁੱਲ ਜਾਂ ਗਲਤ ਕਾਲਮ 'ਤੇ join ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਇੱਕ Cartesian product (ਹਰ ਗਾਹਕ ਹਰ ਆਰਡਰ ਨਾਲ) ਬਣਾ ਸਕਦੇ ਹੋ ਜਾਂ ਨਰਮ matches ਬਣ ਸਕਦੇ ਹਨ।

ਬੁਰਾ (ਇਹ ਨਾ ਕਰੋ):

SELECT c.name, o.order_id
FROM customers c
JOIN orders o;

ਹਮੇਸ਼ਾ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ON (ਜਾਂ ਜਿੱਥੇ ਲਾਗੂ ਹੋਵੇ USING) ਵਿੱਚ ਸਪਸ਼ਟ join ਸ਼ਰਤ ਹੋਵੇ।

LEFT JOIN: ਖੱਬੀ ਟੇਬਲ ਤੋਂ ਹਰ ਚੀਜ਼ ਰੱਖੋ

LEFT JOIN ਖੱਬੀ ਟੇਬਲ ਦੀਆਂ ਸਾਰੀ ਕਤਾਰਾਂ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਮੈਚ ਮਿਲੇ ਤਾਂ ਸੱਜੀ ਟੇਬਲ ਤੋਂ ਡੇਟਾ ਜੋੜਦਾ ਹੈ। ਜੇ ਮੈਚ ਨਹੀਂ ਮਿਲਦਾ, ਤਾਂ ਸੱਜੇ ਪਾਸੇ ਵਾਲੇ ਕਾਲਮ NULL ਦਿਖਦੇ ਹਨ।

ਇਹ ਕਦੋਂ ਵਰਤੋਂ

ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੀ ਪ੍ਰਾਇਮਰੀ ਟੇਬਲ ਦੀ ਪੂਰੀ ਲਿਸਟ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਸਬੰਧਿਤ ਵੱਕਲ ਡੇਟਾ ਜੇ ਉਪਲੱਬਧ ਹੋਵੇ ਤਾਂ ਸ਼ਾਮਲ ਕਰਨਾ ਹੋਵੇ।

ਉਦਾਹਰਨ: “ਮੇਨੂੰ ਸਾਰੇ ਗਾਹਕ ਦਿਖਾਓ, ਅਤੇ ਜੇ ਉਹਨਾਂ ਕੋਲ ਕੋਈ ਆਰਡਰ ਹੋਵੇ ਤਾਂ ਉਹ ਵੀ ਦਿਖਾਓ।”

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
ORDER BY c.customer_id;

ਆਰਡਰ ਵਾਲੇ ਗਾਹਕ ਆਪਣੇ ਆਰਡਰ ਵੇਰਵਿਆਂ ਨਾਲ ਦਿਖਦੇ ਹਨ।
ਜਿਨ੍ਹਾਂ ਗਾਹਕਾਂ ਕੋਲ ਆਰਡਰ ਨਹੀਂ, ਉਹ ਫਿਰ ਵੀ ਦਿਖਦੇ ਹਨ, ਪਰ o.order_id (ਅਤੇ ਹੋਰ orders ਕਾਲਮ) NULL ਹੋਵੇਗਾ।

“ਨੋ ਮੈਚ” ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਲੱਭਣ ਦਾ ਰਿਵਾਜ਼ੀ ਪੈਟਰਨ

LEFT JOIN ਵਰਤੋਂ ਦਾ ਇੱਕ ਬਹੁਤ ਆਮ ਕਾਰਨ ਉਹ ਆਈਟਮ ਲੱਭਣਾ ਹੈ ਜਿਹੜਿਆਂ ਦੇ ਸਬੰਧੀ ਰਿਕਾਰਡ ਨਹੀਂ ਹਨ।

ਉਦਾਹਰਨ: “ਕਿਹੜੇ ਗਾਹਕਾਂ ਨੇ ਕਦੇ ਵੀ ਆਰਡਰ ਨਹੀਂ ਕੀਤਾ?”

SELECT
  c.customer_id,
  c.name
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
WHERE o.order_id IS NULL;

ਉਹ WHERE ... IS NULL ਸ਼ਰਤ ਸਿਰਫ ਉਹ ਖੱਬੇ-ਟੇਬਲ ਦੀਆਂ ਕਤਾਰਾਂ ਰੱਖਦੀ ਹੈ ਜਿੱਥੇ JOIN ਨੂੰ ਕੋਈ ਮੈਚ ਨਹੀਂ ਮਿਲਿਆ।

ਧਿਆਨ ਰੱਖੋ: ਬਹੁਤ ਸਾਰੇ ਮੈਚ ਹੋਣ ਤੇ ਕਤਾਰਾਂ ਗੁਣਾ ਹੋ ਜਾਂਦੀਆਂ ਹਨ

LEFT JOIN ਖੱਬੇ-ਟੇਬਲ ਦੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਅਕਸਰ ਦੁਹਰਾਉਂਦਾ ਹੈ ਜਦੋਂ ਸੱਜੇ ਪਾਸੇ ਕਈ ਮਿਲਦੇ ਹਨ।

ਜੇ ਇੱਕ ਗਾਹਕ ਕੋਲ 3 ਆਰਡਰ ਹਨ, ਤਾਂ ਉਹ ਗਾਹਕ 3 ਵਾਰੀ ਆਵੇਗਾ—ਹਰ ਆਰਡਰ ਲਈ ਇੱਕ ਵਾਰੀ। ਇਹ ਉਮੀਦਯੋਗ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਗਾਹਕਾਂ ਨੂੰ ਗਿਣ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਹੈਰਾਨੀ ਵਾਲੀ ਗੱਲ ਹੋ ਸਕਦੀ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਇਹ orders ਗਿਣਦਾ ਹੈ (customers ਨਹੀਂ):

SELECT COUNT(*)
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id;

ਜੇ ਤੁਹਾਡਾ ਟੀਚਾ ਗਾਹਕਾਂ ਦੀ ਗਿਣਤੀ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ customer key ਗਿਣੋਗੇ (ਅਕਸਰ COUNT(DISTINCT c.customer_id)), ਇਸ ਗੱਲ ਤੇ ਨਿਰਭਰ ਕਰਕੇ ਕਿ ਤੁਸੀਂ ਕੀ ਮੈਪ ਕਰ ਰਹੇ ਹੋ।

RIGHT JOIN: ਸੱਜੀ ਟੇਬਲ ਤੋਂ ਹਰ ਚੀਜ਼ ਰੱਖੋ

RIGHT JOIN ਸੱਜੀ ਟੇਬਲ ਦੀਆਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਖੱਬੇ ਟੇਬਲ ਤੋਂ ਸਿਰਫ਼ ਮਿਲਣ ਵਾਲੀਆਂ ਕਤਾਰਾਂ। ਜੇ ਮੈਚ ਨਹੀਂ ਮਿਲਦਾ, ਤਾਂ ਖੱਬੇ-ਟੇਬਲ ਦੇ ਕਾਲਮ NULL ਦਿਖਦੇ ਹਨ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ LEFT JOIN ਦਾ ਉਲਟਾ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ

ਸਾਡੀਆਂ ਉਦਾਹਰਨ ਟੇਬਲਾਂ ਵਰਤ ਕੇ, ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਹਰ ਭੁਗਤਾਨ ਨੂੰ ਲਿਸਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਚਾਹੇ ਉਹ ਕਿਸੇ ਆਰਡਰ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੋਵੇ ਜਾਂ ਨਹੀਂ (ਸ਼ਾਇਦ ਆਰਡਰ ਮਿਟ ਗਿਆ ਹੋਵੇ, ਜਾਂ ਡੇਟਾ ਗੰਦਗੀ ਹੋਵੇ)।

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount,
  p.paid_at
FROM orders o
RIGHT JOIN payments p
  ON o.order_id = p.order_id;

ਤੁਹਾਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ:

ਸਾਰੇ payments ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਕਿਉਂਕਿ payments ਸੱਜੀ ਵੱਲ ਹਨ)।
ਜੇ ਕਿਸੇ payment ਦਾ ਕੋਈ matching order ਨਹੀਂ, ਤਾਂ o.order_id ਅਤੇ o.customer_id NULL ਹੋਉਣਗੇ।

ਇਹੀ ਕੁਏਰੀ LEFT JOIN ਵਰਗੇ ਤਰੀਕੇ ਨਾਲ (ਅਕਸਰ ਪਸੰਦ ਕੀਤਾ ਜਾਂਦਾ)

ਜ਼ਿਆਦਾਤਰ ਵਾਰ, ਤੁਸੀਂ RIGHT JOIN ਨੂੰ LEFT JOIN ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖ ਸਕਦੇ ਹੋ ਉਸ ਟੇਬਲ ਦੇ ਅਨੁਕੂਲ ਕਰਕੇ:

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount,
  p.paid_at
FROM payments p
LEFT JOIN orders o
  ON o.order_id = p.order_id;

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

ਪਾਠਨੀਯਤਾ: ਕਈ ਟੀਮਾਂ RIGHT JOIN ਤੋਂ ਦੂਰ ਰਹਿੰਦੀਆਂ ਹਨ

ਕਈ SQL ਸਟਾਈਲ ਗਾਈਡ RIGHT JOIN ਨੂੰ ਨਕਾਰਾਂਦਿਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਪਾਠਕਾਂ ਨੂੰ ਆਮ ਪੈਟਰਨ ਨੂੰ ਅਲਟਾ ਸੋਚਣ 'ਤੇ ਮਜਬੂਰ ਕਰਦਾ ਹੈ:

"ਮੁੱਖ ਟੇਬਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ"
"LEFT JOIN ਨਾਲ ਹੋਰ ਟੇਬਲ ਜੋੜੋ"

ਜਦੋਂ optional relationships ਲਗਾਤਾਰ LEFT JOIN ਵੱਜੋਂ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਕੁਏਰੀਆਂ ਤੁਰੰਤ ਸਕੈਨ ਕਰਨ ਵਿੱਚ ਸੌਖੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

RIGHT JOIN ਕਦੋਂ ਫ਼ਾਇਦੇਮੰਦ ਹੋ ਸਕਦੀ ਹੈ

RIGHT JOIN ਉਸ ਸਮੇਂ ਸਹਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਮੌਜੂਦਾ ਲੰਬੀ ਕੁਏਰੀ ਸੋਧ ਰਹੇ ਹੋ ਅਤੇ ਪਤਾ ਲੱਗੇ ਕਿ “ਹਰ-ਰੱਖਣ ਵਾਲੀ” ਟੇਬਲ ਹੁਣ ਸੱਜੀ ਵੱਲ ਹੈ। ਸਾਰੇ ਕੁਏਰੀ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਥਾਂ, ਇੱਕ JOIN ਨੂੰ RIGHT JOIN 'ਤੇ ਬਦਲਣਾ ਇੱਕ ਤੇਜ਼ ਅਤੇ ਘੱਟ-ਖ਼ਤਰੇ ਵਾਲਾ ਬਦਲਾਵ ਹੋ ਸਕਦਾ ਹੈ।

FULL OUTER JOIN: ਦੋਨੋਂ ਟੇਬਲਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਰੱਖੋ

ਬਣਾਓ ਅਤੇ ਕਮਾਓ

Koder.ai ਨਾਲ ਜੋ ਤੁਸੀਂ ਬਣਾਇਆ ਉਹ ਸਾਂਝਾ ਕਰਕੇ ਜਾਂ ਦੂਜਿਆਂ ਨੂੰ ਨਿਯੋਤਾ ਦੇ ਕੇ ਕ੍ਰੈਡਿਟ ਕਮਾਓ।

ਕ੍ਰੈਡਿਟ ਪ੍ਰਾਪਤ ਕਰੋ

FULL OUTER JOIN ਦੋਹਾਂ ਟੇਬਲਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਜੇ ਰਿਕਾਰਡ join key 'ਤੇ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਸੰਯੁਕਤ ਕਤਾਰ ਮਿਲਦੀ ਹੈ (ਜਿਵੇਂ INNER JOIN)।
ਜੇ ਕੇਵਲ ਖੱਬੇ ਟੇਬਲ ਵਿੱਚ ਰਿਕਾਰਡ ਹੈ, ਤਾਂ ਉਹ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ — ਸੱਜੇ ਟੇਬਲ ਦੇ ਕਾਲਮ NULL ਨਾਲ।
ਜੇ ਕੇਵਲ ਸੱਜੇ ਟੇਬਲ ਵਿੱਚ ਰਿਕਾਰਡ ਹੈ, ਤਾਂ ਵੀ ਉਹ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ — ਖੱਬੇ ਟੇਬਲ ਦੇ ਕਾਲਮ NULL ਨਾਲ।

ਇਹ ਕਦੋਂ ਲਾਭਦਾਇਕ ਹੈ

ਇੱਕ ਕਲਾਸਿਕ ਬਿਜ਼ਨਸ ਕੇਸ orders vs. payments ਦੀ reconciliation ਹੈ:

ਤੁਸੀਂ paid orders ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ (ਮੈਚ)
unpaid orders (order ਹੈ, payment ਗਾਇਬ)
stray payments (payment ਹੈ, ਪਰ ਕੋਈ order ਨਹੀਂ — ਡੇਟਾ ਦੀ ਗਲਤੀ, ਰਿਫ਼ੰਡ, ਗਲਤ ਰੈਫਰੈਂਸ ਵਗੈਰਾ)

ਉਦਾਹਰਨ:

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount
FROM orders o
FULL OUTER JOIN payments p
  ON p.order_id = o.order_id;

ਡੇਟਾਬੇਸ ਸਹਾਇਤਾ (ਕੌਣ ਸਿੱਧਾ ਚਲਾ ਸਕਦਾ ਹੈ)

FULL OUTER JOIN PostgreSQL, SQL Server, ਅਤੇ Oracle ਵਿੱਚ ਸਪੋਰਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਇਹ MySQL ਅਤੇ SQLite ਵਿੱਚ ਉਪਲੱਧ ਨਹੀਂ ਹੈ (ਤੁਹਾਨੂੰ ਵਰਕਅਰਾਉਂਡ ਦੀ ਲੋੜ ਪਵੇਗੀ)।

ਪੋਰਟੇਬਲ ਵਿਕਲਪ: LEFT JOIN ਅਤੇ RIGHT JOIN ਨੂੰ UNION ਕਰੋ

ਜੇ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਵਿੱਚ FULL OUTER JOIN ਦੀ ਸਹਾਇਤਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਏਸ ਤਰੀਕੇ ਨਾਲ ਨੱਕਲ ਕਰ ਸਕਦੇ ਹੋ:

orders ਦੇ ਸਾਰੇ ਰਿਕਾਰਡ (ਜਦੋਂ-ਮੁਕਾਬਲਾ payments ਨਾਲ ਉਪਲੱਧ ਹੋਵੇ ਤਦ) ਅਤੇ
payments ਦੇ ਉਹ ਰਿਕਾਰਡ ਜੋ orders ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ

ਇੱਕ ਆਮ ਨਮੂਨਾ:

SELECT o.order_id, o.customer_id, p.payment_id, p.amount
FROM orders o
LEFT JOIN payments p
  ON p.order_id = o.order_id

UNION

SELECT o.order_id, o.customer_id, p.payment_id, p.amount
FROM orders o
RIGHT JOIN payments p
  ON p.order_id = o.order_id;

ਟਿਪ: ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਪਾਸੇ NULLs ਵੇਖਦੇ ਹੋ, ਉਹ ਸਿਗਨਲ ਹੁੰਦਾ ਹੈ ਕਿ ਰਿਕਾਰਡ ਦੂਜੇ ਪਾਸੇ “ਗਾਇਬ” ਸੀ — ਬਿਲਕੁਲ ਉਹੀ ਜੋ ਤੁਸੀਂ ਆਡੀਟ ਅਤੇ reconciliation ਲਈ ਚਾਹੁੰਦੇ ਹੋ।

CROSS JOIN: ਸਾਰੇ ਸੰਯੋਜਨ ਬਣਾਓ (ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤੋ)

CROSS JOIN ਦੋ ਟੇਬਲਾਂ ਦੀਆਂ ਹਰ ਸੰਭਵ ਜੋੜੀਆਂ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਜੇ ਟੇਬਲ A ਕੋਲ 3 ਕਤਾਰਾਂ ਹਨ ਤੇ ਟੇਬਲ B ਕੋਲ 4, ਤਾਂ ਨਤੀਜਾ 3 × 4 = 12 ਕਤਾਰਾਂ ਵਾਲਾ ਹੋਵੇਗਾ। ਇਸਨੂੰ Cartesian product ਵੀ ਕਹਿੰਦੇ ਹਨ।

ਇਹ ਡਰਾਉਣਾ ਲੱਗ ਸਕਦਾ ਹੈ—ਅਤੇ ਕਈ ਵਾਰੀ ਹੁੰਦਾ ਵੀ ਹੈ—ਪਰ ਇਹ ਓਦੋਂ ਬਹੁਤ ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਜਾਣ-ਬੁਝ ਕੇ combinations ਬਣਾਉਣੇ ਹੋ।

ਇੱਕ ਛੋਟਾ, ਸੁਰੱਖਿਅਤ ਉਦਾਹਰਨ: sizes × colors (SKU ਬਣਾਉਣਾ)

ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਉਤਪਾਦ ਵਿਕਲਪ ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ ਵਿੱਚ ਰੱਖਦੇ ਹੋ:

sizes: S, M, L
colors: Red, Blue

CROSS JOIN ਸਾਰੀਆਂ ਸੰਭਵ variants ਬਣਾਉ ਸਕਦਾ ਹੈ (SKU ਬਣਾਉਣ, ਕੈਟਾਲੌਗ ਪ੍ਰੀਬਿਲਡ ਕਰਨ ਜਾਂ ਟੈਸਟਿੰਗ ਲਈ):

SELECT
  s.size,
  c.color
FROM sizes AS s
CROSS JOIN colors AS c;

ਨਤੀਜਾ (3 × 2 = 6 ਕਤਾਰਾਂ):

S / Red
S / Blue
M / Red
M / Blue
L / Red
L / Blue

ਵੱਡੀ ਚੇਤਾਵਨੀ: ਨਤੀਜੇ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦੇ ਹਨ

ਕਿਉਂਕਿ ਕਤਾਰਾਂ ਗੁਣਾ ਹੁੰਦੀਆਂ ਹਨ, CROSS JOIN ਤੇਜ਼ੀ ਨਾਲ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ:

10,000 customers × 50 products = 500,000 rows
100,000 × 100,000 = 10,000,000,000 rows

ਇਹ ਕੁਏਰੀਆਂ ਨੂੰ ਸੁਸਤ ਕਰ ਸਕਦਾ ਹੈ, ਮੈਮੋਰੀ overwhelm ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਵਰਤੋਂਯੋਗ ਨਤੀਜਾ ਨਹੀਂ ਦਿੰਦਾ। ਜੇ ਤੁਹਾਨੂੰ combinations ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਇਨਪੁਟ ਟੇਬਲਾਂ ਛੋਟੀਆਂ ਰੱਖੋ ਅਤੇ ਲਿਮਿਟ ਜਾਂ ਫਿਲਟਰਜ਼ ਲਾਉਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।

SELF JOIN: ਟੇਬਲ ਨੂੰ ਆਪਣੇ ਆਪ ਨਾਲ ਜੋੜੋ

ਰਿਪੋਰਟਿੰਗ ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ

ਚੈਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੀ ਟੇਬਲਾਂ ਨੂੰ ਲਿਸਟ ਪੇਜਾਂ, ਫਿਲਟਰ ਅਤੇ ਰਿਪੋਰਟਾਂ ਵਿੱਚ ਬਦਲੋ।

ਬਿਲਡਿੰਗ ਸ਼ੁਰੂ ਕਰੋ

SELF JOIN ਉਹੀ ਹੈ ਜੋ ਲੱਗਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਟੇਬਲ ਨੂੰ ਆਪਣੇ ਆਪ ਨਾਲ ਜੋੜਦੇ ਹੋ। ਇਹ ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਕਤਾਰ ਦੂਜੇ ਕਤਾਰ ਨਾਲ ਸੰਬੰਧਿਤ ਹੋਵੇ—ਸਭ ਤੋਂ ਆਮ ਹੈ employees ਅਤੇ ਉਹਨਾਂ ਦੇ managers ਵਾਲੀ ਹਾਇਰਾਰਕੀ।

aliases ਦੀ ਲੋੜ (ਅਤੇ ਇਹ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ)

ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕੋ ਟੇਬਲ ਦੋ ਵਾਰ ਵਰਤ ਰਹੇ ਹੋ, ਹਰ “ਕਾਪੀ” ਨੂੰ ਇੱਕ ਵੱਖਰਾ alias ਦੇਣਾ ਜਰੂਰੀ ਹੁੰਦਾ ਹੈ। aliases ਕੁਏਰੀ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ SQL ਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਸ ਸਾਈਡ ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹੋ।

ਆਮ ਤਰੀਕਾ:

e ਕਰਮਚਾਰੀ ਲਈ
m ਮੈਨੇਜਰ ਲਈ

ਵਰਤੋਂਯੋਗ ਉਦਾਹਰਨ: ਕਰਮਚਾਰੀ ਅਤੇ ਉਹਨਾਂ ਦੇ ਮੈਨੇਜਰ

ਸੋਚੋ ਇੱਕ employees ਟੇਬਲ ਹੈ:

id
name
manager_id (ਕਿਸੇ ਹੋਰ ਕਰਮਚਾਰੀ ਦੇ id ਨੂੰ ਦਰਸਾਉਂਦਾ)

ਹਰ ਕਰਮਚਾਰੀ ਨਾਲ ਉਹਨਾਂ ਦੇ ਮੈਨੇਜਰ ਦਾ ਨਾਮ ਲਿਸਟ ਕਰਨ ਲਈ:

SELECT
  e.id,
  e.name AS employee_name,
  m.name AS manager_name
FROM employees e
LEFT JOIN employees m
  ON e.manager_id = m.id;

top-level ਕਰਮਚਾਰੀ (NULL manager_id) ਨੂੰ ਸੰਭਾਲਣਾ

ਧਿਆਨ ਦੇਓ ਕਿ ਕੁਐਰੀ LEFT JOIN ਵਰਤਦੀ ਹੈ, ਨਾ ਕਿ INNER JOIN। ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਕੁਝ ਕਰਮਚਾਰੀ (ਜਿਵੇਂ CEO) ਦਾ ਕੋਈ ਮੈਨੇਜਰ ਨਹੀਂ ਹੁੰਦਾ। ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ manager_id ਆਮ ਤੌਰ ਤੇ NULL ਹੁੰਦਾ ਹੈ, ਅਤੇ LEFT JOIN ਕਰਮਚਾਰੀ ਦੀ ਕਤਾਰ ਨੂੰ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਕਿ manager_name NULL ਦਿਖਾਉਂਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ INNER JOIN ਵਰਤਦੇ ਤਾਂ ਉਹ top-level ਕਰਮਚਾਰੀ ਨਤੀਜੇ ਵਿੱਚੋਂ ਲਾਪਤਾ ਹੋ ਜਾਣਗੇ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦਾ ਕੋਈ matching manager row ਨਹੀਂ ਹੁੰਦਾ।

JOIN ਸ਼ਰਤਾਂ: ON vs USING (ਅਤੇ ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ)

JOIN "ਆਪਣੇ ਆਪ" ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਦੋ ਟੇਬਲ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ—ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਣਾ ਪੈਂਦਾ ਹੈ। ਉਹ ਸੰਬੰਧ join ਸ਼ਰਤ ਵਿੱਚ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ JOIN ਦੇ ਬਗਲ ਵਿੱਚ ਹੀ ਰਹਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਟੇਬਲਾਂ ਕਿਵੇਂ ਮਿਲਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਅੰਤੀਮ ਨਤੀਜੇ ਨੂੰ ਕਿਵੇਂ ਛਾਂਟਣਾ ਹੈ।

`ON`: ਸਭ ਤੋਂ ਲਚਕੀਲਾ (ਅਤੇ ਸਭ ਤੋਂ ਆਮ)

ON ਉਪਯੋਗ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੀ ਕੰਟਰੋਲ ਚਾਹੁੰਦੇ ਹੋ—ਵੱਖ-ਵੱਖ ਕਾਲਮ ਨਾਮ, ਇੱਕ ਤੋਂ ਵੱਧ ਸ਼ਰਤਾਂ, ਜਾਂ ਹੋਰ ਕਦਮ।

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.created_at
FROM customers AS c
INNER JOIN orders AS o
  ON o.customer_id = c.customer_id;

ON ਓਥੇ ਵੀ ਵਰਤੋਂ ਜਿੱਥੇ ਤੁਸੀਂ ਕਈ-ਕਾਲਮ_MATCH ਜਾਂ ਹੋਰ ਜਟਿਲ ਮੈਚਿੰਗ ਲਾਜਿਕ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

`USING`: ਛੋਟਾ, ਪਰ ਸਿਰਫ਼ ਇੱਕੋ-ਨਾਂ ਦੇ ਕਾਲਮਾਂ ਲਈ

ਕੁਝ ਡੇਟਾਬੇਸ (ਜਿਵੇਂ PostgreSQL ਅਤੇ MySQL) USING ਨੂੰ ਸਹਿਯੋਗ ਕਰਦੇ ਹਨ। ਇਹ ਉਸ ਵੇਲੇ ਇੱਕ ਸੁਖਾਦ ਸੰਖੇਪ ਹੈ ਜਦੋਂ ਦੋਹਾਂ ਟੇਬਲਾਂ ਵਿੱਚ ਇੱਕੋ ਨਾਂ ਵਾਲਾ ਕਾਲਮ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਉਸ 'ਤੇ JOIN ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

SELECT
  customer_id,
  name,
  order_id
FROM customers
JOIN orders
USING (customer_id);

ਇਕ ਲਾਭ ਇਹ ਹੈ ਕਿ USING ਆਮ ਤੌਰ 'ਤੇ ਆਊਟਪੁੱਟ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ customer_id ਕਾਲਮ ਦਿੰਦਾ ਹੈ (ਦੋ ਨਕਲਾਂ ਦੀ ਥਾਂ)।

ambiguous column names ਤੋਂ ਬਚੋ: JOINs ਵਿੱਚ ਹਮੇਸ਼ਾਂ qualify ਕਰੋ

ਜਦੋਂ ਤੁਸੀਂ tables join ਕਰਦੇ ਹੋ, ਕਈ ਵਾਰੀ ਕਾਲਮ ਨਾਮ ਇੱਕੋ-ਝੈ ਹੁੰਦੇ ਹਨ (id, created_at, status). ਜੇ ਤੁਸੀਂ SELECT id ਲਿਖਦੇ ਹੋ, ਡੇਟਾਬੇਸ “ambiguous column” error ਦੇ ਸਕਦਾ ਹੈ—ਜਾਂ ਤੁਹਾਨੂੰ ਗਲਤ id ਮਿਲ ਸਕਦਾ ਹੈ।

ਸਪਸ਼ਟਤਾ ਲਈ table prefixes (ਜਾਂ aliases) ਵਰਤੋ:

SELECT c.customer_id, o.order_id
FROM customers AS c
JOIN orders AS o
  ON o.customer_id = c.customer_id;

JOIN ਕੀਤੀਆਂ ਕੁਏਰੀਆਂ ਵਿੱਚ `SELECT *` ਛੱਡੋ

ਜੋੜੀਆਂ ਕੁਏਰੀਆਂ ਵਿੱਚ SELECT * ਤੇਜ਼ੀ ਨਾਲ ਗੰਦੀਆਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਬੇਕਾਰ ਕਾਲਮ ਖਿੱਚ ਲੈਂਦੇ ਹੋ, duplicate ਨਾਮਾਂ ਦਾ ਖਤਰਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੇਖਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕੁਏਰੀ ਦਾ ਮਕਸਦ ਕੀ ਹੈ।

ਇਸ ਦੀ ਬਜਾਏ, ਜਰੂਰੀ ਕਾਲਮਾਂ ਹੀ ਚੁਣੋ। ਨਤੀਜਾ ਸਾਫ਼, ਰੱਖ-ਰਖਾਵ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਅਕਸਰ ਜ਼ਿਆਦਾ ਕੁਸ਼ਲ ਹੁੰਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਟੇਬਲ ਚੌੜੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

JOIN ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰਨਾ: WHERE vs ON

ਜਦੋਂ ਤੁਸੀਂ ਟੇਬਲ join ਕਰਦੇ ਹੋ, WHERE ਅਤੇ ON ਦੋਹਾਂ "ਫਿਲਟਰ" ਕਰਦੇ ਹਨ, ਪਰ ਵੱਖ-ਵੱਖ ਸਮੇਂ ਤੇ।

ON ਊਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ JOIN ਦੌਰਾਨ ਕਿਹੜੀਆਂ ਕਤਾਰਾਂ ਮੈਚ ਹੋਣਗੀਆਂ।
WHERE ਆਖ਼ਰੀ ਨਤੀਜੇ ਨੂੰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ ਜਦੋਂ JOIN ਛ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।

ਉਹ ਸਮੇਂ-ਫਰਕ ਉਹ ਕਾਰਨ ਹੈ ਕਿ ਲੋਕ ਅਕਸਰ ਇੱਕ LEFT JOIN ਨੂੰ ਗਲਤੀ ਨਾਲ INNER JOIN ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।

ਕਿਵੇਂ WHERE ਇੱਕ LEFT JOIN ਨੂੰ ਗਲਤੀ ਨਾਲ ਤਬਦੀਲ ਕਰ ਸਕਦਾ ਹੈ

ਕਹੋ ਕਿ ਤੁਸੀਂ ਸਾਰੇ ਗਾਹਕ ਚਾਹੁੰਦੇ ਹੋ, ਭਾਵੇਂ ਉਹਨਾਂ ਕੋਲ ਹਾਲੀਆ ਭੁਗਤਾਨ ਕੀਤੇ ਗਏ ਆਰਡਰ ਨਾ ਹੋਣ।

SELECT c.customer_id, c.name, o.order_id, o.status, o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
WHERE o.status = 'PAID'
  AND o.order_date >= DATE '2025-01-01';

ਸਮੱਸਿਆ: ਜਿਨ੍ਹਾਂ ਗਾਹਕਾਂ ਦੇ ਕੋਈ matching order ਨਹੀਂ ਹਨ, ਉਹਨਾਂ ਲਈ o.status ਅਤੇ o.order_date NULL ਹੁੰਦੇ ਹਨ। WHERE ਸ਼ਰਤ ਉਹਨਾਂ ਕਤਾਰਾਂ ਨੂੰ ਨਕਾਰ ਦਿੰਦੀ ਹੈ—ਤਾਂ ਤੁਹਾਡਾ LEFT JOIN ਅਸਲ ਵਿੱਚ INNER JOIN ਵਰਗਾ ਵਿਹਾਰ ਕਰਨ ਲੱਗਦਾ ਹੈ।

unmatched rows ਨੂੰ ਰੱਖਣ ਲਈ join-ਸਬੰਧੀ ਸ਼ਰਤਾਂ ਨੂੰ ON ਵਿੱਚ ਰੱਖੋ

SELECT c.customer_id, c.name, o.order_id, o.status, o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
 AND o.status = 'PAID'
 AND o.order_date >= DATE '2025-01-01';

ਹੁਣ ਉਹ ਗਾਹਕ ਜਿਨ੍ਹਾਂ ਦੇ ਪਾਸ qualifying orders ਨਹੀਂ, ਉਹ ਫਿਰ ਵੀ (NULL order ਕਾਲਮਾਂ ਨਾਲ) ਦਿਖਦੇ ਹਨ—ਜੋ ਆਮ ਤੌਰ 'ਤੇ LEFT JOIN ਦਾ ਮਕਸਦ ਹੁੰਦਾ ਹੈ।

ਤੁਰੰਤ ਚੈੱਕਲਿਸਟ: ON vs WHERE ਵਿੱਚ ਕੀ ਰੱਖਣਾ ਹੈ?

ON ਵਿੱਚ ਉਹ ਸ਼ਰਤ ਰੱਖੋ ਜੋ ਇਹ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜੀਆਂ ਸੱਜੀ-ਟੇਬਲ ਕਤਾਰਾਂ ਮੈਚ ਹੋ ਸਕਦੀਆਂ ਹਨ (status/date/type ਵਗੈਰਾ ਜੋੜੀ ਟੇਬਲ 'ਤੇ)।
WHERE ਵਿੱਚ ਉਹ ਸ਼ਰਤ ਰੱਖੋ ਜੋ ਇਹ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਆਖ਼ਰੀ ਨਤੀਜੇ ਵਿੱਚ ਕਿਹੜੀਆਂ ਕਤਾਰਾਂ ਰੱਖਣੀਆਂ ਹਨ (ਖੱਬੇ ਟੇਬਲ 'ਤੇ ਫਿਲਟਰ, ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਸਚਮੁਚ ਇੱਕ ਮੈਚ ਲੋੜੀਂਦਾ ਹੋ)।
ਜੇ ਤੁਹਾਨੂੰ “ਸਾਰੇ ਖੱਬੇ ਰਿਕਾਰਡ ਰੱਖਣੇ ਨੇ ਪਰ ਸੱਜੇ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ ਹੈ,” ਤਾਂ LEFT JOIN + ON ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
ਜੇ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ "ਸਿਰਫ਼ ਮੈਚ ਹੋਏ ਰਿਕਾਰਡ" ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ INNER JOIN (ਜਾਂ ਸਪਸ਼ਟ WHERE o.order_id IS NOT NULL) ਵਰਤੋ।

ਡੁਪਲੀਕੇਟ ਕਤਾਰਾਂ ਅਤੇ ਬਹੁ-ਤਹਿ (many-to-many) ਜਾਲੜੀਆਂ ਤੋਂ ਬਚਣਾ

ਕੁਏਰੀ ਤੋਂ ਫੀਚਰ ਤੱਕ ਜਾਓ

ਐਂਡਪੌਇੰਟ ਅਤੇ UI scaffold ਕਰੋ, ਫਿਰ ਆਪਣੀ SQL 'ਤੇ ਪੂਰੀ ਕਾਬੂ ਰੱਖੋ।

ਕੋਡ ਜਨਰੇਟ ਕਰੋ

JOINs ਸਿਰਫ ਕਾਲਮ ਨਹੀਂ ਜੋੜਦੇ—ਉਹ ਕਤਾਰਾਂ ਨੂੰ ਵੀ ਗੁਣਾ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ ਹੁੰਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਸੰਖਿਆਵਾਂ ਅਚਾਨਕ ਦੋਹਰੀਆਂ (ਜਾਂ ਹੋਰ) ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਇਹ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ।

ਕਤਾਰਾਂ ਕਿਉਂ ਗੁਣਾ ਹੁੰਦੀਆਂ ਹਨ

ਇੱਕ join ਹਰ ਜੋੜੇ ਮੈਚ ਲਈ ਇੱਕ ਆਉਟਪੁਟ ਰਿਕਾਰਡ ਦਿੰਦਾ ਹੈ।

One-to-many: ਇੱਕ ਗਾਹਕ ਦੇ ਬਹੁਤ ਸਾਰੇ ਆਰਡਰ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ customers ਨੂੰ orders ਨਾਲ join ਕਰੋ, ਤਾਂ ਹਰ ਆਰਡਰ ਲਈ ਉਹ ਗਾਹਕ ਵੱਖਰੀ ਵਾਰੀ ਆਵੇਗਾ।
Many-to-many (ਅਸਲ ਟ੍ਰੈਪ): ਜੇ ਤੁਸੀਂ orders ਨੂੰ payments ਨਾਲ join ਕਰਦੇ ਹੋ ਅਤੇ ਹਰ order ਦੇ ਇਕ ਤੋਂ ਵੱਧ payments ਹਨ, ਤਾਂ ਇੱਕ order ਲਈ ਕਈ ਕਤਾਰਾਂ ਆ ਸਕਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਹੋਰ “many” ਟੇਬਲ (ਜਿਵੇਂ order_items) ਨੂੰ ਵੀ join ਕਰੋਗੇ, ਤਾਂ payments × items ਵਰਗਾ multiplication ਪ੍ਰਭਾਵ ਬਣ ਸਕਦਾ ਹੈ।

ਭੇਟ ਤੋਂ ਪਹਿਲਾਂ aggregate ਕਰੋ

ਜੇ ਤੁਹਾਡਾ ਟੀਚਾ “ਇੱਕ ਕਤਾਰ ਪ੍ਰਤੀ ਗਾਹਕ” ਜਾਂ “ਇੱਕ ਕਤਾਰ ਪ੍ਰਤੀ ਆਰਡਰ” ਹੈ, ਤਾਂ ਪਹਿਲਾਂ "many" ਪਾਸੇ ਨੂੰ summarize ਕਰੋ, ਫਿਰ join ਕਰੋ।

-- One row per order from payments
WITH payment_totals AS (
  SELECT
    order_id,
    SUM(amount) AS total_paid,
    COUNT(*)   AS payment_count
  FROM payments
  GROUP BY order_id
)
SELECT
  o.order_id,
  o.customer_id,
  COALESCE(pt.total_paid, 0) AS total_paid,
  COALESCE(pt.payment_count, 0) AS payment_count
FROM orders o
LEFT JOIN payment_totals pt
  ON pt.order_id = o.order_id;

ਇਸ ਨਾਲ join ਦਾ "shape" ਪੇਸ਼ਗੀ ਤਰ੍ਹਾਂ ਰਹਿੰਦਾ ਹੈ: ਇੱਕ order ਦੀ ਇਕ ਕਤਾਰ ਹੀ ਇੱਕ order ਰਿਹਾ।

DISTINCT ਅੰਤਿਮ ਉਪਾਯ ਹੈ

SELECT DISTINCT duplicates ਨੂੰ ਦੁਰੁਸਤ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਅਸਲੀ ਸਮੱਸਿਆ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ:

ਇਹ legitimate rows ਨੂੰ ਲੋਕੀ ਤਰੀਕੇ ਨਾਲ ਹਟਾ ਸਕਦਾ ਹੈ।
ਇਹ ਮਿਸ਼ਰੁਕ join condition (ਜਿਵੇਂ composite key ਦੇ ਹਿੱਸੇ ਦੀ ਕਮੀ) ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ।
ਇਹ totals (ਖ਼ਾਸ ਕਰਕੇ sums ਅਤੇ counts) ਨੂੰ ਗਲਤ ਕਰ ਸਕਦਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਾਣਦੇ ਹੋ ਕਿ duplicates ਬਿਲਕੁਲ ਅਣਚਾਹੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦਾ ਕਾਰਨ ਸਮਝਦੇ ਹੋ ਤਾਂ ਹੀ ਇਸ ਨੂੰ ਵਰਤੋ।

ਛੋਟੀ ਸੁਰੱਖਿਆ ਜਾਂਚ: ਗਿਣਤੀਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਨਤੀਜਿਆਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ row counts ਦੀ ਤੁਲਨਾ ਕਰੋ:

ਆਪਣੇ ਮੁੱਖ ਟੇਬਲ (ਉਦਾਹਰਨ ਲਈ orders) ਵਿੱਚ ਕਤਾਰਾਂ ਦੀ ਗਿਣਤੀ ਕਰੋ।
JOIN ਤੋਂ ਬਾਅਦ ਕਤਾਰਾਂ ਦੀ ਗਿਣਤੀ ਕਰੋ।
ਜੇ ਨੰਬਰ ਅਚਾਨਕ ਵਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਦੇਖੋ ਕਿ ਕਿਹੜੇ ਕੀਆ ਕਿਸੇ key ਨੇ ਲਗਾਤਾਰ matches ਦਿੱਤੇ ਹਨ ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਤੁਸੀਂ pre-aggregation ਜਾਂ ਵੱਖਰਾ join ਰਸਤਾ ਚਾਹੁੰਦੇ ਹੋ।

ਪਰਫਾਰਮੈਂਸ ਬੁਨਿਆਦੀਆਂ ਅਤੇ ਇੱਕ ਛੋਟਾ JOIN ਚੀਟਸ਼ੀਟ

JOINs ਨੂੰ ਅਕਸਰ “ਢੀਲੀ ਕੁਏਰੀ” ਲਈ ਦੋਸ਼ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਅਸਲ ਕਾਰਨ ਅਕਸਰ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਡੇਟਾ ਦੀ ਕਿੰਨੀ ਮਾਤਰਾ ਨੂੰ ਜੋੜਨ ਦੀ ਬੇਨਤੀ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਉਹ ਕਿੰਨੀ ਅਸਾਨੀ ਨਾਲ ਇਸਨੂੰ ਲੱਭ ਸਕਦਾ ਹੈ।

Indexing (ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ) ਅਤੇ JOINs ਵਿੱਚ ਇਹ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ

ਇੱਕ index ਨੂੰ ਇਕ ਕਿਤਾਬ ਦੀ table of contents ਦੀ ਤਰ੍ਹਾਂ ਸੋਚੋ। ਬਿਨਾ index ਦੇ, ਡੇਟਾਬੇਸ ਨੂੰ JOIN ਸ਼ਰਤ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਸਕੈਨ ਕਰਨੀ ਪੈ ਸਕਦੀਆਂ ਹਨ। join key (ਜਿਵੇਂ customers.customer_id ਅਤੇ orders.customer_id) 'ਤੇ index ਹੋਣ ਨਾਲ ਡੇਟਾਬੇਸ ਤੇਜ਼ੀ ਨਾਲ ਸੰਬੰਧਿਤ ਕਤਾਰਾਂ 'ਤੇ jump ਕਰ ਸਕਦਾ ਹੈ।

ਤੁਹਾਨੂੰ ਅੰਦਰੂਨੀ ਵੇਰਵੇ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ—ਜੇ ਕੋਈ ਕਾਲਮ ਅਕਸਰ JOIN ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਉਹ ਇੱਕ ਚੰਗਾ ਉਮੀਦਵਾਰ ਹੈ ਕਿ ਉਸ 'ਤੇ index ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸਥਿਰ keys 'ਤੇ JOIN ਕਰੋ (ਨਾਂ ਜਾਂ emails ਨਹੀਂ)

ਜਿੰਨ੍ਹਾਂ ਕਾਲਮਾਂ ਨੂੰ stable, unique identifiers ਬਣਾਇਆ ਗਿਆ ਹੈ ਉਨ੍ਹਾਂ 'ਤੇ JOIN ਕਰੋ:

ਚੰਗਾ: customers.customer_id = orders.customer_id
ਖਤਰਨਾਕ: customers.email = orders.email ਜਾਂ customers.name = orders.name

ਨਾਂ ਬਦਲ ਸਕਦੇ ਹਨ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ। IDs ਮੁਕੰਮਲ ਮਿਲਾਪ ਲਈ ਤਿਆਰ ਹੁੰਦੇ ਹਨ ਅਤੇ ਆਮ ਤੌਰ ਤੇ indexed ਹੁੰਦੇ ਹਨ।

ਕੰਮ ਨੂੰ ਪਹਿਲਾਂ ਘਟਾਓ

ਦੋ ਆਦਤਾਂ JOINs ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਯੋਗ ਤੇਜ਼ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ:

ਘੱਟ ਕਾਲਮ ਚੁਣੋ। multiple tables join ਕਰਨ 'ਤੇ SELECT * ਤੋਂ ਬਚੋ—ਵਾਧੂ ਕਾਲਮ ਮੇਮੋਰੀ ਅਤੇ ਨੈੱਟਵਰਕ ਬਰ੍ਹਾਉਂਦੇ ਹਨ।
JOIN ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ JOIN ਦੌਰਾਨ rows ਨੂੰ ਸੀਮਤ ਕਰੋ। ਜਿੰਨਾ ਜਲਦੀ ਸੰਭਵ ਹੋਵੇ ਫਿਲਟਰ ਕਰੋ।

ਉਦਾਹਰਨ: ਪਹਿਲਾਂ orders ਨੂੰ ਸੀਮਤ ਕਰੋ, ਫਿਰ join:

SELECT c.customer_id, c.name, o.order_id, o.created_at
FROM customers c
JOIN (
  SELECT order_id, customer_id, created_at
  FROM orders
  WHERE created_at >= DATE '2025-01-01'
) o
  ON o.customer_id = c.customer_id;

ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਕੁਏਰੀਆਂ 'ਤੇ ਐਪ ਬਣਾਉਣ ਦੌਰਾਨ ਦੁਹਰਾਈ ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, PostgreSQL ਦੇ ਨਾਲ ਇੱਕ ਰਿਪੋਰਟਿੰਗ ਪੇਜ਼ ਬਣਾਉਣਾ), ਤਾਂ Tools ਜਿਵੇਂ Koder.ai scaffold ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ—schema, endpoints, UI—ਜਦਕਿ ਤੁਸੀਂ JOIN ਲਾਜ਼ਮਤਾਂ 'ਤੇ ਪੂਰਾ ਕਬੂ ਰੱਖਦੇ ਹੋ ਜੋ ਸਹੀਤ ਨਤੀਜੇ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ।

ਛੋਟਾ JOIN ਚੀਟਸ਼ੀਟ

INNER JOIN → ਸਿਰਫ਼ ਉਹ ਕਤਾਰਾਂ ਜੋ ਦੋਹਾਂ ਟੇਬਲਾਂ ਵਿੱਚ ਮੈਚ ਕਰਦੀਆਂ ਹਨ
LEFT JOIN → ਖੱਬੇ ਟੇਬਲ ਦੀਆਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ, ਨਾਲ ਹੀ ਸੱਜੇ ਤੋਂ ਮੈਚ (ਗੈਰ-ਮੈਚ NULL ਬਣਦੇ)
RIGHT JOIN → ਸੱਜੇ ਟੇਬਲ ਦੀਆਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ, ਨਾਲ ਹੀ ਖੱਬੇ ਤੋਂ ਮੈਚ (NULL ਜਦੋਂ ਗਾਇਬ)
FULL OUTER JOIN → ਦੋਹਾਂ ਟੇਬਲਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ; ਮੈਚ ਮਰਜ ਹੁੰਦੇ ਹਨ, ਗੈਰ-ਮੈਚ NULL ਵੇਖਾਉਂਦੇ ਹਨ
CROSS JOIN → ਕਤਾਰਾਂ ਦੇ ਹਰ ਸੰਯੋਜਨ (ਸਾਈਜ਼ ਗੁਣਾ ਹੁੰਦੀ), ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤੋ
SELF JOIN → ਇੱਕ ਟੇਬਲ ਨੂੰ ਆਪਣੇ ਆਪ ਨਾਲ join ਕਰੋ (ਹਾਇਰਾਰਕੀ ਅਤੇ ਤੁਲਨਾਵਾਂ ਲਈ ਉਪਯੋਗ)

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

ਸਧੇ ਅੰਗ ਵਿੱਚ SQL JOIN ਕੀ ਹੈ?

SQL JOIN ਦੋ (ਜਾਂ ਵੱਧ) ਟੇਬਲਾਂ ਦੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਇੱਕ ਨਤੀਜੇ ਸੈੱਟ ਵਿੱਚ ਜੋੜਦਾ ਹੈ, ਜਿੱਥੇ ਸੰਬੰਧਤ ਕਾਲਮ ਮਿਲਦੇ ਹਨ—ਅਕਸਰ ਇੱਕ primary key ਨੂੰ foreign key ਨਾਲ ਜੋੜ ਕੇ (ਉਦਾਹਰਨ ਵਜੋਂ customers.customer_id = orders.customer_id). ਇਹ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ normalized ਟੇਬਲਾਂ ਨੂੰ ਰਿਪੋਰਟਾਂ, ਆਡੀਟਾਂ ਜਾਂ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰਦੇ ਹੋ।

ਮੈਨੂੰ INNER JOIN ਕਦੋਂ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ?

ਜਦੋਂ ਤੁਸੀਂ ਸਿਰਫ ਉਹੀ ਕਤਾਰਾਂ ਚਾਹੁੰਦੇ ਹੋ ਜਿੱਥੇ ਦੋਨੋਂ ਟੇਬਲਾਂ ਵਿੱਚ ਰਿਸ਼ਤਾ ਮੌਜੂਦ ਹੋਵੇ, ਤਾਂ INNER JOIN ਵਰਤੋਂ।

ਗਾਹਕ ਜਿਨ੍ਹਾਂ ਨੇ ਆਰਡਰ ਨਹੀਂ ਦਿੱਤਾ, ਉਹ ਨਤੀਜੇ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੇ।
ਉਹ ਆਰਡਰ ਜੋ ਕਿਸੇ ਗਾਇਬ ਗਾਹਕ ਦੀ ਹੋਂਦੇ ਹਨ, ਉਹ ਵੀ ਨਹੀਂ ਆਉਂਦੇ।

ਇਹ “ਪੱਕੇ ਰਿਸ਼ਤਿਆਂ” ਲਈ ਵਧੀਆ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਸਿਰਫ ਉਹ ਗਾਹਕ ਲਿਸਟ ਕਰਨਾ ਜਿਨ੍ਹਾਂ ਨੇ ਅਸਲ ਵਿੱਚ ਆਰਡਰ ਕੀਤੇ।

ਮੈਂ ਉਹ ਕਤਾਰਾਂ ਕਿਵੇਂ ਲੱਭਾਂ ਜੋ ਕਿਸੇ ਹੋਰ ਟੇਬਲ ਵਿੱਚ ਮੈਚ ਨਹੀਂ ਹੁੰਦੀਆਂ?

ਜਦੋਂ ਤੁਹਾਨੂੰ ਆਪਣੀ ਮੁੱਖ (ਲੈਫਟ) ਟੇਬਲ ਦੀ ਸਾਰੀ ਲਿਸਟ ਚਾਹੀਦੀ ਹੋਵੇ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਦਾ ਡੇਟਾ ਜੇ ਮਿਲੇ ਤਾਂ ਜੋੜਨਾ ਹੋਵੇ, ਤਾਂ LEFT JOIN ਵਰਤੋਂ।

“ਕੋਨ-ਕੋਣ ਸੇ ਗਾਹਕ ਨੇ ਕਦੇ ਆਰਡਰ ਨਹੀਂ ਦਿੱਤਾ?” ਲੱਭਣ ਲਈ, JOIN ਕਰਕੇ ਫਿਰ ਸੱਜੇ ਪਾਸੇ ਨੂੰ NULL ਲਈ ਫਿਲਟਰ ਕਰੋ:

 c.customer_id, c.name
 customers c
  orders o  o.customer_id  c.customer_id
 o.order_id  ;

ਕੀ ਮੈਨੂੰ ਵਾਕਈ RIGHT JOIN ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਕਿਸ ਤਰ੍ਹਾਂ LEFT JOIN ਨਾਲ ਇਸ ਨੂੰ ਬਦਲ ਦਿਆਂ?

RIGHT JOIN ਸੱਜੀ ਟੇਬਲ ਦੀ ਹਰ ਕਤਾਰ ਨੂੰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਜੇ ਮੈਚ ਨਹੀਂ ਮਿਲਦਾ ਤਾਂ ਖੱਬੇ ਟੇਬਲ ਦੇ ਕਾਲਮ NULL ਹੁੰਦੇ ਹਨ। ਇਹ ਅਕਸਰ ਪਠਨ ਦੇ ਤਰੀਕੇ ਕਾਰਨ ਟਾਲਿਆ ਜਾਂਦਾ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਇਸ ਨੂੰ LEFT JOIN ਨਾਲ ਬਦਲ ਸਕਦੇ ਹੋ ਬੱਸ ਟੇਬਲ ਦੇ ਹੁਕਮ ਨੂੰ ਉਲਟ ਕੇ:

FROM payments p
LEFT JOIN orders o  o.order_id  p.order_id

FULL OUTER JOIN ਸਭ ਤੋਂ ਵਧੀਆ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ?

FULL OUTER JOIN ਉਨ੍ਹਾਂ ਮਾਮਲਿਆਂ ਲਈ ਵਧੀਆ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ reconciliations ਕਰ ਰਹੇ ਹੋ: ਤੁਹਾਨੂੰ ਮਿਲਦੇ ਹੋਏ ਰਿਕਾਰਡ, ਸਿਰਫ ਖੱਬੇ-ਪਾਸੇ ਵਾਲੇ ਰਿਕਾਰਡ ਅਤੇ ਸਿਰਫ ਸੱਜੇ-ਪਾਸੇ ਵਾਲੇ ਰਿਕਾਰਡ ਸਭ ਇੱਕ ਨਤੀਜੇ ਵਿੱਚ ਚਾਹੀਦੇ ਹਨ।

ਇਹ audits ਲਈ ਧੰਨਵਾਦੀ ਹੈ, ਜਿਵੇਂ “ਆਰਡਰ ਬਿਨਾਂ ਭੁਗਤਾਨ” ਅਤੇ “ਭੁਗਤਾਨ ਬਿਨਾਂ ਆਰਡਰ” ਨੂੰ ਇੱਕੱਠੇ ਵੇਖਣਾ।

ਜੇ ਮੇਰੇ ਡੇਟਾਬੇਸ ਵਿੱਚ FULL OUTER JOIN ਸਪੋਰਟ ਨਹੀਂ ਹੁੰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ?

ਕੁਝ ਡੇਟਾਬੇਸ (ਖਾਸ ਕਰਕੇ MySQL ਅਤੇ SQLite) ਸਿੱਧੇ FULL OUTER JOIN ਨੂੰ ਸਹਾਇਤਾ ਨਹੀਂ ਦਿੰਦੇ। ਇੱਕ ਆਮ ਵਰਕਅਰਾਉਂਡ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਦੋ ਕੁਏਰੀਆਂ ਨੂੰ ਜੋੜੋ:

orders LEFT JOIN payments
ਅਤੇ payments ਪਾਸੇ ਜਿਹੜੇ ਰਿਕਾਰਡ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਉਹਨਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ

ਅਕਸਰ ਇਹ UNION (ਜਾਂ UNION ALL ਨਾਲ ਧਿਆਨ) ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦੋਹਾਂ “left-only” ਅਤੇ “right-only” ਰਿਕਾਰਡ ਰੱਖ ਸਕੋ।

CROSS JOIN ਕੀ ਹੈ, ਅਤੇ ਇਹ ਅਸਲ ਵਿੱਚ ਕਦੋਂ ਲਾਭਦਾਇਕ ਹੈ?

CROSS JOIN ਦੋ ਟੇਬਲਾਂ ਦੇ ਹਰ ਸੰਭਵ ਜੋੜੇ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ (Cartesian product). ਇਹ ਸੈਨੇਰਿਓ ਜਨਰੇਸ਼ਨ ਜਾਂ ਛੋਟੀ ਇਨਪੁਟ ਲਈ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ—ਉਦਾਹਰਨ ਲਈ sizes × colors।

ਸਾਵਧਾਨ ਰਹੋ: ਕਿਉਂਕਿ ਕਤਾਰਾਂ ਗੁਣਾ ਹੋ ਕੇ ਵਧਦੀਆਂ ਹਨ, ਨਤੀਜਾ ਤੇਜ਼ੀ ਨਾਲ ਵੱਡਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਕੁਏਰੀ ਨੂੰ ਸਲੋ ਕਰ ਸਕਦਾ ਹੈ।

SELF JOIN ਕੀ ਹੈ, ਅਤੇ ਮੈਨੂੰ ਟੇਬਲ aliases ਦੀ ਲੋੜ ਕਿਉਂ ਪੈਂਦੀ ਹੈ?

Self join ਉਹ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਟੇਬਲ ਨੂੰ ਆਪਣੇ ਆਪ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿਰਿਆਸ਼ੀਲ ਸੰਬੰਧ ਜਿਹੜੇ ਟੇਬਲ ਦੇ ਅੰਦਰ ਹੋਣ (ਉਦਾਹਰਣ ਲਈ employee → manager)।

ਤੁਸੀਂ ਦੋਨਾ “ਕਾਪੀਆਂ” ਲਈ alias ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਤਾਂ ਕਿ ਸਪਸ਼ਟ ਹੋਵੇ ਕਿ ਤੁਹਾਡੀ ਕੋਰੀ ਕਿਹੜੇ ਸਾਈਡ ਦਾ ਹਵਾਲਾ ਦੇ ਰਹੀ ਹੈ:

FROM employees e
LEFT JOIN employees m
  ON e.manager_id = m.id

JOINs ਲਈ ON ਅਤੇ WHERE ਵਿੱਚ ਫਿਲਟਰ ਕਰਨ ਵਿੱਚ ਕੀ ਫ਼ਰਕ ਹੈ?

ON ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ JOIN ਦੌਰਾਨ ਕਿਹੜੀਆਂ ਕਤਾਰਾਂ ਮੈਚ ਹੋਣਗੀਆਂ; WHERE ਆਖਿਰਕਾਰ ਨਤੀਜੇ 'ਤੇ ਫਿਲਟਰ ਲਗਾਂਦਾ ਹੈ।

LEFT JOIN ਦੇ ਨਾਲ, ਜੇ ਤੁਸੀਂ ਸੱਜੇ ਪਾਸੇ ਦੀਆਂ ਸ਼ਰਤਾਂ WHERE ਵਿੱਚ ਰੱਖਦੇ ਹੋ ਤਾਂ ਉਹ NULL ਵਾਲੀਆਂ (ਮੈਚ ਨਾ ਹੋਈਆਂ) ਕਤਾਰਾਂ ਨੂੰ ਹਟਾ ਦੇਵੇਗੀ ਅਤੇLEFT JOIN ਅਸਰਤੌਰ 'ਤੇ INNER JOIN ਬਣ ਜਾਵੇਗੀ।

ਜੇ ਤੁਸੀਂ ਸਾਰੇ ਖੱਬੇ ਰਿਕਾਰਡ ਰੱਖਣੇ ਹਨ ਪਰ ਸੱਜੇ ਪਾਸੇ ਦੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ ਹੈ, ਤਾਂ ਉਹ ਸ਼ਰਤਾਂ ਵਿੱਚ ਰੱਖੋ।

joins ਡੁਪਲੀਕੇਟ ਕਤਾਰਾਂ ਕਿਉਂ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਡਬਲ-ਕਾਉਂਟਿੰਗ ਕਿਵੇਂ ਰੋਕੀਏ?

ਜਦੋਂ ਰਿਲੇਸ਼ਨ one-to-many ਜਾਂ many-to-many ਹੋਵੇ ਤਾਂ joins ਕਤਾਰਾਂ ਨੂੰ ਗੁਣਾ ਕਰ ਦਿੰਦੇ ਹਨ—ਇਸ ਲਈ ਤੁਸੀਂ ਡਬਲ-ਕਾਉਂਟਿੰਗ ਦੇ ਫਾਇਲ ਹੋ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਆਰਡਰ ਦੇ ਦੋ ਭੁਗਤਾਨ ਹੋਣ 'ਤੇ orders ਨੂੰ payments ਨਾਲ join ਕਰਨ ਤੇ ਉਹ ਆਰਡਰ ਦੋ ਵਾਰੀ ਆਵੇਗਾ।

ਇਸ ਨੂੰ ਰੋਕਣ ਲਈ, “many” ਪਾਸੇ ਨੂੰ ਪਹਿਲਾਂ aggregate ਕਰੋ (ਜਿਵੇਂ SUM(amount) grouped by order_id) ਅਤੇ ਫਿਰ join ਕਰੋ, ਤਾਂ ਜੋ ਇੱਕ ਆਰਡਰ ਇੱਕ ਸਤਰ ਹੀ ਰੱਖੇ।

DISTINCT ਅੰਤਿਮ ਵਿਕਲਪ ਵਜੋਂ ਵਰਤੋ ਕਿਉਂਕਿ ਇਹ ਅਸਲੀ ਸਮੱਸਿਆ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ ਅਤੇ ਟੋਟਲਾਂ ਨੂੰ ਗਲਤ ਕਰ ਸਕਦਾ ਹੈ।

ON

6 SQL JOINs ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਣੇ ਚਾਹੀਦੇ (ਸਰਲ, ਸਪਸ਼ਟ ਉਦਾਹਰਨਾਂ) | Koder.ai