Forumo pulsas

[Augustas]

Vienok po prigožino demonstracijos dabar visi apsišikę orkų kareiviai verkiantys kad juos čia verčia tarnauti ir žudyti ukrainiečius, atrodo dar labiau apgailėtinai. Nueitų iki maskvos ir nuverstų savo cariuką užuot veršklenę. Arba gali stipti Ukrainoje, jų pasirinkimas.

Jiems įsakyta stipti Ukrainoje, todėl nėra kito pasirinkimo. Ar kaip ten jie sako...

Realiai viskas fronte, Maskvą paimtų ir civiliai. Su aukomis, aišku, kaip Maidane ar didesnėmis. Bet jiems tiesiog dzin, net opozicija juos įkalbinėja, kad nieko nedarytų, nes jie tipo bejėgiai prieš bananus.

Tikrai ne viskas fronte, bent jau FSO su rossgvardiečiais tikrai yra ne fronte.

[Svetimas]

Vienok po prigožino demonstracijos dabar visi apsišikę orkų kareiviai verkiantys kad juos čia verčia tarnauti ir žudyti ukrainiečius, atrodo dar labiau apgailėtinai. Nueitų iki maskvos ir nuverstų savo cariuką užuot veršklenę. Arba gali stipti Ukrainoje, jų pasirinkimas.

Jiems įsakyta stipti Ukrainoje, todėl nėra kito pasirinkimo. Ar kaip ten jie sako...

Realiai viskas fronte, Maskvą paimtų ir civiliai. Su aukomis, aišku, kaip Maidane ar didesnėmis. Bet jiems tiesiog dzin, net opozicija juos įkalbinėja, kad nieko nedarytų, nes jie tipo bejėgiai prieš bananus.

Smulkmena. Svarbu, kad moliūginės latė kol kas kai kam netrūksta.

[Augustas]

Jiems įsakyta stipti Ukrainoje, todėl nėra kito pasirinkimo. Ar kaip ten jie sako...

Realiai viskas fronte, Maskvą paimtų ir civiliai. Su aukomis, aišku, kaip Maidane ar didesnėmis. Bet jiems tiesiog dzin, net opozicija juos įkalbinėja, kad nieko nedarytų, nes jie tipo bejėgiai prieš bananus.

Smulkmena. Svarbu, kad moliūginės latė kol kas kai kam netrūksta.

Ir, deja, netrūksta tos "latė" daug kam. Todėl niekas ir neis protestuoti iki tokio lygio, kad nuverstų V.Putino režimą.

[Svetimas]

Ir, deja, netrūksta tos "latė" daug kam. Todėl niekas ir neis protestuoti iki tokio lygio, kad nuverstų V.Putino režimą.

"Moliūginė latė" yra runete paplitęs tam tikras memas. Tik gal daugiau painiavos įveda, nei kažką paaiškina ar prasmingo pasako daugumai. Nors kokiems žmonių psichikos tyrinėtojams galimai įdomus psichologinis fenomenas.

[Svetimas]

Aš tiesiog tikiuosi, kad išsikelti tikslai yra pagal realias galimybes, o ne pagal kažkieno sukeltus lūkesčius.

Panašiai irgi tikiuosi. Tik kai kurie girdėti lyg ir pernelyg optimistiniai Zelenskio pareiškimai ir pan., gan rimtai pasilpnino tokį mano tikėjimąsi.

Savotiškas ir keistokas nesenas Alfred Koch postas.

[Seianus]

Now it's official.

A federal judge yesterday ordered the Biden administration to halt a wide range of communications with social media companies, siding with Missouri and Louisiana in a lawsuit that alleges Biden and his administration violated the First Amendment by colluding with social networks "to suppress disfavored speakers, viewpoints, and content."

The agencies and officials are prohibited from communicating "with social-media companies for the purpose of urging, encouraging, pressuring, or inducing in any manner the removal, deletion, suppression, or reduction of content containing protected free speech posted on social-media platforms," Doughty ruled. The injunction prohibits "specifically flagging content or posts on social-media platforms and/or forwarding such to social-media companies urging, encouraging, pressuring, or inducing in any manner for removal, deletion, suppression, or reduction of content containing protected free speech."

