>> Далее plain-text можно ускорить в несколько раз если заменить hostname на hostId,
>> время указывать в виде unix-time как набор байт, а не "03-Мрт-12
>> 04:48". Какое приложение выдало сообщение - локальный идентификатор размером в int.
> Вот, именно об этом я и говорю. Проведём нормализацию, напендюрим справочников и
> т.п. - именно это и характеризует _R_DBMS.Однако, как указывает К. Дейт, нормализация в точности и является теми принципами здравого смысла, которыми руководствуется в своём сознании зрелый проектировщик, то есть принципы нормализации — это формализованный здравый смысл.
Нормализация применима для NoSQL, и для любых систем хранения типа KV. Это здравый смысл и снижение издержек.
> Чушь. Сислог крайне чувствителен ко времени записи, а запись в DBMS априори
> медленнее простого добавления строки в файл.
> Конечно не будет, указал по чему.
Не увидел ни одного факта почему запись в DBMS априори медленнее записи в файл. если DBMS работает поверх CSV то скорость записи будет идентична. Если тот же CSV нормализовать и вынести повторяющиеся элементы, то скорост записи повысится банально за счет записи меньшего числа байтов.
То, что для скоростного логирования не подходят СУБД общего назначения. Но специально созданные будут конкретно быстрее файлов.
PS если бы текстовые файлы были идеалом скорости записи, то СУБД фигарили бы данные именно в плоские файлы. И git хранилищем использовать plain-text. Но хитрый Оракл извращается над файлами БД. Да и Линус тоже такой не хороший - вместо написания git с идеальным для "Имя и код" бэкэндом поверх plain-text пишет в бинарные файлы. ;)
