Савремени информациони системи су прилично сложени. Не мање од свега, њихова сложеност је последица сложености података који се у њима обрађују. Сложеност података често лежи у разноврсности коришћених модела података. Тако, на пример, када подаци постану „велики”, једна од проблематичних карактеристика није само њихов обим („волумен”), већ и њихова разноликост („разноврсност”).

Ако још увек не пронађете недостатак у образложењу, читајте даље.

Садржина

Упорност полиглота
Мулти-модел
Вишемоделни ДБМС заснован на релационом моделу
     Модел документа у МС СКЛ Серверу
     Графички модел у МС СКЛ Серверу
Вишемоделни ДБМС заснован на моделу документа
     Релациони модел у МаркЛогиц-у
     Графички модел у МаркЛогиц-у
Мулти-модел ДБМС „без главног модела”
     АрангоДБ
     ОриентДБ
     Азуре ЦосмосДБ
Мулти-модел ДБМС заснован на моделу графа?
Закључак
Опрос

Упорност полиглота

Наведено доводи до тога да је понекад чак иу оквиру једног система потребно користити више различитих ДБМС-а за складиштење података и решавање различитих проблема њихове обраде, од којих сваки подржава свој модел података. Лаком руком М. Фаулера, аутор низ познатих књига и једна од коаутори Агилни манифест, ова ситуација се зове вишеваријантно складиштење („упорност полиглота“).

Фовлер такође има следећи пример организовања складиштења података у потпуно опремљеној апликацији са великим оптерећењем у области е-трговине.

Овај пример је, наравно, донекле преувеличан, али се могу наћи нека разматрања у корист избора једног или другог ДБМС-а за одговарајућу намену, нпр. овде.

Јасно је да бити слуга у таквом зоолошком врту није лако.

• Количина кода који обавља складиштење података расте сразмерно броју коришћених ДБМС; количина података за синхронизацију кода је добра ако није пропорционална квадрату овог броја.
• Као вишекратник броја коришћених ДБМС-ова, трошкови обезбеђивања карактеристика предузећа (скалабилност, толеранција грешака, висока доступност) сваког од коришћених ДБМС-а расту.
• Немогуће је обезбедити карактеристике предузећа за подсистем за складиштење у целини - посебно трансакције.

Из угла директора зоолошког врта, све изгледа овако:

• Вишеструко повећање трошкова лиценци и техничке подршке произвођача ДБМС-а.
• Прекомерно особље и повећани рокови.
• Директни финансијски губици или казне због недоследности података.

Постоји значајно повећање укупних трошкова власништва система (ТЦО). Постоји ли излаз из ситуације „више опција за складиштење“?

Мулти-модел

Термин „мултиваријантно складиштење“ ушао је у употребу 2011. Свест о проблемима приступа и тражење решења трајало је неколико година, а до 2015. године, кроз уста аналитичара Гартнера, формулисан је одговор:

• Од "Водич за тржиште за НоСКЛ ДБМС - 2015"
  

  Будућност ДБМС-а, њихове архитектуре и начина њиховог коришћења је вишемоделна.

• Од "Магични квадрант за ОДБМС - 2016"
  

  Водећи оперативни ДБМС-ови ће понудити више модела – релационих и нерелационих – као део једне платформе.

Чини се да су овог пута аналитичари Гартнера били у праву са својом прогнозом. Ако одете на страницу са главни рејтинг ДБМС на ДБ-Енгинес, то можете видетиоВећина његових лидера себе позиционира посебно као вишемоделне ДБМС. Исто се може видети на страници са било којом приватном оценом.

У табели испод приказани су ДБМС - лидери у свакој од приватних оцена, који тврде да су вишемоделни. За сваки ДБМС је назначен оригинални подржани модел (који је некада био једини) и заједно са њим тренутно подржани модели. Наведени су и ДБМС-ови који се позиционирају као „првобитно мултимоделни” и, према речима креатора, немају никакав иницијални наслеђени модел.

Табеле белешке

Звездице у табели означавају изјаве које захтевају резервације:

