உங்கள் ஆப்பில் டேட்டாபேஸ் சேர்ப்பது எப்படி (பின்னர் டேட்டாவை இழக்காமல்)

ஆப்புக்கு டேட்டாபேஸ் சேர்க்க, நிர்வகிக்கப்படும் ஒரு relational டேட்டாபேஸைத் தேர்ந்தெடுங்கள் (பொதுவாக Postgres), அதன் connection string-ஐ server-side secret-ஆக வையுங்கள், உங்கள் ஆப் சேமிக்கும் ஒவ்வொரு வகைக்கும் ஒரு table உருவாக்குங்கள், மேலும் உங்கள் backend தான் அதைப் படிக்கவும் எழுதவும் வேண்டும் — browser அல்ல. AI app builder பயன்படுத்தினால், பொதுவாக "இதை ஒரு டேட்டாபேஸில் சேமி" என்று சொன்னாலே agent tables-ஐயும் code-ஐயும் அமைத்துவிடும்; உங்கள் வேலை தரவை தெளிவாக விவரிப்பதும், அது உண்மையில் சேமிக்கப்படுகிறதா என்று சரிபார்ப்பதும்தான்.

இந்த வழிகாட்டி, உங்களுக்கு எப்போது டேட்டாபேஸ் தேவை, முக்கிய விருப்பங்கள், உங்கள் டேட்டாவை எப்படி விவரிப்பது, மற்றும் டேட்டா இழப்பு அல்லது கசிவை ஏற்படுத்தும் தவறுகள் ஆகியவற்றை விளக்குகிறது.

உங்கள் ஆப்புக்கு எப்போது டேட்டாபேஸ் தேவை

பக்கத்தை மூடிய பிறகும் உங்கள் ஆப் ஏதாவது ஒன்றை நினைவில் வைத்திருக்க, அல்லது பயனர்களுக்கிடையே டேட்டாவை பகிர வேண்டியிருந்தால் டேட்டாபேஸ் தேவை. வழக்கமான அறிகுறிகள்:

• பார்வையாளர்கள் ஏதாவது சமர்ப்பிக்கிறார்கள்: ஒரு படிவம், sign-up, முன்பதிவு, அல்லது order
• பயனர்களுக்குத் தங்கள் சொந்த சேமித்த உள்ளடக்கத்துடன் accounts உள்ளன
• ஒரு admin, மற்றவர்கள் உருவாக்கியதைப் பார்க்க அல்லது திருத்த வேண்டியிருக்கிறது
• காலப்போக்கில் reports அல்லது எண்ணிக்கைகள் வேண்டும்

எல்லோரும் ஒரே உள்ளடக்கத்தைப் பார்க்கும் static தளத்துக்கு (portfolio அல்லது எளிய landing page போன்றவை) டேட்டாபேஸ் தேவையில்லை. டேட்டாபேஸ் என்றால் என்ன என்று உறுதியில்லை என்றால், முதலில் டேட்டாபேஸ் என்றால் என்ன என்பதைப் படியுங்கள்.

உங்கள் விருப்பங்கள்

பெரும்பாலான சிறிய மற்றும் நடுத்தர web ஆப்களுக்கு, Postgres போன்ற relational டேட்டாபேஸ்தான் சரியான தேர்வு. உறவுகளைக் கையாள்வதில் (ஒரு customer-க்கு பல orders உண்டு) இது சிறந்தது, டேட்டாவை சீராக வைத்திருக்கும், பின்னர் SQL மூலம் கேள்விகளுக்கு விடை காண அனுமதிக்கும். எளிய மொழியில் ஒரு விளக்கத்துக்கு Postgres என்றால் என்ன என்பதைப் பாருங்கள்.

உருவாக்கும் முன் உங்கள் டேட்டாவை விவரியுங்கள்

நீங்கள் செய்யக்கூடிய மிகப் பயனுள்ள விஷயம், உங்கள் ஆப் சேமிக்கும் விஷயங்களையும், அவை எப்படி இணைகின்றன என்பதையும் எழுதி வைப்பதுதான். டேட்டாபேஸ் வார்த்தைகள் தேவையில்லை. ஒரு முன்பதிவு ஆப்புக்கு:

• Customers: பெயர், email, தொலைபேசி
• Services: பெயர், கால அளவு, விலை
• Bookings: எந்த customer, எந்த service, தொடக்க நேரம், நிலை (pending, confirmed, cancelled)

இது மூன்று tables. "எந்த customer" மற்றும் "எந்த service" ஆகியவை அவற்றுக்கிடையேயான இணைப்புகள் (foreign keys) ஆகின்றன. இதைத் தொடக்கத்திலேயே சரியாகச் செய்வது எந்த தொழில்நுட்பத் தேர்வைவிடவும் முக்கியம், ஏனெனில் ஏற்கனவே உண்மையான வரிசைகள் உள்ள டேட்டாவின் அமைப்பை மாற்றுவது, page layout-ஐ மாற்றுவதைவிடக் கடினம்.

சில பொது விதிகள்:

