История изменений

Индексировать затем, что никогда нельзя придумать наперёд, что захочется сделать пользователю.

Замечательное обоснование. А давайте добавим еще и потоковое видео из журнала, криптозащиту и тетрис? Вдруг пользователю захочется свои логи на ютубе смотреть и играцца одновременно? Вы это для прикола написали, признайтесь. Другой причины писать такой бред в обосновании я не вижу.

Оверхед на индексирование (он невелик) не мешает, потому что 1) сообщения всё равно генерируются медленнее (почти всегда), 2) есть буфер, 3) периоды «всплеска» интенсивности появления новых сообщений в нормальных условиях невелики.

Извините, вы когда-нибудь индексировали что-то постоянно меняющееся? Сколько дополнительных движений надо сделать при поддержке актуализации индексов представляете? И все это на каждую запись в журнале. Вместо тривиального fputs Леня предлагет генерить fputs и сто-пицот ненужных вызовов, лишь на том смешном основании, что «может вдруг понадобится».

Опять же вопрос: _зачем_ нужно индексирование???? Ускорить поиск. На кой нужно ускорять поиск при записи? В журнале!!

Опять изначально кривой дизайн приводит к героическим поступкам по устранению последствий. Леня, по-ходу из СССР — наша логика, «зачем думать? прыгать надо». Или ему за строчки кода платят, как индусам, вот он и строчит всякую хрень, чтобы бабло шло.

Убеждаться в том, что журнал не скомпрометирован, нужно по очевидным причинам.

Приведите пример хотя бы 3 «очевидных причин», причем для десктопа.

С точки зрения формата файла — по постановке задачи.

Про это вам и говорят, что изначально кривая постановка задачи типа «вдруг кому-то захочется» или «это будет круто» приводят к таким уродским дизайнам и, соответственно, к реализации.

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

Какие метаданные вам нужны в текстовом файле журнала? Про позиционное разделение полей в тексте вы не слышали или про CSV? Что такое пишется в журнал, что ему нужны развернутая система именования полей? Вы не путаете текстовые файлы с JSON или XML?

К тому же, нет никакой проблемы извлечь из бинарного файла текстовые данные даже при отсутствии специализированного парсера формата.

Что за ерунда? Вы когда-нибудь выковыривали что-то из бинарных файлов руками? Или чисто умозрительный опыт? А не проще было оставить текст?

Опять, же, основаясь на «документах», которые вы представляли, в частности по переписке, Леня не пишет в свой бинарник типизированную информацию вроде дат и цифр, только текст. Тогда зачем ему бинарник???

Следуя вашей логике, спрошу, если для предобработки журнала перед анализом/чтением, нужно использовать спец-преобразователи, почему нельзя было использовать предобработку простых текстовых логов вместо создания велосипеда с индексами?

Индексировать затем, что никогда нельзя придумать наперёд, что захочется сделать пользователю.

Замечательное обоснование. А давайте добавим еще и потоковое видео из журнала, криптозащиту и тетрис? Вдруг пользователю захочется свои логи на ютубе смотреть и играцца одновременно? Вы это для прикола написали, признайтесь. Другой причины писать такой бред в обосновании я не вижу.

Оверхед на индексирование (он невелик) не мешает, потому что 1) сообщения всё равно генерируются медленнее (почти всегда), 2) есть буфер, 3) периоды «всплеска» интенсивности появления новых сообщений в нормальных условиях невелики.

Извините, вы когда-нибудь индексировали что-то постоянно меняющееся? Сколько дополнительных движений надо сделать при поддержке актуализации индексов представляете? И все это на каждую запись в журнале. Вместо тривиального fputs Леня предлагет генерить fputs и сто-пицот ненужных вызовов, лишь на том смешном основании, что «может вдруг понадобится».

Опять же вопрос: _зачем_ нужно индексирование???? Ускорить поиск. На кой нужно ускорять поиск при записи? В журнале!!

Опять изначально кривой дизайн приводит к героическим поступкам по устранению последствий. Леня, по-ходу из СССР — наша логика, «зачем думать? прыгать надо». Или ему за строчки кода платят, как индусам, вот он и строчит всякую хрень, чтобы бабло шло.

Убеждаться в том, что журнал не скомпрометирован, нужно по очевидным причинам.

Приведите пример хотя бы 3 «очевидных причин», причем для десктопа.

С точки зрения формата файла — по постановке задачи.

Про это вам и говорят, что изначально кривая постановка задачи типа «вдруг кому-то захочется» или «это будет круто» приводят к таким уродским дизайнам и, соответственно, к реализации.

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

Какие метаданные вам нужны в текстовом файле журнала? Про позиционное разделение полей в тексте вы не слышали или про CSV? Что такое пишется в журнал, что ему нужны развернутая система именования полей? Вы не путаете текстовые файлы с JSON или XML?

К тому же, нет никакой проблемы извлечь из бинарного файла текстовые данные даже при отсутствии специализированного парсера формата.

Очередной костыль для того, чтобы кривое поделие поддержать.

Следуя вашей логике, спрошу, если для предобработки журнала перед анализом/чтением, нужно использовать спец-преобразователи, почему нельзя было использовать предобработку простых текстовых логов?