ការពិតដំបូង ឬហេតុអ្វីបានជាប្រព័ន្ធត្រូវរចនាដោយផ្អែកលើឧបករណ៍មូលដ្ឋានទិន្នន័យ

ហេហេ!

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

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

អត្ថបទនេះត្រូវបានសរសេរដោយផ្អែកលើ សំណួរមួយ។ដែលត្រូវបានផ្តល់ឱ្យនៅលើ Stack Overflow ។

ការពិភាក្សាគួរឱ្យចាប់អារម្មណ៍លើ reddit នៅក្នុងផ្នែក /r/java и /r/ការសរសេរកម្មវិធី.

ការបង្កើតកូដ

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

	for (Record2<String, String> record : DSL.using(configuration)
//   ^^^^^^^^^^^^^^^^^^^^^^^ Информация о типах выведена на 
//   основании сгенерированного кода, на который ссылается приведенное
// ниже условие SELECT 
 
       .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
//           vvvvv ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ сгенерированные имена
       .from(ACTOR)
       .orderBy(1, 2)) {
    // ...
}

កូដត្រូវបានបង្កើតដោយដៃនៅខាងក្រៅសន្និបាត ឬដោយដៃនៅឯសន្និបាតនីមួយៗ។ ជាឧទាហរណ៍ ការបង្កើតឡើងវិញបែបនេះអាចកើតឡើងភ្លាមៗបន្ទាប់ពីនោះ។ ការធ្វើចំណាកស្រុកមូលដ្ឋានទិន្នន័យ Flyway ដែលអាចត្រូវបានធ្វើដោយដៃ ឬដោយស្វ័យប្រវត្តិផងដែរ។.

ការបង្កើតកូដប្រភព

មានទស្សនវិជ្ជា គុណសម្បត្តិ និងគុណវិបត្តិផ្សេងៗដែលទាក់ទងនឹងវិធីសាស្រ្តទាំងនេះចំពោះការបង្កើតកូដ - សៀវភៅដៃ និងស្វ័យប្រវត្តិ - ដែលខ្ញុំនឹងមិនពិភាក្សាលម្អិតនៅក្នុងអត្ថបទនេះទេ។ ប៉ុន្តែជាទូទៅចំណុចទាំងមូលនៃកូដដែលបានបង្កើតគឺថាវាអនុញ្ញាតឱ្យយើងបង្កើតឡើងវិញនៅក្នុង Java ថា "ការពិត" ដែលយើងទទួលយកមិនថានៅក្នុងប្រព័ន្ធរបស់យើងឬនៅខាងក្រៅវា។ ក្នុងន័យមួយ នេះគឺជាអ្វីដែលអ្នកចងក្រងធ្វើនៅពេលដែលពួកគេបង្កើត bytecode កូដម៉ាស៊ីន ឬទម្រង់កូដប្រភពផ្សេងទៀត - យើងទទួលបានតំណាងនៃ "សេចក្តីពិត" របស់យើងជាភាសាមួយផ្សេងទៀត ដោយមិនគិតពីហេតុផលជាក់លាក់ណាមួយឡើយ។

មានម៉ាស៊ីនបង្កើតកូដបែបនេះជាច្រើន។ ឧទាហរណ៍, XJC អាចបង្កើតកូដ Java ដោយផ្អែកលើឯកសារ XSD ឬ WSDL. គោលការណ៍គឺតែងតែដូចគ្នា៖

• មានសេចក្តីពិតខ្លះ (ខាងក្នុង ឬខាងក្រៅ) - ឧទាហរណ៍ ការបញ្ជាក់ គំរូទិន្នន័យ។ល។
• យើងត្រូវការតំណាងក្នុងតំបន់នៃការពិតនេះនៅក្នុងភាសាសរសេរកម្មវិធីរបស់យើង។

ជាងនេះទៅទៀត វាគឺតែងតែត្រូវបានណែនាំឱ្យបង្កើតតំណាងបែបនេះ ដើម្បីជៀសវាងការលែងត្រូវការតទៅទៀត។

ប្រភេទអ្នកផ្តល់សេវា និងដំណើរការចំណាំ