• ПостгреСКЛ ДБМС не подржава модел података графикона, али га овај производ подржава на основу тога, као што је АгенсГрапх.
• У односу на МонгоДБ, исправније је говорити о присуству оператора графа у језику упита ($lookup, $graphLookup) него о подршци моделу графа, иако је, наравно, њихово увођење захтевало неке оптимизације на нивоу физичког складиштења у правцу подршке графичком моделу.
• У односу на Редис, мислимо на проширење РедисГрапх.

Затим ћемо за сваку од класа показати како је подршка за неколико модела имплементирана у ДБМС из ове класе. Сматраћемо да су релациони, документни и графички модели најважнији и користићемо примере специфичних ДБМС-а да покажемо како се имплементирају „они који недостају“.

Вишемоделни ДБМС заснован на релационом моделу

Водећи ДБМС-ови тренутно су релациони; Гартнерова прогноза се не би могла сматрати истинитом ако РДБМС-ови не показују кретање у правцу мулти-моделирања. И демонстрирају. Сада се идеја да је вишемоделни ДБМС као швајцарски нож, који не може ништа добро да уради, може директно усмерити на Ларија Елисона.

Аутор, међутим, преферира имплементацију мулти-моделирања у Мицрософт СКЛ Сервер, на чијем примеру ће бити описана подршка РДБМС за моделе докумената и графова.

Модел документа у МС СКЛ Серверу

Већ су била два одлична чланка на Хабреу о томе како МС СКЛ Сервер имплементира подршку за модел документа; ограничићу се на кратко препричавање и коментар:

• Рад са ЈСОН-ом у СКЛ Серверу 2016
• СКЛ Сервер 2017 ЈСОН

Начин подршке моделу документа у МС СКЛ Серверу је прилично типичан за релационе ДБМС: предлаже се да се ЈСОН документи чувају у обичним текстуалним пољима. Подршка за модел документа је да обезбеди посебне операторе за рашчлањивање овог ЈСОН-а:

• JSON_VALUE да издвојите вредности скаларних атрибута,
• JSON_QUERY за издвајање поддокумената.

Други аргумент оба оператора је израз у синтакси сличној ЈСОНПатх-у.

Апстрактно, можемо рећи да документи који се чувају на овај начин нису „првокласни ентитети“ у релационом ДБМС-у, за разлику од тупле-а. Конкретно, у МС СКЛ Серверу тренутно нема индекса на пољима ЈСОН докумената, што отежава спајање табела користећи вредности ових поља, па чак и одабир докумената користећи ове вредности. Међутим, могуће је креирати израчунату колону за такво поље и индекс на њему.

Поред тога, МС СКЛ Сервер пружа могућност погодне израде ЈСОН документа из садржаја табела користећи оператор FOR JSON PATH - могућност, у извесном смислу, супротна претходној, конвенционално складиштење. Јасно је да без обзира на то колико је брз РДБМС, овај приступ је у супротности са идеологијом документних ДБМС-а, који у суштини чувају готове одговоре на популарне упите и могу само да решавају проблеме лакоће развоја, али не и брзине.

Коначно, МС СКЛ Сервер вам омогућава да решите супротан проблем конструкције документа: можете да декомпонујете ЈСОН у табеле користећи OPENJSON. Ако документ није потпуно раван, мораћете да га користите CROSS APPLY.

Графички модел у МС СКЛ Серверу

Подршка за модел графа (ЛПГ) је такође у потпуности имплементирана у Мицрософт СКЛ Сервер предвидљиво: Предлаже се коришћење посебних табела за чување чворова и за чување ивица графа. Такве табеле се креирају помоћу израза CREATE TABLE AS NODE и CREATE TABLE AS EDGE респективно.

Табеле првог типа су сличне обичним табелама за складиштење записа, са једином спољашњом разликом што табела садржи системско поље $node_id — јединствени идентификатор чвора графа у бази података.

Слично, табеле другог типа имају системска поља $from_id и $to_id, уноси у таквим табелама јасно дефинишу везе између чворова. За чување односа сваког типа користи се посебна табела.

