Repozytorium w chmurze – NoSQL

Wprowadzenie

Coraz czę­ściej czy­ta­my o śro­do­wi­skach chmu­ro­wych” (nadal nie mogę się prze­ko­nać do pisa­nia tego bez cudzy­sło­wu). Nawet tak zaawan­so­wa­ne jak Amazon WS czy AZURE, są nadal bar­dzo czę­sto wyko­rzy­sty­wa­ne tyl­ko jako hosting apli­ka­cji. Oba te ser­wi­sy moż­na wyko­rzy­sty­wać jako sie­cio­wy dysk, śro­do­wi­sko sys­te­mo­we (Windows, Linux), bazę danych SQL, ale tak­że jako bazy NoSQL. 

Jednym z naj­istot­niej­szych ele­men­tów sys­te­mów infor­ma­cyj­nych (patrz: infor­ma­tion scien­ce) jest utrwa­la­nie danych (pamię­taj­my, że dane to zapi­sy, a infor­ma­cja to to, co rozu­mie czło­wiek, któ­ry je czy­ta). Niedawno nawią­zy­wa­łem do pro­ble­mu utrwa­la­nia danych.

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! (źr.: Dokument a kumu­la­cja fak­tów: OOAD i model dzie­dzi­ny sys­te­mu) Prosty dia­gram po lewej stro­nie poka­zu­je pro­blem opi­sa­ny przez Smith’a jako Computers, Models, and the Embedding World, The Limits of Correctness.” 

Komputer (rozu­mia­ny jako pro­ce­sor, pamięć i pro­gram) sta­no­wi dla czło­wie­ka narzę­dzie pracy. 

Cechą kom­pu­te­ra jest w ogrom­nej więk­szo­ści przy­pad­ków odwzo­ro­wy­wa­nie tego co zastę­pu­je­my kom­pu­te­rem, a tak zwa­ne sys­te­my biz­ne­so­we, zastę­pu­ją papie­ro­we for­my prze­twa­rza­nia i prze­cho­wy­wa­nia infor­ma­cji. Systemy ERP, CRM, Workflow, Sklepy inter­ne­to­we, Archiwa, i wie­le innych to tak na praw­dę doku­men­ty i ich treść. 

Istota pro­ble­mu pole­ga na tym, że okre­ślo­ne, dostęp­ne tech­no­lo­gie same z sie­bie czę­sto stwa­rza­ją ogra­ni­cze­nia tego co mogą (potra­fią) odwzo­ro­wać, i mimo upły­wu cza­su i postę­pu tech­no­lo­gii, ana­li­za i pro­jek­to­wa­nie zarzą­dza­nia infor­ma­cją nadal jest jed­nym z naj­więk­szych pro­ble­mów wdro­żeń systemów. 

SQL vs. NoSQL

SQL

Skrót NoSQL jest inte­pre­to­wa­ny jako nie SQL” lub nie tyl­ko SQL” (Not only SQL). SQL (Structured Query Language) to język zapy­tań do baz danych o rela­cyj­nym mode­lu danych (ang. RDBMS: Relational Data Base Management System). Cechą tego mode­lu danych jest usu­wa­nie redun­dan­cji i podział danych na tabe­le i słow­ni­ki pól tych tabel, oraz związ­ki mię­dzy nimi (rela­cje). W efek­cie otrzy­mu­je­my sche­ma­ty tabel i rela­cji mię­dzy nimi np. takie:

A nawet takie:

(model danych pew­ne­go sys­te­mu ERP)

Odtworzenie doku­men­tu (for­mu­la­rza) będą­ce­go np. fak­tu­rą lub dekla­ra­cją podat­ko­wą, wyma­ga wyko­na­nia sze­re­gu bar­dzo skom­pli­ko­wa­nych ope­ra­cji łącze­nia danych z tych tabel i odwzo­ro­wa­nia ich pier­wot­nej posta­ci np. fak­tu­ry. W tego typu bazach danych fizycz­nie nie ma żad­nych dokumentów. 

