როგორ დავამატოთ მონაცემთა ბაზა თქვენს აპში (მონაცემების დაკარგვის გარეშე)

აპში მონაცემთა ბაზის დასამატებლად აირჩიეთ მართული რელაციური მონაცემთა ბაზა (ჩვეულებრივ Postgres), შეინახეთ მისი კავშირის სტრიქონი სერვერის მხარის საიდუმლოში, შექმენით ერთი ცხრილი ყოველი სახის ობიექტისთვის, რომელსაც აპი ინახავს, და ისეთი ბექენდი გააკეთეთ, რომელიც კითხულობს და წერს ბაზაში — და არა ბრაუზერი. თუ აპს AI აპის შემქმნელით აშენებთ, ხშირად საკმარისია თქვათ „შეინახე ეს მონაცემთა ბაზაში“ და აგენტი ცხრილებსა და კოდს თავად დააყენებს; თქვენი ამოცანაა მონაცემების მკაფიოდ აღწერა და იმის შემოწმება, რომ ისინი მართლა ინახება.

ეს სახელმძღვანელო განმარტავს, როდის გჭირდებათ მონაცემთა ბაზა, მთავარ ვარიანტებს, როგორ აღწეროთ მონაცემები და შეცდომებს, რომლებიც მონაცემების დაკარგვას ან გაჟონვას იწვევს.

როდის სჭირდება თქვენს აპს მონაცემთა ბაზა

მონაცემთა ბაზა გჭირდებათ, როცა აპმა გვერდის დახურვის შემდეგ უნდა დაიმახსოვროს რაიმე, ან მონაცემები გააზიაროს ხალხს შორის. დამახასიათებელი ნიშნები:

ვიზიტორები აგზავნიან რაღაცას: ფორმას, რეგისტრაციას, დაჯავშნას, შეკვეთას
მომხმარებლებს აქვთ ანგარიშები საკუთარი შენახული კონტენტით
ადმინისტრატორს უნდა ნახოს ან შეცვალოს ის, რაც სხვებმა შექმნეს
გსურთ ანგარიშგება ან რიცხვები დროის მიხედვით

მონაცემთა ბაზა არ გჭირდებათ სტატიკური საიტისთვის, სადაც ყველა ერთსა და იმავე კონტენტს ხედავს, როგორიცაა პორტფოლიო ან მარტივი სადესანტო გვერდი. თუ არ იცით, რა არის მონაცემთა ბაზა, ჯერ წაიკითხეთ რა არის მონაცემთა ბაზა.

თქვენი ვარიანტები

ვარიანტი	რა არის	რისთვის კარგია	კომპრომისები
ჩაშენებული მონაცემთა ბაზა AI აპის შემქმნელიდან	მონაცემთა ბაზა, რომელიც თქვენი პროექტისთვის იქმნება და უკავშირდება	უმეტესობა აპებისა, რომლებიც AI შემქმნელით კეთდება	დაკავშირებულია იმ პლატფორმის ჰოსტინგთან; ექსპორტი და სარეზერვო ასლები პლატფორმაზეა დამოკიდებული
მართული Postgres ან MySQL	მასპინძლობადი რელაციური მონაცემთა ბაზა, რომელსაც ცალკე ირეგისტრირებთ	აპები, რომლებსაც თავად ჰოსტავთ, ან რამდენიმე სერვისი იზიარებს	გასაღებებს, კავშირების ლიმიტებსა და გეგმებს თქვენ მართავთ
Backend-as-a-service	მონაცემთა ბაზა, ავთენტიფიკაცია, საცავი და API ერთ პროდუქტში	frontend-ზე ორიენტირებული აპები, რომლებსაც მზა შესვლა უნდათ	მეტი პროდუქტ-სპეციფიური ცნება უნდა ისწავლოთ
დოკუმენტური (NoSQL) მონაცემთა ბაზა	ინახავს მოქნილ, JSON-ის მსგავს დოკუმენტებს	ძალიან არარეგულარული მონაცემები	კავშირებთან და ანგარიშგებასთან მუშაობა უფრო რთულია
ცხრილი მონაცემთა ბაზის სახით	Google Sheets ან მსგავსი API-ით	პატარა შიდა ინსტრუმენტები, პროტოტიპები	ნელია, რეალური შეზღუდვები არ აქვს, ერთდროულ რედაქტირებაზე იშლება

