ប្រព័ន្ធព័ត៌មានទំនើបគឺស្មុគស្មាញណាស់។ យ៉ាងហោចណាស់ភាពស្មុគស្មាញរបស់ពួកគេគឺដោយសារតែភាពស្មុគស្មាញនៃទិន្នន័យដែលបានដំណើរការនៅក្នុងពួកគេ។ ភាពស្មុគស្មាញនៃទិន្នន័យច្រើនតែស្ថិតនៅក្នុងភាពខុសគ្នានៃគំរូទិន្នន័យដែលបានប្រើ។ ដូច្នេះ ជាឧទាហរណ៍ នៅពេលដែលទិន្នន័យក្លាយជា "ធំ" លក្ខណៈបញ្ហាមួយគឺមិនត្រឹមតែបរិមាណរបស់វា ("បរិមាណ") ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានភាពខុសគ្នារបស់វាផងដែរ ("ភាពខុសគ្នា") ។

ប្រសិនបើអ្នកមិនទាន់រកឃើញកំហុសក្នុងការវែកញែកទេ សូមអានបន្ត។

មាតិកា

ភាពស្ថិតស្ថេរ Polyglot
ច្រើនម៉ូដែល
DBMS ច្រើនម៉ូដែលផ្អែកលើគំរូទំនាក់ទំនង
     គំរូឯកសារនៅក្នុង MS SQL Server
     គំរូក្រាហ្វិកនៅក្នុង MS SQL Server
DBMS ច្រើនម៉ូដែលផ្អែកលើគំរូឯកសារ
     គំរូទំនាក់ទំនងនៅក្នុង MarkLogic
     គំរូក្រាហ្វនៅក្នុង MarkLogic
DBMS ពហុម៉ូដែល "ដោយគ្មានគំរូសំខាន់"
     អារ៉ាន់ដូឌី
     OrientDB ។
     Azure CosmosDB
DBMS ច្រើនម៉ូដែលផ្អែកលើគំរូក្រាហ្វ?
សេចក្តីសន្និដ្ឋាន
ការស្ទង់មតិ

ភាពស្ថិតស្ថេរ Polyglot

ខាងលើនាំឱ្យការពិតដែលថាជួនកាលសូម្បីតែនៅក្នុងក្របខ័ណ្ឌនៃប្រព័ន្ធមួយក៏ចាំបាច់ត្រូវប្រើ DBMSs ផ្សេងៗគ្នាជាច្រើនដើម្បីរក្សាទុកទិន្នន័យ និងដោះស្រាយបញ្ហាផ្សេងៗនៃដំណើរការពួកវា ដែលនីមួយៗគាំទ្រគំរូទិន្នន័យផ្ទាល់ខ្លួនរបស់វា។ ជាមួយនឹងដៃស្រាលរបស់ M. Fowler, អ្នកនិពន្ធ សៀវភៅល្បីៗមួយចំនួន និងសៀវភៅមួយក្បាល សហអ្នកនិពន្ធ Agile Manifesto, ស្ថានភាពនេះត្រូវបានគេហៅថា ការផ្ទុកពហុវ៉ារ្យ៉ង់ ("ការតស៊ូពហុកោណ") ។

Fowler ក៏មានឧទាហរណ៍ខាងក្រោមនៃការរៀបចំការផ្ទុកទិន្នន័យនៅក្នុងកម្មវិធីដែលមានលក្ខណៈពេញលេញ និងផ្ទុកខ្ពស់ក្នុងវិស័យពាណិជ្ជកម្មអេឡិចត្រូនិក។

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

វាច្បាស់ណាស់ថាការធ្វើជាអ្នកបំរើក្នុងសួនសត្វបែបនេះមិនងាយស្រួលនោះទេ។

• បរិមាណនៃកូដដែលដំណើរការការផ្ទុកទិន្នន័យកើនឡើងតាមសមាមាត្រទៅនឹងចំនួន DBMSs ដែលបានប្រើ។ ចំនួននៃទិន្នន័យដែលធ្វើសមកាលកម្មកូដគឺល្អប្រសិនបើមិនសមាមាត្រទៅនឹងការេនៃលេខនេះ។
• ក្នុងនាមជាពហុគុណនៃចំនួន DBMSs ដែលបានប្រើ ការចំណាយលើការផ្តល់នូវលក្ខណៈសហគ្រាស (ការធ្វើមាត្រដ្ឋាន ការអត់ធ្មត់កំហុស ភាពអាចរកបានខ្ពស់) នៃ DBMSs នីមួយៗដែលបានប្រើកើនឡើង។
• វាមិនអាចទៅរួចទេក្នុងការធានានូវលក្ខណៈសហគ្រាសនៃប្រព័ន្ធរងការផ្ទុកទាំងមូល - ជាពិសេសប្រតិបត្តិការ។

តាមទស្សនៈរបស់នាយកសួនសត្វ អ្វីៗមើលទៅដូចនេះ៖

