ថ្មីៗនេះខ្ញុំបានរកឃើញថា Red Hat ដកការគាំទ្រ MongoDB ចេញពីផ្កាយរណប (ពួកគេនិយាយថាដោយសារតែការផ្លាស់ប្តូរអាជ្ញាប័ណ្ណ) ។ នេះធ្វើឱ្យខ្ញុំគិតព្រោះក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះខ្ញុំបានឃើញអត្ថបទជាច្រើនអំពីថាតើ MongoDB អាក្រក់ប៉ុណ្ណា ហើយរបៀបដែលគ្មាននរណាម្នាក់មិនគួរប្រើវា។ ប៉ុន្តែក្នុងអំឡុងពេលនេះ MongoDB បានក្លាយជាផលិតផលដែលមានភាពចាស់ទុំជាងមុន។ តើមានអ្វីកើតឡើង? តើការស្អប់ទាំងអស់ពិតជាដោយសារកំហុសក្នុងទីផ្សារដំបូងនៃ DBMS មែនទេ? ឬមនុស្សគ្រាន់តែប្រើ MongoDB នៅកន្លែងខុស?

ប្រសិនបើអ្នកមានអារម្មណ៍ថាខ្ញុំកំពុងការពារ MongoDB សូមអាន ការបដិសេធ នៅចុងបញ្ចប់នៃអត្ថបទ។

និន្នាការថ្មី

ខ្ញុំបានធ្វើការនៅក្នុងឧស្សាហកម្មសូហ្វវែរអស់រយៈពេលជាច្រើនឆ្នាំជាងអ្វីដែលខ្ញុំអាចនិយាយបាន ប៉ុន្តែខ្ញុំនៅតែត្រូវបានលាតត្រដាងនូវផ្នែកតូចមួយនៃនិន្នាការដែលបានវាយប្រហារឧស្សាហកម្មរបស់យើង។ ខ្ញុំបានឃើញការកើនឡើងនៃ 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... បញ្ជីនេះគឺគ្មានទីបញ្ចប់។ ជារៀងរាល់ឆ្នាំនិន្នាការថ្មីលេចឡើង។ ខ្លះ​បាត់​ទៅ​វិញ​យ៉ាង​ឆាប់​រហ័ស ខណៈ​អ្នក​ខ្លះ​ទៀត​ប្តូរ​របៀប​បង្កើត​កម្មវិធី​ជា​មូលដ្ឋាន។

រាល់និន្នាការថ្មីបង្កើតភាពរំភើបទូទៅ៖ មនុស្សលោតឡើងលើយន្តហោះ ឬឃើញសំលេងរំខានដែលបង្កើតដោយអ្នកដទៃ ហើយដើរតាមហ្វូងមនុស្ស។ ដំណើរការនេះត្រូវបានសរសេរដោយ Gartner in វដ្តឃោសនាបំផ្លើស. ទោះបីជាមានភាពចម្រូងចម្រាសក៏ដោយ ការកំណត់ពេលវេលានេះពិពណ៌នាអំពីអ្វីដែលកើតឡើងចំពោះបច្ចេកវិទ្យា មុនពេលពួកវាក្លាយជាមានប្រយោជន៍។

ប៉ុន្តែពីពេលមួយទៅពេលមួយការច្នៃប្រឌិតថ្មីលេចឡើង (ឬមានការមកជាលើកទីពីរដូចក្នុងករណីនេះ) ដែលជំរុញដោយការអនុវត្តជាក់លាក់មួយ។ ក្នុងករណី NoSQL ការឃោសនាបំផ្លើសត្រូវបានជំរុញយ៉ាងខ្លាំងដោយការលេចចេញ និងការកើនឡើងឧតុនិយមនៃ MongoDB ។ MongoDB មិនបានចាប់ផ្តើមនិន្នាការនេះទេ៖ តាមពិតទៅ ក្រុមហ៊ុនអ៊ីនធឺណែតធំៗបានចាប់ផ្តើមមានបញ្ហាក្នុងដំណើរការទិន្នន័យជាច្រើន ដែលនាំទៅដល់ការត្រលប់មកវិញនូវមូលដ្ឋានទិន្នន័យដែលមិនទាក់ទង។ ចលនាទាំងមូលបានចាប់ផ្តើមជាមួយនឹងគម្រោងដូចជា Bigtable របស់ Google និង Cassandra របស់ Facebook ប៉ុន្តែវាគឺជា MongoDB ដែលបានក្លាយជាការអនុវត្តមូលដ្ឋានទិន្នន័យ NoSQL ដ៏ល្បី និងអាចចូលដំណើរការបានដែលអ្នកអភិវឌ្ឍន៍ភាគច្រើនមានសិទ្ធិចូលប្រើប្រាស់។

