О рождении сложности :)

Сидел давеча за кодом монитора станционных сообщений. Ничего особо сложного, но код отяжелён стремлением сделать его универсальным. Два режима, несколько параметров в разном сочетании. На основе этих данных формируется sql-запрос, запрашиваются данные и полученные отображаются. Засада в том, что с какого-то момента стал нещадно тормозить. Если дать sql-запрос компактненько, с указание всех интересующих критериев, то суточная сводка выдаётcя менее чем за секунду. Добавив "вкусную" таблицу получаю не более полутора секунд. В скрипте-же, с его универсально построенным запросом получается, блин, пол-минуты... Вот за что такое наказание? ;)

Вспомнил старую систему. Много лет назад (лет, наверно, 15) был у нас слабенький (по теперешним меркам) сервак на шапке. Крутился там интербейз. В базах я тогда практически не шарил. И в вебе тоже. В общем, только-только разбирался как это хозяйство работает. И в частности строил интерфейс. В базу загружались данные станционной статистики. Приятель, для того чтобы отображать интербейзовские данные на веб, наваял програмку-гейт, которой скармливались html-заготовки, в которых специальный тег заменялся на результат запроса. Эдакий cgi/ssi в одном лице. Это позже уже были и php, и perl, а тогда это всё было в новинку. В общем то, что сейчас сделано на одной странце одним скриптом (толстым, конечно), тогда выглядело как несколько каталогов с парой сотней html-шаблонов и приблизительно столько же sql-шаблонов. Блин! И ведь это работало! Да ещё как! А интерактив? Понятно что если что-то в базе существенно менялось, то приходилось править во многих шаблонах. Но зато это как-то просто получалось. А сейчас гляжу и начинает доходить, что вместо прокариотно-подобного кода ранее получил теперь эукариотно-подобный. Например, с кучей альтернативного сплайсинга. Поэтому приходится снимать показания в промежуточных точках и смотреть что за запрос получается. Но беда ещё в том, что режимы эти могут оказаться несовместимыми... Не вернуться ли к старой методике? ;)