მცირე და საშუალო ვებ აპების უმეტესობისთვის რელაციური მონაცემთა ბაზა, როგორიცაა Postgres, სწორი ნაგულისხმევი არჩევანია. ის კარგად მუშაობს კავშირებთან (მომხმარებელს ბევრი შეკვეთა აქვს), ინარჩუნებს მონაცემთა თანმიმდევრულობას და მოგვიანებით კითხვებს SQL-ით სვამს. მარტივი განმარტებისთვის იხილეთ რა არის Postgres.

აღწერეთ თქვენი მონაცემები აშენებამდე

ყველაზე სასარგებლო, რაც შეგიძლიათ, არის ჩამოწეროთ ის ობიექტები, რომელთაც აპი ინახავს, და როგორ უკავშირდებიან ისინი ერთმანეთს. მონაცემთა ბაზის ტერმინოლოგია არ გჭირდებათ. დაჯავშნის აპისთვის:

მომხმარებლები: სახელი, ელფოსტა, ტელეფონი
სერვისები: სახელი, ხანგრძლივობა, ფასი
დაჯავშნები: რომელი მომხმარებელი, რომელი სერვისი, დაწყების დრო, სტატუსი (მოლოდინში, დადასტურებული, გაუქმებული)

ეს სამი ცხრილია. „რომელი მომხმარებელი“ და „რომელი სერვისი“ ხდება ბმულები (გარე გასაღებები) ცხრილებს შორის. ამის სწორად გაკეთება ადრეულ ეტაპზე ბევრად უფრო მნიშვნელოვანია, ვიდრე ტექნოლოგიის არჩევა, რადგან უკვე რეალური ჩანაწერების მქონე მონაცემების სტრუქტურის შეცვლა უფრო რთულია, ვიდრე გვერდის განლაგების შეცვლა.

რამდენიმე პრაქტიკული წესი:

ერთი ცხრილი ყოველი სახის ობიექტისთვის. შეკვეთები არ უნდა ჩაწეროთ მომხმარებლის ტექსტურ სვეტში.
ყოველ ჩანაწერს მიანიჭეთ ID და შექმნის დრო. ორივე მოგვიანებით გამოგადგებათ.
გამოიყენეთ სწორი ტიპები. თარიღები თარიღებად, ფული მთელ თეთრებად ან ათწილადი ტიპით, არა ტექსტად.
მონიშნეთ სავალდებულო ველები. მონაცემთა ბაზამ უნდა უარყოს არასწორი მონაცემები და არა მხოლოდ ფორმამ.

მაგალითი მოთხოვნები

დაიწყეთ ერთი ფუნქციით და არა მთელი სქემის ერთდროულად ჩაწერით:

დაამატე მონაცემთა ბაზა ამ აპს. შექმენი bookings ცხრილი მომხმარებლის სახელით, ელფოსტით, სერვისით, დაწყების დროითა და სტატუსით (მოლოდინში, დადასტურებული, გაუქმებული; ნაგულისხმევი მოლოდინში). დაჯავშნის ფორმის გაგზავნები შეინახე მასში, აჩვენე წარმატების შეტყობინება და დაამატე ადმინისტრატორის გვერდი, სადაც დაჯავშნები ჩამოთვლილია ახლიდან ძველისკენ.

შემდეგ გააფართოვეთ:

დაამატე services ცხრილი (სახელი, ხანგრძლივობა წუთებში, ფასი თეთრებში). დაჯავშნებში თავისუფალი ტექსტის სერვისის ველი შეცვალე სერვისებთან ბმულით და არსებული დაჯავშნები გადაიტანე ისე, რომ არაფერი წაშალო.

და გააძლიერეთ:

დარწმუნდი, რომ მონაცემთა ბაზის ყველა წაკითხვა და ჩაწერა სერვერზე ხდება. ბრაუზერმა არასდროს უნდა მიიღოს მონაცემთა ბაზის კავშირის სტრიქონი. დაჯავშნის ჩამატებამდე სერვერზე შეამოწმე ელფოსტა და დაწყების დრო.

ნაბიჯ-ნაბიჯ