ចំណាំ៖ អ្នកប្រហែលជាគិតថាខ្ញុំច្រឡំមូលដ្ឋានទិន្នន័យឯកសារជាមួយមូលដ្ឋានទិន្នន័យ columnar, key/value stores, ឬណាមួយនៃប្រភេទផ្សេងទៀតជាច្រើននៃ data store ដែលស្ថិតនៅក្រោមនិយមន័យ NoSQL ទូទៅ។ ហើយអ្នកនិយាយត្រូវ។ ប៉ុន្តែនៅពេលនោះ ភាពវឹកវរបានគ្រប់គ្រង។ មនុស្សគ្រប់គ្នាជក់ចិត្តនឹង NoSQL វាបានក្លាយជាមនុស្សគ្រប់គ្នា ពិតជា ចាំបាច់ ទោះបីជាមនុស្សជាច្រើនមិនបានឃើញភាពខុសគ្នានៃបច្ចេកវិទ្យាផ្សេងគ្នាក៏ដោយ។ សម្រាប់មនុស្សជាច្រើន MongoDB បានក្លាយជា មានន័យដូច NoSQL ។

ហើយអ្នកអភិវឌ្ឍន៍បានវាយលុកលើវា។ គំនិតនៃមូលដ្ឋានទិន្នន័យគ្មានគ្រោងការណ៍ដែលធ្វើមាត្រដ្ឋានដោយវេទមន្តដើម្បីដោះស្រាយបញ្ហាណាមួយគឺគួរឱ្យទាក់ទាញណាស់។ នៅជុំវិញឆ្នាំ 2014 វាហាក់បីដូចជានៅគ្រប់ទីកន្លែងដែលកាលពីមួយឆ្នាំមុនបានប្រើមូលដ្ឋានទិន្នន័យទំនាក់ទំនងដូចជា MySQL, Postgres ឬ SQL Server បានចាប់ផ្តើមដាក់ពង្រាយមូលដ្ឋានទិន្នន័យ MongoDB ។ នៅពេលសួរថាហេតុអ្វីបានជាអ្នកអាចទទួលបានចម្លើយពី banal "នេះគឺជាទំហំនៃគេហទំព័រ" ទៅជាការគិតកាន់តែច្រើន "ទិន្នន័យរបស់ខ្ញុំមានរចនាសម្ព័ន្ធរលុងណាស់ ហើយសមល្អក្នុងមូលដ្ឋានទិន្នន័យដោយគ្មានគ្រោងការណ៍"។

វាជារឿងសំខាន់ដែលត្រូវចងចាំថា MongoDB និងមូលដ្ឋានទិន្នន័យឯកសារជាទូទៅដោះស្រាយបញ្ហាមួយចំនួនជាមួយមូលដ្ឋានទិន្នន័យទំនាក់ទំនងប្រពៃណី៖

• គ្រោងការណ៍តឹងរ៉ឹង៖ ជាមួយនឹងមូលដ្ឋានទិន្នន័យទំនាក់ទំនង ប្រសិនបើអ្នកបានបង្កើតទិន្នន័យថាមវន្ត អ្នកត្រូវបានបង្ខំឱ្យបង្កើតជួរឈរ "ផ្សេងៗ" ចៃដន្យនៃទិន្នន័យ រុញប្លុកទិន្នន័យនៅទីនោះ ឬប្រើការកំណត់រចនាសម្ព័ន្ធ។ អេវ៉ា...ទាំងអស់នេះមានគុណវិបត្តិយ៉ាងសំខាន់។
• ការលំបាកក្នុងការធ្វើមាត្រដ្ឋាន៖ ប្រសិនបើមានទិន្នន័យច្រើនដែលវាមិនសមនឹងម៉ាស៊ីនមេមួយ MongoDB បានផ្តល់យន្តការដើម្បីអនុញ្ញាតឱ្យវាធ្វើមាត្រដ្ឋានលើម៉ាស៊ីនជាច្រើន។
• ការកែប្រែសៀគ្វីស្មុគស្មាញ៖ គ្មានការធ្វើចំណាកស្រុកទេ! នៅក្នុងមូលដ្ឋានទិន្នន័យទំនាក់ទំនង ការផ្លាស់ប្តូររចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យអាចជាបញ្ហាដ៏ធំមួយ (ជាពិសេសនៅពេលមានទិន្នន័យច្រើន)។ MongoDB អាចជួយសម្រួលដំណើរការបានយ៉ាងច្រើន។ ហើយវាធ្វើឱ្យវាមានភាពងាយស្រួល ដែលអ្នកគ្រាន់តែអាចធ្វើបច្ចុប្បន្នភាពសៀគ្វីនៅពេលអ្នកទៅ និងបន្តយ៉ាងលឿន។
• ការសម្តែងថត៖ ដំណើរការរបស់ MongoDB គឺល្អ ជាពិសេសនៅពេលដែលបានកំណត់រចនាសម្ព័ន្ធត្រឹមត្រូវ។ សូម្បីតែការកំណត់រចនាសម្ព័ន្ធក្រៅប្រអប់របស់ MongoDB ដែលវាត្រូវបានរិះគន់ជាញឹកញាប់ បានបង្ហាញនូវតួលេខប្រតិបត្តិការគួរឱ្យចាប់អារម្មណ៍មួយចំនួន។

