មូលដ្ឋានទិន្នន័យនេះត្រូវបានឆេះ...

ខ្ញុំសូមប្រាប់រឿងបច្ចេកទេសមួយ។

ជាច្រើនឆ្នាំកន្លងមកនេះ ខ្ញុំកំពុងបង្កើតកម្មវិធីមួយដែលមានមុខងារសហការដែលបង្កើតឡើងនៅក្នុងវា។ វាគឺជាជង់ពិសោធន៍ដែលងាយស្រួលប្រើដែលទាញយកអត្ថប្រយោជន៍ពីសក្តានុពលពេញលេញនៃ React និង CouchDB ដំបូង។ វាធ្វើសមកាលកម្មទិន្នន័យក្នុងពេលវេលាជាក់ស្តែងតាមរយៈ JSON OT. វា​ត្រូវ​បាន​ប្រើ​នៅ​ក្នុង​ក្រុមហ៊ុន ប៉ុន្តែ​ការ​អនុវត្ត​យ៉ាង​ទូលំទូលាយ និង​សក្ដានុពល​របស់​វា​ក្នុង​ផ្នែក​ផ្សេង​ទៀត​គឺ​ច្បាស់​លាស់។

ខណៈពេលដែលព្យាយាមលក់បច្ចេកវិទ្យានេះទៅឱ្យអតិថិជនសក្តានុពល យើងបានជួបប្រទះឧបសគ្គដែលមិននឹកស្មានដល់។ នៅក្នុងវីដេអូសាកល្បង បច្ចេកវិទ្យារបស់យើងមើលទៅ និងដំណើរការល្អ គ្មានបញ្ហានៅទីនោះទេ។ វីដេអូ​នេះ​បាន​បង្ហាញ​យ៉ាង​ច្បាស់​ពី​របៀប​ដែល​វា​ដំណើរការ ហើយ​មិន​ធ្វើ​ត្រាប់​តាម​អ្វី​ឡើយ។ យើងបានបង្កើត និងសរសេរកូដសេណារីយ៉ូជាក់ស្តែងសម្រាប់ការប្រើប្រាស់កម្មវិធី។


តាមពិតនេះបានក្លាយជាបញ្ហា។ ការបង្ហាញរបស់យើងបានដំណើរការយ៉ាងពិតប្រាកដនូវវិធីដែលអ្នកគ្រប់គ្នាក្លែងធ្វើកម្មវិធីរបស់ពួកគេ។ ជាពិសេស ព័ត៌មានត្រូវបានផ្ទេរភ្លាមៗពី A ទៅ B ទោះបីជាវាជាឯកសារមេឌៀធំក៏ដោយ។ បន្ទាប់ពីចូល អ្នកប្រើប្រាស់ម្នាក់ៗបានឃើញធាតុថ្មី។ ការប្រើប្រាស់កម្មវិធី អ្នកប្រើប្រាស់ផ្សេងគ្នាអាចធ្វើការជាមួយគ្នាយ៉ាងច្បាស់លើគម្រោងដូចគ្នា បើទោះបីជាការតភ្ជាប់អ៊ីនធឺណិតត្រូវបានរំខាននៅកន្លែងណាមួយនៅក្នុងភូមិក៏ដោយ។ នេះ​បង្កប់​អត្ថន័យ​ក្នុង​ការ​កាត់​វីដេអូ​ផលិតផល​ណា​មួយ​នៅ​ក្នុង​កម្មវិធី After Effects។

ទោះបីជាគ្រប់គ្នាដឹងថាប៊ូតុង ធ្វើឱ្យស្រស់សម្រាប់អ្វីក៏ដោយ ក៏គ្មាននរណាម្នាក់យល់ច្បាស់ថាកម្មវិធីបណ្ដាញដែលពួកគេស្នើឱ្យយើងបង្កើតជាធម្មតា ស្ថិតនៅក្រោមដែនកំណត់របស់ពួកគេផ្ទាល់។ ហើយថាប្រសិនបើពួកគេលែងត្រូវការ បទពិសោធន៍អ្នកប្រើប្រាស់នឹងខុសគ្នាទាំងស្រុង។ ភាគច្រើនពួកគេបានកត់សម្គាល់ឃើញថាពួកគេអាច "ជជែក" ដោយទុកកំណត់ត្រាសម្រាប់មនុស្សដែលពួកគេកំពុងនិយាយជាមួយ ដូច្នេះពួកគេឆ្ងល់ថាតើវាខុសពីឧទាហរណ៍ Slack យ៉ាងដូចម្តេច។ ភុយ!

ការរចនានៃការធ្វើសមកាលកម្មប្រចាំថ្ងៃ