ចំណាំ៖ វិធីសាស្រ្តមួយទៀត ទំនើប និងជាក់លាក់ក្នុងការបង្កើតកូដសម្រាប់ jOOQ គឺប្រើប្រាស់អ្នកផ្តល់សេវាប្រភេទ ដូចដែលពួកវាត្រូវបានអនុវត្តនៅក្នុង F#. ក្នុងករណីនេះ កូដត្រូវបានបង្កើតដោយអ្នកចងក្រង តាមពិតនៅដំណាក់កាលចងក្រង។ ជាគោលការណ៍ កូដបែបនេះមិនមាននៅក្នុងទម្រង់ប្រភពទេ។ Java មានឧបករណ៍ស្រដៀងគ្នា ទោះបីជាមិនឆើតឆាយក៏ដោយ ឧបករណ៍ - ដំណើរការចំណារពន្យល់ ជាឧទាហរណ៍ Lombok.

ក្នុងន័យមួយ រឿងដូចគ្នាកើតឡើងនៅទីនេះ ដូចករណីទីមួយ លើកលែងតែ៖

• អ្នក​មិន​ឃើញ​កូដ​ដែល​បាន​បង្កើត​ទេ (ប្រហែល​ជា​ស្ថានភាព​នេះ​ហាក់​ដូច​ជា​មិន​សូវ​ច្រណែន​ចំពោះ​អ្នក​ណា​ម្នាក់?)
• អ្នកត្រូវតែធានាថាប្រភេទអាចត្រូវបានផ្តល់ឱ្យ នោះគឺ "ពិត" ត្រូវតែមានជានិច្ច។ នេះ​ជា​ការ​ងាយ​ស្រួល​ក្នុង​ករណី Lombok ដែល​មាន​ន័យ​ថា "សេចក្តី​ពិត"។ វាមានភាពស្មុគស្មាញបន្តិចជាមួយនឹងគំរូមូលដ្ឋានទិន្នន័យ ដែលពឹងផ្អែកលើការតភ្ជាប់បន្តផ្ទាល់ដែលមានជានិច្ច។

តើការបង្កើតកូដមានបញ្ហាអ្វី?

បន្ថែមពីលើសំណួរដ៏លំបាកអំពីរបៀបដែលល្អបំផុតដើម្បីដំណើរការការបង្កើតកូដ - ដោយដៃ ឬដោយស្វ័យប្រវត្តិ យើងក៏ត្រូវលើកឡើងផងដែរថា មានមនុស្សដែលជឿថាការបង្កើតកូដមិនចាំបាច់ទាល់តែសោះ។ យុត្តិកម្មសម្រាប់ទស្សនៈនេះ ដែលខ្ញុំបានជួបប្រទះញឹកញាប់បំផុត គឺថានៅពេលនោះវាពិបាកក្នុងការរៀបចំបំពង់បង្ហូរប្រេង។ បាទ វាពិតជាពិបាកណាស់។ ការចំណាយលើហេដ្ឋារចនាសម្ព័ន្ធបន្ថែមកើតឡើង។ ប្រសិនបើអ្នកទើបតែចាប់ផ្តើមជាមួយនឹងផលិតផលជាក់លាក់មួយ (មិនថាវាជា jOOQ ឬ JAXB ឬ Hibernate ជាដើម) ការបង្កើតបរិយាកាសផលិតកម្មត្រូវការពេលវេលាដែលអ្នកចង់ចំណាយដើម្បីរៀន API ដោយខ្លួនឯង ដូច្នេះអ្នកអាចទាញយកតម្លៃពីវាបាន .

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

មនុស្សជាច្រើននឹងនិយាយថា ពួកគេមិនមានពេលដើម្បីធ្វើរឿងទាំងអស់នេះទេ។ ពួកគេកំពុងអស់ពេលកំណត់សម្រាប់ Super Product របស់ពួកគេ។ នៅថ្ងៃណាមួយ យើងនឹងរៀបចំឧបករណ៍បញ្ចោញដំឡើង យើងនឹងមានពេល។ ខ្ញុំនឹងឆ្លើយពួកគេ៖

ដើម, Alan O'Rourke, ក្រុមទស្សនិកជន

ប៉ុន្តែនៅក្នុង Hibernate/JPA វាងាយស្រួលណាស់ក្នុងការសរសេរកូដ Java ។

ពិត។ សម្រាប់ Hibernate និងអ្នកប្រើប្រាស់របស់វា នេះគឺជាពរជ័យ និងបណ្តាសា។ នៅក្នុង Hibernate អ្នកអាចសរសេរធាតុពីរយ៉ាងសាមញ្ញដូចនេះ៖

	@Entity
class Book {
  @Id
  int id;
  String title;
}