• ஒவ்வொரு வகைக்கும் ஒரு table. Orders-ஐ customer-இன் ஒரு text column-க்குள் அடைக்காதீர்கள்.
• ஒவ்வொரு வரிசைக்கும் ஒரு ID மற்றும் created-at நேரம் கொடுங்கள். பின்னர் இரண்டுமே தேவைப்படும்.
• சரியான types பயன்படுத்துங்கள். தேதிகளை தேதிகளாகவும், பணத்தை முழு cents அல்லது decimal வகையிலும் வையுங்கள், text ஆக அல்ல.
• கட்டாய fields-ஐ கட்டாயம் என்று குறியுங்கள். படிவம் மட்டுமல்ல, டேட்டாபேஸும் தவறான டேட்டாவை நிராகரிக்கட்டும்.

எடுத்துக்காட்டு prompts

முழு schema-ஐ ஒரே நேரத்தில் கொட்டாமல், ஒரு அம்சத்தில் தொடங்குங்கள்:

இந்த ஆப்புக்கு டேட்டாபேஸ் சேர்க்கவும். customer name, email, service, start time மற்றும் status (pending, confirmed, cancelled; default pending) கொண்ட bookings table உருவாக்கவும். முன்பதிவு படிவத்திலிருந்து வரும் சமர்ப்பிப்புகளை அதில் சேமிக்கவும், வெற்றி செய்தியைக் காட்டவும், புதியவை முதலில் வரும்படி bookings-ஐப் பட்டியலிடும் ஒரு admin பக்கம் சேர்க்கவும்.

பிறகு அதை விரிவாக்குங்கள்:

services table சேர்க்கவும் (name, duration நிமிடங்களில், price cents-இல்). bookings-இல் இருக்கும் இலவச உரை service புலத்தை services-க்கான இணைப்பாக மாற்றவும், ஏற்கனவே உள்ள bookings-ஐ நீக்காமல் migrate செய்யவும்.

இன்னும் இறுக்கமாக்குங்கள்:

எல்லா டேட்டாபேஸ் read மற்றும் write செயல்களும் server-இல் மட்டுமே நடப்பதை உறுதி செய்யவும். டேட்டாபேஸ் connection string ஒருபோதும் browser-ஐ அடையக்கூடாது. Insert செய்வதற்கு முன் email மற்றும் start time-ஐ server-இல் சரிபார்க்கவும்.

படிப்படியாக

1. உங்கள் டேட்டாவைப் பட்டியலிடுங்கள் மேலே உள்ளபடி: விஷயங்கள், fields, அவற்றுக்கிடையேயான இணைப்புகள்.
2. டேட்டாபேஸை உருவாக்குங்கள். AI builder-இல் chat-இல் கேளுங்கள். வேறிடத்தில் என்றால், managed Postgres instance உருவாக்கி அதன் connection string-ஐ நகலெடுங்கள்.
3. Connection string-ஐ ஒரு secret-ஆக சேமியுங்கள் (server-இல் ஒரு environment variable), ஒருபோதும் code-இல் வேண்டாம். environment variables மற்றும் secrets பாருங்கள்.
4. Tables-ஐ உருவாக்குங்கள். Migrations பயன்படுத்துங்கள் — schema-வை மாற்றும் versioned scripts — அதனால் மாற்றங்கள் மீண்டும் செய்யக்கூடியதாகவும் திரும்பப்பெறக்கூடியதாகவும் இருக்கும்.
5. Server routes உருவாக்குங்கள் rows-ஐ உருவாக்கவும், படிக்கவும், புதுப்பிக்கவும், நீக்கவும் (CRUD). Browser இந்த routes-ஐ அழைக்கும்; அது டேட்டாபேஸுடன் நேரடியாகப் பேசாது.
6. UI-ஐ அந்த routes-உடன் இணையுங்கள்: சேமிக்கும் படிவங்கள், ஏற்றப்படும் பட்டியல்கள், எதுவும் இல்லாதபோது empty states.
7. Persistence-ஐ சோதியுங்கள். ஏதாவது சமர்ப்பியுங்கள், பக்கத்தை reload செய்யுங்கள், வேறு browser-இல் திறவுங்கள். டேட்டா இல்லையென்றால், அது டேட்டாபேஸில் சேமிக்கப்படவில்லை.
8. அணுகலைச் சரிபார்க்கவும். இரண்டாவது பயனராக login செய்து, முதல் பயனரின் டேட்டாவைப் பார்க்கவோ திருத்தவோ முடியவில்லை என்பதை உறுதி செய்யுங்கள்.
9. Publish செய்து, பிறகு நேரலை URL-இல் மீண்டும் சோதியுங்கள், ஏனெனில் வெளியிடப்பட்ட ஆப் preview-ஐவிட வேறு connection-ஐப் பயன்படுத்தலாம்.

பொதுவான தவறுகள்