ប្រសិនបើអ្នកមានបទពិសោធន៍ក្នុងការអភិវឌ្ឍន៍កម្មវិធី វាត្រូវតែមានការភ័យព្រួយក្នុងការចងចាំថា មនុស្សភាគច្រើនមិនអាចគ្រាន់តែមើលរូបភាពនៃចំណុចប្រទាក់ និងយល់ពីអ្វីដែលវានឹងធ្វើនៅពេលធ្វើអន្តរកម្មជាមួយវានោះទេ។ មិននិយាយពីអ្វីដែលកើតឡើងនៅក្នុងកម្មវិធីខ្លួនឯង។ ចំណេះដឹងនោះ។ អាចធ្វើបាន កើតឡើងភាគច្រើនជាលទ្ធផលនៃការដឹងពីអ្វីដែលមិនអាចកើតឡើង និងអ្វីដែលមិនគួរកើតឡើង។ នេះទាមទារ គំរូផ្លូវចិត្ត មិន​ត្រឹម​តែ​អ្វី​ដែល​កម្មវិធី​ធ្វើ​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​ក៏​របៀប​ដែល​ផ្នែក​នីមួយៗ​របស់​វា​ត្រូវ​បាន​សំរបសំរួល និង​ទំនាក់​ទំនង​គ្នា​ទៅ​វិញ​ទៅ​មក។

ឧទាហរណ៍​បុរាណ​នៃ​ការ​នេះ​គឺ​ជា​អ្នក​ប្រើ​សម្លឹង​មើល​ទៅ a spinner.gifដោយឆ្ងល់ថា តើនៅពេលណាដែលការងារនឹងត្រូវបញ្ចប់។ អ្នកអភិវឌ្ឍន៍នឹងដឹងថាដំណើរការនេះប្រហែលជាជាប់គាំង ហើយ gif នឹងមិនបាត់ពីអេក្រង់ទេ។ គំនូរជីវចលនេះក្លែងធ្វើការអនុវត្តការងារ ប៉ុន្តែមិនពាក់ព័ន្ធនឹងស្ថានភាពរបស់វាទេ។ ក្នុង​ករណី​បែប​នេះ អ្នក​ប្រើ​បច្ចេកវិទ្យា​ខ្លះ​ចូល​ចិត្ត​បើក​ភ្នែក​ដោយ​ភ្ញាក់ផ្អើល​ចំពោះ​វិសាលភាព​នៃ​ការ​យល់​ច្រឡំ​របស់​អ្នក​ប្រើ។ ទោះជាយ៉ាងណាក៏ដោយ ចូរកត់សំគាល់ថាតើពួកគេប៉ុន្មាននាក់ចង្អុលទៅនាឡិកាបង្វិល ហើយនិយាយថាវាពិតជាស្ថានីមែនទេ?

នេះគឺជាខ្លឹមសារនៃតម្លៃពេលវេលាជាក់ស្តែង។ សព្វថ្ងៃនេះ មូលដ្ឋានទិន្នន័យតាមពេលវេលាពិតនៅតែត្រូវបានប្រើប្រាស់តិចតួចបំផុត ហើយមនុស្សជាច្រើនមើលពួកវាដោយមានការសង្ស័យ។ ភាគច្រើននៃមូលដ្ឋានទិន្នន័យទាំងនេះពឹងផ្អែកយ៉ាងខ្លាំងទៅលើរចនាប័ទ្ម NoSQL ដែលជាមូលហេតុដែលពួកគេជាធម្មតាប្រើដំណោះស្រាយដែលមានមូលដ្ឋានលើម៉ុងហ្គោ ដែលត្រូវបានគេបំភ្លេចចោលល្អបំផុត។ ទោះជាយ៉ាងណាក៏ដោយ សម្រាប់ខ្ញុំ នេះមានន័យថាទទួលបានផាសុកភាពក្នុងការធ្វើការជាមួយ CouchDB ក៏ដូចជាការរៀនរចនារចនាសម្ព័ន្ធដែលលើសពីការិយាធិបតេយ្យមួយចំនួនអាចបំពេញទិន្នន័យបាន។ ខ្ញុំគិតថាខ្ញុំប្រើពេលវេលារបស់ខ្ញុំប្រសើរជាង។

ប៉ុន្តែប្រធានបទពិតនៃប្រកាសនេះគឺអ្វីដែលខ្ញុំកំពុងប្រើសព្វថ្ងៃនេះ។ មិន​មែន​ជា​ជម្រើស​ទេ ប៉ុន្តែ​ដោយ​សារ​តែ​ការ​អនុវត្ត​គោលនយោបាយ​សាជីវកម្ម​ដោយ​ព្រងើយ​កន្តើយ និង​ដោយ​មិន​ច្បាស់លាស់។ ដូច្នេះខ្ញុំនឹងផ្តល់នូវការប្រៀបធៀបដោយយុត្តិធម៌ និងមិនលំអៀងនៃផលិតផលមូលដ្ឋានទិន្នន័យពេលវេលាជាក់ស្តែងពីររបស់ Google ដែលទាក់ទងគ្នាយ៉ាងជិតស្និទ្ធ។