• ការកើនឡើងច្រើននៃថ្លៃអាជ្ញាប័ណ្ណ និងជំនួយបច្ចេកទេសពីក្រុមហ៊ុនផលិត DBMS ។
• បុគ្គលិក​លើស​និង​បង្កើន​កាល​បរិច្ឆេទ។
• ការខាតបង់ផ្នែកហិរញ្ញវត្ថុដោយផ្ទាល់ ឬការពិន័យដោយសារតែទិន្នន័យមិនស៊ីសង្វាក់គ្នា។

មានការកើនឡើងគួរឱ្យកត់សម្គាល់នៅក្នុងការចំណាយសរុបនៃកម្មសិទ្ធិ (TCO) របស់ប្រព័ន្ធ។ តើមានផ្លូវចេញពីស្ថានភាព "ជម្រើសផ្ទុកច្រើន" ទេ?

ច្រើនម៉ូដែល

ពាក្យ "ការផ្ទុកចម្រុះ" បានចូលប្រើក្នុងឆ្នាំ 2011 ។ ការយល់ដឹងអំពីបញ្ហានៃវិធីសាស្រ្ត និងការស្វែងរកដំណោះស្រាយបានចំណាយពេលជាច្រើនឆ្នាំ ហើយនៅឆ្នាំ 2015 តាមរយៈមាត់របស់អ្នកវិភាគ Gartner ចម្លើយត្រូវបានបង្កើតឡើង:

• ពី "មគ្គុទ្ទេសក៍ទីផ្សារសម្រាប់ NoSQL DBMSs - 2015»:
  

  អនាគតនៃ DBMSs ស្ថាបត្យកម្ម និងវិធីប្រើប្រាស់ពួកវាគឺពហុគំរូ។

• ពី "Magic Quadrant សម្រាប់ ODBMS - 2016»:
  

  DBMSs ប្រតិបត្តិការឈានមុខគេនឹងផ្តល់ជូននូវម៉ូដែលជាច្រើន - ទំនាក់ទំនងនិងមិនទាក់ទង - ជាផ្នែកនៃវេទិកាតែមួយ។

វាហាក់ដូចជាថាពេលនេះអ្នកវិភាគ Gartner ត្រឹមត្រូវជាមួយនឹងការព្យាករណ៍របស់ពួកគេ។ ប្រសិនបើអ្នកចូលទៅកាន់ទំព័រជាមួយ ការវាយតម្លៃចម្បង DBMS នៅលើ DB-Engines អ្នកអាចឃើញវា។оអ្នកដឹកនាំភាគច្រើនកំណត់ខ្លួនឯងជាពិសេសថាជា DBMSs ពហុគំរូ។ ដូចគ្នានេះដែរអាចត្រូវបានគេមើលឃើញនៅលើទំព័រជាមួយនឹងការវាយតម្លៃឯកជនណាមួយ។

តារាងខាងក្រោមបង្ហាញពី DBMS - អ្នកដឹកនាំនៅក្នុងការវាយតម្លៃឯកជននីមួយៗ ដែលអះអាងថាជាពហុគំរូ។ សម្រាប់ DBMS នីមួយៗ គំរូដែលបានគាំទ្រដើម (ដែលធ្លាប់មានតែមួយ) ហើយរួមជាមួយវា ម៉ូដែលដែលបានគាំទ្របច្ចុប្បន្នត្រូវបានចង្អុលបង្ហាញ។ ក្នុងបញ្ជីផងដែរគឺ DBMSs ដែលដាក់ខ្លួនឯងថាជា "គំរូដើមច្រើន" ហើយយោងទៅតាមអ្នកបង្កើត មិនមានគំរូទទួលមរតកដំបូងឡើយ។

កំណត់ចំណាំនៅលើតុ

សញ្ញាផ្កាយនៅក្នុងតារាងសម្គាល់សេចក្តីថ្លែងការណ៍ដែលទាមទារការកក់ទុក៖

• PostgreSQL DBMS មិនគាំទ្រគំរូទិន្នន័យក្រាហ្វទេ ប៉ុន្តែផលិតផលនេះគាំទ្រវា។ ផ្អែកលើវា។ដូចជា AgensGraph ។
• ទាក់ទងនឹង MongoDB វាកាន់តែត្រឹមត្រូវក្នុងការនិយាយអំពីវត្តមានរបស់ប្រតិបត្តិករក្រាហ្វក្នុងភាសាសំណួរ ($lookup, $graphLookup) ជាងអំពីការគាំទ្រគំរូក្រាហ្វ ទោះបីជាជាការពិតណាស់ ការណែនាំរបស់ពួកគេតម្រូវឱ្យមានការបង្កើនប្រសិទ្ធភាពមួយចំនួននៅកម្រិតផ្ទុករាងកាយក្នុងទិសដៅនៃការគាំទ្រគំរូក្រាហ្វ។
• ទាក់ទងទៅនឹង Redis យើងមានន័យថាផ្នែកបន្ថែម RedisGraph.

បន្ទាប់ សម្រាប់ថ្នាក់នីមួយៗ យើងនឹងបង្ហាញពីរបៀបដែលការគាំទ្រសម្រាប់ម៉ូដែលជាច្រើនត្រូវបានអនុវត្តនៅក្នុង DBMS ពីថ្នាក់នេះ។ យើងនឹងពិចារណាគំរូទំនាក់ទំនង ឯកសារ និងក្រាហ្វជាគំរូសំខាន់បំផុត ហើយប្រើឧទាហរណ៍នៃ DBMSs ជាក់លាក់ ដើម្បីបង្ហាញពីរបៀបដែល "បាត់" ត្រូវបានអនុវត្ត។