Government agencies and officials are further barred from urging, encouraging, or pressuring social media companies "to change their guidelines for removing, deleting, suppressing, or reducing content containing protected free speech." The ruling also said the government may not coordinate with third-party groups, including the Election Integrity Partnership, the Virality Project, and the Stanford Internet Observatory, to pressure social media companies.

[Svetimas]

viewtopic.php?p=117161#p117161
1) Valdykis su kabutėmis.

Ačiū kad priminei.

2) Nei vienas iš variantų netinka absoliučiai visiems gyvenimo atvejams. Bet apskritai nemanau, kad duombazių gamintojai turi ar kada nors turėjo ambicijų gaminti pilnavertiškus produktus programavimui. Visa tai daugiau papildomi, pavėluotai įgyvendinti featurai, kurie gali būti visai naudingi sprendžiant labai specifiškas problemas. Bet naudoti plačiai? Neee.

Suprantu, kad netinka visiems atvejams. Šiek tiek susiaurinu situaciją dėl didesnio problemos aiškumo. Kuri būtų suderinama su bet kuria kiek pažangesne kliento jau turima Y DB, kuri palaiko SQL standartą.

Tarkime, jog kalbame apie tam tikros pardavimui patrauklios specifinės analitinės X sistemos (aplikacijos) sukūrimą. Kliento, t.y. potencialaus parduodamos X sistemos pirkėjo jau esamos ir nuo seno naudotos Y DB duomenų struktūrose labai tikėtina jog bus ne mažiau nei keli milijonai įrašų, kurių duomenys reikalingi X sistemos analitiniams rezultatams. Dalis įrašų ir jų duomenų tose milijonus įrašų turinčiose lentelėse nuolatos kas dieną įvairiomis transakcijomis (pvz., ne mažiau nei keli tūkstančiai transakcijų per dieną) pasipildo/atsinaujina. Skirtingų analitinių užklausų, kad informacinė X sistema galėtų paimti ir sugeneruoti jai reikalingus rezultatus iš Kliento Y DB esančių duomenų, yra ne mažiau nei keliasdešimt. Šias analitines užklausas (reikalingas X sistemai) per dieną reikės įvykdyti irgi ne mažiau kaip kelis tūkstančius kartų.

Šitoje situacijoje grubiai yra galimi 2 variantai:

1-as variantas. Kliento Y DB duomenų struktūrų su milijonais įrašų X sistemai reikiami duomenys yra perkeliami (per kažkokią I integraciją su neišvengiamais duomenų transformavimais) į X sistemos savą atskirą lokalią L DBVS. Po to papildomai kiekvienas kasdienis Y DB duomenų struktūrų duomenų atnaujinimas skirtingomis transakcijomis per X sistemą iš karto online replikuojamas (per I integraciją) į X sistemos lokalios L DBVS duomenų bazę. Toliau X sistema naudoja savo lokalią L DBVS nesigilindama per daug į kliento Y DBVS specifiką. Vykdo sau reikalingas analitines SELECT užklausas X sistemos lokalioje L DB ir t.t.

2-as variantas. Kliento Y DB duomenų bazėje sukuriami tam tikri X sistemai reikalingi standartizuoti view'ai, duomenų struktūros ar pan. ir X sistema vykdo sau reikalingas Y DB pritaikytas analitines SELECT užklausas tiesiogiai į kliento Y DB. Sugeneruotus analitinių užklausų rezultatų duomenis (kurių apimtis yra daug kartų mažesnė nei analitinių užklausų pagalba nuskaitomi duomenys) X sistema nusiskaito ir įsirašo į lokalią DB (arba, gan tikėtina, ir į tos pačios kliento Y DB papildomas X sistemai reikalingas naujai sukurtas struktūras Y DB, jei kliento Y DB DBVS yra pilnai tinkama ir suderinama su X sistema).