ហើយស្ទើរតែទាំងអស់គឺរួចរាល់។ ឥឡូវនេះវាអាស្រ័យលើ Hibernate ដើម្បីបង្កើត "ព័ត៌មានលម្អិត" ស្មុគស្មាញនៃរបៀបដែលអង្គភាពនេះនឹងត្រូវបានកំណត់នៅក្នុង DDL នៃ SQL "គ្រាមភាសា" របស់អ្នក៖

	CREATE TABLE book (
  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  title VARCHAR(50),
 
  CONSTRAINT pk_book PRIMARY KEY (id)
);
 
CREATE INDEX i_book_title ON book (title);

... ហើយចាប់ផ្តើមដំណើរការកម្មវិធី។ ពិតជាឱកាសដ៏ល្អដើម្បីចាប់ផ្តើមយ៉ាងឆាប់រហ័ស និងសាកល្បងអ្វីៗផ្សេងៗ។

ទោះយ៉ាងណាក៏ដោយសូមអនុញ្ញាត។ ខ្ញុំ​បាន​កុហក។

• តើ Hibernate ពិត​ជា​អនុវត្ត​និយមន័យ​នៃ​គន្លឹះ​សំខាន់​ដែល​មាន​ឈ្មោះ​នេះ​ឬ?
• តើ Hibernate នឹងបង្កើតលិបិក្រមក្នុង TITLE ដែរឬទេ? - ខ្ញុំដឹងច្បាស់ថាយើងនឹងត្រូវការវា។
• តើ Hibernate នឹងធ្វើឱ្យការកំណត់អត្តសញ្ញាណគន្លឹះនេះយ៉ាងពិតប្រាកដនៅក្នុងការកំណត់អត្តសញ្ញាណដែរឬទេ?

ប្រហែលជា​មិន។ ប្រសិនបើអ្នកកំពុងបង្កើតគម្រោងរបស់អ្នកតាំងពីដំបូង វាតែងតែងាយស្រួលក្នុងការបោះបង់មូលដ្ឋានទិន្នន័យចាស់ ហើយបង្កើតថ្មីមួយភ្លាមៗនៅពេលដែលអ្នកបន្ថែមចំណារពន្យល់ចាំបាច់។ ដូច្នេះ អង្គភាពសៀវភៅនៅទីបំផុតនឹងយកទម្រង់៖

	@Entity