អ្នកទាំងពីរមានពាក្យ Fire នៅក្នុងឈ្មោះរបស់ពួកគេ។ រឿងមួយដែលខ្ញុំចងចាំដោយក្តីស្រលាញ់។ រឿងទីពីរសម្រាប់ខ្ញុំគឺប្រភេទភ្លើងផ្សេង។ ខ្ញុំ​មិន​ប្រញាប់​និយាយ​ឈ្មោះ​ពួក​គេ​ទេ ព្រោះ​ពេល​ខ្ញុំ​ធ្វើ​រួច យើង​នឹង​ជួប​បញ្ហា​ធំ​ទី​មួយ​គឺ​ឈ្មោះ។

ទីមួយត្រូវបានគេហៅថា មូលដ្ឋានទិន្នន័យពេលវេលាពិតរបស់ Firebaseនិងទីពីរ - Firebase Cloud Firestore. ទាំងពីរជាផលិតផលមកពី ឈុត Firebase Google APIs របស់ពួកគេត្រូវបានគេហៅថារៀងៗខ្លួន firebase.database(…) и firebase.firestore(…).

នេះបានកើតឡើងដោយសារតែ មូលដ្ឋានទិន្នន័យពេលវេលាពិត - វាគ្រាន់តែជាដើមប៉ុណ្ណោះ។ Firebase មុន​ពេល​ការ​ទិញ​ដោយ Google ក្នុង​ឆ្នាំ 2014។ បន្ទាប់មក Google បានសម្រេចចិត្តបង្កើតជាផលិតផលស្របគ្នា។ ច្បាប់ចម្លង Firebase ផ្អែកលើក្រុមហ៊ុនទិន្នន័យធំ ហើយបានហៅវាថា Firestore ជាមួយនឹងពពក។ ខ្ញុំសង្ឃឹមថាអ្នកមិនទាន់យល់ច្រលំទេ។ ប្រសិនបើអ្នកនៅតែយល់ច្រលំ កុំបារម្ភ ខ្ញុំខ្លួនឯងបានសរសេរផ្នែកនេះឡើងវិញដប់ដង។

ដោយសារតែអ្នកត្រូវចង្អុលបង្ហាញ Firebase នៅក្នុងសំណួរ Firebase និង ចើងរកានកមដោ នៅក្នុងសំណួរអំពី Firebase យ៉ាងហោចណាស់ដើម្បីធ្វើឱ្យអ្នកយល់កាលពីប៉ុន្មានឆ្នាំមុននៅលើ Stack Overflow ។

ប្រសិនបើមានពានរង្វាន់សម្រាប់បទពិសោធន៍នៃការដាក់ឈ្មោះកម្មវិធីដ៏អាក្រក់បំផុតនោះ នេះប្រាកដជាក្លាយជាការប្រកួតប្រជែងមួយ។ ចម្ងាយ Hamming រវាងឈ្មោះទាំងនេះគឺតូចណាស់ ដែលវាច្រឡំសូម្បីតែវិស្វករដែលមានបទពិសោធន៍ ដែលម្រាមដៃមួយវាយឈ្មោះមួយ ខណៈពេលដែលក្បាលរបស់ពួកគេកំពុងគិតអំពីមួយផ្សេងទៀត។ ទាំងនេះគឺជាផែនការដែលមានចេតនាល្អ ដែលបរាជ័យយ៉ាងវេទនា។ ពួក​គេ​បាន​បំពេញ​តាម​ការ​ព្យាករណ៍​ដែល​ថា​ឃ្លាំង​ទិន្នន័យ​នឹង​ត្រូវ​ឆេះ។ ហើយខ្ញុំមិននិយាយលេងទាល់តែសោះ។ អ្នក​ដែល​ចេញ​ឈ្មោះ​នេះ​ធ្វើ​ឲ្យ​ឈាម ញើស និង​ទឹកភ្នែក។

ជ័យជំនះ Pyrhic

មនុស្សម្នាក់នឹងគិតថា Firestore គឺ ជំនួស។ Firebase ដែលជាកូនចៅជំនាន់ក្រោយរបស់វា ប៉ុន្តែវានឹងជាការយល់ច្រឡំ។ Firestore មិនត្រូវបានធានាថាជាការជំនួសសមរម្យសម្រាប់ Firebase ទេ។ វាហាក់បីដូចជាមាននរណាម្នាក់កាត់ចេញនូវអ្វីគ្រប់យ៉ាងដែលគួរឱ្យចាប់អារម្មណ៍ពីវា ហើយច្រឡំភាគច្រើននៃអ្វីដែលនៅសល់តាមវិធីផ្សេងៗ។