Drugim pro­ble­mem jaki stwa­rza model rela­cyj­ny, jest koniecz­ność jego prze­bu­do­wy prak­tycz­nie zawsze, gdy zmie­ni się struk­tu­ra prze­cho­wy­wa­nych w nim doku­men­tów (opra­co­wa­nie nowe­go mode­lu, migra­cja danych do nowe­go mode­lu – bywa że nie­moż­li­wa w 100%, aktu­ali­za­cja zapy­tań SQL do nowej struk­tu­ry bazy danych). 

Biorąc pod uwa­gę fakt, że real­ny świat to cią­głe zmia­ny, model rela­cyj­ny jest w tym przy­pad­ku po pro­stu nieadekwatny. 

Koszty utrzy­ma­nia i roz­wo­ju sys­te­mów zarza­dza­nia dany­mi (i apli­ka­cja­mi, któ­re je wyko­rzy­stu­ją) w mode­lu rela­cyj­nym, są wie­lo­krot­nie wyż­sze niż pier­wot­ne ich wdro­że­nie .

Po co więc wymy­ślo­no te rela­cyj­ne bazy? To były cza­sy gdy pamięć była naj­kosz­tow­niej­szym zaso­bem kom­pu­te­ra zaś dane mię­dzy sys­te­ma­mi w zasa­dzie nie były wymie­nia­ne! Było kil­ka zalet, np. brak błę­dów nazew­nic­twa itp. wię­cej o nich w sie­ci moż­na poczy­tać, jed­nak moim zda­niem baza danych będą­ca imple­men­ta­cją tak zwa­nych związ­ków poję­cio­wych (tym są rela­cyj­ne mode­le danych) nie spraw­dza się bo nie mode­lu­je obiek­tów świa­ta rze­czy­wi­ste­go a jedy­nie ich nazwy i powią­za­nia mię­dzy nimi a to ogrom­na róż­ni­ca. (źr.: SQL albo NoSQL, oto jest pyta­nie – 2011 r.)

NoSQL

Jednym z typo­wych przy­kła­dów bazy danych typu NoSQL są bazy typu key-value i ich odmia­ny . Z uwa­gi na ich cechy i powszech­ność sku­pię się na tego typu bazach. 

Wśród tego typu baz są tak zwa­ne bazy doku­men­to­we. Idea tego typu baz danych reali­zu­je jed­no pod­sta­wo­wych zało­żeń obiek­to­we­go para­dyg­ma­tu (role obiek­tów): repo­zy­to­rium nie słu­ży do prze­twa­rza­nia tre­ści a jedy­nie do jej utrwa­la­nia i szyb­kie­go przy­wo­ły­wa­nia (dostę­pu). Przetwarzaniem danych (tre­ści) zaj­mu­ją kom­po­nen­ty odpo­wie­dzial­ne wyłącz­nie za reali­za­cję logi­ki apli­ka­cji. Skoro repo­zy­to­rium nie prze­twa­rza tre­ści, jest ono – prze­cho­wy­wa­na treść i jej struk­tu­ra – neu­tral­nym ele­men­tem. Dlatego ope­ru­je­my tu czę­sto poję­ciem plik, któ­rym zależ­nie od typu bazy, może być np. ciąg zna­ków XML lub JSON albo po pro­stu ciąg binar­ny (czy­li cokol­wiek”). Taka baza to hipo­te­tycz­ne dwie kolum­ny: pierw­sza zawie­ra iden­ty­fi­ka­to­ry wier­szy a dru­ga prze­cho­wy­wa­ną treść. I teraz zależ­nie od typu bazy i logi­ki apli­ka­cji, któ­ra ją wyko­rzy­stu­je, tą tre­ścią może by ciąg zna­ków (np. XML, JSON) lub dowol­ny ciąg zna­ków binar­ny (czy­li XML tak­że, ale tak­że np. zdję­cie lub plik edy­to­ra tekstów). 