ហានិភ័យទាំងអស់គឺស្ថិតនៅលើអ្នក។

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

ដើម្បីយុត្តិធម៌ គ្មាននរណាម្នាក់នៅ 10gen/MongoDB Inc. នឹងមិននិយាយថាខាងក្រោមមិនមែនជាការពិតទេ ទាំងនេះគ្រាន់តែជាការសម្របសម្រួលប៉ុណ្ណោះ។

• បាត់បង់ប្រតិបត្តិការ៖ ប្រតិបត្តិការគឺជាលក្ខណៈស្នូលនៃមូលដ្ឋានទិន្នន័យទំនាក់ទំនងជាច្រើន (មិនមែនទាំងអស់ទេ ប៉ុន្តែភាគច្រើនបំផុត)។ ប្រតិបត្តិការមានន័យថាអ្នកអាចអនុវត្តប្រតិបត្តិការជាច្រើនតាមអាតូម ហើយអាចធានាថាទិន្នន័យនៅតែជាប់លាប់។ ជាការពិតណាស់ ជាមួយនឹងមូលដ្ឋានទិន្នន័យ NoSQL ប្រតិបត្តិការអាចស្ថិតនៅក្នុងឯកសារតែមួយ ឬអ្នកអាចប្រើការប្តេជ្ញាចិត្តពីរដំណាក់កាល ដើម្បីទទួលបានសមីការប្រតិបត្តិការ។ ប៉ុន្តែអ្នកនឹងត្រូវអនុវត្តមុខងារនេះដោយខ្លួនឯង... ដែលអាចជាកិច្ចការដ៏លំបាក និងចំណាយពេលច្រើន។ ជារឿយៗអ្នកមិនដឹងថាមានបញ្ហាទេ រហូតទាល់តែអ្នកឃើញទិន្នន័យនៅក្នុងមូលដ្ឋានទិន្នន័យបញ្ចប់ក្នុងស្ថានភាពមិនត្រឹមត្រូវ ដោយសារអាតូមិកនៃប្រតិបត្តិការមិនអាចធានាបាន។ ចំណាំ៖ មនុស្សជាច្រើនបានប្រាប់ខ្ញុំថា MongoDB 4.0 បានណែនាំប្រតិបត្តិការកាលពីឆ្នាំមុន ប៉ុន្តែជាមួយនឹងដែនកំណត់មួយចំនួន។ ការដកចេញពីអត្ថបទនៅតែដដែល៖ វាយតម្លៃថាតើបច្ចេកវិទ្យាបំពេញតម្រូវការរបស់អ្នកបានល្អប៉ុណ្ណា។
• ការបាត់បង់សុច្ចរិតភាពទំនាក់ទំនង (សោរបរទេស)៖ ប្រសិនបើទិន្នន័យរបស់អ្នកមានទំនាក់ទំនង នោះអ្នកនឹងត្រូវអនុវត្តពួកវានៅក្នុងកម្មវិធី។ ការ​មាន​មូលដ្ឋាន​ទិន្នន័យ​ដែល​គោរព​ទំនាក់​ទំនង​ទាំង​នេះ​នឹង​ត្រូវ​ចំណាយ​ពេល​ជា​ច្រើន​នៃ​ការ​អនុវត្ត​កម្មវិធី ហើយ​ដូច្នេះ​អ្នក​សរសេរ​កម្មវិធី​របស់​អ្នក។
• កង្វះសមត្ថភាពក្នុងការអនុវត្តរចនាសម្ព័ន្ធទិន្នន័យ៖ គ្រោងការណ៍តឹងរ៉ឹង ជួនកាលអាចជាបញ្ហាធំមួយ ប៉ុន្តែពួកវាក៏ជាយន្តការដ៏មានអានុភាពសម្រាប់ការរៀបចំរចនាសម្ព័ន្ធទិន្នន័យដ៏ល្អ ប្រសិនបើប្រើដោយប្រាជ្ញា។ មូលដ្ឋានទិន្នន័យឯកសារដូចជា MongoDB ផ្តល់នូវភាពបត់បែនតាមគ្រោងការណ៍ដែលមិនគួរឱ្យជឿ ប៉ុន្តែភាពបត់បែននេះដកការទទួលខុសត្រូវក្នុងការរក្សាទិន្នន័យឱ្យស្អាត។ ប្រសិនបើអ្នកមិនថែរក្សាពួកគេទេ អ្នកនឹងបញ្ចប់ការសរសេរកូដជាច្រើននៅក្នុងកម្មវិធីរបស់អ្នក ដើម្បីគណនីទិន្នន័យដែលមិនត្រូវបានរក្សាទុកក្នុងទម្រង់ដែលអ្នករំពឹងទុក។ ដូចដែលយើងតែងតែនិយាយនៅឯក្រុមហ៊ុនរបស់យើង Simple Thread... កម្មវិធីនឹងត្រូវបានសរសេរឡើងវិញនៅថ្ងៃណាមួយ ប៉ុន្តែទិន្នន័យនឹងរស់នៅជារៀងរហូត។ ចំណាំ៖ MongoDB គាំទ្រការត្រួតពិនិត្យគ្រោងការណ៍៖ វាមានប្រយោជន៍ ប៉ុន្តែមិនផ្តល់ការធានាដូចនៅក្នុងមូលដ្ឋានទិន្នន័យទំនាក់ទំនងទេ។ ជាដំបូង ការបន្ថែម ឬផ្លាស់ប្តូរការត្រួតពិនិត្យគ្រោងការណ៍មិនប៉ះពាល់ដល់ទិន្នន័យដែលមានស្រាប់នៅក្នុងការប្រមូលនោះទេ។ វាអាស្រ័យលើអ្នកដើម្បីធានាថាអ្នកធ្វើបច្ចុប្បន្នភាពទិន្នន័យយោងទៅតាមគ្រោងការណ៍ថ្មី។ សម្រេចចិត្តដោយខ្លួនឯងថាតើវាគ្រប់គ្រាន់សម្រាប់តម្រូវការរបស់អ្នក។
• ភាសាសំណួរដើម / ការបាត់បង់ប្រព័ន្ធអេកូឧបករណ៍៖ ការមកដល់នៃ SQL គឺជាបដិវត្តន៍ទាំងស្រុង ហើយគ្មានអ្វីផ្លាស់ប្តូរចាប់តាំងពីពេលនោះមក។ វា​ជា​ភាសា​ដែល​មាន​ឥទ្ធិពល​មិន​គួរ​ឱ្យ​ជឿ ប៉ុន្តែ​ក៏​មាន​ភាព​ស្មុគស្មាញ​ផង​ដែរ។ តម្រូវការក្នុងការសាងសង់សំណួរមូលដ្ឋានទិន្នន័យជាភាសាថ្មីដែលមានបំណែក JSON ត្រូវបានចាត់ទុកថាជាជំហានដ៏ធំមួយថយក្រោយដោយអ្នកដែលមានបទពិសោធន៍ធ្វើការជាមួយ SQL ។ មានឧបករណ៍សកលទាំងមូលដែលមានអន្តរកម្មជាមួយមូលដ្ឋានទិន្នន័យ SQL ចាប់ពី IDEs រហូតដល់ឧបករណ៍រាយការណ៍។ ការផ្លាស់ទីទៅមូលដ្ឋានទិន្នន័យដែលមិនគាំទ្រ SQL មានន័យថាអ្នកមិនអាចប្រើឧបករណ៍ទាំងនេះភាគច្រើន ឬអ្នកត្រូវបកប្រែទិន្នន័យទៅជា SQL ដើម្បីប្រើវា ដែលអាចពិបាកជាងអ្នកគិត។