1-u atveju reikalinga kliento Y DB nuolatos atnaujinamus X sistemai reikalingus didelės apimties duomenis online dubliuoti transformuotai X sistemos savoje lokalioje L DBVS. Tam reikia realizuoti iš kliento pusės specifinę standartizuotą integraciją dėl kliento Y DB duomenų perkėlimo į X sistemą. Bet yra ir savų privalumų. X sistema po to yra "out of the box". Ir X sistemai yra naudojama kažkokia viena konkreti suderinta, standartizuota, suoptimizuota, X sistemai pritaikyta lokali L DBVS. Kokie nors specifiniai indeksai ar pan. efektyviam L DB panaudojimui šitoje vietoje gali būti pakankamai svarbūs.

2-u atveju nereikalinga kliento Y DB X sistemai reikalingų didelės apimties duomenų online dubliuoti transformuotai X sistemos savoje lokalioje L DBVS. Bet atsiranda savi trūkumai, kad X sistemą reikia derinti prie kliento Y DB specifikos. Tačiau tada nereikia realizuoti iš kliento pusės specifinės integracijos dėl kliento Y DB duomenų perkėlimo į X sistemą. Be to, jei kliento Y DB, kurią jis iki tol jau naudoja savo reikmėms, yra kažkuo specifiškai pažangi (o kartu ir brangi), tai ji galimai efektyviau galėtų tvarkytis su analitinėmis X sistemos užklausomis, nei X sistemos tikėtinai nemokama lokali L DBVS.

Kuris realizacijos variantas, jeigu būtumėte X sistemos potencialus pirkėjas, jums atrodytų su mažesniais trūkumais ir patrauklesnis?

3) Pati reliacinė DB yra gana specifiškiems uždaviniams reikalingas dalykas. Dažnu atveju ji yra overkillas net ir tiesiog duomenų saugojimui be jokių stored procedūrų naudojimo.

Dalykas tas, kad situacijoje aukščiau aprašyta sistema X dėl savo specifikos bet kokiu atveju naudotų kažkokią DBVS (tiek analitinių sistemos X užklausų vykdymui, tiek jų pagalba gautų rezultatų įrašymui). Vienoks ar kitoks "overkillas", tavo terminais, būtų bet kokiu atveju.

Galų gale nelabai esu girdėjęs atveju, kad rimtesnėse informacinėse sistemose galima būtų kažkaip lengvai išsiversti be su jomis susijusių duomenų bazių. Jei tokių atvejų žinai, tai gal gali pasidalinti? Kol kas nematau kokių alternatyvų tam.

O apie tai, kad aplikacijų programuotojai į skirtingas DBVS sistemas neretai gan atsainiai žiūri kaip į bjaurias juodas dėžes (su savo "durnais" veikimo principais), į kurias reikia neva nepatogiai sukišinėti duomenis arba paiminėti iš jų keistais bjauriais nemaloniais būdais, arba kad jiems dažnai labai mažai įdomios skirtingų DBVS specifikos, dėl ko neretai kyla įvairių bėdų, taip pat istorijų iš savo pusės galėčiau parankioti.

[Seianus]

Galų gale nelabai esu girdėjęs atveju, kad rimtesnėse informacinėse sistemose galima būtų kažkaip lengvai išsiversti be su jomis susijusių duomenų bazių. Jei tokių atvejų žinai, tai gal gali pasidalinti? Kol kas nematau kokių alternatyvų tam.

Priklausomai nuo to, ką laikai rimtesnėmis, greičiausiai jos neišsiverčia be duomenų bazių pagal apibrėžimą. Nežinau, ką omeny turėjo Lionginas, tačiau aš sakyčiau, dauguma reprezentacinių įmonių websaitų gali būti puikiai padaryti be SQL ir niekas nepajaustų skirtumo, net kai prireikia updatinti tekstus kartą per du metus. Tam puikiai užtektų paprastų tekstinių failų ar blogesniu atveju XML / XSLT, ar jei baisiai norisi duombazių - kad ir SQLite. Na bet programuotojai norėjo žaisti su įdomesniais žaisliukais, vadybininkai norėjo parduoti brangesnį produktą, o šiais laikais turbūt visi jau nori parduoti wordpressą, nes dauguma websaitų kūrimo įmonių programuotojų nebeturi, tik wordpresso jungėjus, save laikančius programuotojais. Mat savikaina mažesnė.

