Максим Федоров

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

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

ООП
Бертран Мейер. "Объектно-ориентированное проектирование программных систем"
Гради Буч “Объектно-ориентированный анализ и проектирование с примерами приложений”

Алгоритмы / структуры данных
Томас Кормен "Алгоритмы построение и анализ"
Генри Уоррен "Алгоритмические трюки для программистов"
Николас Вирт "Алгоритмы и структуры данных"
Дональд Кнут "Искусство программирования"

Как по мне создание справочника кодов бессмысленная и геморройная вещь.
Почему геморройная - Вы сами на этот вопрос ответили.
Почему бессмысленная: Вы думаете что клиенты будут обращаться в техподдержку и сразу говорить код ошибки? на практике такого не будет... клиент обратившись просто скажет "Я тут клацнул кнопку а оно перестало работать", и сотрудникам поддержки все равно придется уточнять что и как там у него случилось. Так что как-бы коды ничего не изменят. К тому же по началу справочник будет добросовестно вестись, а в процессе эксплуатации клиент/начальник скажет какому-то программисту Васе - запили как фичу на проекте по быстрому, он ее сделает но в справочник данные не внесет, ибо нафик ему нужен этот гемор. Поэтому как бы актуальность справочника скорее всего на практике пострадает.

Зачем вообще коды? Возникла ошибка - вернули 500 статус и описание проблемы, записали подробную информацию в лог и все. Обратился клиент в тех. поддержку - посмотрели что за исключение возникло, посмотрели его stack-trace в логе и все. Грамотно сформированный лог + система поиска по нем решают все проблемы с поддержкой.

По поводу сервисов google не скажу, но делать продление после завершения текущей подписки не очень хороший вариант. Есть риск что процесс продления задержится, либо произойдет какой-то сбой при ее продлении, а это соответственно приведет к тому что пользователь какое-то время не сможет юзать необходимый ему функционал. Поэтому лучше реализовывать продление подписки за ранее, скажем за 5-10 минут до момента окончания текущей подписки (соответственно делать это все через демон).

если Вы внимательно посмотрите на пример, то увидите что там идет селект с подзапроса, которому присвоен псевдоним. В Вашем же коде чему присвоен псевдоним? ничему... должно быть так

SELECT model
FROM table_name AS t1
WHERE model = 1401

т.е. псевдоним Вы должны присваивать либо конкретной таблице, либо конкретному полю, либо конкретной выборке