អ្នកអភិវឌ្ឍន៍ជាច្រើនដែលងាកមកប្រើ MongoDB ពិតជាមិនយល់ពីការដោះដូរពាណិជ្ជកម្មនោះទេ ហើយជារឿយៗបានងាកទៅរកការដំឡើងវាជាឃ្លាំងទិន្នន័យចម្បងរបស់ពួកគេ។ បន្ទាប់​ពី​នេះ វា​ជា​ញឹក​ញាប់​ពិបាក​នឹង​ត្រឡប់​មក​វិញ។

តើអ្វីដែលអាចធ្វើបានខុសគ្នា?

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

តើធ្វើដូចម្តេចដើម្បីជ្រើសរើសបច្ចេកវិទ្យាត្រឹមត្រូវ? មានការប៉ុនប៉ងជាច្រើនដើម្បីបង្កើតក្របខ័ណ្ឌជាប្រព័ន្ធសម្រាប់ការវាយតម្លៃបច្ចេកវិទ្យា ដូចជា "ក្របខ័ណ្ឌសម្រាប់ការណែនាំបច្ចេកវិទ្យាទៅក្នុងស្ថាប័នកម្មវិធី" и "ក្របខ័ណ្ឌសម្រាប់ការវាយតម្លៃបច្ចេកវិទ្យាកម្មវិធី"ប៉ុន្តែវាហាក់ដូចជាខ្ញុំថា នេះគឺជាភាពស្មុគស្មាញដែលមិនចាំបាច់។