[Svetimas]

Priklausomai nuo to, ką laikai rimtesnėmis, greičiausiai jos neišsiverčia be duomenų bazių pagal apibrėžimą.

Taip. Tai, ką turiu galvoje nupasakotoje situacijoje, neišsiverčia be kliento jau turimos Y DB (arba su ja tiesiogiai sąveikaujančios kliento turimos aplikacijos/sistemos Z) pagal apibrėžimą.

[Seianus]

Kasmetinis priminimas, kad Saulės sistema yra išskirtinė.

[Svetimas]

Kasmetinis priminimas, kad Saulės sistema yra išskirtinė.

Įvertinus tikimybę, kad Saulė pakankamai reta savo savybėmis žvaigždė, lyginant su kitomis kiek panašiomis žvaigždėmis, ir tai, kad Saulės sistema ir planetų "architektūra" Saulės sistemoje yra gan nebūdinga panašių žvaigždžių sistemoms, sumoje gaunasi dar didesnis išskirtinumo koeficientas (net nevertinat kitų neįvardintų ir visiems akivaizdžių iškirtinumo faktorių ).

[Seianus]

Įvertinus tikimybę, kad Saulė pakankamai reta savo savybėmis žvaigždė, lyginant su kitomis kiek panašiomis žvaigždėmis, ir tai, kad Saulės sistema ir planetų "architektūra" Saulės sistemoje yra gan nebūdinga panašių žvaigždžių sistemoms, sumoje gaunasi dar didesnis išskirtinumo koeficientas (net nevertinat kitų neįvardintų ir visiems akivaizdžių iškirtinumo faktorių ).

Ironiška, kad laikantys save reikšmingais visatoje visokių mokslo populiarintojų būdavo tiek mokomi kuklumo. Pasirodo, mokytojams patiems neprošal pasimokyti kuklumo ir prisiminti, kad iš nežinojimo neplaukia žinios. Jei nežinome, ar Saulės sistema išskirtinė ar įprasta bent jau mūsų galaktikoje, tai nežinome. O ne imti prielaidą, kad tokių pilna, ir remiantis ta nepagrįsta prielaida pamokslauti kitiems nuo savo aukšto nemoksliško arklio.

Kitas šių gana naujų žinių rezultatas aišku turėtų būti Dreiko „lygties“ ir Fermi atsiprašant „paradokso“ galutinis išmetimas į šiukšlyną kur jiems seniai vieta, bet tas žinoma neįvyks, per daug clickų pritraukia paistalai šiomis temomis. Tad ir toliau visokie mokslo taip vadinami populiarintojai rimtu snukiu postringaus, koks čia keistas paradoksas, o paskui atsisukę į tikinčiuosius tokiu pat rimtu veidu aiškins, kad kai trūksta žinių, reikia sakyti nežinau, o ne išsigalvoti dievybes.

[Svetimas]

Įvertinus tikimybę, kad Saulė pakankamai reta savo savybėmis žvaigždė, lyginant su kitomis kiek panašiomis žvaigždėmis, ir tai, kad Saulės sistema ir planetų "architektūra" Saulės sistemoje yra gan nebūdinga panašių žvaigždžių sistemoms, sumoje gaunasi dar didesnis išskirtinumo koeficientas (net nevertinat kitų neįvardintų ir visiems akivaizdžių iškirtinumo faktorių ).

Ironiška, kad laikantys save reikšmingais visatoje visokių mokslo populiarintojų būdavo tiek mokomi kuklumo. Pasirodo, mokytojams patiems neprošal pasimokyti kuklumo ir prisiminti, kad iš nežinojimo neplaukia žinios. Jei nežinome, ar Saulės sistema išskirtinė ar įprasta bent jau mūsų galaktikoje, tai nežinome. O ne imti prielaidą, kad tokių pilna, ir remiantis ta nepagrįsta prielaida pamokslauti kitiems nuo savo aukšto nemoksliško arklio.