Хајде да то илуструјемо примером. Нека подаци графикона имају изглед као што је приказано на слици. Затим да бисте креирали одговарајућу структуру у бази података, потребно је да покренете следеће ДДЛ упите:

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);

Главна специфичност оваквих табела је у томе што је у упитима против њих могуће користити шаблоне графикона са синтаксом сличном Ципхер-у (међутим, „*„итд. још нису подржани). На основу мерења перформанси, такође се може претпоставити да се начин на који се подаци чувају у овим табелама разликује од начина на који се подаци чувају у редовним табелама и да је оптимизован за извршавање таквих упита на графикону.

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

Штавише, прилично је тешко не користити ове обрасце графова када радите са таквим табелама, јер ће у обичним СКЛ упитима за решавање сличних проблема бити потребно уложити додатне напоре да се добију идентификатори чворова „графа“ система ($node_id, $from_id, $to_id; Из истог разлога, упити за убацивање података нису приказани овде јер су непотребно гломазни).

Да сумирамо опис имплементација модела докумената и графова у МС СКЛ Серверу, приметио бих да овакве имплементације једног модела изнад другог не делују успешно, пре свега са становишта језичког дизајна. Неопходно је проширити један језик другим, језици нису потпуно „ортогонални“, правила компатибилности могу бити прилично бизарна.

Вишемоделни ДБМС заснован на моделу документа

У овом одељку желео бих да илуструјем имплементацију мултимодела у ДБМС-овима докумената користећи пример не најпопуларнијег од њих, МонгоДБ (као што је речено, има само условне операторе графа $lookup и $graphLookup, не радећи на подељеним колекцијама), али користећи пример зрелијег и „предузетничког“ ДБМС-а МаркЛогиц.

Дакле, нека колекција садржи скуп КСМЛ докумената следећег типа (МаркЛогиц вам такође омогућава да складиштите ЈСОН документе):

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

Релациони модел у МаркЛогиц-у

Релациони поглед на колекцију докумената може се креирати помоћу шаблон за приказ (садржај елемената value у примеру испод може постојати произвољан КСПатх):

<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>

Можете адресирати креирани приказ помоћу СКЛ упита (на пример, преко ОДБЦ-а):

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

Нажалост, релациони приказ креиран шаблоном приказа је само за читање. Приликом обраде захтева за то, МаркЛогиц ће покушати да га користи индекси докумената. Раније је МаркЛогиц у потпуности имао ограничене релационе погледе на основу индекса и за писање, али се сада сматрају застарелим.

Графички модел у МаркЛогиц-у

Уз подршку за граф (РДФ) модел, све је отприлике исто. Опет уз помоћ шаблон за приказ Можете креирати РДФ репрезентацију колекције докумената из примера изнад:

<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>

Добијени РДФ графикон можете адресирати помоћу СПАРКЛ упита:

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

За разлику од релационог, МаркЛогиц подржава модел графа на два друга начина:

1. ДБМС може бити потпуно одвојено складиште РДФ података (тројке у њему ће се звати управља за разлику од горе описаних извучен).
2. РДФ у специјалној серијализацији може једноставно да се убаци у КСМЛ или ЈСОН документе (и тројке ће се тада звати неуправљано). Ово је вероватно алтернатива механизмима idref итд

Добра идеја о томе како ствари „стварно“ функционишу у МаркЛогиц-у даје Оптички АПИ, у том смислу је ниског нивоа, иако је његова сврха пре супротна – да покуша да се апстрахује од коришћеног модела података, да обезбеди конзистентан рад са подацима у различитим моделима, трансакционалност итд.

Мулти-модел ДБМС „без главног модела”

На тржишту постоје и ДБМС који се позиционирају као иницијално мултимоделни, без икаквог наслеђеног главног модела. Ови укључују АрангоДБ, ОриентДБ (од 2018 развојна компанија припада САП-у) и ЦосмосДБ (услуга као део Мицрософт Азуре цлоуд платформе).