បច្ចេកវិទ្យាជាច្រើនអាចត្រូវបានវាយតម្លៃដោយឆ្លាតវៃដោយសួរសំណួរជាមូលដ្ឋានចំនួនពីរ។ បញ្ហា​គឺ​ស្វែងរក​មនុស្ស​ដែល​អាច​ឆ្លើយ​ពួកគេ​ដោយ​ការ​ទទួល​ខុសត្រូវ ដោយ​ចំណាយ​ពេល​ដើម្បី​ស្វែងរក​ចម្លើយ និង​ដោយ​គ្មាន​ការលំអៀង។

ប្រសិនបើអ្នកមិនប្រឈមមុខនឹងបញ្ហាណាមួយទេ អ្នកមិនត្រូវការឧបករណ៍ថ្មីទេ។ ចំណុច។

សំណួរទី 1: តើបញ្ហាអ្វីខ្លះដែលខ្ញុំកំពុងព្យាយាមដោះស្រាយ?

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

សំណួរទី 2: តើខ្ញុំបាត់អ្វី?

នេះ​គឺ​ជា​សំណួរ​ដែល​ពិបាក​ជាង​នេះ​ព្រោះ​អ្នក​នឹង​ត្រូវ​ជីក​កកាយ​និង​មាន​ការ​យល់​ដឹង​ច្បាស់​ពី​បច្ចេកវិទ្យា​ចាស់​និង​ថ្មី។ ពេលខ្លះ អ្នកពិតជាមិនអាចយល់អំពីអ្វីដែលថ្មីនោះទេ រហូតដល់អ្នកបានបង្កើតអ្វីមួយជាមួយវា ឬមាននរណាម្នាក់ដែលមានបទពិសោធន៍នោះ។

ប្រសិនបើអ្នកមិនមាន នោះវាសមហេតុផលក្នុងការគិតអំពីការវិនិយោគអប្បបរមាដែលអាចធ្វើទៅបានដើម្បីកំណត់តម្លៃនៃឧបករណ៍នេះ។ ហើយនៅពេលដែលអ្នកធ្វើការបណ្តាក់ទុន តើវាពិបាកប៉ុណ្ណាក្នុងការបដិសេធការសម្រេចចិត្ត?

មនុស្សតែងតែបំផ្លាញអ្វីៗទាំងអស់។

នៅពេលអ្នកព្យាយាមឆ្លើយសំណួរទាំងនេះដោយមិនលំអៀងតាមដែលអាចធ្វើទៅបាន សូមចងចាំរឿងមួយ៖ អ្នកនឹងត្រូវប្រយុទ្ធនឹងធម្មជាតិរបស់មនុស្ស។ មាន​ភាពលំអៀង​នៃ​ការយល់ដឹង​មួយចំនួន​ដែល​ត្រូវតែ​យកឈ្នះ​ដើម្បី​វាយតម្លៃ​បច្ចេកវិទ្យា​ប្រកបដោយ​ប្រសិទ្ធភាព។ នេះគ្រាន់តែជាមួយចំនួនប៉ុណ្ណោះ៖