Čia gal Carl Sagan kontekste šitą dalyką komentuoji? Ar ir kiek plačiau kabini? Įtarčiau, kad Drake lygtį ir Fermi paradoksą ateivių temų populiarumo madomis užsikrėtusios medijos greičiausiai neproporcingai išpūtė. Tokiu atveju nelabai suprantu tavo akmenukų į mokslo populiarintojų daržą. Nebent turi kažkokių savo duomenų ir apie Drake, Fermi ar pan. mokslo populiarinimo tiesioginę veiklą ar kad jie minėtus dalykus kažkaip agresyviai laymanams bruko/reklamavo?

Ir, apskritai, sunku atrasti žmogų, kuris praktiškai nenusikalbėtų įvairiais klausimais. Net ir savo srityse. Nors, aišku, iš to neseka, jog vertinimai, kokiu dažniu vienas ar kitas žmogus nusikalba, neturi prasmės. Ypač savo srityse.

[Lionginas]

J.Prigožinas yra vadinamojo "kolektyvinio Putino" sudėtinė dalis ir vienas tokių dalykų realiai negalėjo suorganizuoti. Nepamirškim, jis pats net nėra karys.
O tikslai tai aiškūs - 1) apmulkinti ukrainiečių karius, kad jie lįstų į spąstus, kuriuos, matyt, jau buvo paspendęs D.Utkinas (aka "Vagneris") Ukrainoje, ir patirtų daug aukų, bei 2) vakariečius įtikinti, kad V.Putinas yra silpnesnis nei atrodo, kad tie irgi lįstų spąstus, kuriuos galimai paspendė FSB. Tik antrasis tikslas tikriausiai liko neįgyvendintas, nes kažkur spaudoje buvo žinutė apie tai, jog JAV perspėjo ukrainiečius nelįsti į Rusiją. O pirmąjį nutyli patys ukrainiečiai.

Tai planas buvo stipriai surizikuoti putino reputacija ir režimo stabilumu tam, kad kažką įvilioti į spąstus? Ir tada viską staiga nutraukti nelaukiant, kol kas nors ryšis į tuos spąstus lįsti? Gudru, ką ir besakyti. Čia kaip pokeryje padaryti didžiulį statymą ir nelaukiant, kaip į tai atsakys oponentas, iš karto pasuoti

Iš tiesų tai tau pats esi nejuokingai pasidavęs kremliaus propagandai, neva už kiekvieno putino liapsuso slypi kažkoks genialus planas. Nėra jokio plano, buvo maišto bandymas, po to buvo susitarimas ir tiek.

[Lionginas]

Kuris realizacijos variantas, jeigu būtumėte X sistemos potencialus pirkėjas, jums atrodytų su mažesniais trūkumais ir patrauklesnis?

Tai kad čia visiškai teorinės alternatyvos be jokio konteksto. Prašai pasirinkti, kuris variantas estetiškai man labiau patinka?

3) Pati reliacinė DB yra gana specifiškiems uždaviniams reikalingas dalykas. Dažnu atveju ji yra overkillas net ir tiesiog duomenų saugojimui be jokių stored procedūrų naudojimo.

Dalykas tas, kad situacijoje aukščiau aprašyta sistema X dėl savo specifikos bet kokiu atveju naudotų kažkokią DBVS (tiek analitinių sistemos X užklausų vykdymui, tiek jų pagalba gautų rezultatų įrašymui). Vienoks ar kitoks "overkillas", tavo terminais, būtų bet kokiu atveju.

Galų gale nelabai esu girdėjęs atveju, kad rimtesnėse informacinėse sistemose galima būtų kažkaip lengvai išsiversti be su jomis susijusių duomenų bazių. Jei tokių atvejų žinai, tai gal gali pasidalinti? Kol kas nematau kokių alternatyvų tam.