DBMS ច្រើនម៉ូដែលផ្អែកលើគំរូទំនាក់ទំនង

DBMSs ឈានមុខគេនាពេលបច្ចុប្បន្ននេះគឺជាការទាក់ទងគ្នា; ហើយពួកគេធ្វើបាតុកម្ម។ ឥឡូវនេះគំនិតដែលថា DBMS ពហុម៉ូដែលគឺដូចជាកាំបិតស្វីស ដែលមិនអាចធ្វើអ្វីបានល្អនោះ អាចត្រូវបានដឹកនាំដោយផ្ទាល់ទៅលោក Larry Ellison ។

ទោះយ៉ាងណាក៏ដោយ អ្នកនិពន្ធចូលចិត្តការអនុវត្តគំរូច្រើននៅក្នុង Microsoft SQL Server លើឧទាហរណ៍ដែលការគាំទ្រ RDBMS សម្រាប់គំរូឯកសារ និងក្រាហ្វនឹងត្រូវបានពិពណ៌នា។

គំរូឯកសារនៅក្នុង MS SQL Server

មានអត្ថបទដ៏ល្អចំនួនពីររួចហើយនៅលើHabre អំពីរបៀបដែល MS SQL Server អនុវត្តការគាំទ្រសម្រាប់គំរូឯកសារ ខ្ញុំនឹងដាក់កម្រិតខ្លួនខ្ញុំចំពោះការនិយាយឡើងវិញ និងអត្ថាធិប្បាយសង្ខេប៖

• ធ្វើការជាមួយ JSON នៅក្នុង SQL Server 2016
• SQL Server 2017 JSON

វិធីដើម្បីគាំទ្រគំរូឯកសារនៅក្នុង MS SQL Server គឺជារឿងធម្មតាសម្រាប់ DBMSs ទំនាក់ទំនង៖ ឯកសារ JSON ត្រូវបានស្នើឱ្យរក្សាទុកក្នុងវាលអត្ថបទធម្មតា។ ការគាំទ្រសម្រាប់គំរូឯកសារគឺផ្តល់ប្រតិបត្តិករពិសេសដើម្បីញែក JSON នេះ៖

• JSON_VALUE ដើម្បីទាញយកតម្លៃគុណលក្ខណៈ scalar,
• JSON_QUERY ដើម្បីទាញយកឯកសាររង។

អាគុយម៉ង់ទីពីរនៃប្រតិបត្តិករទាំងពីរគឺជាកន្សោមនៅក្នុងវាក្យសម្ព័ន្ធដូច JSONPath ។

សរុបមក យើងអាចនិយាយបានថាឯកសារដែលរក្សាទុកតាមរបៀបនេះមិនមែនជា "អង្គភាពលំដាប់ទីមួយ" នៅក្នុងទំនាក់ទំនង DBMS មិនដូច tuples ទេ។ ជាពិសេសនៅក្នុង MS SQL Server បច្ចុប្បន្នមិនមានលិបិក្រមនៅលើវាលនៃឯកសារ JSON ដែលធ្វើឱ្យវាពិបាកក្នុងការចូលរួមតារាងដោយប្រើតម្លៃនៃវាលទាំងនេះ ហើយថែមទាំងជ្រើសរើសឯកសារដោយប្រើតម្លៃទាំងនេះទៀតផង។ ទោះយ៉ាងណាក៏ដោយ វាអាចបង្កើតជួរឈរដែលបានគណនាសម្រាប់វាលបែបនេះ និងសន្ទស្សន៍នៅលើវា។

លើសពីនេះទៀត MS SQL Server ផ្តល់នូវសមត្ថភាពក្នុងការបង្កើតឯកសារ JSON យ៉ាងងាយស្រួលពីមាតិកានៃតារាងដោយប្រើប្រតិបត្តិករ។ FOR JSON PATH - លទ្ធភាពមួយ ក្នុងន័យជាក់លាក់មួយ ទល់មុខនឹងមួយមុន ការផ្ទុកធម្មតា។ វាច្បាស់ណាស់ថាមិនថា RDBMS លឿនប៉ុណ្ណានោះទេ វិធីសាស្រ្តនេះផ្ទុយនឹងមនោគមវិជ្ជានៃឯកសារ DBMSs ដែលរក្សាទុកចម្លើយដែលត្រៀមរួចជាស្រេចសម្រាប់សំណួរពេញនិយម ហើយអាចដោះស្រាយបញ្ហាភាពងាយស្រួលនៃការអភិវឌ្ឍន៍ ប៉ុន្តែមិនមែនល្បឿនទេ។

ជាចុងក្រោយ MS SQL Server អនុញ្ញាតឱ្យអ្នកដោះស្រាយបញ្ហាផ្ទុយនៃការសាងសង់ឯកសារ៖ អ្នកអាចបំបែក JSON ទៅជាតារាងដោយប្រើ OPENJSON. ប្រសិនបើឯកសារមិនរាបស្មើទាំងស្រុងទេ អ្នកនឹងត្រូវប្រើ CROSS APPLY.