Przykładem bazy doku­men­to­wej jest Amazon DynamoDB. Poniższy dia­gram poka­zu­je w uprosz­cze­niu idee tej bazy i porów­na­nie z typo­wą mode­lem rela­cyj­nym: odtwo­rze­nie doku­men­tu z bazy rela­cyj­nej (po lewej) wyma­ga skom­pli­ko­wa­nych ope­ra­cji łącze­nia tabel, po pra­wej stro­nie mamy zaś zestaw cią­gów zna­ków, każ­dy sta­no­wi sobą kom­plet­ny już doku­ment, mogą one mieć róż­ną struk­tu­rę. Pobranie doku­men­tu z bazy po pra­wej odby­wa się zawsze pro­stym zapy­ta­niem, takim samym„ bez wzglę­du na struk­tu­rę tych danych. 

Dzięki temu osią­ga­my dwie klu­czo­we korzy­ści: zmie­nia­ją­ca się w cza­sie struk­tu­ra doku­men­tów nie wpły­wa na bazę danych, czas pobra­nia doku­men­tu jest bar­dzo krót­ki i nie zale­ży od struk­tu­ry doku­men­tu . Różnicę efek­tyw­no­ści poka­za­no poniżej:



Dokument jako struktura danych

Opisane bazy NoSQL mają sze­reg zalet w sto­sun­ku do baz danych w mode­lu rela­cyj­nym. Jednak pro­blem two­rze­nia mode­li rela­cyj­nych jest zastę­po­wa­ny pro­ble­mem mode­lo­wa­nia struk­tur doku­men­tów . Nie jest to jed­nak pro­blem budo­wa­nia znor­ma­li­zo­wa­nych rela­cyj­nych struk­tur danych. Jest to pro­blem natu­ry czy­sto seman­tycz­nej: rzecz w tym czym jest doku­ment i czym są pola, z któ­rych on się skła­da. Jest wie­le podejść do tego zagad­nie­nia, uwa­żam, że klu­czo­we jest odkry­cie i zro­zu­mie­nie co opi­su­je dany doku­ment. Po dru­gie istot­ne jest umie­jęt­ne zapro­jek­to­wa­nie logi­ki apli­ka­cji. Dlatego repo­zy­to­ria NoSQL z zasa­dy nie bio­rą udzia­łu w logi­ce biz­ne­so­wej ale struk­tu­ra doku­men­tów deter­mi­nu­je logi­kę ich prze­twa­rza­nia. Rolą repo­zy­to­rium jest wyłącz­nie utrwa­la­nie i udo­stęp­nia­nie. Poniżej przy­kład dość typo­wy: fak­tu­ry i opi­sy pro­duk­tów (opis pro­duk­tu jako Karta Produktu): mimo tego, że oba te typy doku­men­tów mają inną struk­tu­rę, mogą być prze­cho­wy­wa­ne w jed­nej i tej samej bazie danych NoSQL. 

Rejestry sepa­ru­ją­ce doku­men­to­wą bazę danych od logi­ki apli­ka­cyj­nej, dia­gram pocho­dzi z wyda­nej wła­śnie publi­ka­cji, w któ­rej dokład­nie opi­sa­no zasa­dy pro­jek­to­wa­nia sys­te­mów infor­ma­cyj­nych i tego typu repo­zy­to­riów: .

Baza doku­men­to­wa słu­ży wyłącz­nie do prze­cho­wy­wa­nia danych. Kontekstowy i seman­tycz­ny dostęp do danych zapew­nia­ją dzie­dzi­no­we reje­stry: dodat­ko­we pro­ste tabe­le umiesz­czo­ne przez repo­zy­to­rium, w czę­ści apli­ka­cyj­nej. Z uwa­gi na to, że bazy doku­men­to­we nie nada­ją się do reali­za­cji wyra­fi­no­wa­nych zbio­ro­wych obli­czeń na tre­ści doku­men­tów, wyko­rzy­stu­je się do tego typo­we hur­tow­nie danych. 

[uzu­peł­nie­nie mie­siąc póź­niej] Z tego wzglę­du bar­dzo przy­dat­ny jest tu dobrze zna­ny wzo­rzec pro­jek­to­wy Repozytorium (Repository). Istotą tego wzor­ca jest sepa­ra­cja kolek­cji obiek­tów (np. nośni­ków doku­men­tów) od logi­ki apli­ka­cji za pomo­cą kla­sy reali­zu­ją­cej inter­fejs do tej kolek­cji. Poniżej wer­sja adre­so­wa­na do chmury:

