![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bowhillШироко известный в узких кругах Анатолий Левенчук взялся за базы данных. Взялся со всем пылом профессионального дилетанта. Его текст можно прочесть по двум причинам: a) чтобы узнать, что есть ахинея, которую не надо повторять самим и b) посмотреть что бывает, когда человек предпочитает объяснять прежде или вместо того, чтобы начать изучать и разбираться.
https://ailev.livejournal.com/1486407.html
https://ailev.livejournal.com/1486407.html
По просьбам трудящих
Date: 2019-08-24 06:45 pm (UTC)---
Ну вот SAP — это про базы данных, и там "из коробки" есть модель данных на примерно 30тыс. табличек. Это некоторая модель предприятия. При этом, скажем, если у тебя нужно описать каталог оборудования и (что неправда) каждый вид оборудования описывается одной табличкой, то 15тыс. видов оборудования (это очень маленький каталог!) описываются сразу 15тыс. табличек, и запросы к такой базе начинают быть грустными. При этом, конечно, как-то изгаляются: на реляционной модели пишут какую-то другую "наложенную объектную модель" (чаще всего объектную, ибо других вариантов не знают) и как-то уже заполняют всю базу в соответствии с этой моделью. Потом скорости не хватает, и пишут прямо поверх этой модели в исходные таблички, наступает бардак. Но вот обработка ведётся где-то в "бизнес-логике", внутри программ. А программы пишутся на "обычных языках программирования", и дальше идут запросы в базу данных, переконвертация из типов базы данных в типы языка программирования, а затем вычисления для предметной области обработки этих данных (что-то там в коропоративной аналитике, например) в самом языке программирования и затем выгрузка результатов назад в базу данных. Всё это сопровождается головной болью по поводу синхронизации работы разных программ над этой базой данных (кто-то ещё читает, а кто-то уже пишет туда же), распараллеливания работы (считать-то много, параллельность выполнения запроса к базе, дальше параллельность обработки выгруженного), часть вычислений уходит в GPU-ускорители баз данных, часть в GPU-ускорители для операций с массивами языка программирования, и весь этот весёлый бардак с перегоном из формата в формат для вроде бы копеечных обработок весело журчит и булькает часами, и энтерпрайз прямо на глазах становится кровавым. Перегонка СУБД в оперативную память помогает, но не сильно — там всё плохо архитектурно, так что это просто "механическое ускорение", оно не из первых принципов. Так что SAP очень, очень хороший пример того, как всё печально)))
По просьбам трудящих
Date: 2019-08-24 06:49 pm (UTC)---
Ну вот я спрашиваю, как мне кодировать мир не в реляционных табличках, а прямо в типах языка программирования? Есть методичка? А мне отвечают: кодируй мир в реляционных табличках, но мы тебе расскажем, как более безошибочно строить реляционный запрос к этим табличкам, где ты закодировал мир (и всё достоинство нового языка в том, что он хорошая прокладка к SQL — который убог). Только программировать ты будешь на функциональном языке, типы внутри языка у тебя будут побогаче, но как кодировать в этой богатой системе типов мир, мы тебе не скажем — ибо ты просто будешь работать с этой богатейшей системой типов с убогим миром реляционных табличек. Ну, с убогим миром реляционных табличек и паскаль справится. Вопрос-то в том, что сначала богатый мир упихиваем в таблички, а потом таблички распаковываем в чудесатые типы — уже после того, как миру при упихиванию его описания в реляционку уже обрезали всё, что можно.
По просьбам трудящих
Date: 2019-08-24 06:51 pm (UTC)---
Меня не интересуют SQL базы данных с реляционной моделью данных как foundation ontology. Я спрашиваю, зачем мне вообще эти базы данных, если у меня есть много более богатые системы типов для описания мира мимо реляционного представления — и я могу выражать сложные описания мира в типах языков программирования много более кучеряво, чем в реляционных табличках. А если мне скажут, что это неуниверсально, так я отвечу, что для доступа к значениям типов в языке программирования у меня есть сам этот язык — и уж он всяко будет не хуже языка запросов, он ведь как раз для обработки данных, упакованных в этих его кучерявых типах придуман!
По просьбам трудящих
Date: 2019-08-24 06:54 pm (UTC)На продажу несуществущей панацеи для выдуманных концепций и проблем.