Aš ne be reikalo rašiau "reliacinė DB". Yra visokių DB, pavyzdžiui, NoSQL. Ir iš tiesų, reliacinė dažnu atveju nelabai reikalinga, nes labai daug aplikacijų reikalingas tik skaitymas pagal indeksą ir rašymas pagal indeksą. Dažnai net nereikia, kad kažką įrašius, rezultatus realiu laiku visi galėtų nuskaityti. Pavyzdžiui, tokiai aplikacijai kaip Gmail, realiacinė DB ne tik nereikalinga, bet ir turi daug trūkumų, nes NoSQL duombazės yra kur kas spartesnės ir labiau scalable nei reliacinės. Arba, jei aplikacijos pagrindinė funkcija yra paieška, tai geriau rinktis kokį nors ElasticSearch, kuris čia visa galva pranašesnis nei reliacinės DB.

Tiesą sakant, ne kartą teko susidurti su situacija, kai visokie VIEW'ai yra naikinami ir reliacinės DB struktūra stipriai denormalizuojama vien tam, kad kaip nors išspręsti spartos problemas. O kai pradedama atsisakyti to, kuo reliacinė DB stipri, tai kyla mintis, kad gal nuo pat pradžių pasirinktas nelabai teisingas įrankis konkrečiai problemai.

[Lionginas]

Priklausomai nuo to, ką laikai rimtesnėmis, greičiausiai jos neišsiverčia be duomenų bazių pagal apibrėžimą. Nežinau, ką omeny turėjo Lionginas, tačiau aš sakyčiau, dauguma reprezentacinių įmonių websaitų gali būti puikiai padaryti be SQL ir niekas nepajaustų skirtumo, net kai prireikia updatinti tekstus kartą per du metus. Tam puikiai užtektų paprastų tekstinių failų ar blogesniu atveju XML / XSLT, ar jei baisiai norisi duombazių - kad ir SQLite. Na bet programuotojai norėjo žaisti su įdomesniais žaisliukais, vadybininkai norėjo parduoti brangesnį produktą, o šiais laikais turbūt visi jau nori parduoti wordpressą, nes dauguma websaitų kūrimo įmonių programuotojų nebeturi, tik wordpresso jungėjus, save laikančius programuotojais. Mat savikaina mažesnė.

Kas liečia reprezentacines svetaines, tai joms galima naudoti prantiškai bet ką, ten overkillas bus bet kas sudėtingesnio nei failų sistema ir CSV.

Bet net ir sudėtingesnių aplikacijų atveju reliacinė DB gali būti overkillas, nes reliacinės DB navarotai - sudėtingi JOINai, duomenų duplikacijos minimizavimas, duomenų nuoseklumas ir prieinamumas iš karto po įrašymo - tiesiog nėra labai reikalingi. Pavyzdžiui, jei tai koks nors socialinis tnklas, kam jam viso to reikia? Na taip, kai kurie socialiniai tinklai naudoja reliacines DB, bet dažniausiai tiesiog todėl, kad su jomis pradėjo, o dabar turbūt net nenaudoja pagal paskirtį. Kiek žinau, Facebook naudoja MySQL, bet tiesiog kaip key-value talpyklą. Jei rašytų viską nuo 0, tai greičiausiai nesirinktų nei MySQL, nei jokios kitos reliacinės DB. Nes didesnis prioritetas yra ne mano išvardinti reliacinės DB privalumai, o gebėjimas suvirškinti didelius duomenų kiekius ir scalability. Jei vis tiek norisi turėti kažkokį rudimentinį SQL analogą infromacijos ištraukimui, tai tam yra, pavyzdžiui, Cassandra, kuri socialiniams tinklams tinka kur kas labiau.

[Lionginas]

Jiems įsakyta stipti Ukrainoje, todėl nėra kito pasirinkimo. Ar kaip ten jie sako...

Realiai viskas fronte, Maskvą paimtų ir civiliai. Su aukomis, aišku, kaip Maidane ar didesnėmis. Bet jiems tiesiog dzin, net opozicija juos įkalbinėja, kad nieko nedarytų, nes jie tipo bejėgiai prieš bananus.

Tikrai ne viskas fronte, bent jau FSO su rossgvardiečiais tikrai yra ne fronte.

FSO ir rossgvardiečiai tai čia Ukrainos berkuto analogai? Kur berkutas dabar, beje? Po Maidano kažkaip nieko negirdėti, kažkas nutiko?