គំរូក្រាហ្វិកនៅក្នុង MS SQL Server

ការគាំទ្រសម្រាប់គំរូក្រាហ្វ (LPG) ក៏ត្រូវបានអនុវត្តយ៉ាងពេញលេញនៅក្នុង Microsoft SQL Server ផងដែរ។ អាចទស្សន៍ទាយបាន។៖ វាត្រូវបានស្នើឱ្យប្រើតារាងពិសេសដើម្បីរក្សាទុកថ្នាំង និងរក្សាទុកគែមក្រាហ្វ។ តារាងបែបនេះត្រូវបានបង្កើតដោយប្រើកន្សោម CREATE TABLE AS NODE и CREATE TABLE AS EDGE រៀងគ្នា។

តារាងនៃប្រភេទទីមួយគឺស្រដៀងទៅនឹងតារាងធម្មតាសម្រាប់រក្សាទុកកំណត់ត្រា ដោយភាពខុសគ្នាខាងក្រៅតែមួយគត់គឺថាតារាងមានវាលប្រព័ន្ធ។ $node_id - ការកំណត់អត្តសញ្ញាណតែមួយគត់នៃថ្នាំងក្រាហ្វក្នុងមូលដ្ឋានទិន្នន័យ។

ដូចគ្នានេះដែរតារាងនៃប្រភេទទីពីរមានវាលប្រព័ន្ធ $from_id и $to_idធាតុនៅក្នុងតារាងបែបនេះកំណត់យ៉ាងច្បាស់នូវការតភ្ជាប់រវាងថ្នាំង។ តារាងដាច់ដោយឡែកមួយត្រូវបានប្រើដើម្បីរក្សាទុកទំនាក់ទំនងនៃប្រភេទនីមួយៗ។

ចូរយើងលើកឧទាហរណ៍នេះមកបង្ហាញ។ អនុញ្ញាតឱ្យទិន្នន័យក្រាហ្វមានប្លង់ដូចដែលបានបង្ហាញក្នុងរូប។ បន្ទាប់មកដើម្បីបង្កើតរចនាសម្ព័ន្ធដែលត្រូវគ្នានៅក្នុងមូលដ្ឋានទិន្នន័យ អ្នកត្រូវដំណើរការសំណួរ DDL ខាងក្រោម៖

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

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

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

លើសពីនេះទៅទៀត វាពិតជាលំបាកណាស់ក្នុងការមិនប្រើគំរូក្រាហ្វទាំងនេះ នៅពេលធ្វើការជាមួយតារាងបែបនេះ ចាប់តាំងពីនៅក្នុងសំណួរ SQL ធម្មតាដើម្បីដោះស្រាយបញ្ហាស្រដៀងគ្នា វានឹងចាំបាច់ក្នុងការខិតខំប្រឹងប្រែងបន្ថែមទៀតដើម្បីទទួលបានប្រព័ន្ធ "ក្រាហ្វ" ឧបករណ៍កំណត់អត្តសញ្ញាណថ្នាំង ($node_id, $from_id, $to_id; សម្រាប់ហេតុផលដូចគ្នា សំណួរសម្រាប់ការបញ្ចូលទិន្នន័យមិនត្រូវបានបង្ហាញនៅទីនេះទេ ដោយសារវាស្មុគស្មាញដោយមិនចាំបាច់)។

ដើម្បីសង្ខេបការពិពណ៌នាអំពីការអនុវត្តនៃគំរូឯកសារ និងក្រាហ្វនៅក្នុង MS SQL Server ខ្ញុំនឹងកត់សម្គាល់ថាការអនុវត្តបែបនេះនៃគំរូមួយនៅលើកំពូលនៃគំរូមួយផ្សេងទៀតហាក់ដូចជាមិនជោគជ័យទេ ជាចម្បងពីទស្សនៈនៃការរចនាភាសា។ វាចាំបាច់ក្នុងការពង្រីកភាសាមួយជាមួយភាសាមួយទៀត ភាសាមិនមែន "រាងពងក្រពើ" ទាំងស្រុងនោះទេ ច្បាប់នៃភាពត្រូវគ្នាអាចមានភាពចម្លែកណាស់។

DBMS ច្រើនម៉ូដែលផ្អែកលើគំរូឯកសារ

នៅក្នុងផ្នែកនេះ ខ្ញុំចង់បង្ហាញពីការអនុវត្តពហុគំរូនៅក្នុងឯកសារ DBMSs ដោយប្រើឧទាហរណ៍នៃការមិនពេញនិយមបំផុតរបស់ពួកគេ MongoDB (ដូចដែលបាននិយាយ វាមានតែប្រតិបត្តិករក្រាហ្វិកតាមលក្ខខណ្ឌប៉ុណ្ណោះ $lookup и $graphLookupមិនដំណើរការលើការប្រមូលដែលបានបែងចែក) ប៉ុន្តែការប្រើឧទាហរណ៍នៃ DBMS កាន់តែចាស់ទុំ និង "សហគ្រាស" ម៉ាកឡាក់.

