Database क्या है? ऐप बनाने वालों के लिए एक गाइड
Database जानकारी का एक व्यवस्थित भंडार है जिसमें ऐप लिखता है और जिससे पढ़ता है — उसके users, orders, bookings, messages। ब्राउज़र टैब में रखी जानकारी के विपरीत, database का डेटा refresh या restart के बाद भी रहता है, और ऐप इस्तेमाल करने वाला हर व्यक्ति एक ही records देखता है। ज़्यादातर databases डेटा को tables में व्यवस्थित करते हैं, कुछ-कुछ spreadsheet की sheets जैसे, पर सख्त नियमों के साथ जो डेटा को सुसंगत रखते हैं।
AI से बनाते समय यह क्यों मायने रखता है
AI से बनाने वालों के लिए सबसे आम झटका एक ऐसा ऐप है जो पूरा दिखता है, पर सब कुछ भूल जाता है। आप एक customer जोड़ते हैं, page refresh करते हैं, और वह गायब हो जाता है। इसका आम तौर पर मतलब होता है कि ऐप डेटा को browser की memory में रख रहा था, database में नहीं।
Database वह जगह भी है जहाँ आपके कई सबसे महत्वपूर्ण फ़ैसले रहते हैं, चाहे आप इसे समझें या न समझें:
- आप क्या रिकॉर्ड करते हैं। अगर आप booking का status स्टोर नहीं करते, तो आप यह नहीं दिखा सकते कि कौन सी bookings रद्द हुईं।
- चीज़ें कैसे जुड़ती हैं। क्या एक customer की कई bookings हो सकती हैं, या एक booking में कई services, यह पूरे ऐप का ढाँचा तय करता है।
- कौन क्या देख सकता है। ज़्यादातर privacy गलतियाँ इस पर होती हैं कि कोई user कौन से records पढ़ सकता है।
आपको database खुद डिज़ाइन करने की ज़रूरत नहीं है। पर बुनियादी बातें समझने से आप अपने डेटा को साफ़ तौर पर बता सकते हैं और समस्याएँ जल्दी पकड़ सकते हैं।
रोज़मर्रा की मिसाल
एक छोटे दफ़्तर की अच्छी तरह संभाली गई filing cabinet की कल्पना कीजिए।
हर drawer में एक ही तरह की चीज़ रहती है: एक drawer clients के लिए, एक appointments के लिए, एक invoices के लिए। हर drawer के अंदर हर folder एक ही फ़ॉर्मेट को मानता है, एक जैसे fields भरे हुए। हर folder का एक unique reference number है, और जब कोई invoice किसी client का होता है, तो invoice का folder उस client का number लिख देता है, उसकी पूरी फ़ाइल की फ़ोटोकॉपी नहीं बनाता।
यही relational database है। Drawers tables हैं, folders rows हैं, fields columns हैं, reference numbers primary keys हैं, और किसी दूसरे folder की ओर इशारा करने वाले नोट foreign keys हैं। एक अच्छा office manager नियम भी लागू करता है — बिना तारीख के कोई appointment नहीं, दो clients का एक ही नंबर नहीं — ठीक वैसे ही जैसे database करता है।
एक उदाहरण: एक salon booking ऐप
मान लीजिए आप AI से एक हेयर सैलून के लिए booking साइट बनवाते हैं। एक समझदार database में चार tables होंगी।
services
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | Haircut | 45 | 40.00 |
| 2 | Colour | 90 | 95.00 |
staff
| id | name | |
|---|---|---|
| 1 | Sara | sara@example.com |
| 2 | Omar | omar@example.com |
customers
| id | name | phone | |
|---|---|---|---|
| 101 | Lena Park | lena@example.com | 555-0100 |
bookings
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmed |
bookings table को देखें। यह हर booking में Lena का नाम और फ़ोन नंबर नहीं कॉपी करता; यह customer_id = 101 स्टोर करता है। अगर Lena अपना फ़ोन नंबर बदलती है, तो वह एक ही जगह बदलता है और हर booking नया नंबर दिखाती है। Relational database का मूल विचार यही है: हर तथ्य को एक बार स्टोर करें, और उससे जोड़ें।
यही ढाँचा उपयोगी सवालों के जवाब भी देता है:
- "शुक्रवार को Omar के कौन से slots खाली हैं?" — उस दिन की Omar की bookings देखें।
- "इस महीने colour appointments से कितनी कमाई हुई?" — bookings को services से जोड़ें और कीमतें जोड़ें।
- "कौन से customers 90 दिन से नहीं आए?" — customers की तुलना उनकी आख़िरी booking से करें।
आम शब्दों की व्याख्या
| शब्द | मतलब |
|---|---|
| Table | एक ही तरह के records का संग्रह, जैसे customers या bookings। |
| Row (record) | एक table का एक आइटम — एक customer, एक booking। |
| Column (field) | हर row में रहने वाली एक जानकारी, जैसे email या price। |
| Primary key | हर row के लिए एक unique ID, आम तौर पर एक नंबर या random string। |
| Foreign key | एक column जो दूसरी table की row की ओर इशारा करता है, जैसे bookings में customer_id। |
| Schema | पूरा डिज़ाइन: कौन सी tables हैं, उनके columns और वे कैसे जुड़ती हैं। |
| Query | डेटा पढ़ने या बदलने का अनुरोध, जैसे "कल की सारी bookings"। |
| SQL | Structured Query Language, relational databases को query करने की मानक भाषा। |
| Migration | Schema में सहेजा गया, दोहराया जा सकने वाला बदलाव, जैसे एक column जोड़ना। |
| Index | एक lookup संरचना जो किसी column पर खोज को तेज़ करती है, किताब के index की तरह। |
| CRUD | Create, Read, Update, Delete — वे चार बुनियादी काम जो ऐप्स डेटा के साथ करते हैं। |
| Backup | डेटा की एक कॉपी जिसे कुछ गलत होने पर वापस लाया जा सके। |
Databases के प्रकार
| प्रकार | डेटा कैसे स्टोर होता है | उदाहरण | किसके लिए अच्छा |
|---|---|---|---|
| Relational (SQL) | तय columns और उनके बीच संबंधों वाली tables | Postgres, MySQL, SQLite | ज़्यादातर business ऐप्स: bookings, stores, CRMs, SaaS |
| Document (NoSQL) | लचीले JSON-जैसे documents | MongoDB, Firestore | ऐसा डेटा जिसका आकार हर record में काफ़ी बदलता है |
| Key-value | एक key के नीचे स्टोर की गई value | Redis | कैशिंग, sessions जैसा अल्पकालिक डेटा |
ज़्यादातर चीज़ों के लिए जो कोई founder या छोटा व्यवसाय पहले बनाता है, relational database सुरक्षित डिफ़ॉल्ट है।
Database आपके ऐप में कहाँ बैठता है
विज़िटर database से सीधे बात नहीं करते। उनके browser का पेज (frontend) आपके सर्वर (backend) से डेटा माँगता है, आम तौर पर एक API के ज़रिए। सर्वर जाँचता है कि कौन पूछ रहा है और उसे अनुमति है या नहीं, फिर database को query करता है और केवल वही भेजता है जो उस व्यक्ति को देखना चाहिए।
वह बीच का कदम महत्वपूर्ण है। अगर browser database को पूरी पहुँच के साथ सीधे query कर सके, तो कोई भी developer tools खोलकर सब कुछ पढ़ सकता है।
आम गलतियाँ और गलतफ़हमियाँ
- डेटा केवल browser में रखना। Browser storage (जैसे localStorage) एक डिवाइस और एक browser पर रहता है। किसी याद किए गए filter के लिए ठीक है, orders के लिए नहीं।
- सब कुछ एक ही table में ठूँसना। एक "bookings" table जिसमें हर row में customer का नाम, फ़ोन और service की कीमत कॉपी की गई हो, जल्दी असंगत हो जाती है।
- Passwords को plain text में स्टोर करना। Passwords hash होने चाहिए, कभी पढ़े जा सकने वाले रूप में नहीं। देखें authentication क्या है।
- डेटा पर कोई नियम न होना। आवश्यक fields और uniqueness नियमों के बिना आपको बिना तारीख की bookings और डुप्लिकेट customers मिलेंगे।
- मिटाने के बारे में न सोचना। तय करें कि customer मिटाने पर उसकी bookings भी मिटेंगी, रहेंगी, या रोकी जाएँगी।
- प्रयोग के लिए production डेटा इस्तेमाल करना। जोखिम भरे बदलाव पहले किसी सुरक्षित जगह पर टेस्ट करें, और backups रखें।
- Spreadsheet को हमेशा के लिए database मान लेना। शुरुआत में spreadsheets बढ़िया हैं, पर कई एक साथ यूज़र्स और permissions में दिक्कत होती है। देखें spreadsheet को ऐप में कैसे बदलें।
अपने AI builder से क्या माँगें
- "इसे browser में नहीं, database में सेव करें। बताएँ कि आप कौन सी tables बनाएँगे।"
- "Schema को एक सरल table के रूप में दिखाएँ: हर table, उसके columns, और वे कैसे जुड़ती हैं।"
- "एक customer की कई bookings हो सकती हैं; हर booking में ठीक एक service और एक staff member हो।"
- "Customers के लिए email अनिवार्य और unique रखें।"
- "एक ही staff member की दो bookings को आपस में overlap होने से रोकें।"
- "सभी bookings केवल लॉग-इन owner पढ़ सकता है; customers केवल अपनी देख सकते हैं। यह सर्वर पर लागू करें।"
- "जब मैं कोई service मिटाऊँ, तो पिछली bookings न मिटाएँ — उसके बजाय service को inactive चिह्नित करें।"
Mythex में databases
जब आपके ऐप को डेटा सेव करना हो, तो Mythex प्रोजेक्ट में एक समर्पित Postgres database जोड़ता है — आप chat में पूछ सकते हैं ("waitlist sign-ups को database में सेव करो") या /database कमांड इस्तेमाल कर सकते हैं। Connection details अपने आप आपके ऐप को दी जाती हैं, और agent tables बनाता है। Database पाँच मिनट की निष्क्रियता के बाद सो जाता है और अगले request पर जाग जाता है; publish किए गए ऐप का उपयोग उतने समय के लिए शुल्क लेता है जितनी देर वह जागा रहा, और यह उसी credit balance से लिया जाता है जो build करने के लिए इस्तेमाल होता है। यह Free और Pro दोनों पर उपलब्ध है। विवरण के लिए database docs देखें, और ऐप टेम्पलेट्स में डेटा-आधारित शुरुआती बिंदु मिलते हैं।
सवाल
सरल शब्दों में database क्या है?
Database जानकारी का एक व्यवस्थित भंडार है जिसमें ऐप लिख सकता है और जिससे पढ़ सकता है, जैसे users, orders या bookings। ब्राउज़र टैब में रखे डेटा के विपरीत, यह डेटा refresh, restart या किसी दूसरे डिवाइस से ऐप खोलने के बाद भी मौजूद रहता है।
क्या spreadsheet एक database है?
Spreadsheet में वैसा ही डेटा रखा जा सकता है, पर वह ऐप्स के लिए नहीं बनी है। असली database हर column में क्या रखा जाए, इसके नियम लागू करता है, tables को भरोसेमंद तरीके से जोड़ता है, एक साथ कई लोगों के लिखने को संभालता है, और यह तय करता है कि कौन क्या पढ़ सकता है।
SQL और NoSQL databases में क्या फ़र्क है?
SQL (relational) databases, जैसे Postgres और MySQL, डेटा को तय columns वाली tables और उनके बीच संबंधों में रखते हैं। NoSQL databases, जैसे MongoDB, लचीले documents रखते हैं। ज़्यादातर business ऐप्स — bookings, CRMs, stores — relational मॉडल में अच्छी तरह फ़िट होते हैं।
क्या मेरे ऐप को database चाहिए?
अगर उसे लोगों के डाले हुए कुछ भी याद रखना है — sign-ups, orders, messages, settings — और उसे बाद में या किसी और को दिखाना है, तो हाँ। जो सिर्फ़ जानकारी देने वाली वेबसाइट है और जिसमें डेटा सेव करने वाले forms नहीं हैं, उसे आम तौर पर नहीं चाहिए।