@Table(name = "book", indexes = {
  @Index(name = "i_book_title", columnList = "title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
  String title;
}

ត្រជាក់។ បង្កើតឡើងវិញ។ ជាថ្មីម្តងទៀតក្នុងករណីនេះវានឹងមានភាពងាយស្រួលនៅពេលចាប់ផ្តើម។

ប៉ុន្តែអ្នកនឹងត្រូវចំណាយសម្រាប់វានៅពេលក្រោយ

មិនយូរមិនឆាប់ អ្នកនឹងត្រូវចូលផលិតកម្ម។ នោះហើយជាពេលដែលម៉ូដែលនេះនឹងឈប់ដំណើរការ។ ដោយសារតែ៖

នៅក្នុងការផលិត វានឹងមិនអាចធ្វើទៅបានទេ ប្រសិនបើចាំបាច់ ដើម្បីបោះបង់មូលដ្ឋានទិន្នន័យចាស់ ហើយចាប់ផ្តើមពីដំបូង។ មូលដ្ឋានទិន្នន័យរបស់អ្នកនឹងក្លាយជាមរតក។

ចាប់ពីពេលនេះតទៅ និងជារៀងរហូត អ្នកនឹងត្រូវសរសេរ ជាឧទាហរណ៍ ស្គ្រីបផ្ទេរទិន្នន័យ DDL ដោយប្រើ Flyway. តើនឹងមានអ្វីកើតឡើងចំពោះអង្គភាពរបស់អ្នកក្នុងករណីនេះ? អ្នកអាចសម្របវាដោយដៃ (ហើយដូច្នេះបង្កើនបន្ទុកការងាររបស់អ្នកទ្វេដង) ឬអ្នកអាចប្រាប់ Hibernate ឱ្យបង្កើតវាឡើងវិញសម្រាប់អ្នក (តើអ្នកបង្កើតវាតាមរបៀបនេះទំនងយ៉ាងណាដើម្បីបំពេញតាមការរំពឹងទុករបស់អ្នក?) វិធីណាក៏ដោយ អ្នកចាញ់។

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

ផ្ទុយទៅវិញ អ្វីៗអាចត្រូវបានធ្វើខុសពីដើមទាំងស្រុង។ ជាឧទាហរណ៍ ដាក់កង់មូលលើកង់។

មូលដ្ឋានទិន្នន័យដំបូង

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

លើសពីនេះទៅទៀត នោះមិនមែនទាំងអស់នោះទេ។ ជាឧទាហរណ៍ ដោយប្រើ Oracle អ្នកប្រហែលជាចង់បញ្ជាក់៖

• តើតារាងរបស់អ្នកស្ថិតនៅលើតុអ្វី?
• តើតម្លៃ PCTFRE របស់វាគឺជាអ្វី?
• តើទំហំឃ្លាំងសម្ងាត់នៅក្នុងលំដាប់របស់អ្នកគឺជាអ្វី (នៅពីក្រោយលេខសម្គាល់)

នេះប្រហែលជាមិនសំខាន់នៅក្នុងប្រព័ន្ធតូចទេ ប៉ុន្តែអ្នកមិនចាំបាច់រង់ចាំរហូតដល់អ្នកផ្លាស់ទីទៅក្នុងអាណាចក្រទិន្នន័យធំនោះទេ - អ្នកអាចចាប់ផ្តើមទទួលបានអត្ថប្រយោជន៍ពីការបង្កើនប្រសិទ្ធភាពទំហំផ្ទុកដែលផ្តល់ដោយអ្នកលក់ដូចអ្វីដែលបានរៀបរាប់ខាងលើកាន់តែឆាប់។ គ្មាន ORMs ណាមួយដែលខ្ញុំបានឃើញទេ (រួមទាំង jOOQ) ផ្តល់នូវការចូលទៅកាន់សំណុំពេញលេញនៃជម្រើស DDL ដែលអ្នកប្រហែលជាចង់ប្រើនៅក្នុងមូលដ្ឋានទិន្នន័យរបស់អ្នក។ ORMs ផ្តល់ជូននូវឧបករណ៍មួយចំនួនដែលជួយអ្នកក្នុងការសរសេរ DDL ។

ប៉ុន្តែនៅចុងបញ្ចប់នៃថ្ងៃ សៀគ្វីដែលបានរចនាយ៉ាងល្អត្រូវបានសរសេរដោយដៃនៅក្នុង DDL ។ DDL ណាមួយដែលបានបង្កើតគឺគ្រាន់តែជាការប៉ាន់ស្មានរបស់វាប៉ុណ្ណោះ។

ចុះម៉ូដែលអតិថិជនវិញ?

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

មូលដ្ឋានទិន្នន័យទាំងអស់ផ្តល់ព័ត៌មានមេតារបស់ពួកគេតាមរយៈ SQL ។ នេះជារបៀបយកតារាងទាំងអស់ពីមូលដ្ឋានទិន្នន័យរបស់អ្នកក្នុងគ្រាមភាសា SQL ផ្សេងៗគ្នា៖

	-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables
 
-- DB2
SELECT tabschema, tabname
FROM syscat.tables
 
-- Oracle
SELECT owner, table_name
FROM all_tables
 
-- SQLite
SELECT name
FROM sqlite_master
 
-- Teradata
SELECT databasename, tablename
FROM dbc.tables

សំណួរទាំងនេះ (ឬស្រដៀងគ្នា អាស្រ័យលើថាតើអ្នកក៏ត្រូវពិចារណាលើទិដ្ឋភាព ទិដ្ឋភាពជាក់ស្តែង មុខងារតារាងតម្លៃ) ក៏ត្រូវបានប្រតិបត្តិដោយការហៅទូរសព្ទ។ DatabaseMetaData.getTables() ពី JDBC ឬប្រើម៉ូឌុលមេតា jOOQ ។

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

• ប្រសិនបើអ្នកកំពុងប្រើ JDBC ឬ Spring អ្នកអាចបង្កើតសំណុំនៃខ្សែអក្សរថេរ
• ប្រសិនបើអ្នកប្រើ JPA អ្នកអាចបង្កើតអង្គភាពដោយខ្លួនឯង។
• ប្រសិនបើអ្នកប្រើ jOOQ អ្នកអាចបង្កើតគំរូមេតា jOOQ

អាស្រ័យលើមុខងារជាច្រើនដែលត្រូវបានផ្តល់ជូនដោយ API អតិថិជនរបស់អ្នក (ឧទាហរណ៍ jOOQ ឬ JPA) គំរូមេតាដែលបានបង្កើតអាចពិតជាសម្បូរបែប និងពេញលេញ។ យកឧទាហរណ៍លទ្ធភាពនៃការចូលរួមដោយប្រយោល, ណែនាំនៅក្នុង jOOQ 3.11ដែលពឹងផ្អែកលើព័ត៌មានមេតាដែលបានបង្កើតអំពីទំនាក់ទំនងគន្លឹះបរទេសដែលមានរវាងតារាងរបស់អ្នក។

ឥឡូវនេះការបង្កើនមូលដ្ឋានទិន្នន័យណាមួយនឹងធ្វើបច្ចុប្បន្នភាពកូដអតិថិជនដោយស្វ័យប្រវត្តិ។ ស្រមៃមើលឧទាហរណ៍៖

ALTER TABLE book RENAME COLUMN title TO book_title;

តើអ្នកពិតជាចង់ធ្វើការងារនេះពីរដងទេ? ក្នុងករណីណាទេ។ ដោយគ្រាន់តែអនុវត្ត DDL ដំណើរការវាតាមរយៈបំពង់បង្កើតរបស់អ្នក ហើយទទួលបានអង្គភាពដែលបានធ្វើបច្ចុប្បន្នភាព៖

@Entity
@Table(name = "book", indexes = {
 
  // Вы об этом задумывались?
  @Index(name = "i_book_title", columnList = "book_title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
 
  @Column("book_title")
  String bookTitle;
}

ឬថ្នាក់ jOOQ ដែលបានធ្វើបច្ចុប្បន្នភាព។ ការផ្លាស់ប្តូរ DDL ភាគច្រើនក៏ជះឥទ្ធិពលលើអត្ថន័យ មិនត្រឹមតែវាក្យសម្ព័ន្ធប៉ុណ្ណោះទេ។ ដូច្នេះ វាអាចមានប្រយោជន៍ក្នុងការរកមើលនៅក្នុងកូដដែលបានចងក្រង ដើម្បីមើលថាតើកូដអ្វីនឹង (ឬអាច) រងផលប៉ះពាល់ដោយការបង្កើនមូលដ្ឋានទិន្នន័យរបស់អ្នក។

ការពិតតែមួយគត់

មិនថាអ្នកប្រើបច្ចេកវិទ្យាណាក៏ដោយ វាតែងតែមានគំរូមួយដែលជាប្រភពនៃការពិតសម្រាប់ប្រព័ន្ធរងមួយចំនួន ឬយ៉ាងហោចណាស់ យើងគួរតែខិតខំសម្រាប់រឿងនេះ ហើយជៀសវាងការភាន់ច្រឡំបែបនេះ ដែល "ការពិត" មាននៅគ្រប់ទីកន្លែង និងគ្មានកន្លែងណាក្នុងពេលតែមួយ។ . អ្វីគ្រប់យ៉ាងអាចកាន់តែសាមញ្ញ។ ប្រសិនបើអ្នកគ្រាន់តែផ្លាស់ប្តូរឯកសារ XML ជាមួយប្រព័ន្ធផ្សេងទៀត គ្រាន់តែប្រើ XSD ។ សូមក្រឡេកមើល INFORMATION_SCHEMA គំរូមេតាពី jOOQ ក្នុងទម្រង់ XML៖
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD ត្រូវបានយល់ច្បាស់
• XSD tokenizes មាតិកា XML បានយ៉ាងល្អហើយអនុញ្ញាតឱ្យមានសុពលភាពនៅក្នុងភាសាអតិថិជនទាំងអស់។
• XSD គឺ​មាន​កំណែ​ទម្រង់​យ៉ាង​ល្អ និង​មាន​ភាព​ឆប​គ្នា​ថយ​ក្រោយ​កម្រិត​ខ្ពស់​
• XSD អាចត្រូវបានបកប្រែទៅជាកូដ Java ដោយប្រើ XJC

ចំណុចចុងក្រោយគឺសំខាន់។ នៅពេលទំនាក់ទំនងជាមួយប្រព័ន្ធខាងក្រៅដោយប្រើសារ XML យើងចង់ប្រាកដថាសាររបស់យើងត្រឹមត្រូវ។ វាងាយស្រួលណាស់ក្នុងការសម្រេចបានដោយប្រើ JAXB, XJC និង XSD ។ វាជាការឆ្កួតមែនទែនក្នុងការគិតថា ជាមួយនឹងវិធីសាស្រ្តរចនា "Java first" ដែលយើងបង្កើតសាររបស់យើងជាវត្ថុ Java ថាពួកគេអាចត្រូវបានគេធ្វើផែនទីយ៉ាងស៊ីសង្វាក់គ្នាទៅនឹង XML ហើយបញ្ជូនទៅប្រព័ន្ធមួយផ្សេងទៀតសម្រាប់ប្រើប្រាស់។ XML ដែលបង្កើតតាមវិធីនេះនឹងមានគុណភាពអន់ខ្លាំង គ្មានឯកសារ និងពិបាកក្នុងការអភិវឌ្ឍ។ ប្រសិនបើមានកិច្ចព្រមព្រៀងកម្រិតសេវាកម្ម (SLA) សម្រាប់ចំណុចប្រទាក់បែបនេះ យើងនឹងដោះស្រាយវាភ្លាមៗ។

និយាយតាមត្រង់ នេះជាអ្វីដែលកើតឡើងគ្រប់ពេលជាមួយ JSON APIs ប៉ុន្តែនោះជារឿងមួយទៀត ខ្ញុំនឹងឈ្លោះគ្នាលើកក្រោយ...

មូលដ្ឋានទិន្នន័យ៖ ពួកគេគឺដូចគ្នា។

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

នៅពេលដែលការអាប់ដេតប្រភពបានកើតឡើង អតិថិជនទាំងអស់ត្រូវតែធ្វើបច្ចុប្បន្នភាពច្បាប់ចម្លងនៃគំរូរបស់ពួកគេផងដែរ។ អតិថិជនមួយចំនួនអាចត្រូវបានសរសេរជា Java ដោយប្រើ jOOQ និង Hibernate ឬ JDBC (ឬទាំងពីរ) ។ អតិថិជនផ្សេងទៀតអាចត្រូវបានសរសេរនៅក្នុង Perl (យើងគ្រាន់តែជូនពរឱ្យពួកគេសំណាងល្អ) ខណៈពេលដែលអ្នកផ្សេងទៀតអាចត្រូវបានសរសេរនៅក្នុង C# ។ វាមិនសំខាន់ទេ។ គំរូសំខាន់គឺនៅក្នុងមូលដ្ឋានទិន្នន័យ។ ម៉ូដែលដែលបង្កើតដោយប្រើ ORMs ជាធម្មតាមានគុណភាពអន់ ឯកសារមិនសូវល្អ និងពិបាកក្នុងការអភិវឌ្ឍ។

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

កុំ​អរគុណ​ខ្ញុំ​នៅ​ពេល​ក្រោយ។

ការពន្យល់

ដើម្បីឱ្យច្បាស់៖ អត្ថបទនេះមិនមានវិធីតស៊ូមតិដែលអ្នកត្រូវការពត់ប្រព័ន្ធទាំងមូល (ឧ. ដែន តក្កវិជ្ជាអាជីវកម្ម។ល។) ដើម្បីឱ្យសមនឹងគំរូមូលដ្ឋានទិន្នន័យរបស់អ្នក។ អ្វីដែលខ្ញុំកំពុងនិយាយនៅក្នុងអត្ថបទនេះគឺថា កូដអតិថិជនដែលមានអន្តរកម្មជាមួយមូលដ្ឋានទិន្នន័យគួរតែធ្វើសកម្មភាពនៅលើមូលដ្ឋាននៃគំរូមូលដ្ឋានទិន្នន័យ ដូច្នេះវាមិនបង្កើតគំរូមូលដ្ឋានទិន្នន័យឡើងវិញក្នុងស្ថានភាព "ថ្នាក់ដំបូង" នោះទេ។ តក្កវិជ្ជានេះជាធម្មតាមានទីតាំងនៅស្រទាប់ចូលប្រើទិន្នន័យនៅលើម៉ាស៊ីនភ្ញៀវរបស់អ្នក។

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

ករណីលើកលែង

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

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

ករណីលើកលែងគឺដោយធម្មជាតិ។ ក្នុងករណីភាគច្រើនដែលពាក់ព័ន្ធនឹងការប្រើប្រាស់ RDBMS គ្រោងការណ៍ត្រូវបានគេដឹងជាមុន វាស្ថិតនៅក្នុង RDBMS និងជាប្រភពតែមួយគត់នៃ "ការពិត" ហើយអតិថិជនទាំងអស់ត្រូវតែទទួលបានច្បាប់ចម្លងដែលបានមកពីវា។ តាមឧត្ដមគតិអ្នកត្រូវប្រើម៉ាស៊ីនបង្កើតកូដ។

ប្រភព: www.habr.com