Maksim B

p.s в дальнейшем по этим данным будет производится сортировка.

Если будет JSON - нет, не будет.
Или берите Postgres.

Постановка вопроса интересная - Нормально ли блаблабла.
Сделайте сначала как думаете, храните динамичные поля в json поле строки таблицы. Потом когда задолбает писать sql запросы по извлечению этих полей вы сами поймете что нужно где хранить. Нормально то что решает конкретно ваши проблемы.

Postgresql умеет работать с json, но приходится писать десериалайзеры и сериалайзеры этих полей при сохранении и извлечении. Мне это не нравится, дополнительный код.
Посмотрите для интереса что умеет делать Mongo. Сейчас меня будут критиковать, типа человек работает с релиационными бд, но если вы не знакомы с ней то я считаю это будет полезной информацией

Прелесть bower в возможности ставить зависимости куда тебе надо, а не в node_modules. Это незаменимо на легаси-проектах, например.
С другой стороны, если ты и на сервере и на клиенте юзаешь, например, momentjs, или у тебя изоморфный рендеринг на react — то не будешь же ставить одно и то же два раза двумя разными менеджерами.

А зачем вам в данном случае вообще Mongo? Опции вполне нормально можно джойнить при условии, что индексы проставлены верно. После первого раза запрос закэшируется и будет работать довольно быстро. Это при условии, что вы пишете запрос с использованием биндов.

Думаю, что лучше взять ES6 + Babel + Webpack. Может я ошибаюсь и лучше взять что-то другое?

Нормально.

Использовать сервер только для получения каких-либо данных, а бизнес-логику поручить клиентсайду? SPA или классический сайт?

Так вы задайте себе вопрос, у вас SPA или классический сайт? Приложение или газета? Gmail нет смысла делать классическим сайтом, визитку нет смысла делать SPA.

Сам по себе ORM, именно как maaping, в крупных проектах нужен как раз очень сильно. Опишу здесь свой опыт. Если понравится кому, может и статью потом.

Итак.
Представьте себе — у меня есть очень крупная система, и есть в ней таблица orders, в ней скажем, 50 колонок (на самом деле у нас 150, ну да ладно. Нормализаторы, молчать! Про нормальные формы я тоже знаю). И вот надо значит вам выбрать один ордер и показать его на экране. Допустим, вы пишете селект, неважно. Дальше что делать, в промежуточном слое? Вы не же вызываете хранимую процедуру (запрос) напрямую с, скажем, JSP страницы (я надеюсь), вам все равно надо получить данные и передать их как-то.
Так что, передавать их в виде массива, ArrayList-a, ассоциативного массива имя колонки/значения? Ну так дико громоздно, неудобно, и очень легко ошибиться. А если вам надо несколько ордеров, тогда что, создавать вложенные коллекции для конвертации результатов? Неудобно же.

Потому, очевидно, нам нужен объект Order, имеющий все нужные property, и нужен код, который умеет конвертировать результаты скл запрос в эти объекты (или коллекцию этих объектов).

Далее, очевидно, что писать руками _все_ запросы трудно и нудно, легко ошибиться, т.к. в Java они будут представляться в коде в виде строк (а значит, никакой статической типизации и compile-time проверок и прочее и прочее), и их надо держать либо в Java коде (если они мелкие), либо, если побольше, выносить в отдельные XML файлы.

В общем, ORM в больших проектах нужен для упрощения рутинной части. Без него — никуда :)

Безусловно, обойтись ТОЛЬКО ORM не получится. Есть у нас масса мест, где сложная логика написана в хранимых процедурах в 500-1000 строк на PL/SQL, написанная через ORM /Java она бы занимала в 10 раз больше и работала в 2 раза медленнее (при этом, она была бы еще и менее понятная, т.к. есть такая логика, которые в терминах реляционной алгебры описывается куда проще, чем в терминах ООП :), следовательно ложится на ORM со скрипом). Сколько нибудь сложные запросы с подзапросами, юнионами, хитрыми джойнами тоже писать через чистый ORM громоздко. Оптимизировать запросы, работающими в таблицах где, хотя бы, несколько сотен миллионов записей, без доступа к планам SQL оптимизатора и статистики/средствам мониторинга уровня СУБД тоже крайне сложно. Так что без SQL тоже — никуда :)

По моему скромному мнению, ORM придумали люди, которым сложновато мыслить теорией множеств, что необходимо для понимания и правильного применения SQL.

Практической пользы от ORM в серьезных проектах чуть меньше, чем от какого-нибудь, прости, Господи, скрама.
В мелких — реальная польза лишь в том, что кто-то будет себя считать крутым ООП-программистом.

Как всегда, рекомендую статью:
citforum.ru/database/articles/vietnam/