Stored procedures என்றால் என்ன, அவற்றை எப்போது பயன்படுத்த வேண்டும்?

Question

Accepted Answer

ஒரு **stored procedure** என்பது டேட்டாபேஸில் சேமிக்கப்பட்டு பெயரால் இயக்கப்படும் SQL statements (மற்றும் procedural தர்க்கம்) இன் தொகுப்பாகும். இது பயன்பாட்டுக் குறியீட்டுக்குப் பதிலாக தர்க்கத்தை டேட்டாபேஸுக்கு *உள்ளே* இயக்குகிறது. அவை உண்மையான நன்மைகளைக் கொண்டுள்ளன ஆனால் குறிப்பிடத்தக்க trade-offs ஐயும் கொண்டுள்ளன, எனவே அவற்றை எப்போது பயன்படுத்த வேண்டும் என்பது ஒரு உண்மையான வடிவமைப்பு முடிவாகும்.

## ஒரு 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 தர்க்கத்தை (variables, conditionals, loops, error handling) ஒரு பெயரிடப்பட்ட, மீள்பயன்படுத்தக்கூடிய டேட்டாபேஸ் routine ஆக இணைக்கிறது. Functions ஒத்தவை ஆனால் ஒரு மதிப்பைத் திருப்பித் தருகின்றன.

## சாத்தியமான நன்மைகள்

```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
```

## குறிப்பிடத்தக்க trade-offs (ஏன் பலர் இன்று அவற்றைத் தவிர்க்கிறார்கள்)

```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 ஐப் புரிந்துகொள்வது — அவற்றின் trade-offs உட்பட — மதிப்புமிக்க அறிவாகும், ஏனெனில் அவை உண்மையான நன்மைகள் மற்றும் உண்மையான குறைபாடுகளுடன் ஒரு உண்மையான கட்டமைப்புத் தேர்வைக் குறிக்கின்றன, மற்றும் அவற்றை *எப்போது* பயன்படுத்த வேண்டும் (மற்றும் எப்போது வேண்டாம்) என்பதை அறிவது முதிர்ந்த நுண்ணறிவைப் பிரதிபலிக்கிறது.

Stored procedures **செயல்திறன் நன்மைகளை** (பல படி தர்க்கத்தை டேட்டாபேஸுக்குள் இயக்குவது network round-trips ஐத் தவிர்க்கிறது), குறைந்த network traffic, clients முழுவதும் மீள்பயன்பாடு, பாதுகாப்பு (table access இல்லாமல் execute ஐ வழங்குதல்), மற்றும் மையப்படுத்தப்பட்ட ஒருமைப்பாடு ஆகியவற்றை வழங்க முடியும் — இவை அவற்றை செயல்திறன்-முக்கியமான தரவு-தீவிர செயல்பாடுகள், batch செயலாக்கம், மற்றும் பல பயன்பாடுகள் முழுவதும் டேட்டாபேஸ் மட்டத்தில் கட்டாயப்படுத்தப்பட வேண்டிய தர்க்கத்துக்கு ஏற்றதாக ஆக்குகின்றன.

இருப்பினும், **குறிப்பிடத்தக்க trade-offs** ஐப் புரிந்துகொள்வது அதேபோல் முக்கியம் மற்றும் நவீன நடைமுறையைப் பிரதிபலிக்கிறது: business logic ஐ டேட்டாபேஸில் வைப்பது அதை version-control செய்வதையும், test செய்வதையும், பராமரிப்பதையும் கடினமாக்குகிறது (app மற்றும் டேட்டாபேஸ் இடையே தர்க்கத்தைப் பிரித்தல்), ஒரு குறிப்பிட்ட டேட்டாபேஸின் procedural மொழியுடன் (PL/pgSQL, T-SQL, PL/SQL — portability ஐக் குறைத்தல்) உங்களைக் கட்டுகிறது, debug செய்வது கடினம், மற்றும் டேட்டாபேஸ் tier க்கு (பெரும்பாலும் scale செய்ய மிகக் கடினமானது) சுமையைச் சேர்க்கிறது.

இந்தக் காரணங்களுக்காக, **நவீன பயன்பாட்டு மேம்பாடு பெரும்பாலும் business logic ஐ பயன்பாட்டு அடுக்கில் வைப்பதை** (testable, portable, version-controlled) stored procedures க்குப் பதிலாக விரும்புகிறது.

முக்கிய நுண்ணறிவு **அவற்றை எப்போது பயன்படுத்த வேண்டும் என்ற நுண்ணறிவு** — குறிப்பிட்ட செயல்திறன்-முக்கியமான அல்லது DB-மட்ட-கட்டாயப்படுத்தல் தேவைகளுக்கு ஏற்றது, ஆனால் பொதுவாக business logic க்கு இயல்பாகத் தவிர்க்கப்படுகிறது.

Stored procedures பல அமைப்புகளில் பொதுவாக இருப்பதால் (குறிப்பாக enterprise/legacy), மற்றும் அவற்றின் நன்மைகள் மற்றும் trade-offs இரண்டையும் (மற்றும் பயன்பாட்டு-அடுக்கு தர்க்கத்தை நோக்கிய நவீன சாய்வையும்) புரிந்துகொள்வது சரியான கட்டமைப்பு முடிவுகளை எடுக்க உதவுவதால், stored procedures ஐப் புரிந்துகொள்வது டேட்டாபேஸ்-பக்க vs பயன்பாட்டு-பக்க தர்க்கத்தை எடைபோடும் திறனை வெளிப்படுத்தும் மதிப்புமிக்க senior-நிலை அறிவாகும் — ஒரு அர்த்தமுள்ள வடிவமைப்பு கருத்தாகவும் கட்டமைப்பு முதிர்ச்சியைப் பிரதிபலிக்கும் ஒரு தலைப்பாகவும் உள்ளது.