• Browser-இல் சேமிப்பதை சேமிப்பு என்று நினைப்பது. localStorage வேலை செய்வது போலத் தோன்றும், ஆனால் யாராவது வேறு சாதனத்தில் ஆப்பைத் திறக்கும் வரைதான். எப்போதும் இரண்டாவது browser-இல் சோதியுங்கள்.
• Connection string-ஐ frontend code-இல் வைப்பது. Frontend code-ஐ யாரும் படிக்கலாம். அது உங்கள் முழு டேட்டாபேஸையும் அவர்களுக்குக் கொடுத்துவிடும்.
• Access சோதனைகள் இல்லாமை. "என் orders-ஐக் காட்டு" என்பது உள்நுழைந்த பயனரால் server-இல் வடிகட்டப்பட வேண்டும், UI-இல் அல்ல. AI-உருவாக்கிய ஆப்களில் இதுவே மிகப் பொதுவான பாதுகாப்புக் குறைபாடு; எங்கள் AI-உருவாக்கிய ஆப்களுக்கான பாதுகாப்புப் பட்டியல் இதை உள்ளடக்குகிறது.
• அழிவை ஏற்படுத்தும் schema மாற்றங்கள். "table-ஐ மறுபெயரிடு" அல்லது "அமைப்பை மாற்று" என்று கேட்பது table-ஐ நீக்கி மீண்டும் உருவாக்கக்கூடும். உண்மையான டேட்டா இருக்கும்போது, "ஏற்கனவே உள்ள வரிசைகளை migrate செய், எதையும் நீக்காதே" என்று சொல்லுங்கள்.
• கோப்புகளை டேட்டாபேஸில் சேமிப்பது. படங்களும் PDFகளும் file storage-இல் இருக்க வேண்டும், அட்டவணையில் அவற்றின் URL அல்லது key மட்டும் இருக்க வேண்டும். பார்க்க: ஆப்பில் file uploads சேர்ப்பது எப்படி.
• Backups இல்லாமை. வாடிக்கையாளர்கள் வருவதற்கு முன், உங்கள் platform டேட்டாவை எப்படி backup செய்கிறது, எப்படி மீட்டெடுப்பது என்று தெரிந்திருக்க வேண்டும்.

சரிபார்ப்புப் பட்டியல்

• ஒவ்வொரு வகை விஷயத்துக்கும் ID மற்றும் created-at நேரத்துடன் தனி table உள்ளது
• கட்டாய fields மற்றும் types டேட்டாபேஸால் அமல்படுத்தப்படுகின்றன
• Connection string server-side secrets-இல் மட்டுமே உள்ளது
• எல்லா read மற்றும் write செயல்களும் server routes வழியாகவே செல்கின்றன
• ஒவ்வொரு பயனரும் தங்களது வரிசைகளை மட்டுமே படிக்கவும் மாற்றவும் முடியும்
• Reload-க்குப் பிறகும் டேட்டா நிலைக்கிறது, வேறு browser-இலும் தெரிகிறது
• Schema மாற்றங்கள் migrations மூலம் நடக்கின்றன, ஏற்கனவே உள்ள வரிசைகளைப் பாதுகாக்கின்றன
• Backup மற்றும் restore எப்படி வேலை செய்கின்றன என்று தெரியும்
• Publish செய்த பிறகு நேரலை ஆப் சோதிக்கப்பட்டுள்ளது

Mythex-இல் டேட்டாபேஸ் சேர்ப்பது

Mythex-இல் ஒவ்வொரு project-க்கும் பிரத்யேக Postgres டேட்டாபேஸ் கிடைக்கும், Free மற்றும் Pro இரண்டிலும். பொதுவாக தனியாக "attach" பொத்தானை அழுத்த வேண்டியதில்லை: chat-இல் கேளுங்கள் ("waitlist emails-ஐ ஒரு டேட்டாபேஸில் சேமி") அல்லது /database என தட்டச்சு செய்யுங்கள், இணைப்பு விவரங்கள் workspace-இலும் நீங்கள் வெளியிட்ட ஆப்பிலும் உட்செலுத்தப்படும். Project settings-இல் டேட்டாபேஸ் செயலில் உள்ளதா என்று தெரியும்.

டேட்டாபேஸ் 5 நிமிடம் செயலற்று இருந்தால் தூங்கும், அடுத்த request-இல் விழிக்கும். வெளியிடப்பட்ட பயன்பாடு, அது உண்மையில் விழித்திருந்த நேரத்துக்கு மட்டும் கட்டணம் வசூலிக்கப்படும், நீங்கள் ஆப் உருவாக்கப் பயன்படுத்தும் அதே credit இருப்பிலிருந்து. ஏற்கனவே வெளியிட்ட பிறகு டேட்டாபேஸ் சேர்த்தால், நேரலை ஆப் அதை எடுத்துக்கொள்ள மீண்டும் publish செய்யுங்கள்.

Database மற்றும் docs-இல் உள்ள CRUD ஆப் உருவாக்குதல் recipe-ஐப் பாருங்கள். பயனர்வாரி டேட்டாவின் login பகுதிக்கு, ஆப்பில் login சேர்ப்பது எப்படி படியுங்கள்.

கேள்விகள்