Понял, спасибо! В показательных целях очень стоит его добавить. Понятно что сканы сами по себе у вас быстрые, но вся мякотка аналитических (OLAP) движков именно вот в этих вот развесистых запросах. TPC-H load, условно говоря. Ну или взять ту же SAP HANA, которая (по крайней мере) утверждает, что никаких больше кубов и преагрегаций, все запросы прямо на колоночном движке с очень высокой скоростью.
Так ведь скрам-тренеры и напирают на то, что надо следовать букве этого скрама, а мы вам продадим свои услуги, чтобы ему ещё более лучше следовать. В любой методологии есть здравый смысл, но когда его возводят в ранг истины в первой инстанции, то проблемы искать надо в самой компании — команде, менеджменте.
Или же постановка действительно адекватных, интересных целей, соотнесённых с видением компании и требованиями заказчика, и здравый смысл. И никакой сахарной пудры сверху.
> Из-за подчеркнутой важности этого элемента скрама, мы всегда его использовали. Но из-за того, что мы не понимали смысла, мы придумывали ужасные цели. Обычно мы просто упрощали процесс выбора цели, задавая негласное правило, брать целью выпуск очередного релиза или реализацию какой-то очередной жирной спринтовой фичи. От этого усиливалось ощущение бесполезности цели, а то и ее вреда.
ПОЧЕМУ нужно выключать мозг и следовать за «серебряными пулями», вместо того чтобы немного подумать и придти к логичным выводам.
В случае если денормализованное представление — это единственное представление, в которое можно писать. Ну не знают модули о нормализованном представлении, оно инкапсулировано как раз-таки через VIEWs. Оно не обязательно, на самом деле, просто денормализованное — оно просто другое, «фасет» если хотите.
Например, несколько систем, разработанных различными группами, будучи установленными, используют одну базу. Внутри этой базы сидит нормализованное представление, разработанное главным БД архитектором. Однако же системы обращаются с данными исключительно через VIEWs. Тем самым достигается decoupling между приложениями и архитектурой базы. Можно не менять приложения и VIEWs, но постоянно работать над внутренним нормализованным представлением и мигрировать его через версии схемы. Separation of concerns на уровне БД.
Если не надо инкапсулировать нормализованное представление и все части приложения знают всё о базе данных (обернули в один большой Repository и подобные паттерны) — то вроде и не требуется.
Согласен, materialised view в теории должен решать означенные в статье проблемы. Если это read-only views — всё тип-топ на самом деле. Если же надо писать туда, на практике выходит, что реализации updatable views имеют много тонкостей, с которыми надо жить.
Это верно, но это не одно и то же. Алгоритмика очень разная. Можно запустить тест, скажем, на агрегацию и простеньким джойном, с классическим MS Sql Server и рядом с чем-нибудь типа MemSQL или VoltDB, и посмотреть. Памяти там много не потребуется, даже на 100 Мб данных разница будет разы или десятки раз. При разрастании числа джойнов это дело уйдёт в сотни раз разницы. Дело не в объёме памяти, а в том, как база работает с хранилищем. После можно попробовать другое упражнение, написать это в хранимке на Ms Sql Server 2014-2016 Hekaton (in-memory table). Hekaton закомпилит это дело и исполнит как нативную DLL внутри процесса in-memory таблицы. В сравнении с обычной Ms Sql Server таблицей разница будет очень заметна. Если бы всё было так просто с памятью и классической БД, то и никакого Hekaton Microsoft не стал бы добавлять в продукт.
Кстати, с in-memory database вопрос денормализации обычно не стоит. Исполнение JOIN суть разыменование указателей в памяти, эта операция тоже чего-то стоит, но безобразно дёшева в сравнении с disk-based JOIN-ами. Я конечно понимаю, big data и все дела, данные не влезают в память. Но во многих бизнес-приложениях «большая база» — это 50-80 Гб. Это уже всё влезает спокойно. 128 Gb сервер совершенно нормально. Ну и опять же, окей, положите своп на быстрый SSD и дайте ей туда немного залезть, тоже ничего страшного. В таком случае, вместо того чтобы кушать кактус и денормализовывать / избыточно материализовать таблицы, проще перейти на true in-memory и получить возможность быстренько все эти данные запрашивать на чтение вдоль и поперёк, и одновременно работая с ними на запись, всё в одном флаконе.
А они как вообще, выпустились, с какими результатами, легко ли? Как экзамены сдавали, быстро или медленно готовились? Надо оценить, как человек проходил этот квест. Если это для него не квест, а каторга — ну что ж. Универ — отличный фильтр. Те, кто застревает в такой вот узкой модели — это (на моей памяти, сам собеседовал десятки) обычно такие ребята, которые ходят на все лекции и повторяют за профессором, а потом ещё и сдают на 4. Смышленые, скоростные — они иногда и профессора-то не видели до экзамена, но сдают с блеском, т.к. к вопросу подошли не зубрежкой и повторением, а собственным пониманием.
Положительнейший эффект российского образования — это получение навыка думать. Казалось бы, зачем кодерам все эти матаны, поверхностные интегралы и критерий Рауса-Гурвица. Очевидно, эти знания будут не нужны в 99% случаев. Дело не в знаниях, а в получении навыка поиска, понимания, отождествления связанных вещей и системного анализа. Знания оставлены в университете, навык сохранён и уже дальше развивается в ваших других областях. Люди, которые развивались в университетские годы по какой-то причине узко — будут такими же узко(лобыми) и на работе. На первой же нестандартной ситуации — пык-мык, не знаю, пойду домой. Или, например, нежелание понимать область коллеги по работе — "не, я узкий специалист". Университет (ну или то что вы причисляете к науке) от этого отучивает. Нисколько не ученых готовят университеты, а закаляют к дальнейшей эффективной жизни.
Есть мнение, что Windows NT архитектура в целом лучше спроектирована для современных приложений, чем posix-основанная архитектура Linux. На архитектурном уровне там действительно довольно много вкусных вещей. Тот кто говорит про проблемы с I/O на Linux, скорее всего не видели IOCP на Windows в действии. А как хороши легковесные fibers в Винде? Эта точка зрения, конечно, теряется за тем, что Windows — это проприетарная система. А чтобы все эти вкусности заиграли, должно быть написано массовое прикладное ПО, его утилизирующее. Что в обозримом будущем не предвидится, ведь из-за недавней закрытой политики Microsoft никто действительно "не любит" Windows. Но что если бы Windows была сделана open-source?..
Быть может всё-таки CORBA?
https://www.vividcortex.com/blog/2015/11/13/capacity-planning-with-usl/
https://en.wikipedia.org/wiki/Neil_J._Gunther
ПОЧЕМУ нужно выключать мозг и следовать за «серебряными пулями», вместо того чтобы немного подумать и придти к логичным выводам.