stored procedures کیا ہیں اور آپ انہیں کب استعمال کریں؟

Question

Accepted Answer

ایک **stored procedure** SQL statements اور procedural logic کا ایک مجموعہ ہے جو ڈیٹابیس میں محفوظ رہتا ہے اور نام سے چلایا جاتا ہے۔ یہ application code کی بجائے ڈیٹابیس *اندر* logic چلاتا ہے۔ ان کے اصل فوائد ہیں لیکن نمایاں نقصانات بھی ہیں، اس لیے انہیں کب استعمال کریں یہ ایک حقیقی ڈیزائن فیصلہ ہے۔

## ایک stored procedure

```sql
-- define a procedure that encapsulates logic in the database
CREATE PROCEDURE transfer_funds(from_id INT, to_id INT, amount DECIMAL)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_id;
  UPDATE accounts SET balance = balance + amount WHERE id = to_id;
  -- can include logic: conditionals, loops, error handling, transactions
END;
$$;

CALL transfer_funds(1, 2, 100);   -- execute by name
```

ایک stored procedure SQL اور procedural logic (variables، conditionals، loops، error handling) کو ایک named، reusable ڈیٹابیس routine میں بندھتا ہے۔ Functions ملتی جلتی ہیں لیکن ایک value واپس کرتے ہیں۔

## ممکنہ فوائل

```text
✓ Performance — runs IN the database (no round-trips for multi-step logic); precompiled
✓ Reduced network traffic — one call vs many queries from the app
✓ Reusability — shared logic callable from multiple applications/clients
✓ Security — grant EXECUTE on a procedure without granting table access; reduces
  injection surface (parameterized)
✓ Consistency — centralize critical logic so all clients use the same implementation
```

## اہم نقصانات (یہ آج کل بہت سے لوگ انہیں کیوں نہ استعمال کریں)

```text
✗ Business logic in the DATABASE → harder to version-control, test, and maintain
  (logic split between app code and the database)
✗ Database-specific (PL/pgSQL vs T-SQL vs PL/SQL) → less portable, vendor lock-in
✗ Harder to debug than application code; weaker tooling
✗ Scaling — the database is often the hardest tier to scale; pushing logic there
  can increase its load
✗ Modern apps often prefer logic in the application layer (testable, portable, versioned)
```

## انہیں کب استعمال کریں

```text
✓ Performance-critical data-intensive operations (heavy multi-step DB logic, batch jobs)
✓ Logic that MUST be enforced at the DB level across multiple clients
✓ Reducing round-trips for operations involving many queries
✗ AVOID putting general business logic in procedures by default — modern practice
  usually favors the application layer (better testing, versioning, portability)
```

## اہمیت

Stored procedures کو سمجھنا — ان کے نقصانات سمیت — قیمتی علم ہے کیونکہ یہ ایک حقیقی معماری انتخاب کی نمائندگی کرتے ہیں جس کے اصل فوائل اور نقصانات ہیں، اور یہ جاننا *کہ* انہیں کب استعمال کریں (اور کب نہیں) پکی بالغ سوچ ظاہر کرتا ہے۔

Stored procedures **کارکردگی کے فوائل** (multi-step logic کو ڈیٹابیس کے اندر چلانا network round-trips سے بچتا ہے)، نیٹ ورک ٹریفک میں کمی، مختلف clients میں دوبارہ استعمال، سیکیورٹی (table access کے بغیر execute دینا)، اور مرکزی مطابقت فراہم کر سکتے ہیں — انہیں کارکردگی سے اہم ڈیٹا سے متعلق operations، batch processing، اور logic کے لیے موزوں بناتے ہوئے جو ڈیٹابیس کی سطح پر متعدد applications میں لازمی ہونی چاہیے۔

تاہم، **اہم نقصانات** کو سمجھنا برابر اہم ہے اور جدید طریقہ کار کو ظاہر کرتا ہے: ڈیٹابیس میں business logic ڈالنا اسے version-control، test، اور maintain کرنا مشکل بناتا ہے (logic کو app اور ڈیٹابیس میں تقسیم کرتا ہے)، آپ کو کسی خاص ڈیٹابیس کی procedural language سے باندھتا ہے (PL/pgSQL، T-SQL، PL/SQL — portability کو کم کرتے ہیں)، debug کرنا مشکل ہے، اور ڈیٹابیس tier پر load شامل کرتا ہے (اکثر scale کرنے میں سب سے مشکل)۔

ان وجوہات سے، **جدید application development اکثر business logic کو application layer میں رکھنے کو ترجیح دیتا ہے** (قابل test، portable، version-controlled) بجائے stored procedures میں۔

اہم بصیرت **انہیں کب استعمال کریں اس کا فیصلہ** ہے — مخصوص کارکردگی سے اہم یا DB-level-enforcement ضروریات کے لیے موزوں، لیکن عام طور پر business logic کے لیے ڈیفالٹ کے طور پر نہیں استعمال کیے جاتے۔

چونکہ stored procedures بہت سے systems میں عام ہیں (خاص طور پر enterprise/legacy)، اور چونکہ ان کے فوائل اور ان کے نقصانات دونوں کو سمجھنا (اور جدید application-layer logic کی طرف رجحان) قابل فہم معماری فیصلوں کو ممکن بناتا ہے، stored procedures کو سمجھنا قیمتی senior-level علم ہے جو database-side بمقابلہ application-side logic کا وزن کرنے کی صلاحیت کو ظاہر کرتا ہے — ایک معنی خیز ڈیزائن غور و فکر اور معماری بالغیت کو ظاہر کرنے والا موضوع۔