ჩამოწერეთ თქვენი მონაცემები ზემოთ აღწერილი სახით: ობიექტები, ველები, მათ შორის ბმულები.
შექმენით მონაცემთა ბაზა. AI შემქმნელში ჩატში სთხოვეთ. სხვაგან შექმენით მართული Postgres და დააკოპირეთ მისი კავშირის სტრიქონი.
შეინახეთ კავშირის სტრიქონი როგორც საიდუმლო (სერვერზე გარემოს ცვლადი), არასდროს კოდში. იხილეთ გარემოს ცვლადები და საიდუმლოები.
შექმენით ცხრილები. გამოიყენეთ მიგრაციები — ვერსირებული სკრიპტები, რომლებიც სქემას ცვლის — რათა ცვლილებები განმეორებადი და შექცევადი იყოს.
ააგეთ სერვერის მარშრუტები, რომლებიც ქმნიან, კითხულობენ, განაახლებენ და შლიან ჩანაწერებს (CRUD). ბრაუზერი ამ მარშრუტებს იძახებს; ის მონაცემთა ბაზასთან პირდაპირ არ მუშაობს.
დააკავშირეთ ინტერფეისი ამ მარშრუტებთან: ფორმები, რომლებიც ინახავს, სიები, რომლებიც იტვირთება, და ცარიელი მდგომარეობის ეკრანები, როცა ჯერ არაფერია.
შეამოწმეთ შენახვა. გააგზავნეთ რაიმე, გადატვირთეთ გვერდი, გახსენით სხვა ბრაუზერში. თუ მონაცემი არ ჩანს, ის მონაცემთა ბაზაში არ შენახულა.
შეამოწმეთ წვდომა. შედით მეორე მომხმარებლით და დარწმუნდით, რომ პირველი მომხმარებლის მონაცემებს ვერ ნახავს და ვერ შეცვლის.
გამოაქვეყნეთ, შემდეგ ხელახლა შეამოწმეთ ცოცხალ URL-ზე, რადგან გამოქვეყნებულ აპს შეიძლება სხვა კავშირი ჰქონდეს, ვიდრე თქვენს გადახედვას.

ხშირი შეცდომები

ბრაუზერში შენახვა და ფიქრი, რომ შენახულია. localStorage მუშაობს, სანამ აპს სხვა მოწყობილობაზე არ გახსნით. ყოველთვის შეამოწმეთ მეორე ბრაუზერში.
კავშირის სტრიქონი frontend კოდში. frontend კოდს ყველა წაიკითხავს. ეს მათ მთელ მონაცემთა ბაზას აძლევს.
წვდომის შემოწმების გარეშე. „აჩვენე ჩემი შეკვეთები“ სერვერზე უნდა ფილტრავდეს შესული მომხმარებლით და არა ინტერფეისში. ეს AI-ით აშენებულ აპებში ყველაზე გავრცელებული უსაფრთხოების ხვრელია; ჩვენი უსაფრთხოების ჩამონათვალი ამას ფარავს.
დესტრუქციული სქემის ცვლილებები. თხოვნამ „გადაასახელე ცხრილი“ ან „შეცვალე სტრუქტურა“ შეიძლება ცხრილი წაშალოს და ხელახლა შექმნას. როცა რეალური მონაცემები არსებობს, თქვით „გადაიტანე არსებული ჩანაწერები, არაფერი წაშალო“.
ფაილების მონაცემთა ბაზაში შენახვა. სურათები და PDF-ები ფაილურ საცავში უნდა იყოს, ცხრილში კი მხოლოდ მათი URL ან გასაღები. იხილეთ როგორ დავამატოთ ფაილების ატვირთვა.
სარეზერვო ასლების გარეშე. სანამ მომხმარებლები გეყოლებათ, იცოდეთ, როგორ ინახავს პლატფორმა მონაცემებს და როგორ აღადგენთ მათ.

ჩამონათვალი

ყოველ სახის ობიექტს აქვს საკუთარი ცხრილი ID-ითა და შექმნის დროით
სავალდებულო ველებსა და ტიპებს მონაცემთა ბაზა ამოწმებს
კავშირის სტრიქონი მხოლოდ სერვერის მხარის საიდუმლოებშია
ყველა წაკითხვა და ჩაწერა სერვერის მარშრუტებით მიდის
თითოეულ მომხმარებელს მხოლოდ საკუთარი ჩანაწერების წაკითხვა და შეცვლა შეუძლია
მონაცემები გადატვირთვის შემდეგაც რჩება და სხვა ბრაუზერში ჩანს
სქემის ცვლილებები მიგრაციებით კეთდება და არსებულ ჩანაწერებს ინარჩუნებს
იცით, როგორ მუშაობს სარეზერვო ასლები და აღდგენა
ცოცხალი აპი გამოქვეყნების შემდეგ შემოწმებულია

