ការបំបែក
ព្រំដែនដែលមូលដ្ឋានទិន្នន័យរក្សា មិនមែនកូដទេ
CRM គ្រប់ប្រភេទអះអាងថាខ្លួនជា multi-tenant។ ការអះអាងគឺងាយស្រួល; អ្វីសំខាន់គឺថាតើថ្នាក់ណាកំពុងរក្សាព្រំដែន។ ប្រសិនបើចម្លើយគឺ "កម្មវិធីរបស់យើងតែងតែបន្ថែមតម្រងត្រឹមត្រូវ" នោះការធានាមានគុណភាពតែប៉ុណ្ណោះដែលអ្នកអភិវឌ្ឍន៍ដែលមិនសូវសម្រាកបំផុតដែលធ្លាប់សរសេរសំណួរអាចធានាបាន។
iKonekt ជា multi-tenant តាំងពីការជម្លៀសទិន្នន័យដំបូង មិនមែនបន្ថែមក្រោយមកទេ ដែលឮដូចជាការអួត ប៉ុន្តែពិតជាការទទួលស្គាល់៖ ការបន្ថែមវាក្រោយមកគឺជិតមិនអាចធ្វើបានយ៉ាងទុកចិត្ត ហើយអ្នកដែលបានព្យាយាមទាំងអស់មានរឿងរ៉ាវ។
ការបែងចែករស់នៅក្នុងមូលដ្ឋានទិន្នន័យ។ តារាងទាំងម្ភៃប្រាំមួយនីមួយៗផ្ទុកអ្នកប្រើប្រាស់ដែលវាជាកម្មសិទ្ធិ ហើយគោលនយោបាយដែលពិនិត្យវាដំណើរការលើការអាននិងការសរសេរទាំងអស់ ក្រោមកម្មវិធីទាំងស្រុង។ សំណួរដែលភ្លេចព្រំដែនមិនបញ្ជូនអតិថិជនរបស់អ្នកដទៃមកវិញទេ។ វាមិនបញ្ជូនអ្វីទាំងស្រុង។
សុវត្ថិភាពកម្រិតជួរដេក ដែលបង្ខំ
មិនមែនជាទម្លាប់ មិនមែនជាក្បួនពិនិត្យកូដទេ។ មូលដ្ឋានទិន្នន័យបដិសេធ។ គោលនយោបាយចំនួនប្រាំពីរដប់ សរសេរម្តងមួយៗ មិនមែនបង្កើតដោយស្វ័យប្រវត្តិទេ — ព្រោះគោលនយោបាយដែលបង្កើតដោយស្វ័យប្រវត្តិគឺជាគោលនយោបាយដែលគ្មាននរណាបានអាន។
គន្លឹះសមាសធាតុ
កំណត់ត្រាកូដយោងទៅអ្នកប្រើប្រាស់របស់វា និង មេរបស់វាទាំងគូជាគូ។ លេខសម្គាល់ច្រឡំពីក្រុមហ៊ុនខុសមិនដំណើរការទេ — វាគ្រាន់តែមិនមែនជាការយោងត្រឹមត្រូវ។
គ្មានអ្នកប្រើប្រាស់លំនាំដើម ដែលណាមួយឡើយ
សំណើដែលគ្មានវិសាលភាពមិនក្លាយជាសំណើសម្រាប់អ្នកប្រើប្រាស់សូន្យដោយស្ងាត់ៗទេ។ វាដាក់កំហុសមុនពេលវាដល់មូលដ្ឋានទិន្នន័យ។ គ្មានរបៀប "unscoped" ដែលអាចភ្លេចបិទទេ។
កំហុសដែលមិនអាចប្រកាសខ្លួនឯង
ខណៈពេលធ្វើការងារតំបន់ជួល (tenancy) កំហុសភាគច្រើនគឺឮខ្លាំង។ ផ្តល់ដូមេនអតិថិជនដូចគ្នាដល់ក្រុមហ៊ុនពីរ ហើយវត្ថុฐាន់ទិន្នន័យនឹងបង្ហាញភ្លាមៗ ជាមួយកូដកំហុស និង stack trace; អ្នកអាចជួសជុលវាមុនពេលថ្ងៃត្រង់។
មួយទៀតមិនបានតវ៉ាទេ។ តារាងនៃការ.override សេចក្តីជំនួស prompt ដែលអាចកែបាន ត្រូវបានគណនាដោយពឹងលើ kind របស់ prompt តែមួយមុខ — មិនមែនលើ kind និង tenant ទេ។ ក្រុមហ៊ុនទីពីរដែលកែសម្រួលចម្លងរបស់ខ្លួន នឹងសរសេរជាន់លើចម្លងរបស់ក្រុមហ៊ុនទីមួយដោយស្ងាត់ៗ តាមរយៈ SQL ដែលត្រឹមត្រូវទាំងស្រុង ដោយគ្មានកំហុស គ្មានការព្រមាន និងគ្មានការធ្វើតេស្តបរាជ័យ។ វាត្រូវបានរកឃើញដោយអានលិបិក្រមពិសេស (unique index) ដែលនៅសល់ទាំងអស់ បន្ទាប់ពីផ្លាស់ប្តូរគន្លឹះមួយ ម្តងមួយៗ ដោយសារការសង្ស័យថាកំហុសដែលឮខ្លាំងទាំងនោះមានដៃគូ។
យើងលើកឡើងពីវាព្រោះវាជាទម្រង់ពិតប្រាកដនៃការងារនេះ។ ការបំបែកដាច់ដោយឡែកមិនមែនជាមុខងារដែលអ្នកបើកបិទបានទេ; វាជាទម្លាប់នៃការអានផ្នែកគ្មានអ្វីគួរឱ្យចាប់អារម្មណ៍នៃ schema ដោយសន្មតថាមានអ្វីមួយនៅទីនោះមិនយល់ស្របជាមួយអ្នក។
ការធ្វើតេស្ត ដើម្បីចងក្រងទុក៖ ចំនួន 942 ដែលដំណើរការលើฐាន់ទិន្នន័យដែលបានសាងសង់ឡើងវិញពីសូន្យរាល់ពេលមានការផ្លាស់ប្តូរ។ ពួកវាមិនមានវត្តមានដើម្បីបញ្ជាក់ថាការរចនាមានភាពឆ្លាតវៃទេ។ ពួកវាមានវត្តមានព្រោះទម្រង់នៃការបរាជ័យនៃការរចនាពិសេសនេះគឺស្ងាត់ ហើយការបរាជ័យស្ងាត់ត្រូវការនរណាម្នាក់ហៅឱ្យខ្លាំងៗជំនួសវា។
អត្ថប្រយោជន៍នៃការបំបែកដាច់ដោយឡែកសម្រាប់មនុស្សធម្មតា
- ក្រុមមួយអាចដំណើរការក្រុមហ៊ុនជាច្រើនពីការដំឡើងតែមួយ ហើយអ្នកលក់នៅក្នុងក្រុមហ៊ុនមួយនឹងមិនដែលឃើញអតិថិជនរបស់ក្រុមហ៊ុនផ្សេងទៀតឡើយ — មិនមែនដោយគោលនយោបាយ តែដោយស្ថាបត្យកម្ម។
- កម្មវិធីភាគីជាដៃគូ សំណុំសេចក្តីជំនួស prompt និងសិទ្ធិទាមទារលើអតិថិជន៖ ទាំងអស់ត្រូវបានកំណត់វិស័យតាមក្រុមហ៊ុន ដូច្នេះការកំណត់រចនាសម្ព័ន្ធរបស់ tenant មួយមិនអាចក្លាយជារបស់អ្នកទាំងអស់គ្នាបានទេ។
- សំណើលុបទិន្នន័យត្រូវបានគោរពក្នុងព្រំដែនមួយ ជាជាងឆ្លងកាត់ជង់ទិន្នន័យរួម ដែលជាអ្វីដែលធ្វើឱ្យអាចឆ្លើយតបដោយស្មារតីត្រង់បាន។
- ហើយគ្មាននរណាម្នាក់ត្រូវចងចាំអ្វីទាំងអស់នោះឡើយ។ នោះគឺជាចំណុចសំខាន់ — ការធានាដែលអាស្រ័យលើការចងចាំមិនមែនជាការធានាទេ។
បន្ទាត់មួយទៀតដែលមិនពាក់ព័ន្ធនឹងฐាន់ទិន្នន័យ
សេវាកម្មបងប្អូនទាំងឡាយនៅក្នុងគ្រួសារនីមួយៗ កាន់កាប់ព័ត៌មានសម្ងាត់ (credential) ដែលមានឈ្មោះរបស់ខ្លួន។ គ្មានអ្វីនិយាយតាមរយៈព័ត៌មានសម្ងាត់រួមមួយឡើយ ដូច្នេះសេវាកម្មណាមួយមិនអាចសម្តែងជាសេវាកម្មផ្សេងដោយចៃដន្យបានទេ — វិន័យតូចមួយដែលមកដោយផ្ទាល់ពីការធ្លាប់មាន token រួមម្តង ហើយមិនសប្បាយចិត្តនឹងវា។
វាជាអារម្មណ៍ដូចគ្នានឹងច្បាប់របស់ฐាន់ទិន្នន័យ។ ធ្វើឱ្យអ្វីដែលខុសក្លាយជាមិនអាចកើតឡើងបាន ជាជាងគ្រាន់តែ discourage ហើយអ្នកនឹងចំណាយការយកចិត្តទុកដាក់លើអតិថិជន ជាជាងលើការត្រួតពិនិត្យជាប្រចាំ។
- 1តារាង 26តារាងទាំងអស់ផ្ទុក tenant របស់ខ្លួន ដោយបង្ខំការពិនិត្យឱ្យដំណើរការ។
- 2គោលនយោបាយ 72សរសេរចេញម្តងមួយៗ ដូច្នេះគ្រប់គោលនយោបាយត្រូវបានមនុស្សម្នាក់អានហើយ។
- 3ការធ្វើតេស្ត 942លើฐាន់ទិន្នន័យដែលសាងសង់ឡើងវិញពីសូន្យ រាល់ពេលមានការផ្លាស់ប្តូរ។
- 4tenant លំនាំដើម 0សំណើដែលគ្មានវិស័យ (scope) មិនដែលទៅដល់ទិន្នន័យឡើយ។
វាស់នៅលើ build ផ្ទាល់
«កម្មវិធីរបស់យើងតែងតែត្រងតាមក្រុមហ៊ុនជានិច្ច។»
ពាក្យថា «តែងតែ» កំពុងធ្វើការច្រើនណាស់ក្នុងប្រយោគនោះ។
បញ្ជូនព្រំដែនចុះក្រោមទៅក្នុងฐាន់ទិន្នន័យ ហើយ WHERE clause ដែលភ្លេចនឹងបង្ហាញលទ្ធផលទទេ ជាជាងអតិថិជនរបស់អ្នកដទៃ។ អេក្រង់ទទេគឺជាការបរាជ័យដ៏ល្អជាងការណែនាំដ៏អាក្រក់។
សម្រាប់ក្រុមដែលដំណើរការម៉ាកជាច្រើន →