← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

🛡️ Parameters विरुद्ध string जोडणे — धडा 13

⏮️ parameterised queries आधी

Apps वापरकर्त्याचे input SQL strings मध्ये चिकटवत आणि quotes हाताने escape करण्याचा प्रयत्न करत; एक चुकलेली केस आणि टाइप केलेले ' OR '1'='1 संपूर्ण tables वाचू किंवा पुसू शकत असे — दोन दशके SQL injection OWASP यादीच्या जवळजवळ शिखरावर होते.

✅ फायदे

  • input एक value म्हणून पाठवला जातो, कधीच SQL म्हणून वाचला जात नाही — bugs चा संपूर्ण प्रकारच नाहीसा होतो
  • database query plan पुन्हा वापरू शकतो
  • प्रत्येक driver आणि ORM हे support करतो

❌ तोटे

  • table आणि column ची नावे parameters होऊ शकत नाहीत — त्यांच्यासाठी allow-list वापरा
  • developers 'dynamic' queries साठी अजूनही strings जोडतात आणि bug परत आणतात

👍 वापरा जेव्हा

  • ज्या query मध्ये वापरकर्त्याने, फाइलने किंवा दुसऱ्या service ने दिलेले काहीही आहे, ती प्रत्येक query
  • नेहमी — न वापरण्याचे performance चे कोणतेही कारण नाही

👎 दोनदा विचार करा जेव्हा

  • हाताने केलेले escaping हेच संरक्षण म्हणून
  • allow-list शिवाय input मधून identifiers string-format करणे

📡 Synchronous विरुद्ध asynchronous replication — धडा 16

⏮️ streaming replication आधी

standby म्हणजे दुसऱ्या machine वर restore केलेला कालच्या रात्रीचा backup; failover म्हणजे एक दिवसाचा data गमावणे आणि तासन्‌तास बंद राहणे.

✅ फायदे

  • async: commits जलद राहतात; replicas reads सांभाळतात
  • sync: promote केलेल्या replica कडे प्रत्येक commit असतो (RPO = 0)

❌ तोटे

  • async: failover वर writes चे शेवटचे काही सेकंद हरवू शकतात; वाचणाऱ्यांना भूतकाळ दिसू शकतो
  • sync: प्रत्येक commit एका network फेरीची वाट पाहतो; आजारी replica writes अडवू शकते

👍 वापरा जेव्हा

  • read replicas आणि cross-region प्रतींसाठी async
  • commit झालेले payment हरवणे अजिबात चालणार नसेल तेव्हा जवळच्या एका standby ला sync (किंवा semi-sync)

👎 दोनदा विचार करा जेव्हा

  • प्रत्येक commit वर दूरच्या region ला sync
  • async replica मधून स्वतःचा ताजा write वाचणे

🧑‍🍳 Stored procedures विरुद्ध app code — धडा 14

⏮️ stored procedures आधी (आणि सोबत)

व्यवसायाचे नियम फक्त एका application मध्ये होते; दुसरे app, data दुरुस्ती किंवा एखादी झटपट script थेट tables मध्ये लिहायची आणि database मध्ये कोणीच न ठेवलेला नियम मोडायची.

✅ फायदे

  • प्रत्येक app आणि script साठी एकच नियम — data च्या शेजारीच तपासला जातो
  • एका round trip मध्ये, एका transaction मध्ये अनेक statements
  • tables न देता EXECUTE देता येते (धडा 13)

❌ तोटे

  • app च्या code review, tests आणि debugger पासून logic लपलेले
  • procedures ची versioning आणि deploy साठी migrations लागतात (धडा 08)
  • vendor ची खास भाषा (PL/pgSQL, T-SQL) — database बदलणे कठीण
  • SQLite मध्ये हे अजिबात नाही

👍 वापरा जेव्हा

  • प्रत्येक लिहिणाऱ्याने पाळायचे नियम (मर्यादा, audit rows, पैशांची हालचाल)
  • अनेक rows ला हात लावणारी batch कामे

👎 दोनदा विचार करा जेव्हा

  • बहुतेक business logic — app मध्ये ठेवा, tested आणि reviewed
  • procedures एकमेकांना बोलावणाऱ्या लांब साखळ्या ज्या कोणालाच वाचता येत नाहीत

🏛️ OLTP विरुद्ध OLAP — धडा 18

⏮️ वेगळ्या analytics stores आधी

महिनाअखेरचे reports चालू database वरच चालत; report पूर्ण होई, पण दर वेळी कार्यालय वीस मिनिटे ठप्प होई.

✅ फायदे

  • OLTP खोली अनेक लहान reads आणि writes साठी जलद राहते
  • OLAP (columnar warehouse) अब्जावधी rows वरच्या बेरजा काही सेकंदांत देतो
  • ETL किंवा CDC तुम्ही निवडलेल्या वेळापत्रकानुसार data हलवतो

