Как правильно ебнуться

http://utro-vecher.livejournal.com/1860438.html
http://www.sorokoumoff.com/o-polze-negativnogo-myishleniya/
Две противоположных по смыслу статьи на тему "как начать тревожится и перестать жить".

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

Универсальный грид, айседы, лавсаны, ORM и тонкости кишков БД

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

Например, два варианта реализации ORM с наследованием:
1) базовая табличка, соответствующая типу вроде Object, в которой хранится информация вроде "ID объекта", "класс объекта", для каждого из наследников - своя таблица, связанная с первой отношением 1:0..1

Из реальных проблем в такой схеме я вижу что: для запросов придется на каждого наследника делать вьюшку с кучей join на всех предков (у меня это похер, все равно из модели БД генерить), view должны быть редактируемые (т.е. либо instead of триггеры, либо хранимки), индексы для связей будут замедлять вставку

Я такую модель с неглубоким наследованием (1-2 уровня) использую у себя, т.к. она больше соответствует духу статической типизации.

2) EAV-модель, она же "база данных-хранилище объектов" тенцера (http://compress.ru/article.aspx?id=11515). Дичайше гибкая модель, больше соответствует динамической типизации, хэшмапам, прототипам и прочему такому хипстерству. Индексы ебаных размеров (без кластерных индексов и index-only чтения очень печально), сплошные N+1 запросы, дикие планы в случае "фильтр более чем по одному полю". Но зато хорошо подходит для небольшого количества объектов с кучей редко используемых опциональных параметров.

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

Так вот, вроде бы я подводные камни всей этой хрени знаю, но в формулировках чатико-срачей между лавсаном и айседом непонятно, имеют ли они в виду те подводные камни, которые известны всем (оверхед на индексы, лишний i/o, селективность индексов, index-only чтения, разреженность данных, заебы оптимизатора и прочая такая муть) или же, из-за того, что в них проснулся внутренний ботаник-выпускник элитной физматшколы, выдумывают какой-нибудь сверхчастный случай, про который знают только они и которым можно унизить оппонента, подловить его на незнании и объявить неучем. Это блядь, адски бесит, вне зависимости от того, кто там умнее.