ទោះជាយ៉ាងណាក៏ដោយ ការក្រឡេកមើលផលិតផលទាំងពីរអាចធ្វើឲ្យអ្នកយល់ច្រឡំ៖ ពួកគេហាក់ដូចជាធ្វើដូចគ្នា តាមរយៈ APIs ដូចគ្នា និងសូម្បីតែនៅក្នុងវគ្គមូលដ្ឋានទិន្នន័យដូចគ្នា។ ភាពខុសគ្នាគឺមានភាពស្រពិចស្រពិល ហើយត្រូវបានបង្ហាញដោយការសិក្សាប្រៀបធៀបយ៉ាងប្រុងប្រយ័ត្ននៃឯកសារទូលំទូលាយប៉ុណ្ណោះ។ ឬនៅពេលអ្នកកំពុងព្យាយាមបញ្ចូលកូដដែលដំណើរការយ៉ាងល្អឥតខ្ចោះនៅលើ Firebase ដូច្នេះវាដំណើរការជាមួយ Firestore ។ សូម្បីតែបន្ទាប់មកអ្នកដឹងថាចំណុចប្រទាក់មូលដ្ឋានទិន្នន័យនឹងភ្លឺភ្លាមៗនៅពេលដែលអ្នកព្យាយាមអូសនិងទម្លាក់ដោយប្រើកណ្ដុរក្នុងពេលជាក់ស្តែង។ ខ្ញុំនិយាយម្តងទៀត ខ្ញុំមិននិយាយលេងទេ។

ម៉ាស៊ីនភ្ញៀវ Firebase មានសុជីវធម៌ក្នុងន័យថាវាសតិបណ្ដោះអាសន្ន និងព្យាយាមឡើងវិញដោយស្វ័យប្រវត្តិ ដែលផ្តល់អាទិភាពដល់ប្រតិបត្តិការសរសេរចុងក្រោយ។ ទោះយ៉ាងណាក៏ដោយ Firestore មានដែនកំណត់នៃប្រតិបត្តិការសរសេរ 1 ក្នុងមួយឯកសារក្នុងមួយអ្នកប្រើប្រាស់ក្នុងមួយវិនាទី ហើយដែនកំណត់នេះត្រូវបានអនុវត្តដោយម៉ាស៊ីនមេ។ នៅពេលធ្វើការជាមួយវា វាអាស្រ័យលើអ្នកក្នុងការស្វែងរកវិធីជុំវិញវា និងអនុវត្តការកំណត់អត្រាការអាប់ដេត ទោះបីជាអ្នកគ្រាន់តែព្យាយាមបង្កើតកម្មវិធីរបស់អ្នកក៏ដោយ។ នោះ​គឺ Firestore គឺជា​មូលដ្ឋាន​ទិន្នន័យ​ពេល​វេលា​ពិត​ប្រាកដ​មួយ​ដោយ​មិន​មាន​ម៉ាស៊ីន​ភ្ញៀវ​ពេល​វេលា​ពិត​ប្រាកដ​ដែល​ក្លែង​ក្លាយ​ជា​អ្នក​ប្រើ API ។

នៅទីនេះយើងចាប់ផ្តើមឃើញសញ្ញាដំបូងនៃ raison d'être របស់ Firestore ។ ខ្ញុំប្រហែលជាខុស ប៉ុន្តែខ្ញុំសង្ស័យថាមាននរណាម្នាក់ឡើងខ្ពស់ក្នុងការគ្រប់គ្រងរបស់ Google បានមើល Firebase បន្ទាប់ពីការទិញហើយនិយាយយ៉ាងសាមញ្ញថា “ទេ អូព្រះរបស់ខ្ញុំ ទេ។ នេះមិនអាចទទួលយកបានទេ។ មិន​ស្ថិត​នៅ​ក្រោម​ការ​ដឹក​នាំ​របស់​ខ្ញុំ​ទេ»។

គាត់​បាន​លេច​ចេញ​ពី​បន្ទប់​របស់​គាត់ ហើយ​បាន​ប្រកាស​ថា៖

“ឯកសារ JSON ធំមួយ? ទេ អ្នក​នឹង​បំបែក​ទិន្នន័យ​ជា​ឯកសារ​ដាច់​ដោយ​ឡែក​ពី​គ្នា ដែល​ឯកសារ​នីមួយៗ​នឹង​មាន​ទំហំ​មិន​លើស​ពី 1 មេកាបៃ។