Realizacja utrwa­la­nia (zapis danych) to obiek­ty prze­cho­wu­ją­ce («Storage» Repozytorium danych) oraz dane («docu­ment» Zestaw danych) prze­cho­wy­wa­ne jako doku­men­ty (XML, JSON) lub pli­ki (baza key value). Dostęp do tej kolek­cji zapew­nia kla­sa «Management» Kontrola dostę­pu do danych, sta­no­wią­ca zara­zem inter­fejs do tej kolek­cji. Interfejsów do jed­ne­go repo­zy­to­rium może być wię­cej, reali­zu­ją one wte­dy kon­tek­sto­we udo­stęp­nia­nie danych z tej samej kolek­cji. Tak więc Realizacja usłu­gi to dzie­dzi­no­wy kod apli­ka­cji, zaś Realizacja utrwa­la­nia to chmu­ro­wa usłu­ga taka jak bazy NoSQL dostęp­ne w chmurze. 

Chmury Amazon i AZURE

Ciekawym przy­kła­dem bazy doku­men­to­wej jest DynamoDB. Jest to par­ty­cjo­no­wa­na baza NoSQL mają­ca dwie kolum­ny z klu­czem: jeden to stan­dar­do­wy dla tego typu bazy iden­ty­fi­ka­tor, dru­gi to klucz wska­zu­ją­cy na struk­tu­rę defi­niu­ją­cą for­mat danych w trze­ciej kolum­nie prze­cho­wu­ją­cej dane (doku­men­ty). Jest to baza prze­cho­wu­ją­ca dane w for­ma­cie JSON, więc ich inter­pre­ta­cja wyma­ga defi­ni­cji kon­kret­nej struk­tu­ry danych. dodat­ko­wa kolum­na (SortKey) peł­ni rolę defi­ni­cji typu (iden­ty­fi­ka­tor struk­tu­ry). Jest to wygod­ne bo w sys­te­mach obiek­to­wych łatwo defi­niu­je się typy zło­żo­ne, nada­jąc każ­de­mu rekor­do­wi dodat­ko­wy iden­ty­fi­ka­tor, moż­na inte­pre­to­wać pobra­ne dane. 