მონაცემთა ბაზის დამატება Mythex-ში

Mythex-ზე თითოეულ პროექტს შეუძლია მიიღოს საკუთარი გამოყოფილი Postgres მონაცემთა ბაზა როგორც Free, ისე Pro გეგმაზე. როგორც წესი, ცალკე „მიერთების“ ღილაკი არ გჭირდებათ: ჩატში მოითხოვეთ („შეინახე ელფოსტები ბაზაში“) ან აკრიფეთ /database, და კავშირის დეტალები სამუშაო სივრცესა და გამოქვეყნებულ აპში ჩაიწერება. პროექტის პარამეტრებში ჩანს, არის თუ არა მონაცემთა ბაზა აქტიური.

მონაცემთა ბაზა 5 წუთის უმოქმედობის შემდეგ ძინავს და შემდეგ მოთხოვნაზე იღვიძებს. გამოქვეყნებული გამოყენება იხდება იმ დროისთვის, როცა ის რეალურად იყო გაღვიძებული, იმავე კრედიტების ბალანსიდან, რომელსაც აშენებისთვის იყენებთ. თუ მონაცემთა ბაზას გამოქვეყნების შემდეგ დაამატებთ, ხელახლა გამოაქვეყნეთ, რომ ცოცხალმა აპმა ის აიღოს.

იხილეთ მონაცემთა ბაზა და რეცეპტი CRUD აპის აშენება დოკუმენტაციაში. მომხმარებლების მონაცემების შესვლის მხარისთვის წაიკითხეთ როგორ დავამატოთ შესვლა თქვენს აპში.

კითხვები

მჭირდება თუ არა მონაცემთა ბაზა ჩემი აპისთვის?

გჭირდებათ, როგორც კი აპმა უნდა დაიმახსოვროს რაიმე ვიზიტებს შორის ან მონაცემები სხვა მომხმარებლებს შორის გააზიაროს: რეგისტრაციები, შეკვეთები, დაჯავშნები, პოსტები ან პარამეტრები. სტატიკურ ვებსაიტს, რომელიც ყველას ერთსა და იმავე კონტენტს უჩვენებს, მონაცემთა ბაზა არ სჭირდება.

რომელი მონაცემთა ბაზა ავირჩიო მცირე ვებ აპისთვის?

რელაციური მონაცემთა ბაზა, როგორიცაა Postgres, უსაფრთხო არჩევანია მცირე ვებ აპების უმეტესობისთვის. ის კარგად ართმევს თავს მომხმარებლებს, შეკვეთებს, კავშირებსა და ანგარიშგებას, ფართოდ არის მხარდაჭერილი და მცირე მასშტაბზე იშვიათად ზღუდავს.

შემიძლია მონაცემები ბრაუზერში შევინახო მონაცემთა ბაზის ნაცვლად?

ბრაუზერის საცავი, როგორიცაა localStorage, მხოლოდ ერთ მოწყობილობაზე, ერთ ბრაუზერში არსებობს და მომხმარებელს ნებისმიერ დროს შეუძლია წაშალოს. ის კარგია ისეთი პარამეტრებისთვის, როგორიცაა თემის არჩევანი, მაგრამ არა იმისთვის, რაც თქვენ ან სხვა მომხმარებლებს მოგვიანებით უნდა ნახონ.

შედის თუ არა Mythex-ში მონაცემთა ბაზა?

დიახ. Mythex-ის პროექტს შეუძლია ჰქონდეს საკუთარი გამოყოფილი Postgres მონაცემთა ბაზა Free და Pro გეგმებზე. ამას ჩატში ითხოვთ ან იყენებთ /database ბრძანებას, ხოლო კავშირის დეტალები თქვენთვის ავტომატურად ჩაიწერება. გამოყენება იხდება იმავე კრედიტების ბალანსიდან, რომელიც აშენებაზე იხარჯება.