វាហាក់បីដូចជាការកំណត់បែបនេះនឹងមិនរួចផុតពីការជួបលើកដំបូងជាមួយនឹងមូលដ្ឋានអ្នកប្រើប្រាស់ដែលលើកទឹកចិត្តគ្រប់គ្រាន់នោះទេ។ អ្នកដឹងថាវាគឺជា។ ជាឧទាហរណ៍ នៅកន្លែងធ្វើការ យើងមានបទបង្ហាញច្រើនជាងមួយពាន់កន្លះ ហើយនេះគឺជារឿងធម្មតាទាំងស្រុង។

ជាមួយនឹងការកំណត់នេះ អ្នកនឹងត្រូវបង្ខំឱ្យទទួលយកការពិតដែលថា "ឯកសារ" មួយនៅក្នុងមូលដ្ឋានទិន្នន័យនឹងមិនស្រដៀងនឹងវត្ថុណាមួយដែលអ្នកប្រើប្រាស់អាចហៅថាឯកសារនោះទេ។

msgstr "អារេ​នៃ​អារេ​ដែល​អាច​មាន​ធាតុ​ផ្សេង​ទៀត? ទេ អារេ​នឹង​មាន​តែ​វត្ថុ​ឬ​លេខ​ដែល​មាន​ប្រវែង​ថេរ​តាម​បំណង​របស់​ព្រះ»។

ដូច្នេះប្រសិនបើអ្នកសង្ឃឹមថានឹងដាក់ GeoJSON ទៅក្នុង Firestore របស់អ្នក អ្នកនឹងឃើញថាវាមិនអាចទៅរួចនោះទេ។ គ្មានអ្វីដែលមិនមែនជាវិមាត្រអាចទទួលយកបានទេ។ ខ្ញុំសង្ឃឹមថាអ្នកចូលចិត្ត Base64 និង/ឬ JSON នៅក្នុង JSON ។

“នាំចូល និងនាំចេញ JSON តាមរយៈ HTTP ឧបករណ៍បន្ទាត់ពាក្យបញ្ជា ឬផ្ទាំងគ្រប់គ្រង? ទេ អ្នកនឹងអាចនាំចេញ និងនាំចូលទិន្នន័យទៅកាន់ Google Cloud Storage ប៉ុណ្ណោះ។ នោះហើយជាអ្វីដែលហៅថាឥឡូវនេះ ខ្ញុំគិតថា។ ហើយនៅពេលដែលខ្ញុំនិយាយថា "អ្នក" ខ្ញុំគ្រាន់តែនិយាយទៅកាន់អ្នកដែលមានលិខិតសម្គាល់ម្ចាស់គម្រោងប៉ុណ្ណោះ។ អ្នក​ផ្សេង​ទៀត​អាច​ទៅ​បង្កើត​សំបុត្រ​បាន»។

ដូចដែលអ្នកអាចឃើញគំរូទិន្នន័យ FireBase ងាយស្រួលក្នុងការពណ៌នា។ វាមានឯកសារ JSON ដ៏ធំមួយដែលភ្ជាប់សោ JSON ជាមួយផ្លូវ URL ។ ប្រសិនបើអ្នកសរសេរជាមួយ HTTP PUT в / FireBase មានដូចខាងក្រោម៖

{
  "hello": "world"
}

នេះ GET /hello និ​ឹ​ង​ត្រឡប់មកវិញ "world". ជាទូទៅ វាដំណើរការដូចដែលអ្នករំពឹងទុក។ ការប្រមូលវត្ថុ FireBase /my-collection/:id ស្មើនឹងវចនានុក្រម JSON {"my-collection": {...}} នៅក្នុង root មាតិកាដែលមាននៅក្នុង /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

វាដំណើរការល្អប្រសិនបើការបញ្ចូលនីមួយៗមានលេខសម្គាល់ដែលមិនមានការប៉ះទង្គិច ដែលប្រព័ន្ធមានដំណោះស្រាយស្តង់ដារសម្រាប់។

ម្យ៉ាងវិញទៀត មូលដ្ឋានទិន្នន័យគឺ 100% JSON(*) ដែលត្រូវគ្នា និងដំណើរការល្អជាមួយ HTTP ដូចជា CouchDB ជាដើម។ ប៉ុន្តែជាមូលដ្ឋាន អ្នកប្រើវាតាមរយៈ API ពេលវេលាពិត ដែលបង្កើត abstracts websockets ការអនុញ្ញាត និងការជាវ។ បន្ទះគ្រប់គ្រងមានសមត្ថភាពទាំងពីរ ដែលអនុញ្ញាតទាំងការកែសម្រួលពេលវេលាជាក់ស្តែង និងការនាំចូល/នាំចេញ JSON ។ ប្រសិនបើអ្នកធ្វើដូចគ្នានៅក្នុងកូដរបស់អ្នក អ្នកនឹងភ្ញាក់ផ្អើលចំពោះចំនួនកូដឯកទេសនឹងត្រូវខ្ជះខ្ជាយ នៅពេលអ្នកដឹងថា បំណះ និងភាពខុសគ្នា JSON ដោះស្រាយ 90% នៃកិច្ចការទម្លាប់នៃការដោះស្រាយស្ថានភាពជាប់លាប់។