(https://​aws​.ama​zon​.com/​b​l​o​g​s​/​d​a​t​a​b​a​s​e​/​c​h​o​o​s​i​n​g​-​t​h​e​-​r​i​g​h​t​-​d​y​n​a​m​o​d​b​-​p​a​r​t​i​t​i​o​n​-​k​ey/)

Więcej infor­ma­cji o repo­zy­to­riach Amazon, tak­że Amazon S3 (bar­dzo szyb­ka baza pli­ków) znaj­dzie­cie w książ­ce wydaw­nic­twa Helion: Amazon Web Services . Analogiczne roz­wią­za­nie ofe­ru­je AZURE.

Na zakończenie

Osobiście pole­cam roz­wa­że­nie opi­sa­nych tu roz­wią­zań w swo­ich pro­jek­tach. W obsza­rze doku­men­tów i zarzą­dza­nia ich tre­ścią są wręcz dosko­na­łe. Model rela­cyj­ny, dosko­na­ły do obli­czeń, nie­ste­ty prze­gry­wa z kre­te­sem w apli­ka­cjach biz­ne­so­wych, gdzie zaczy­na się liczyć przede wszyst­kim szyb­kość dostę­pu do ogrom­nej ilo­ści danych oraz odpor­ność na szyb­ko zmie­nia­ją­ce się wyma­ga­nia co do struk­tu­ry danych.

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation.

C.d. czy­taj Bazy NoSQL jako imple­men­ta­cje wzor­ców struk­tur infor­ma­cji.

Źródła

Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Wilkins, M. (2020). Amazon Web Services: pod­sta­wy korzy­sta­nia z chmu­ry AWS (J. Zatorska, Trans.). Helion SA.
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A stu­dy of geno­mic data pro­ve­nan­ce in NoSQL docu­ment-orien­ted data­ba­se sys­tems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://​doi​.org/​1​0​.​1​1​0​9​/​B​I​B​M​.​2​0​1​5​.​7​3​5​9​902
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

CHMURY – od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług

Temat clo­ud com­pu­ting jest coraz goręt­szy. Z jed­nej stro­ny pod­grze­wa­ją atmos­fe­rę fir­my ofe­ru­ją­ce róż­ne for­my dzier­ża­wy zaso­bów a z dru­giej tech­no­lo­gie i archi­tek­tu­ry zwa­ne chmu­ro­wy­mi”, pro­wa­dzą do sta­le male­ją­cych kosz­tów inte­gra­cji (chmu­ra prywatna).

Tak zwa­ne tech­no­lo­gie webo­we (np. RESTful/REST API itp.) doty­czą­ce inte­gra­cji, powsta­ły co praw­da już nawet w 2000 roku, jed­nak dopie­ro teraz moż­na mówić o dostęp­nych, prze­te­sto­wa­nych biblio­te­kach, czy­nią­cych tego rodza­ju pro­jek­ty tań­szy­mi, np. oma­wia­ne w arty­ku­le Wymagania poza­funk­cjo­nal­ne ? inte­gra­cja” inte­gra­cja z pomo­cą API to dzi­siaj już taki sam koszt jak spa­wa­nie” z pomo­cą SQL, wystar­czy, że zatrud­ni­my kogoś (fir­mę) kto potra­fi, a nie kogoś kto za nasze pie­nią­dze będzie się dopie­ro zwin­nie uczył, skła­da­jąc ofer­tę mimo bra­ku kom­pe­ten­cji. Opór wie­lu firm przed przed tymi roz­wią­za­nia­mi, z moje­go doświad­cze­nia, wyni­ka z: bra­ku wie­dzy i kom­pe­ten­cji (wie­le zna­nych firm IT nadal ope­ru­je meto­da­mi i tech­no­lo­gia­mi z przed nawet 30 lat!), kur­czo­we­go trzy­ma­nia się mode­lu biz­ne­so­we­go dostar­cza­my jeden mono­li­tycz­ny sys­tem”, któ­ry sil­nie uza­leż­nia klien­ta od dostawcy.

No i sto­so­wa­nie metod opar­tych o tak zwa­ne usłu­gi webse­rvis”, wyma­ga cał­ko­wi­te­go odej­ścia od metod struk­tu­ral­nych pro­jek­to­wa­nia (jed­no­li­te bazy danych w mode­lu rela­cyj­nym i ster­ta funk­cji) na rzecz metod obiek­to­wych i kom­po­nen­to­wych (Large sys­tem archi­tec­tu­re).

Znamienne jest to, że gdy np. prze­szu­ka­my Internet pod kątem SOA, zoba­czy­my, iż w ostat­nich kil­ku latach spo­ro publi­ka­cji poświę­co­no odej­ściu od tra­dy­cyj­ne­go spo­so­bu roz­wo­ju sys­te­mów infor­ma­tycz­nych ? od roz­bu­do­wa­nych roz­wią­zań auto­no­micz­nych do struk­tur zło­żo­nych z róż­ne­go rodza­ju roz­pro­szo­nych usług, ukie­run­ko­wa­nych na obsłu­gę wybra­nych pro­ce­sów biz­ne­so­wych czy choć­by poje­dyn­czych dzia­łań. Równolegle, za Oceanem dyna­micz­nie roz­wi­ja się Cloud Computing. Czymże innym jest to zja­wi­sko, jak nie moż­li­wo­ścią dobie­ra­nia do orga­ni­za­cji (infra­struk­tu­ry IT i mode­lu biz­ne­so­we­go) usług, któ­re są nie­zbęd­ne do efek­tyw­niej­szej pra­cy (?do obsłu­gi wybra­nych pro­ce­sów biz­ne­so­wych czy choć­by poje­dyn­czych dzia­łań?). I tak jak w ostat­nich latach szy­ny inte­gra­cyj­ne słu­ży­ły inte­gro­wa­niu wewnętrz­nej infra­struk­tu­ry IT, tak w naj­bliż­szej przy­szło­ści będą się roz­wi­jać do łącze­nia rów­nież zewnętrz­nych usług z Chmury. (INTEGRACJA ROZWIĄZAŃ Z CHMURY TO WYZWANIE?).

Ja pisa­łem o tym już w 2011 roku (Biznes wycho­dzi .…).

Osobiście nie demo­ni­zo­wał bym koniecz­no­ści posia­da­nia szy­ny inte­gra­cyj­nej”, jak auto­rzy cyto­wa­ne­go powy­żej arty­ku­łu (fir­ma TIBCO jest dostaw­cą takie­go pro­duk­tu), jed­nak trend w kie­run­ku rezy­gna­cji z mono­li­tycz­nych apli­ka­cji już się zazna­cza, a to czy taka szy­na” będzie, raczej jest kon­se­kwen­cją archi­tek­tu­ry. Dobrze zapro­jek­to­wa­na archi­tek­tu­ra całe­go sys­te­mu apli­ka­cji (kom­po­nen­tów) to struk­tu­ra hie­rar­chicz­na: tak zwa­ny front end” to apli­ka­cje, któ­rych odpo­wie­dzial­no­ścią jest zarzą­dza­nie pro­ce­sa­mi, prze­pły­wem pra­cy (wpro­wa­dza­nie danych i korzy­sta­nie z nich). Głębiej są dzie­dzi­no­we apli­ka­cje sta­no­wią­ce refe­ren­cyj­ne skła­dy i źró­dła danych. W takiej archi­tek­tu­rze komu­ni­ka­cja (wywo­ła­nia) jest jed­no­stron­na (zawsze mamy jasny podział usłu­go­bior­ca-usłu­go­daw­ca. Szyny inte­gra­cyj­nej, jako dodat­ko­we­go kom­po­nen­tu, wyma­ga­ją skom­pli­ko­wa­ne sys­te­my i raczej doty­czy to więk­szych kor­po­ra­cji, fir­my nasze­go sek­to­ra MSP rzad­ko kiedy.

Internetowe meto­dy inte­gra­cji (np. wspo­mnia­ny REST) to wymia­na pole­ceń i obiek­tów a nie funk­cja vs. baza danych” (patrz wspo­mnia­ny arty­kuł o inte­gra­cji, dzi­wią mnie deve­lo­pe­rzy narze­ka­ją­cy np. na skom­pli­ko­wa­ne mapo­wa­nie obiek­to­wo-rela­cyj­ne”, bo ono nie ma pra­wa być skom­pli­ko­wa­ne, a jeże­li jest, to jest to pierw­szy sygnał, że to zły projekt!).

Tak więc chmu­ry owszem, to chy­ba przy­szłość, bez wni­ka­nia w to czy to chmu­ry publicz­ne czy pry­wat­ne. Autonomiczne, duże sys­te­my ERP? Nie wró­żę im karie­ry, w obec­nej posta­ci mega-apli­ka­cje umrą, odwle­ka­nie tej śmier­ci z pomo­cą per­swa­zyj­nych reklam i kam­pa­nii dużych kor­po­ra­cji i ich sprze­daw­ców, to tyl­ko sztucz­ne prze­dłu­ża­nie życia inwe­sty­cji w duże ERP, przez pro­du­cen­tów tych roz­wią­zań, dawa­nie sobie cza­su na (mam nadzie­ję) ich refak­to­ring. Mamy np. takie kolo­sy jak Google czy Amazon, któ­re poka­zu­ją, że chmu­ro­we, wyso­ce ska­lo­wal­ne archi­tek­tu­ry zaso­bo­we mają sens. Systemy ERP opar­te na rela­cyj­nych bazach danych i ich wewnętrz­na inte­gra­cja poprzez współ­dzie­le­nie danych, nie mają nawet szan­sy z tego skorzystać.