[Svetimas]

Aš ne be reikalo rašiau "reliacinė DB". Yra visokių DB, pavyzdžiui, NoSQL.

Dabar geriau supratau, ką anksčiau turėjai omenyje. Rašydamas savo komentarą, prieš tai automatiškai atmečiau DB, kurios nėra "reliacinės DB", kaip kad, pvz., NoSQL, iš savo versijų lauko.

Kaip jau minėjau, sistemai X (potencialiai parduodamam produktui), reikės vykdyti gan tankiai tam tikras pakankamai sudėtingas analitines užklausas, didelio skaičiaus turimų išfiltruotų skirtingų duomenų įrašų agregavimui (sum, avg, min, max, count ar pan.) įvairiais pjūviais ir pan., iš kliento informacinėse sistemose (IS) jau turimų duomenų (su pakankamai mažu uždelsimų nuo naujos informacijos įrašymu jose).

Minėtoms analitinėms užklausoms neišvengiamai reikės tam tikrų JOIN'ų pagal kliento turimas skirtingas duomenų struktūras (t.y. specialias pakankamai griežtas skirtingas duomenų formas) ir neretai įvairių kryžminių duomenų palyginimų tarp jų. Kliento duomenys jo IS paprastai bus saugomi iš anksto apibrėžtose ir pakankamai griežtose duomenų struktūrose. Kurių gan nemažas skaičius. Ir kurias lengva logiškai suvesti/normalizuoti į duomenų žvaigždines schemas, kuriose yra kelios didelės faktinės lentelės iš daug įrašų. Duomenis reikės apjunginėti, agreguoti ir lyginti (kryžmiškai ar kitaip) tarp skirtingų tokių didelių faktinių lentelių. Už skirtingus faktinių laikotarpių rėžius ar pan.

Kiek pats žinau ar esu susidūręs, NoSQL DB su duomenų sudėtingesnėmis analitinėmis užklausomis, kurioms prireikia JOIN'ų tarp skirtingų duomenų struktūrų, nėra itin gerai pritaikytos. Nors gal jau ir yra kokių naujų atsiradusių gudrių produktų NoSQL ar pan. DB rinkoje ir galimai šitoje vietoje klystu ir mano žinios jau kiek pasenusios.

Sistema X tuo ir probleminė, kad iš savo panaudojamumo pusės būtų kaip ir savotiškas Online Transaction Processing (OLTP) ir Online Analytical Processing (OLAP) hibridas, kur OLTP operacijos dažnai inicijuotų nemažą seriją OLAP užklausų. Duomenų įrašai saugomi pakankamai griežtose iš anksto apibrėžtose duomenų formose (struktūrose). Naudojami duomenų laukeliai yra trumpi. Dominuoja skaitiniai sumų laukeliai, datos/laiko laukeliai, trumpi tekstai ar klasifikatorių reikšmės ar neilgi duomenų masyvai (subformos), dažniausiai vienmačiai.

Tiesą sakant, ne kartą teko susidurti su situacija, kai visokie VIEW'ai yra naikinami ir reliacinės DB struktūra stipriai denormalizuojama vien tam, kad kaip nors išspręsti spartos problemas.

Duomenų žvaigždinėms schemoms, kaip aukščiau nupasakojau, VIEW'ų naudojimas, jei protingai sudėti indeksai ar kokios particijos gudresnėms DBVS, kaip ir neturėtų kelti spartos problemų reliacinėse DB, kurias iš pat pradžių ir turėjau omenyje.

Tai kad čia visiškai teorinės alternatyvos be jokio konteksto. Prašai pasirinkti, kuris variantas estetiškai man labiau patinka?

Ok. Dar labiau sukonkretinau komentaruose aukščiau situacijos nupasakojimą. Gal dabar kartais kils kokių naujų minčių, idėjų ar patikslinančių klausimų.

O kad per mūsų šiokį tokį nesusikalbėjimą prieš tai paminėjai DB, kurios nėra reliacinės, irgi į naudą išėjo. Buvo proga naujai plačiau pasidomėti dabartinėmis jų galimybėmis.