គំរូទិន្នន័យរបស់ Firestore គឺស្រដៀងទៅនឹង JSON ប៉ុន្តែខុសគ្នាតាមវិធីសំខាន់ៗមួយចំនួន។ ខ្ញុំ​បាន​និយាយ​រួច​ហើយ​អំពី​កង្វះ​នៃ​អារេ​ក្នុង​អារេ។ គំរូសម្រាប់បណ្តុំរងគឺសម្រាប់ពួកវាជាគោលគំនិតថ្នាក់ទីមួយ ដាច់ដោយឡែកពីឯកសារ JSON ដែលមានពួកវា។ ដោយសារមិនមានសៀរៀលដែលត្រៀមរួចជាស្រេចសម្រាប់ការនេះ ផ្លូវកូដឯកទេសត្រូវបានទាមទារដើម្បីទាញយក និងសរសេរទិន្នន័យ។ ដើម្បីដំណើរការបណ្តុំផ្ទាល់ខ្លួនរបស់អ្នក អ្នកត្រូវសរសេរស្គ្រីប និងឧបករណ៍ផ្ទាល់ខ្លួនរបស់អ្នក។ បន្ទះគ្រប់គ្រងអនុញ្ញាតឱ្យអ្នកធ្វើការផ្លាស់ប្តូរបន្តិចបន្តួចប៉ុណ្ណោះក្នុងមួយវាល ហើយមិនមានសមត្ថភាពនាំចូល/នាំចេញទេ។

ពួកគេបានយកមូលដ្ឋានទិន្នន័យ NoSQL ក្នុងពេលជាក់ស្តែង ហើយបានប្រែក្លាយវាទៅជា SQL យឺតជាមួយនឹងការចូលរួមដោយស្វ័យប្រវត្តិ និងជួរឈរដែលមិនមែនជា JSON ដាច់ដោយឡែក។ អ្វីមួយដូចជា GraftQL.

ចាវ៉ាក្តៅ

ប្រសិនបើ Firestore ត្រូវបានគេសន្មត់ថាអាចទុកចិត្តបាន និងអាចធ្វើមាត្រដ្ឋានបាន នោះអ្វីដែលគួរឱ្យហួសចិត្តនោះគឺថា អ្នកអភិវឌ្ឍន៍ជាមធ្យមនឹងបញ្ចប់ជាមួយនឹងដំណោះស្រាយដែលគួរឱ្យទុកចិត្តជាងការជ្រើសរើសយក FireBase ចេញពីប្រអប់។ ប្រភេទនៃកម្មវិធីដែលអ្នកគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ Grumpy ត្រូវការទាមទារកម្រិតនៃការខិតខំប្រឹងប្រែង និងសមត្ថភាពនៃទេពកោសល្យដែលមិនប្រាកដនិយមសម្រាប់ទីផ្សារពិសេសដែលផលិតផលនេះត្រូវបានគេសន្មត់ថាល្អ។ នេះគឺស្រដៀងគ្នាទៅនឹងរបៀបដែល HTML5 Canvas មិនមែនជាការជំនួស Flash ទាល់តែសោះ ប្រសិនបើមិនមានឧបករណ៍អភិវឌ្ឍន៍ និងអ្នកលេង។ ជាងនេះទៅទៀត Firestore ត្រូវបានជាប់គាំងនៅក្នុងបំណងប្រាថ្នាសម្រាប់ភាពបរិសុទ្ធនៃទិន្នន័យ និងសុពលភាពមិនច្បាស់លាស់ ដែលគ្រាន់តែមិនស្របតាមរបៀបដែលអ្នកប្រើប្រាស់អាជីវកម្មជាមធ្យម ចូលចិត្តធ្វើការ៖ សម្រាប់គាត់ អ្វីគ្រប់យ៉ាងគឺស្រេចចិត្ត ពីព្រោះរហូតដល់ទីបញ្ចប់ អ្វីគ្រប់យ៉ាងគឺជាសេចក្តីព្រាង។