ដូច្នេះ អនុញ្ញាតឱ្យការប្រមូលមានសំណុំឯកសារ XML នៃប្រភេទខាងក្រោម (MarkLogic ក៏អនុញ្ញាតឱ្យអ្នករក្សាទុកឯកសារ JSON)៖

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

គំរូទំនាក់ទំនងនៅក្នុង MarkLogic

ទិដ្ឋភាពទំនាក់ទំនងនៃបណ្តុំឯកសារអាចត្រូវបានបង្កើតដោយប្រើ បង្ហាញគំរូ (ខ្លឹមសារនៃធាតុ value ក្នុងឧទាហរណ៍ខាងក្រោមអាចមាន XPath បំពាន)៖

<template >
  <context>/Person</context>
  <rows>
    <row>
      <view-name>Person</view-name>
      <columns>
        <column>
          <name>SSN</name>
          <value>@SSN</value>
          <type>string</type>
        </column>
        <column>
          <name>name</name>
          <value>name</value>
        </column>
        <column>
          <name>surname</name>
          <value>surname</value>
        </column>
      </columns>
    </row>
  <rows>
</template>

អ្នកអាចដោះស្រាយទិដ្ឋភាពដែលបានបង្កើតដោយប្រើសំណួរ SQL (ឧទាហរណ៍តាមរយៈ ODBC)៖

SELECT name, surname FROM Person WHERE name="John"

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

គំរូក្រាហ្វនៅក្នុង MarkLogic

ជាមួយនឹងការគាំទ្រសម្រាប់គំរូក្រាហ្វ (RDF) អ្វីគ្រប់យ៉ាងគឺដូចគ្នា។ ម្តងទៀតជាមួយនឹងជំនួយ បង្ហាញគំរូ អ្នកអាចបង្កើតតំណាង RDF នៃបណ្តុំឯកសារពីឧទាហរណ៍ខាងលើ៖

<template >
  <context>/Person</context>
    <vars>
      <var>
        <name>PREFIX</name>
        <val>"http://example.org/example#"</val>
      </var>
    </vars>
  <triples>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
      <object><value>xs:string( surname )</value></object>
    </triple>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || name )</value></predicate>
      <object><value>xs:string( name )</value></object>
    </triple>
  </triples>
  </template>

អ្នកអាចដោះស្រាយក្រាហ្វ RDF លទ្ធផលជាមួយនឹងសំណួរ SPARQL៖

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

មិនដូចទំនាក់ទំនងមួយ MarkLogic គាំទ្រគំរូក្រាហ្វតាមពីរវិធីផ្សេងទៀត៖

1. DBMS អាចជាការផ្ទុកទិន្នន័យ RDF ដាច់ដោយឡែកពេញលេញ (បីដងនៅក្នុងវានឹងត្រូវបានគេហៅថា គ្រប់គ្រង ផ្ទុយទៅនឹងអ្វីដែលបានពិពណ៌នាខាងលើ ដកស្រង់).
2. RDF នៅក្នុងសៀរៀលពិសេសអាចត្រូវបានបញ្ចូលទៅក្នុងឯកសារ XML ឬ JSON (ហើយបីដងនឹងត្រូវបានគេហៅថា មិនអាចគ្រប់គ្រងបាន) នេះប្រហែលជាជម្រើសមួយសម្រាប់យន្តការ idref និងអ្នកដទៃ។

គំនិតដ៏ល្អនៃរបៀបដែលអ្វីៗ "ពិតជា" ដំណើរការនៅក្នុង MarkLogic ត្រូវបានផ្តល់ឱ្យដោយ API អុបទិកក្នុងន័យនេះ វាមានកម្រិតទាប បើទោះបីជាគោលបំណងរបស់វាគឺផ្ទុយពីនេះ - ដើម្បីព្យាយាមអរូបីពីគំរូទិន្នន័យដែលបានប្រើ ដើម្បីធានាបាននូវការងារស្របគ្នាជាមួយនឹងទិន្នន័យនៅក្នុងគំរូផ្សេងៗ ប្រតិបត្តិការ។ល។

DBMS ពហុម៉ូដែល "ដោយគ្មានគំរូសំខាន់"

វាក៏មាន DBMSs នៅលើទីផ្សារដែលដាក់ខ្លួនពួកគេថាជាពហុគំរូដំបូង ដោយគ្មានគំរូមេដែលបានទទួលមរតក។ ទាំងនេះ​រួម​បញ្ចូល​ទាំង អារ៉ាន់ដូឌី, OrientDB ។ (ចាប់តាំងពីឆ្នាំ 2018 ក្រុមហ៊ុនអភិវឌ្ឍន៍ជាកម្មសិទ្ធិរបស់ SAP) និង CosmosDB (សេវាកម្មជាផ្នែកមួយនៃវេទិកាពពក Microsoft Azure) ។