❌ तोटे

  • चालवायला आणि एकसारख्या ठेवायला दोन systems
  • reports थोडे जुने असतात (कालची रात्र, किंवा CDC सह काही सेकंद)

👍 वापरा जेव्हा

  • dashboards, महिनाअखेरचे reports, data science
  • लाखो rows पुन्हा पुन्हा scan करणारे काहीही

👎 दोनदा विचार करा जेव्हा

  • एक indexed query ने काम होणारे छोटेसे app
  • warehouse मध्ये एकेका row चे edits — तो मोठ्या reads साठी बनलेला आहे

🗄️ Relational (SQL) विरुद्ध NoSQL — धडे 02, 11

⏮️ Relational डेटाबेसआधी (1970 चे दशक) आणि NoSQL लाटेआधी (2009)

नोंदी ॲप-विशिष्ट रचनेच्या फाइल्समध्ये राहायच्या; प्रत्येक प्रोग्राम स्वतःचे format वाचायचा आणि नव्या कोडशिवाय कोणीच नवा प्रश्न विचारू शकत नव्हता. Relational डेटाबेसनी प्रश्न SQL मध्ये आणले. मग web scale मुळे काही टीम्सनी वेगासाठी constraints फेकून दिले — आणि अनेकांनी नंतर ते परत विकत घेतले.

✅ फायदे

  • constraints मुळे चुकीचा data अशक्य होतो, नुसता कमी संभाव्य नाही
  • JOINs आणि transactions नव्या कोडशिवाय नव्या प्रश्नांना उत्तर देतात
  • एक प्रौढ खोली (Postgres) बहुतेक ॲप्सना वर्षानुवर्षे पुरते

❌ तोटे

  • schema बदलांना migrations लागतात (धडा 08)
  • JOIN-भारी queries ना scale वर काळजी लागते
  • आडवे write scaling कठीण आहे (धडा 10)

👍 वापरा जेव्हा

  • नाती, पैसा किंवा नियम असलेले काहीही — default
  • अहवाल आणि तात्कालिक प्रश्न

👎 दोनदा विचार करा जेव्हा

  • relational आकार वाईट उत्तर देतो असा प्रश्न: अर्थाने-जवळचे, graph उड्या, अब्जावधी appends
  • मोजमापाशिवाय 'scale साठी NoSQL' — नेहमीचा पश्चात्ताप

🧩 Normalise विरुद्ध denormalise — धडा 05

⏮️ Normal forms आधी

एक मोठा spreadsheet-सारखा table: शिक्षकाचा फोन 30 ओळींत कॉपी, 29 मध्ये अद्ययावत, आणि वर्षभर चुकीचा राहिलेला अहवाल.

✅ फायदे

  • एक तथ्य, एक जागा: बदल एकमेकांशी विसंगत होऊ शकत नाहीत
  • छोट्या ओळी, स्वच्छ constraints
  • schema हेच क्षेत्राचे दस्तऐवज

❌ तोटे

  • प्रत्येक screen ला जास्त JOINs
  • वाचन-भारी पानांना अनेक queries लागू शकतात

👍 वापरा जेव्हा

  • सत्याचा स्रोत; संपादित होणारे काहीही
  • लवकर — नंतर denormalise करणे उलट्यापेक्षा खूप सोपे आहे

👎 दोनदा विचार करा जेव्हा

  • गरम वाचन-मार्ग जिथे मोजलेला JOIN अडथळा आहे — मूल्य कॉपी करा आणि ते खरे ठेवणारा नियम स्वतःकडे घ्या
  • पुन्हा बांधल्या जाणाऱ्या, संपादित न होणाऱ्या analytics tables

🗂️ Indexes — धडा 06

⏮️ कार्ड कॅटलॉगआधी

प्रत्येक प्रश्न प्रत्येक ओळ वाचायचा. 5 ओळींना ठीक; 200,000 ओळींच्या attendance table ला प्रत्येक शोधासाठी पूर्ण scan.

✅ फायदे

  • SCAN ऐवजी SEARCH: milliseconds वरून microseconds
  • बोनस म्हणून uniqueness (UNIQUE) लागू होते
  • ORDER BY आणि JOIN स्वस्त होतात

❌ तोटे

  • प्रत्येक write प्रत्येक index अद्ययावत करते
  • जागा; आणि चुकीचा column क्रम कोणालाच मदत करत नाही
  • छोट्या tables वर planner index दुर्लक्षित करू शकतो

👍 वापरा जेव्हा

  • जे गाळता, join करता आणि क्रमाने लावता ते columns; foreign keys
  • मोठ्या table वर EXPLAIN ने SCAN दाखवल्यानंतर

👎 दोनदा विचार करा जेव्हा

  • 'सगळ्यावर index' — writes रांगतात
  • मोजण्याआधी — 5 ओळींच्या table ला कॅटलॉग नको

🔒 Isolation levels — धडा 07

