Роман ДынникНа мой взгляд, вцелом спроектировано все верно в обоих заданиях.
Оптимизация должна лежать несколько в иной плоскости, не в ущерб целостности и нормализации.
Для OLTP системы следует рассмотреть механизмы секционирования больших таблиц, а так же индексированные/материализованные представления, кот. и выступают в данном случае некоторым механизмом денормализации повышающем производительность, при этом оставляя целостность данных, их атомарность и нормализованность в прежнем виде.
Следует подумать, как уже выше кто то заметил, о механизмах кеширования на стороне сервера приложений.

Если речь идет о некоторой системе отчетности, то данные из OLTP должны переливаться в OLAP-хранилище
Его как правило проектируют денормализованным.

Люди которые бояться джоинов, в том числе в высоконагруженных системах, возможно не понимают разницу между внешним и внутренним соединением. Внутреннее соединение - дешовая операция.
Более того, оно может даже повысить производительность, если будет использовано горизонтальное секционирование и таблицы будут разнесены по разным серверам в кластере.
Если же эти люди в каждом запросе, с поводом и без, пишут outer join вместо join, а то и желают спихнуть все в одну таблицу или в XML в OLTP-системе, следует задуматься а стоит ли с ними работать...
В MySQL нету матвью. Можно сделать его на триггерах, что не есть гуд на вставках. И если бы можно было его создать какие бы матвью в приведенной задаче вы бы создали?

О NDBCLUSTER автор ничего не сказал, и это уже не совсем MySQL.
Секционировать по разным физическим дискам да - можно. Шардировать тоже.

Никакие дополнительные ОЛАП или ДВХ сервера скорее всего не нужны. На край этими задачами можно загрузить сервак ночью.

Насчет JOIN-ов надо плясать от необходимых запросов учитывая, что в MySQL нет HASH JOIN. Отсутсвие запросов - на совести работодателя. Количество записей в таблицах тоже. Скорее всего надо обеспечить MERGE JOIN для users и orders.

Роман ДынникВнутреннее соединение - дешовая операция.
Более того, оно может даже повысить производительность, если будет использовано горизонтальное секционирование и таблицы будут разнесены по разным серверам в кластере.

В данном случае хранение в отдельных таблицах cities и categories и соединение повысит производительность за счет хранения их в ОЗУ и меньшего чтения с дисков чем при денормализации, даже без партиционирования, шардирования или ndb. В свою очередь партиционирование, шардирование или ndb увеличат скорость и при денормализации.
Но если даже в денормализованном виде вся БД помещается в ОЗУ, в частности при использовании шардирования или ndb, то этот вариант может быть ещё более предпочтительным в плане скорости со всеми вытекающими от сюда косяками.

Роман Дынник exploys ,
Ну а какое отношение приведенные механизмы имеют к проектированию?
С точки зрения проектирования OLTP, задачи решены вцелом верно.

Отношение? Никакое, также как и
Роман ДынникБолее того, оно может даже повысить производительность, если будет использовано горизонтальное секционирование и таблицы будут разнесены по разным серверам в кластере .


Роман ДынникЕсли бы мускул поддерживал матвью, то те же join-ы из n таблиц (если кто то их боится) можно было бы материализовать. И на физическом уровне это выглядело бы как денормализация, только использовались бы эти матвью для поиска, а не для инсертов.
Если бы?
И при DML надо было бы делать в 2 раза больше IO: в таблицу и матвью. Учитывая, что безграмотный работодатель не сообщил какие запросы пойдут к БД.
А если бы MySQL мог выполнять все тоже самое только в 1000 раз быстрее можно вообще все оставить как есть.