តាមពិតមានគំរូ "ស្នូល" នៅក្នុង ArangoDB និង OrientDB ។ ក្នុងករណីទាំងពីរ ទាំងនេះគឺជាគំរូទិន្នន័យផ្ទាល់ខ្លួនរបស់ពួកគេ ដែលជាការធ្វើឱ្យទូទៅនៃឯកសារមួយ។ ការធ្វើទូទៅជាចម្បងដើម្បីជួយសម្រួលដល់សមត្ថភាពក្នុងការអនុវត្តសំណួរនៃក្រាហ្វ និងលក្ខណៈទំនាក់ទំនង។

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

មានអត្ថបទដ៏អស្ចារ្យមួយអំពី ArangoDB និង OrientDB នៅលើ Habre: ចូលរួមនៅក្នុងមូលដ្ឋានទិន្នន័យ NoSQL.

អារ៉ាន់ដូឌី

ArangoDB ទាមទារការគាំទ្រសម្រាប់គំរូទិន្នន័យក្រាហ្វ។

ថ្នាំងនៃក្រាហ្វក្នុង ArangoDB គឺជាឯកសារធម្មតា ហើយគែមគឺជាឯកសារនៃប្រភេទពិសេសដែលរួមជាមួយនឹងប្រព័ន្ធធម្មតា មាន (_key, _id, _rev) វាលប្រព័ន្ធ _from и _to. ឯកសារនៅក្នុងឯកសារ DBMSs ត្រូវបានរួមបញ្ចូលគ្នាជាប្រពៃណីទៅក្នុងបណ្តុំ។ ការប្រមូលឯកសារដែលតំណាងឱ្យគែមត្រូវបានគេហៅថា ការប្រមូលគែមនៅក្នុង ArangoDB ។ ដោយវិធីនេះ ឯកសារប្រមូលគែមក៏ជាឯកសារដែរ ដូច្នេះគែមនៅក្នុង ArangoDB ក៏អាចដើរតួជាថ្នាំងផងដែរ។

ទិន្នន័យដំបូង

សូមឱ្យយើងមានបណ្តុំ personsដែលឯកសារមើលទៅដូចនេះ៖

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

សូមឱ្យមានការប្រមូលផ្តុំផងដែរ។ cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

បន្ទាប់មកការប្រមូលផ្តុំ likes អាចមើលទៅដូចនេះ៖

[
  {
    "_id" : "likes/1" ,
    "_key" : "1" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes/2" ,
    "_key" : "2" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes/3" ,
    "_key" : "3" ,
    "_from" : "persons/bob" ,
    "_to" : "cafes/jd",
    "since" : 2012 
  }
]

សំណួរ និងលទ្ធផល

សំណួររចនាប័ទ្មក្រាហ្វនៅក្នុងភាសា AQL ដែលប្រើក្នុង ArangoDB ត្រឡប់ជាព័ត៌មានទម្រង់ដែលអាចអានបានរបស់មនុស្សអំពីអ្នកដែលចូលចិត្តហាងកាហ្វេ មើលទៅដូចនេះ៖

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

នៅក្នុងរចនាប័ទ្មទំនាក់ទំនងដែលយើងកំពុង "គណនា" ទំនាក់ទំនងជាជាងរក្សាទុកពួកវា សំណួរនេះអាចសរសេរឡើងវិញដូចនេះ (ដោយវិធីនេះ ដោយគ្មានការប្រមូល likes អាចធ្វើបានដោយគ្មាន):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

លទ្ធផលនៅក្នុងករណីទាំងពីរនឹងដូចគ្នា៖

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

សំណួរ និងលទ្ធផលច្រើនទៀត

ប្រសិនបើទម្រង់លទ្ធផលខាងលើហាក់ដូចជាធម្មតាសម្រាប់ DBMS ដែលទាក់ទងជាជាងសម្រាប់ឯកសារ DBMS អ្នកអាចសាកល្បងសំណួរនេះ (ឬអ្នកអាចប្រើ COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

លទ្ធផលនឹងមើលទៅដូចនេះ៖

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB ។

មូលដ្ឋានសម្រាប់ការអនុវត្តគំរូក្រាហ្វនៅលើកំពូលនៃគំរូឯកសារនៅក្នុង OrientDB គឺ ឱកាស វាលឯកសារ បន្ថែមពីលើតម្លៃស្ដង់ដារច្រើន ឬតិច ក៏មានតម្លៃនៃប្រភេទដូចជា LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. តម្លៃនៃប្រភេទទាំងនេះគឺជាតំណភ្ជាប់ឬបណ្តុំនៃតំណភ្ជាប់ទៅ ការកំណត់អត្តសញ្ញាណប្រព័ន្ធ ឯកសារ។

ឧបករណ៍កំណត់អត្តសញ្ញាណឯកសារដែលបានកំណត់ដោយប្រព័ន្ធមាន "អត្ថន័យរូបវន្ត" ដែលបង្ហាញពីទីតាំងនៃកំណត់ត្រានៅក្នុងមូលដ្ឋានទិន្នន័យ ហើយមើលទៅដូចនេះ៖ @rid : #3:16. ដូច្នេះតម្លៃនៃលក្ខណៈសម្បត្តិយោងគឺពិតជាទ្រនិច (ដូចនៅក្នុងគំរូក្រាហ្វ) ជាជាងលក្ខខណ្ឌជ្រើសរើស (ដូចនៅក្នុងគំរូទំនាក់ទំនង)។

ដូច ArangoDB គែមនៅក្នុង OrientDB ត្រូវបានតំណាងជាឯកសារដាច់ដោយឡែក (ទោះបីជាគែមមិនមានលក្ខណៈសម្បត្តិផ្ទាល់ខ្លួនក៏ដោយ វាអាចត្រូវបានបង្កើត ស្រាលហើយវានឹងមិនត្រូវគ្នានឹងឯកសារដាច់ដោយឡែកទេ)។

ទិន្នន័យដំបូង

ក្នុងទម្រង់ជិត ទម្រង់ចាក់សំរាម មូលដ្ឋានទិន្នន័យ OrientDB ទិន្នន័យពីឧទាហរណ៍មុនសម្រាប់ ArangoDB នឹងមើលទៅដូចនេះ៖

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Алиса",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Боб",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Жан-Жак",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "Джон Донн",
      "in_likes": [
        "#30:1"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#30:1",
      "@class": "likes",
      "in": "#22:0",
      "out": "#11:0",
      "since": 1262286000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:2",
      "@class": "likes",
      "in": "#21:0",
      "out": "#11:0",
      "since": 1293822000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:3",
      "@class": "likes",
      "in": "#21:0",
      "out": "#12:0",
      "since": 1325354400000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    }
  ]