У ствари, постоје „основни“ модели у АрангоДБ и ОриентДБ. У оба случаја ради се о сопственим моделима података, који су генерализације документа. Генерализације су углавном да би се олакшала могућност обављања упита графичке и релационе природе.

Ови модели су једини доступни за употребу у наведеном ДБМС-у; њихови сопствени језици упита су дизајнирани да раде са њима. Наравно, такви модели и ДБМС-ови обећавају, али недостатак компатибилности са стандардним моделима и језицима онемогућава коришћење ових ДБМС-а у застарелим системима—да би се заменили ДБМС-ови који се већ тамо користе.

Већ је постојао диван чланак о АрангоДБ и ОриентДБ на Хабре: ЈОИН у НоСКЛ базама података.

АрангоДБ

АрангоДБ тврди да подржава модел података графа.

Чворови графа у АрангоДБ-у су обични документи, а ивице су документи посебног типа који, уз редовна системска поља, имају (_key, _id, _rev) системска поља _from и _to. Документи у ДБМС-овима докумената се традиционално комбинују у колекције. Колекције докумената који представљају ивице називају се колекције ивица у АрангоДБ-у. Иначе, документи за прикупљање ивица су такође документи, тако да ивице у АрангоДБ-у могу да делују и као чворови.

Необрађени подаци

Хајде да имамо колекцију 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 
  }
]

Упити и резултати

Упит у стилу графа на АКЛ језику који се користи у АрангоДБ-у, који враћа у човеку читљивом облику информације о томе ко воли који кафић, изгледа овако:

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 : "Джон Донн" }
]

Више упита и резултата

Ако се чини да је горњи формат резултата типичнији за релациони ДБМС него за документ ДБМС, можете испробати овај упит (или можете користити COLLECT):

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

Резултат ће изгледати овако:

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

ОриентДБ

Основа за имплементацију модела графа на врху модела документа у ОриентДБ је прилика поља документа, поред мање-више стандардних скаларних вредности, имају и вредности типова као нпр LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Вредности ових типова су везе или колекције веза ка идентификатори система документи.

Идентификатор документа који је доделио систем има „физичко значење“, што указује на позицију записа у бази података, и изгледа отприлике овако: @rid : #3:16. Дакле, вредности референтних својстава су заиста показивачи (као у моделу графа), а не услови избора (као у релационом моделу).

Као и АрангоДБ, ивице у ОриентДБ-у су представљене као засебни документи (мада ако ивица нема сопствена својства, може се направити лагана, и неће одговарати посебном документу).

Необрађени подаци

У формату блиском думп формат ОриентДБ базе података, подаци из претходног примера за АрангоДБ би изгледали отприлике овако:

[
     {
      "@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"
    }
  ]

Као што видимо, врхови такође чувају информације о долазним и одлазним ивицама. Ат Користећи Доцумент АПИ мора сам да надгледа референтни интегритет, а Грапх АПИ преузима овај посао. Али хајде да видимо како изгледа приступ ОриентДБ-у у „чистим“ језицима упита који нису интегрисани у програмске језике.

Упити и резултати

Упит сличан по сврси упиту из примера за АрангоДБ у ОриентДБ изгледа овако:

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": [ "Жан-Жак" ' }
]

ОриентДБ-ов језик упита може се описати као СКЛ са уметцима сличним Гремлину. У верзији 2.2, појавио се образац захтева сличан Ципхер, 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

Формат резултата ће бити исти као у претходном захтеву. Размислите о томе шта треба да се уклони да би било више „релације“, као у првом упиту.

Азуре ЦосмосДБ

У мањој мери, оно што је горе речено о АрангоДБ и ОриентДБ односи се на Азуре ЦосмосДБ. ЦосмосДБ обезбеђује следеће АПИ-је за приступ подацима: СКЛ, МонгоДБ, Гремлин и Цассандра.

СКЛ АПИ и МонгоДБ АПИ се користе за приступ подацима у моделу документа. Гремлин АПИ и Цассандра АПИ - за приступ подацима у форматима графикона и колона, респективно. Подаци у свим моделима се чувају у ЦосмосДБ интерном формату модела: АРС (“атом-рецорд-секуенце”), што је такође блиско документу.