⏮️ Isolation आधी

दोन कारकून एकाच वेळी एकच नोंदवही लिहिली की फाटलेल्या ओळी तयार व्हायच्या; उपाय होता 'फाइल फक्त एकच प्रोग्राम वापरेल' — दोन प्रोग्राम येईपर्यंत.

✅ फायदे

  • read committed: वेगवान, dirty reads नाहीत — शहाणा default
  • serializable: जणू एका वेळी एकच कारकून — अचूकता

❌ तोटे

  • कडक पातळ्या जास्त वाट पाहतात आणि जास्त deadlock करतात
  • सैल पातळ्यांवर सूक्ष्म विसंगती (phantoms, lost updates)

👍 वापरा जेव्हा

  • पैसा आणि counters: serializable किंवा स्पष्ट locks (SELECT … FOR UPDATE)
  • बाकी सगळे: read committed + छोटे transactions

👎 दोनदा विचार करा जेव्हा

  • वापरकर्ता विचार करत असताना locks धरून ठेवणारे लांब transactions
  • तुमच्या ORM चे default serializable आहे असे गृहीत धरणे — ते जवळपास कधीच नसते

🏗️ Expand/contract migrations — धडा 08

⏮️ आवृत्ती असलेल्या migrations आधी

कोणीतरी शुक्रवारी production खोलीवर हाताने ALTER TABLE चालवले; schema काय आहे हे कोणीच सांगू शकत नव्हते, आणि rollback म्हणजे स्मरणशक्ती.

✅ फायदे

  • git मधले schema: पुनरावलोकनयोग्य, पुनरावृत्तीयोग्य, तालीम करण्याजोगे
  • expand → migrate → contract नाव बदलतानाही शाळा उघडी ठेवते
  • नोंदवही (schema_migrations) मुळे 'कुठे काय चालले' ही एक query होते

❌ तोटे

  • शिस्त: एक migration = एक बदल, नेहमी उलट करता येणारा किंवा तालीम केलेला
  • मोठ्या tables वरचे backfills तुकड्यांत करावे लागतात
  • काही काळ कोडच्या दोन आवृत्त्या एकत्र चालतात

👍 वापरा जेव्हा

  • प्रत्येक schema बदल, अपवाद नाही
  • downtime शिवाय नावे आणि प्रकार बदलणे

👎 दोनदा विचार करा जेव्हा

  • चालू table वर एका पायरीत नाव बदलणे — जुना कोड तत्काळ मोडतो
  • तपासलेल्या backup शिवाय विनाशकारी migrations (धडा 09)

📈 Read replicas विरुद्ध sharding — धडा 10

⏮️ Replicas आधी

एकच मशीन; ते भरले की उत्तर होते मोठे मशीन — आणखी मोठे मशीन उरेपर्यंत.

✅ फायदे

  • replicas: स्वस्त read scaling आणि तयार standby
  • sharding: writes आणि data खोल्यांत विभागलेला — चालणारा शेवटचा उपाय

❌ तोटे

  • replication lag: वाचणाऱ्याला भूतकाळ दिसू शकतो
  • sharding JOINs आणि cross-shard transactions मोडते; पुन्हा shard करणे हा वेगळा प्रकल्प

👍 वापरा जेव्हा

  • वाचन-भारी ॲप्स आणि अहवालांसाठी replicas
  • एक primary खरोखर writes पेलू शकत नाही तेव्हा sharding — pool, cache, indexes, मोठे मशीन नंतर

👎 दोनदा विचार करा जेव्हा

  • replica वरून स्वतःचेच लिहिलेले वाचणे (lag चे आश्चर्य)
  • ब्लॉगने सांगितले म्हणून 50 GB डेटाबेस shard करणे

☁️ Managed (RDS) विरुद्ध self-hosted — धडे 09, 10

⏮️ managed डेटाबेसच्या आधी

प्रत्येक टीम स्वतःचा Postgres चालवायची: patching, backups, failover scripts, आणि WAL कुठे जातो हे माहीत असलेली एकच व्यक्ती.

✅ फायदे

  • backups, patches, Multi-AZ failover, monitoring — भाड्याने
  • replicas आणि point-in-time restore म्हणजे checkboxes

❌ तोटे

  • तासाला जास्त खर्च; कमी नियंत्रण
  • lock-in चे प्रकार; नंतर स्थलांतराचे श्रम
  • schema, queries, indexes आणि तालमी तरीही तुमच्याच

👍 वापरा जेव्हा

  • बहुतेक टीम्स, बहुतेक वेळा (AWS शाळा L17)
  • WAL माहीत असलेली एकच व्यक्ती सोडून गेल्यावर

👎 दोनदा विचार करा जेव्हा

  • सेवा नाकारते अशी विचित्र extensions किंवा टोकाचे tuning
  • लॅपटॉपची लॅब — SQLite मोफत आणि प्रामाणिक आहे