Freeman

На уровне базы данных такую склейку можно сделать только при условии что заранее известно в каких складах искать(Для этого делается последовательный JOIN одной и той же таблицы с разными sklad_id), или если заранее известен товар, по которому строится такая выборка( select по всем складам по id товара, затем PIVOT выборки).
Для сферического коня в вакууме на мой взгляд подойдет только свистопляска на уровне приложения.

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

Самое лучшее, что я видел на русском о мышлении - это книги по ТРИЗ от Альтшуллера. Сами книги легко гуглятся.

Можно подойти к проблеме просто: делать свою работу в посильном темпе. Неизбежно начнут накапливаться нерешенные задачи в очереди, клиент неизбежно заинтересуется, почему так много "висяков" в багтрекере. А вы ему в ответ собранную за последние неделю-месяц-год статистику: раньше обращений было столько-то, я успевал, а теперь их в N раз больше, а у меня все еще только две руки. И уже можно обоснованно и аргументированно поднимать вопрос о расширении команды и тому подобных вещах.

Что до невозможности увеличивать бюджет, то это явно противоречит тезису Один проект начал успешно разрастаться.: если он разрастается действительно успешно, то с него и доходы должны разрастаться соответственно. А если не разрастаются, то это уже сигнал клиенту, что он фигней занимается.

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

Разница из-за различных методик сбора данных. Рейтинг TIOBE строится на подсчете количества поисковых запросов, содержащих название языка (https://ru.wikipedia.org/wiki/Индекс_TIOBE). Github, полагаю, ориентируется на количество коммитов в проекты, написанные на соответствующих ЯП. Stackoverflow, скорее всего, ориентируется на теги.

Особо зацикливаться на эти рейтинги, честно говоря, не вижу нужды; максимум, на что они годны - это служить аргументом в разных фаллометрических баталиях на тему "ЯП1 vs ЯП2". В реальной жизни лучше ориентироваться на количество/качество предлагаемых вакансий (если хочется программировать профессионально) или на личные предпочтения (если хочется программировать "для души").

Оправдано ли будет сделать первичным ключем гос.номер, т.е. , допустим, поле nchar(6)?

Оправдано, если а) поле фиксированной длины - неважно, строка это или число; б) вы действительно уверены в том, что значения будут уникальны, в том числе во времени. Есть предметные области, где это действительно так, но далеко не везде.
Если строка переменной длины, первичным ключом её лучше не делать, но можно сделать полнотекстовой поиск по ней, если он нужен.

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

Теплицы с искусственным освещением приобретают актуальность при переходе на интенсивное земледелие. В России, как и в большей части стран СНГ, в настоящий момент такой переход еще не произошел (даже необходимость его еще не осознанна) и земледелие продолжает вестись в основном экстенсивными методами. Это обуславливает низкий интерес к внедрению высоких технологий в этой сфере. По этой причине традиционные средства рекламы мало эффективны. Но в следствии высоких уровней коррупции и традиционной восприимчивости менеджеров среднего и звена к "импульсам сверху", весьма эффективным может оказаться "кабинетный" способ продвижения на "рынок" гос.закупок, а через него и на коммерческий рынок, благодаря привычке к подражательству, распространенной также среди коммерческих директоров, вышедших из среды фермеров.