Али модел података који је изабрао корисник и АПИ који се користи су фиксни у тренутку креирања налога у сервису. Није могуће приступити подацима учитаним у једном моделу у формату другог модела, што илуструје нешто попут овога:

Дакле, мулти-модел у Азуре ЦосмосДБ данас је само могућност коришћења неколико база података које подржавају различите моделе једног произвођача, што не решава све проблеме вишеваријантног складиштења.

Мулти-модел ДБМС заснован на моделу графа?

Занимљива је чињеница да на тржишту још увек не постоје мултимоделни ДБМС који су засновани на моделу графа (осим подршке за више модела за истовремено два модела графа: РДФ и ЛПГ; погледајте ово у претходна публикација). Највеће потешкоће изазива имплементација модела документа изнад модела графа, а не релационог.

Питање како имплементирати релациони модел изнад модела графа разматрано је још током формирања овог другог. како on је рекао, на пример, Давид МцГоверн:

Не постоји ништа својствено приступу графа што спречава креирање слоја (нпр. одговарајућим индексирањем) у бази података графикона који омогућава релациони приказ са (1) опорављањем торки из уобичајених парова вредности кључа и (2) груписањем тупле по типу релације.

Када имплементирате модел документа на модел графикона, морате имати на уму, на пример, следеће:

• Елементи ЈСОН низа се сматрају уређеним, али они који потичу из темена ивице графа нису;
• Подаци у моделу документа су обично денормализовани; и даље не желите да складиштите неколико копија истог уграђеног документа, а поддокументи обично немају идентификаторе;
• С друге стране, идеологија документних ДБМС-а је да су документи готови „агрегати“ које не треба сваки пут изнова градити. Потребно је обезбедити модел графа са могућношћу брзог добијања подграфа који одговара готовом документу.

Нека реклама

Аутор чланка се односи на развој НитросБасе ДБМС, чији је унутрашњи модел граф, а екстерни модели – релациони и документ – су његове репрезентације. Сви модели су једнаки: скоро сви подаци су доступни у било ком од њих користећи језик упита који му је природан. Штавише, у било ком погледу подаци се могу мењати. Промене ће се одразити на интерни модел и, сходно томе, на друге погледе.

Надам се да ћу описати како упаривање модела изгледа у НитросБасе-у у једном од следећих чланака.

Закључак

Надам се да су општи обриси онога што се назива мултимоделирањем постали мање-више јасни читаоцу. ДБМС са више модела су прилично различити, а „подршка за више модела“ може изгледати другачије. Да бисмо разумели шта се у сваком конкретном случају назива „мултимодел“, корисно је одговорити на следећа питања:

1. Да ли говоримо о подршци традиционалним моделима или некој врсти „хибридног“ модела?
2. Да ли су модели „једнаки“, или је један од њих предмет других?
3. Да ли су модели „равнодушни” једни према другима? Да ли се подаци написани у једном моделу могу прочитати у другом или чак преписати?

Мислим да се на питање о релевантности мулти-моделних ДБМС већ може позитивно одговорити, али је интересантно питање које врсте њих ће бити траженије у блиској будућности. Чини се да ће више-моделни ДБМС који подржавају традиционалне моделе, првенствено релационе, бити траженији; Популарност мултимоделних ДБМС-ова, који нуде нове моделе који комбинују предности различитих традиционалних, ствар је даље будућности.

Само регистровани корисници могу учествовати у анкети. Пријавите се, Добродошао си.

Да ли користите мулти-модел ДБМС?

• Ми га не користимо, све складиштимо у једном ДБМС-у иу једном моделу

• Користимо мултимоделне могућности традиционалних ДБМС-ова

• Ми практикујемо полиглотску упорност

• Користимо нови мулти-модел ДБМС (Аранго, Ориент, ЦосмосДБ)

Гласало је 19 корисника. 4 корисника су била уздржана.

Извор: ввв.хабр.цом