ដូចដែលយើងអាចមើលឃើញ ចំនុចកំពូលក៏រក្សាទុកព័ត៌មានអំពីគែមចូល និងចេញផងដែរ។ នៅ ដោយប្រើ Document API ត្រូវត្រួតពិនិត្យភាពត្រឹមត្រូវនៃសេចក្តីយោងខ្លួនវា ហើយ Graph API ទទួលយកការងារនេះ។ ប៉ុន្តែសូមមើលថាតើការចូលប្រើ OrientDB មើលទៅដូចម្ដេចនៅក្នុងភាសាសំណួរ "សុទ្ធ" ដែលមិនត្រូវបានបញ្ចូលទៅក្នុងភាសាសរសេរកម្មវិធី។

សំណួរ និងលទ្ធផល

សំណួរស្រដៀងគ្នាក្នុងគោលបំណងទៅនឹងសំណួរពីឧទាហរណ៍សម្រាប់ ArangoDB ក្នុង OrientDB មើលទៅដូចនេះ៖

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

លទ្ធផលនឹងទទួលបានក្នុងទម្រង់ដូចខាងក្រោម៖

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

ប្រសិនបើទ្រង់ទ្រាយលទ្ធផលម្តងទៀតហាក់ដូចជា "ទាក់ទង" ពេក អ្នកត្រូវដកបន្ទាត់ចេញ UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

ភាសាសំណួររបស់ OrientDB អាចត្រូវបានពិពណ៌នាថាជា SQL ជាមួយនឹងការបញ្ចូលដូច Gremlin ។ នៅក្នុងកំណែ 2.2 ទម្រង់សំណើដូច Cypher បានបង្ហាញខ្លួន MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

ទម្រង់លទ្ធផលនឹងដូចគ្នានឹងការស្នើសុំពីមុនដែរ។ គិតអំពីអ្វីដែលត្រូវដកចេញដើម្បីធ្វើឱ្យវាកាន់តែ "ទំនាក់ទំនង" ដូចជានៅក្នុងសំណួរដំបូង។

Azure CosmosDB

ក្នុងកម្រិតតិចជាងនេះ អ្វីដែលបាននិយាយខាងលើអំពី ArangoDB និង OrientDB អនុវត្តចំពោះ Azure CosmosDB ។ CosmosDB ផ្តល់ APIs ចូលប្រើទិន្នន័យខាងក្រោម៖ SQL, MongoDB, Gremlin និង Cassandra ។

SQL API និង MongoDB API ត្រូវបានប្រើដើម្បីចូលប្រើទិន្នន័យក្នុងគំរូឯកសារ។ Gremlin API និង Cassandra API - សម្រាប់ចូលប្រើទិន្នន័យក្នុងទម្រង់ក្រាហ្វ និងជួរឈររៀងៗខ្លួន។ ទិន្នន័យនៅក្នុងម៉ូដែលទាំងអស់ត្រូវបានរក្សាទុកជាទម្រង់គំរូខាងក្នុង CosmosDB៖ នៃ ARS ("អាតូម-កំណត់ត្រា-លំដាប់") ដែលនៅជិតឯកសារមួយផងដែរ។

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

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

DBMS ច្រើនម៉ូដែលផ្អែកលើគំរូក្រាហ្វ?

គួរកត់សម្គាល់ថាមិនមាន DBMSs ពហុគំរូនៅលើទីផ្សារនៅឡើយទេ ដែលផ្អែកលើគំរូក្រាហ្វ (លើកលែងតែការគាំទ្រពហុគំរូសម្រាប់ម៉ូដែលក្រាហ្វពីរក្នុងពេលដំណាលគ្នា៖ RDF និង LPG សូមមើលនេះនៅក្នុង ការបោះពុម្ពមុន។) ការលំបាកខ្លាំងបំផុតគឺបណ្តាលមកពីការអនុវត្តគំរូឯកសារនៅលើកំពូលនៃគំរូក្រាហ្វ ជាជាងទំនាក់ទំនង។

