А что если Все измененный данные буду дописываться в конец файла, а их старое место в файле будет затираться пробелами ?

[ADSoft]

откуда возник вопрос оптимизации?
то что есть стало медленно работать? другие причины?
...вот вы говорите все устраивает... это просто у вас один прибор пишет в вашу БД на файлах... как только вырастет количество приборов в и объем данных - однозначно будут проблемы... с блокировками итд итп....

[tae1980]

Сообщение от ADSoft

откуда возник вопрос оптимизации?
то что есть стало медленно работать? другие причины?
...вот вы говорите все устраивает... это просто у вас один прибор пишет в вашу БД на файлах... как только вырастет количество приборов в и объем данных - однозначно будут проблемы... с блокировками итд итп....

Начинали с 3 шт, сейчас их уже 74, я хотел бы довести до 1500. Не жду проблем при этом. При чем планировалось ~3000 сообщений в год с прибора. Практика показала, что 2500 сообщений в день не предел (хотя такая ситуация признак аварии). Время загрузки данных не значительно, по сравнению с тем временем которое требоваться на их обработку. И работы проводились именно с целью оптимизации их обработки.
Оптимизации работы с файлами, это часть проводимой работы. Хочу выжать максимум возможного сейчас, пока занимаюсь.
Второстепенная задача, применение получены наработок в других проектах, где данный момент может стать критичным. Их параметры должны быть схожими с этим проектом, но разумеется могут и отличаться.
По этом, раз уж делаю, хотелось бы сделать хорошо.

[СтудПом]

Если работаете с текстом, то м.б. рациональнее делать два файла Индексный и Текстовый. В текстовый только дописывается в конец и старые данные не затираются, а Индексный переписывается полностью.

Вопрос целесообразности не решить, т.к. не понятны частота записи/выборки и объём данных.

Если нагрузка не большая, я б предложил делать отдельную директорию на экземпляр прибора (источника), а конкретные значения - в отдельные файлы. Можно даже сохранять данные не в файлах, а в именах файлов по маске ИМЯ_ПАРАМЕТРА=ЗНАЧЕНИЕ.

Это колхозно, но очень просто и эффективно с точки зрения программирования.

[tae1980]

Сообщение от СтудПом

Если работаете с текстом, то м.б. рациональнее делать два файла Индексный и Текстовый. В текстовый только дописывается в конец и старые данные не затираются, а Индексный переписывается полностью.

Сложность в том что я не могу выставить маркер в файле на начало строки по номеру, или прочитать нужную строку по её номеру. При таком решении нужно будет прочитать индексный файл, после чего построчно перебрать файл с данными, игнорируя не нужные строки. Что увеличит время обычной выборки.

Сообщение от СтудПом

Вопрос целесообразности не решить, т.к. не понятны частота записи/выборки и объём данных.

Скорость записи, пока, примерно 10 событий в минуту.
На объекте в день происходит 300-1000 событий, иногда меньше.
У одного пользователя в среднем 3-5 объектов, но есть и больше.
Один объект может быть у нескольких пользователей.
Всего пока 73 объектов.

При запуске программы, идет запрос событий на всех объектах пользователя за последние 31 день, после чего в штатном режиме идет только обновление данных.
Пользователь может запросит для отображения данных за любой период. Обычно это 1 день по дате, 2 дня, недель, месяц, редко год. Больше запрашивал только я, в режиме теста.

Сообщение от СтудПом

Если нагрузка не большая, я б предложил делать отдельную директорию на экземпляр прибора (источника), а конкретные значения - в отдельные файлы. Можно даже сохранять данные не в файлах, а в именах файлов по маске ИМЯ_ПАРАМЕТРА=ЗНАЧЕНИЕ.

Система позволяет реализовать любой алгоритм хранения. При росте числа объектов, думал его менять. Но пока оставил такой из-за функции используемого языка программирования, который позволяет выдергивать из файла строки целиком, по маске содержимого строки. Создаем маску (в данном случае на основе кода объекта), натравливаем её на файл (путь строиться из ходя из нужной даты), получаем массив со строками удовлетворяющим условиям маски (то есть все события на объекте за указный день). Если нужно, можно построить маску на другой основе.
Нет необходимости перебирать в цикле весь файл. Гораздо проще чем написать sql запрос, а результат по сути тот же.

Сообщение от СтудПом

Это колхозно, но очень просто и эффективно с точки зрения программирования.

Так я родился на окраине города, пол жизни бегал по полям, большинство пользователь жители села, система и начиналась как решение задач села. Так что "колхоз", для нас самое то

[Serge_Bliznykov]

Сообщение от tae1980

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

ни в коем разе. Если Вы будете использовать индексный файл, то в нём нужно хранить смещение строки. Это и позволит прочитать ЛЮБУЮ строку мгновенно.

p.s. а вообще, глупостями занимаетесь. Если хватает скорости и надёжности - то ничего не меняйте.
А изобретать СУБД не нужно. Если уж хотите менять, то берите любую СУБД. Она легко обеспечит сотни операций в секунду без всяких напрягов с вашей стороны.

[СтудПом]

+1
В индексный файл записываете структуру
ИМЯ Начальный_Байт Длинна_Записи
После этого, из текстового файла читаете данные как массив байт. Операции типа Seek работают очень быстро.
Но повторюсь, на килобайтных файлах, это не разумно усложнит систему и, вероятно, даже не ускорит.