គុណវិបត្តិចម្បងរបស់ FireBase គឺថាម៉ាស៊ីនភ្ញៀវត្រូវបានបង្កើតឡើងជាច្រើនឆ្នាំមុនពេលវេលារបស់វា មុនពេលអ្នកបង្កើតគេហទំព័រភាគច្រើនបានដឹងអំពីភាពមិនប្រែប្រួល។ ដោយសារតែនេះ FireBase សន្មត់ថាអ្នកនឹងផ្លាស់ប្តូរទិន្នន័យ ដូច្នេះហើយមិនទាញយកអត្ថប្រយោជន៍ពីភាពប្រែប្រួលដែលផ្តល់ដោយអ្នកប្រើប្រាស់នោះទេ។ លើសពីនេះ វាមិនប្រើឡើងវិញនូវទិន្នន័យនៅក្នុងរូបថតដែលវាបញ្ជូនទៅកាន់អ្នកប្រើប្រាស់ទេ ដែលធ្វើអោយភាពខុសគ្នាកាន់តែពិបាក។ សម្រាប់ឯកសារធំៗ យន្តការប្រតិបត្តិការដែលមានមូលដ្ឋានលើភាពខុសគ្នាដែលអាចផ្លាស់ប្តូរបានរបស់វាគឺមិនគ្រប់គ្រាន់ទេ។ បុរស, យើងមានរួចហើយ WeakMap នៅក្នុង JavaScript ។ វាមានផាសុកភាព។

ប្រសិនបើអ្នកផ្តល់ឱ្យទិន្នន័យនូវរូបរាងដែលចង់បាន ហើយមិនធ្វើឱ្យដើមឈើមានពន្លឺខ្លាំងពេកទេនោះ បញ្ហានេះអាចត្រូវបានជៀសវាង។ ប៉ុន្តែខ្ញុំចង់ដឹងថាតើ FireBase នឹងគួរឱ្យចាប់អារម្មណ៍ជាងនេះទៀតដែរឬទេ ប្រសិនបើអ្នកអភិវឌ្ឍន៍បានចេញផ្សាយ API អតិថិជនដ៏ល្អដែលប្រើភាពប្រែប្រួលរួមបញ្ចូលគ្នាជាមួយនឹងដំបូន្មានជាក់ស្តែងមួយចំនួនលើការរចនាមូលដ្ឋានទិន្នន័យ។ ផ្ទុយ​ទៅ​វិញ ពួកគេ​ហាក់​ដូច​ជា​ព្យាយាម​ជួសជុល​អ្វី​ដែល​មិន​ខូច ហើយ​វា​ធ្វើ​ឱ្យ​វា​កាន់តែ​ធ្ងន់ធ្ងរ។

ខ្ញុំមិនដឹងថាតក្កវិជ្ជាទាំងអស់នៅពីក្រោយការបង្កើត Firestore ទេ។ ការស្មានអំពីការជម្រុញដែលកើតឡើងនៅក្នុងប្រអប់ខ្មៅក៏ជាផ្នែកមួយនៃភាពសប្បាយរីករាយផងដែរ។ ការប្រៀបធៀបនៃមូលដ្ឋានទិន្នន័យស្រដៀងគ្នាខ្លាំង ប៉ុន្តែមិនអាចប្រៀបផ្ទឹមបានគឺកម្រណាស់។ វាដូចជានរណាម្នាក់បានគិត៖ "Firebase គ្រាន់តែជាមុខងារដែលយើងអាចធ្វើត្រាប់តាម Google Cloud"ប៉ុន្តែមិនទាន់រកឃើញគំនិតនៃការកំណត់អត្តសញ្ញាណតម្រូវការពិភពលោកពិត ឬបង្កើតដំណោះស្រាយដែលមានប្រយោជន៍ដែលបំពេញតម្រូវការទាំងអស់នោះទេ។ “ទុក​ឲ្យ​អ្នក​អភិវឌ្ឍន៍​គិត​អំពី​វា។ គ្រាន់តែធ្វើឱ្យ UI ស្រស់ស្អាត... តើអ្នកអាចបន្ថែមភ្លើងបន្ថែមទៀតបានទេ?

ខ្ញុំយល់ពីរយ៉ាងអំពីរចនាសម្ព័ន្ធទិន្នន័យ។ ខ្ញុំពិតជាមើលឃើញគំនិត "អ្វីគ្រប់យ៉ាងនៅក្នុងដើមឈើ JSON ធំមួយ" ជាការប៉ុនប៉ងដើម្បីអរូបីនូវអារម្មណ៍នៃរចនាសម្ព័ន្ធទ្រង់ទ្រាយធំពីមូលដ្ឋានទិន្នន័យ។ ការរំពឹងថាកម្មវិធីដើម្បីដោះស្រាយជាមួយនឹងរចនាសម្ព័ន្ធទិន្នន័យគួរឱ្យសង្ស័យណាមួយគឺគ្រាន់តែឆ្កួត។ ខ្ញុំមិនចាំបាច់ស្រមៃថាតើរឿងអាក្រក់អាចទៅជាយ៉ាងណានោះទេ ខ្ញុំបានធ្វើសវនកម្មកូដយ៉ាងម៉ត់ចត់ ខ្ញុំបានឃើញរឿងដែលអ្នកមិនធ្លាប់ស្រមៃ. ប៉ុន្តែ​ខ្ញុំ​ក៏​ដឹង​ដែរ​ថា​តើ​រចនាសម្ព័ន្ធ​ល្អ​បែប​ណា របៀបប្រើពួកវា и ហេតុអ្វីត្រូវធ្វើបែបនេះ. ខ្ញុំអាចស្រមៃមើលពិភពលោកមួយដែល Firestore ហាក់ដូចជាឡូជីខល ហើយអ្នកដែលបង្កើតវានឹងគិតថាពួកគេធ្វើបានល្អ។ ប៉ុន្តែយើងមិនរស់នៅក្នុងពិភពលោកនេះទេ។