• ឥទ្ធិពលនៃការចូលរួមភាគច្រើន - មនុស្សគ្រប់គ្នាដឹងអំពីគាត់ប៉ុន្តែវានៅតែពិបាកក្នុងការប្រយុទ្ធជាមួយគាត់។ គ្រាន់តែធ្វើឱ្យប្រាកដថាបច្ចេកវិទ្យាពិតជាត្រូវគ្នានឹងតម្រូវការជាក់ស្តែងរបស់អ្នក។
• ឥទ្ធិពលថ្មីថ្មោង - អ្នកអភិវឌ្ឍន៍ជាច្រើនមានទំនោរមើលស្រាលលើបច្ចេកវិទ្យាដែលពួកគេបានធ្វើការជាមួយអស់រយៈពេលជាយូរ ហើយវាយតម្លៃលើសអំពីអត្ថប្រយោជន៍នៃបច្ចេកវិទ្យាថ្មី។ វាមិនមែនគ្រាន់តែជាអ្នកសរសេរកម្មវិធីប៉ុណ្ណោះទេ មនុស្សគ្រប់គ្នាងាយនឹងលំអៀងការយល់ដឹងនេះ។
• ឥទ្ធិពលនៃលក្ខណៈវិជ្ជមាន - យើង​មាន​ទំនោរ​ទៅ​មើល​អ្វី​ដែល​នៅ​ទីនោះ​ហើយ​បាត់បង់​ការ​មើល​ឃើញ​នូវ​អ្វី​ដែល​បាត់​។ នេះអាចនាំឱ្យមានភាពច្របូកច្របល់នៅពេលដែលរួមបញ្ចូលជាមួយនឹងឥទ្ធិពលថ្មីថ្មោង ព្រោះថាអ្នកមិនត្រឹមតែផ្តល់តម្លៃលើបច្ចេកវិទ្យាថ្មីប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងមិនអើពើនឹងចំណុចខ្វះខាតរបស់វាផងដែរ។.

ការវាយតម្លៃគោលបំណងមិនងាយស្រួលទេ ប៉ុន្តែការយល់ដឹងអំពីភាពលំអៀងនៃការយល់ដឹងនឹងជួយអ្នកធ្វើការសម្រេចចិត្តប្រកបដោយហេតុផលកាន់តែច្រើន។

សង្ខេប

នៅពេលណាដែលការច្នៃប្រឌិតលេចឡើង សំណួរពីរត្រូវតែឆ្លើយដោយយកចិត្តទុកដាក់បំផុត៖

• តើឧបករណ៍នេះដោះស្រាយបញ្ហាពិតប្រាកដទេ?
• តើ​យើង​យល់​ពី​ការ​ដោះដូរ​នេះ​ល្អ​ទេ?

ប្រសិនបើអ្នកមិនអាចឆ្លើយសំណួរទាំងពីរនេះដោយទំនុកចិត្តទេ សូមដើរថយក្រោយពីរបីជំហាន ហើយគិត។

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

អេស

ខ្ញុំ​ចង់​បញ្ជាក់​ថា ខ្ញុំ​មិន​មាន​ទំនាក់ទំនង​ស្នេហា ឬ​ស្អប់​ជាមួយ MongoDB ទេ។ យើងគ្រាន់តែមិនមានប្រភេទនៃបញ្ហាដែល MongoDB សមស្របបំផុតក្នុងការដោះស្រាយ។ ខ្ញុំដឹងថា 10gen/MongoDB Inc. ដំបូងឡើយគឺមានភាពក្លាហាន ដោយកំណត់លំនាំដើមដែលមិនមានសុវត្ថិភាព និងផ្សព្វផ្សាយ MongoDB គ្រប់ទីកន្លែង (ជាពិសេសនៅ hackathons) ជាដំណោះស្រាយសកលសម្រាប់ធ្វើការជាមួយទិន្នន័យណាមួយ។ វាប្រហែលជាការសម្រេចចិត្តមិនល្អ។ ប៉ុន្តែវាបញ្ជាក់ពីវិធីសាស្រ្តដែលបានពិពណ៌នានៅទីនេះ៖ បញ្ហាទាំងនេះអាចត្រូវបានរកឃើញយ៉ាងឆាប់រហ័ស បើទោះបីជាមានការវាយតម្លៃលើបច្ចេកវិទ្យាទំនើបក៏ដោយ។

ប្រភព: www.habr.com