mletov

Это бунт машин! срочно выбрасывай системник из окна :)

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

Видите ли в чем дело - нормализация это не столько для СУБД и не для приложения ее использующего. Это больше для вас, для разработчика (БД и/или приложения), и для целостности и согласованности данных.

Безусловно, в продакшене идеальна та БД, структура которой позволяет выполнить наиболее частые (или тяжелые) запросы к БД максимально экономно с точки зрения аппаратных ресурсов (меньше чтений блоков с диска, меньше джоинов, наиболее эффективное использование индексов), и такая структура вовсе не обязательно должна быть в высокой нормальной форме. Однако, есть и другой вопрос - какая БД идеальна для вас, как для разработчика? Избыточность в базе - потенциал для ошибок. Если какую-либо информацию нужно обновить в двух местах (например, цену товара в чеке и общую стоимость заказа) - вы всегда имеете возможность где-то забыть это сделать.

Именно по причине несовпадения двух структур БД: максимально нормализованной, удобной для разработчика/проектировщика, и оптимизированной для выполнения запросов - стандартный цикл проектирования БД включает в себя этап нормализации до опредленного уровня (хотя бы до 3нф), и последующей денормализации для ускорения конкретных запросов (также, как и построение необходимых индексов). Т.к. денормализация требует усложнения логики работы с базой (те самые обновления в нескольких местах), эту логику (чаще всего это хранимки или триггеры, реже - на стороне приложения) нужно реализовывать максимально аккуратно и формально. Это похоже на написание кода на высокоуровневом языке и последующая его компиляция под конкретную платформу с максимальными оптимизациями. Единственное важное отличие - особенности целевой платформы известны заранее, и компилятор, учитывающий эти особенности, можно написать один раз, а вот особенности работы БД в каждой задаче - свои, поэтому в каждом случае нужно проводить работу по оптимизации БД с нуля.

Нужно отметить, что в современных системах денормализация схемы - не единственный и не всегда лучший способ повышения производительности. Кэширование часто используемых данных в каком-нибудь memcached - иногда проще и эффективнее, чем денормализация БД и поддержка ее согласованности.

да на любую вменяюмую cms: битрикс, джумла, модиск, вордпресс и т.д.

В mysql это выглядело бы так:

SELECT z.Nomer, GROUP_CONCAT(p.Name SEPARATOR ', ')
FROM Nakladnaya as n
INNER JOIN Product as p ON n.ProductID = p.ID
INNER JOIN Zakaz as z ON n.ZakazNomer = z.Nomer
GROUP BY z.Nomer

В ms sql, насколько я понимаю, group_concat нет, но есть какие-то способы его эмулировать. Возможно, есть еще какие-то специфические нюансы, но я в этом сомневаюсь.

P.S. Печатал эту смесь английского и транслита и плакал кровавыми слезами.

Уходить.

Дизайнер должен уметь работать "под бутстрап". Иначе да, фичи бутстрапа будут использоваться постольку-поскольку и вся выгода от фреймворка пропадает.

Я, если вижу, что дизайн "не лезет" в бутстрап - беру просто less и собираю сетку на нем.