សំណួរអំពីរបៀបអនុវត្តគំរូទំនាក់ទំនងនៅលើកំពូលនៃគំរូក្រាហ្វត្រូវបានគេពិចារណាសូម្បីតែក្នុងអំឡុងពេលនៃការបង្កើតក្រោយ។ របៀប បាននិយាយឧទាហរណ៍ លោក David McGovern:

មិនមានអ្វីជាប់ពាក់ព័ន្ធក្នុងវិធីសាស្រ្តក្រាហ្វដែលរារាំងការបង្កើតស្រទាប់មួយ (ឧ។ ដោយការធ្វើលិបិក្រមសមស្រប) នៅលើមូលដ្ឋានទិន្នន័យក្រាហ្វដែលអាចឱ្យទិដ្ឋភាពទំនាក់ទំនងជាមួយ (1) ការងើបឡើងវិញនៃ tuples ពីគូតម្លៃគន្លឹះធម្មតា និង (2) ការដាក់ជាក្រុមនៃ tuples តាមប្រភេទទំនាក់ទំនង។

នៅពេលអនុវត្តគំរូឯកសារនៅលើកំពូលនៃគំរូក្រាហ្វ អ្នកត្រូវចងចាំជាឧទាហរណ៍ ដូចខាងក្រោម៖

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

ការផ្សាយពាណិជ្ជកម្មតិចតួច

អ្នកនិពន្ធអត្ថបទគឺទាក់ទងទៅនឹងការអភិវឌ្ឍន៍ NitrosBase DBMS ដែលជាគំរូខាងក្នុងដែលជាក្រាហ្វ ហើយគំរូខាងក្រៅ - ទំនាក់ទំនង និងឯកសារ - គឺជាតំណាងរបស់វា។ ម៉ូដែលទាំងអស់គឺស្មើគ្នា៖ ទិន្នន័យស្ទើរតែទាំងអស់មាននៅក្នុងពួកវាណាមួយដោយប្រើភាសាសំណួរដែលមានលក្ខណៈធម្មជាតិរបស់វា។ លើសពីនេះទៅទៀត នៅក្នុងទិដ្ឋភាពណាមួយ ទិន្នន័យអាចត្រូវបានផ្លាស់ប្តូរ។ ការផ្លាស់ប្តូរនឹងត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងគំរូខាងក្នុង និងតាមទស្សនៈផ្សេងទៀត។

ខ្ញុំសង្ឃឹមថានឹងពណ៌នាអំពីអ្វីដែលការផ្គូផ្គងគំរូមើលទៅដូចនៅក្នុង NitrosBase នៅក្នុងអត្ថបទមួយក្នុងចំណោមអត្ថបទខាងក្រោម។

សេចក្តីសន្និដ្ឋាន

ខ្ញុំសង្ឃឹមថា ទិដ្ឋភាពទូទៅនៃអ្វីដែលហៅថា ពហុគំរូ កាន់តែច្បាស់សម្រាប់អ្នកអាន។ DBMS ច្រើនម៉ូដែលគឺខុសគ្នាខ្លាំង ហើយ "ការគាំទ្រច្រើនម៉ូដែល" អាចមើលទៅខុសគ្នា។ ដើម្បីយល់ពីអ្វីដែលហៅថា "ពហុគំរូ" ក្នុងករណីជាក់លាក់នីមួយៗ វាមានប្រយោជន៍ក្នុងការឆ្លើយសំណួរខាងក្រោម៖

1. តើ​យើង​កំពុង​តែ​និយាយ​អំពី​ការ​គាំទ្រ​ម៉ូដែល​ប្រពៃណី ឬ​ប្រភេទ​ម៉ូដែល "កូនកាត់" ខ្លះ?
2. តើគំរូ "ស្មើគ្នា" ឬមួយក្នុងចំនោមពួកគេគឺជាកម្មវត្ថុរបស់អ្នកដទៃ?
3. តើម៉ូដែល "ព្រងើយកណ្តើយ" ចំពោះគ្នាទៅវិញទៅមកទេ? តើ​ទិន្នន័យ​ដែល​សរសេរ​ក្នុង​គំរូ​មួយ​ត្រូវ​បាន​អាន​ក្នុង​មួយ​ទៀត​ឬ​សូម្បី​តែ​សរសេរ​ជាន់​លើ?

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

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើអ្នកប្រើ DBMS ច្រើនម៉ូដែលទេ?

• យើងមិនប្រើវាទេ យើងរក្សាទុកអ្វីគ្រប់យ៉ាងនៅក្នុង DBMS មួយ និងក្នុងគំរូមួយ។

• យើងប្រើសមត្ថភាពពហុគំរូនៃ DBMSs ប្រពៃណី

• យើងអនុវត្តការតស៊ូពហុកោណ

• យើងប្រើ DBMS ពហុម៉ូដែលថ្មី (Arango, Orient, CosmosDB)

អ្នកប្រើប្រាស់ 19 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ៦៣ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com