ការ​គាំទ្រ​សំណួរ​របស់ FireBase គឺ​អន់​ដោយ​ស្ដង់ដារ​ណា​មួយ ហើយ​គឺ​មិន​មាន​ទេ។ វាពិតជាត្រូវការការកែលម្អ ឬយ៉ាងហោចណាស់ការកែប្រែ។ ប៉ុន្តែ Firestore មិនប្រសើរជាងនេះទេ ព្រោះវាត្រូវបានកំណត់ចំពោះសន្ទស្សន៍តែមួយវិមាត្រដូចគ្នាដែលមាននៅក្នុង SQL ធម្មតា។ ប្រសិនបើអ្នកត្រូវការសំណួរដែលមនុស្សដំណើរការលើទិន្នន័យច្របូកច្របល់ អ្នកត្រូវការការស្វែងរកអត្ថបទពេញ តម្រងច្រើនជួរ និងលំដាប់ដែលកំណត់ដោយអ្នកប្រើប្រាស់ផ្ទាល់ខ្លួន។ នៅពេលត្រួតពិនិត្យកាន់តែជិត មុខងាររបស់ SQL ធម្មតាត្រូវបានកំណត់ពេកដោយខ្លួនឯង។ លើសពីនេះ សំណួរ SQL តែមួយគត់ដែលមនុស្សអាចដំណើរការក្នុងផលិតកម្មគឺជាសំណួររហ័ស។ អ្នកនឹងត្រូវការដំណោះស្រាយបង្កើតលិបិក្រមផ្ទាល់ខ្លួនជាមួយនឹងរចនាសម្ព័ន្ធទិន្នន័យដែលគិតគូរ។ សម្រាប់អ្វីៗផ្សេងទៀត យ៉ាងហោចណាស់គួរតែមានការបង្កើនផែនទី-កាត់បន្ថយ ឬអ្វីមួយដែលស្រដៀងគ្នា។

ប្រសិនបើអ្នកស្វែងរក Google Docs សម្រាប់ព័ត៌មានអំពីបញ្ហានេះ អ្នកនឹងសង្ឃឹមថាអ្នកនឹងត្រូវបានចង្អុលទៅទិសដៅនៃអ្វីមួយដូចជា BigTable និង BigQuery ។ ទោះជាយ៉ាងណាក៏ដោយ ដំណោះស្រាយទាំងអស់នេះត្រូវបានអមដោយពាក្យចចាមអារ៉ាមនៃការលក់សាជីវកម្មដ៏ក្រាស់ ដែលអ្នកនឹងត្រលប់មកវិញយ៉ាងឆាប់រហ័ស ហើយចាប់ផ្តើមស្វែងរកអ្វីផ្សេងទៀត។

របស់ចុងក្រោយដែលអ្នកចង់បានជាមួយនឹងមូលដ្ឋានទិន្នន័យពេលវេលាពិតគឺជាអ្វីដែលធ្វើឡើងដោយ និងសម្រាប់មនុស្សនៅលើមាត្រដ្ឋានប្រាក់ឈ្នួលគ្រប់គ្រង។

(*) នេះ​គឺ​ជា​ការ​លេង​សើច​មិន​មាន​ដូច​ជា​ 100% JSON ឆបគ្នា។.

អំពីសិទ្ធិផ្សព្វផ្សាយ

កំពុងស្វែងរក VDS សម្រាប់គម្រោងបំបាត់កំហុស ម៉ាស៊ីនមេសម្រាប់ការអភិវឌ្ឍន៍ និងបង្ហោះ? អ្នកពិតជាអតិថិជនរបស់យើង 🙂 តម្លៃប្រចាំថ្ងៃសម្រាប់ម៉ាស៊ីនមេនៃការកំណត់រចនាសម្ព័ន្ធផ្សេងៗ អាជ្ញាប័ណ្ណប្រឆាំង DDoS និង Windows ត្រូវបានរួមបញ្ចូលក្នុងតម្លៃរួចហើយ។

ប្រភព: www.habr.com