Фетиш строительной пены

В комнате многое время был странный трабл - при полном отсутствии(кажущемся) видимых дырок пахло куревом. Ну народ иногда тут курит в толчках, иногда на коридоре, но с коридора дверь герметичная, в толчке не пахнет, и вообще всегда пахло только в моей комнате, где нету вентиляции и дырок.
В итоге сегодня до меня таки дошло, откуда пахнет. За стеной от моей комнаты находится бетонный моноблок "толчок-ванная" у соседей, с щелью между ним и кирпичной стеной 1-2 см. И кухня.
А при ремонте, прокладке витой пары и установке дверей я пробился к этой щели и из нее есть дыра ровно у моей двери, со стороны комнаты, у короба с витой парой. Я настолько привык к этой картине, что просто не видел ее. А сейчас просто заглянул туда - оттуда такой достаточно сильный сквозняк, который запах и несет.
В общем, щель там огромная по объему (3м*2.5м*(1-2см) только на нашем этаже) - можно лить строительную пену в немыслимых количествах. Пока вылил оставшийся баллончик, потом схожу куплю еще парочку и тоже вылью туда, давно мечтал что-нибудь масштабно запенить.

NoSQL vs RDBMS: Too may FOREIGN KEYs

Сижу делаю очередную опердень, и наткнулся на печаль: таблицы содержат сильно больше внешних ключей и вообще структуры/связей (которые в FB основаны на индексах), чем собственно данных. Это после адекватной нормализации и отображения требуемой для расчетов структуры на базу данных. Типа того, что в таблице, где хранятся суммы, 4 поля, из них 3 - это разного рода ссылки на сущности "налогооблагаемый объект", "период расчета", "период уплаты", и одно поле - собственно сумма.
Причем раньше у меня было чисто технологическое ограничение - чем больше таблиц, тем больше приходилось писать вручную sql-скриптов, маппингов "таблицы-объекты", запросов для работы с таблицами. Я поэтому особо не нормализовал, шел по пути типа "нужно 12 месяцев - заводим 12 полей, нужно 4 квартала - заводим 4 поля". А сейчас, во первых, с кодогенератором это ограничение исчезло, а во вторых, 4 квартала и 12 месяцев превратились в "список периодов, диктуемый каждый отчетный год министерству по налогам и сборам Червем из астрального мира".

Т.е. если мы идем по пути "много структур данных и мало кода", который нам в голову диктует функциональщина, то отражение этого дела в RDBMS превращает ее в невероятно запутанный граф, в котором связи занимают больше места чем данные. Если бы это был NoSQL, а наши данные имели явно заметную тенденцию объединятся в объекты (т.е. работа с записями из связанных таблиц ведется всегда вместе), то мы бы просто ложили в NoSQL объект в виде xml/json/любой структурированный текст.
Бинарное представление в NoSQL было бы сильно эффективнее текста в плане размера и обработки, но, во первых для него нужна статическая типизация, схема и тому подобное (чтобы сериализация/десериализация были эффективными), и обработку этого должна делать СУБД, т.к. я совершенно не испытываю желания это все делать.
Кроме того, как уже неоднократно писалось: RDBMS работает эффективнее, т.к. ее данные, условно говоря - это последовательность бинарных записей одинаковой длины, хождение по которым - это +-длина записей. А всякая бинарщина и xml - это парсеры, сериализация и прочий плохо взаимодействующий с кэшами процессоров и выделением памяти тупизм.

В моем случае это все не применимо в принципе - 99% требуемой от разрабатываемого модуля функциональности уже реализовано в виде "Firebird+Универсальный толстый клиент на дельфи", основная обработка ведется SQL запросами и кодом внутри FB. Всунуться сюда с чем-то, хоть отдаленно похожим на NoSQL, невозможно. Т.е. постулат: NoSQL == разработка с нуля, что на данный момент неприемлемо никак.

Но вообще, даже если мы вместо чистого NoSQL придумаем какой-то хитрожопый вариант типа "статически типизированные объекты в бинарном виде", индексы по внутренностям этих объектов для оптимизации запросов, функциональщину в качестве языка запросов, то все равно останется проблема с тем, что объекты теперь не представимы в виде записей постоянной длины (хотя сейчас больше проблема с дисковым i/o, чем с нагрузкой на проц) и что все равно как-то придется идентифицировать объекты независимо от их физического расположения - а это означает опять ID, опять индексы, сопоставляющие ID и физическое расположение, опять связи по этим ID и прочая и прочая.

Пороговый критерий

Прекращать систематическое образование в некоей области и переходить к изучению только того, что нужно сейчас, следует после того, как в произвольно взятой работе в этой области становится понятно 2/3 текста.
Тогда вместо чтения учебников можно оставшуюся 1/3 добивать чтением справочников, how-to и доизучать в процессе работы.

Линукс на флешках

А вот скажите мне, когда линукс хранят на флешках и прочих EEPROM разной степени перезаписываемости - куда кладут /tmp /log и прочие скратчпады?