Что использовать вместо RECORD?

← →
art36 © (2008-03-24 18:42) [0]

Есть неудобный способ хранить записи в типизированном файле:

var
F:file of Tmytype
a: Tmytype

Но при этом ужасно неудобно удалять и записывать записи в этом файле.

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

Если есть ссылку в инете дайте, пожалста!

← →
Reindeer Moss Eater © (2008-03-24 18:44) [1]

xml

← →
art36 © (2008-03-24 18:45) [2]

> xml

Как?

← →
Reindeer Moss Eater © (2008-03-24 18:46) [3]

Как?
Очень легко и даже приятно.

← →
art36 © (2008-03-24 18:47) [4]

> Очень легко и даже приятно.

(( я понятия не имею как им пользоваться

← →
Reindeer Moss Eater © (2008-03-24 18:50) [5]

ну тогда оставайся на типизированных файлах.

← →
art36 © (2008-03-24 18:55) [6]

> ну тогда оставайся на типизированных файлах.

ну уж нет... у него избыточный код, есть что-нибудь еще?

← →
Семеныч (2008-03-24 19:10) [7]

Зависит от того, что Вы называете удобным и неудобным. Например, вместо записей можно использовать объекты, а файл читать в их список (потомок TObjectList) и писать из этого же списка. Тогда весь вопрос сводится к написанию 2-х простых методов списка - чтение и запись файла (формат файла: перваые 4 байта - количество элементов, далее сами элементы).

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

← →
Reindeer Moss Eater © (2008-03-24 19:14) [8]

Поиск нужного объекта в таком файле будет особенно удобен.

← →
Семеныч (2008-03-24 19:18) [9]

> Reindeer Moss Eater © (24.03.08 19:14) [8]

На всякий случай: в файлах объекты не ищут. В файлах вообще ничего не ищут. Файлы читают и пишут, а ищут - в памяти.

И при этом без разницы, что содержит файл - объекты, записи, просто числа или что угодно еще.

← →
Reindeer Moss Eater © (2008-03-24 19:20) [10]

да да конечно. и не ищут в файлах ничего и никогда.

← →
Kolan © (2008-03-24 19:22) [11]

Прочитай про сериализацию, используй объекты и сериализуй их стандартными методами&#133

← →
Reindeer Moss Eater © (2008-03-24 19:23) [12]

Будет та же хрень что и с типизированными файлами.
С точностью до миллиметра.

← →
Kolan © (2008-03-24 19:23) [13]

Кстати, а как на счет БД?

← →
Reindeer Moss Eater © (2008-03-24 19:26) [14]

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

← →
Johnmen © (2008-03-24 19:27) [15]

Да простой ClientDataSet.

← →
Семеныч (2008-03-24 19:27) [16]

> Reindeer Moss Eater © (24.03.08 19:20) [10]

Можете привести пример поиска в файле?

Если можете - приведите. А я Вам тут же докажу, что это поиск НЕ в файле, а в памяти.

Даже если весь поиск сводится к одному сравнению, то это сравнение все равно производится в памяти. А файлы только читают и пишут.

← →
Reindeer Moss Eater © (2008-03-24 19:29) [17]

Семеныч, вы предлагаете заменить шило на мыло. Причем с гребанием новых граблей.

← →
Семеныч (2008-03-24 19:31) [18]

> Reindeer Moss Eater © (24.03.08 19:26) [14]

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

Если раньше было достаточно переписать кусок размером SizeOf(рекорд), то это означает, что указателей пресловутый рекорд не содержит - и тогда с переходом на объекты будет достаточно переписать кусок размером InstanceSize.

LOL?

← →
Семеныч (2008-03-24 19:33) [19]

> Reindeer Moss Eater © (24.03.08 19:29) [17]

> Семеныч, вы предлагаете заменить шило на мыло. Причем с гребанием
> новых граблей.

Если Вы подкрепите Ваше утверждение указанием конкретных грабель, то, возможно, я с Вами соглашусь. Пока же я этих грабель не вижу.

← →
Reindeer Moss Eater © (2008-03-24 20:23) [20]

Ну поехали.

запись порции данных в типизированный файл: один вызов.
запись сериализированного объекта в файл: один вызов.
чтение аналогично.

поиск записи по значению в поле (поиск объекта по значению поля/свойства):
последовательно читаем и сравниваем. снова никаких преимуществ.

позиционирование на запись с номером N:
В случае типизированного файла: да
В случае с объектами - в цикле делаем считывание N раз. Уже минус.

изменение найденного элемента:
типизированный файл:
считываем запись, меняем поля, делаем seek назад, записываем рекорд.
объекты:
снова облом. все что позади изменяемого объекта, необходимо считать и записать по новой после измененного объекта.

Итого:
Жить стало лучше?
Нет, жить стало просто веселей.

← →
Reindeer Moss Eater © (2008-03-24 20:34) [21]

В случае же обжектлиста появится необходимость считывать весь файл целиком в память. В случае xml дело конечно обстоит примерно так же, но:

- имеем sql-подобный механизм поиска
- не имеем гемора с верисонностью структуры.
- имеем простую возможность визуализации данных в различных форматах (html,txt,rtf etc)
... и так далее

← →
Reindeer Moss Eater © (2008-03-24 20:42) [22]

Если раньше было достаточно переписать кусок размером SizeOf(рекорд), то это означает, что указателей пресловутый рекорд не содержит - и тогда с переходом на объекты будет достаточно переписать кусок размером InstanceSize.

А что, каждый инстанс после сериализации имеет один и тот же размер?

← →
art36 © (2008-03-24 21:28) [23]

Да, кстати.. вся проблема, в основном, при удалении элемента из типизированного файла.. приходится писать в другой файл, а потом копировать его с заменой предыдущего... флеш накопитель не взорвется?? ))

← →
Anatoly Podgoretsky © (2008-03-24 21:34) [24]

> art36 (24.03.2008 21:28:23) [23]

Второй файл лишний.

← →
DVM © (2008-03-24 21:44) [25]

> art36 © (24.03.08 21:28) [23]
> Да, кстати.. вся проблема, в основном, при удалении элемента
> из типизированного файла..

Можно просто помечать элемент как удаленный.

← →
Семеныч (2008-03-24 22:40) [26]

> Reindeer Moss Eater © (24.03.08 20:42) [22]

> А что, каждый инстанс после сериализации имеет один и тот же размер?

И до, и после - один и тот же. Размер инстанса с сериализацией вообще никак не связан. Это 4 байта плюс сумма размеров полей.

Поэтому: поехали, но несколько не так, как Вы полагаете:

> Reindeer Moss Eater © (24.03.08 20:23) [20]

> запись порции данных в типизированный файл: один вызов.
> запись сериализированного объекта в файл: один вызов.
> чтение аналогично.

Согласен.

> поиск записи по значению в поле (поиск объекта по значению
> поля/свойства):
> последовательно читаем и сравниваем. снова никаких преимуществ.

Согласен.

> позиционирование на запись с номером N:
> В случае типизированного файла: да
> В случае с объектами - в цикле делаем считывание N раз. Уже минус.

Если программировать "в лоб", используя "обычную" сериализацию - то да. А если объявить файл, как file of byte, то фигушки: Seek(N * InstanseSize) сразу позиционирует куда надо. И получаем то же самое, что и для рекорда.

> изменение найденного элемента:
> типизированный файл: считываем запись, меняем поля, делаем seek назад,
> записываем рекорд.
> объекты: снова облом. все что позади изменяемого объекта, необходимо
> считать и записать по новой после измененного объекта.

Не-а, снова фигушки. Считываем найденный (по предыдущей схеме) объект, делаем seek назад, записываем объект (InstanceSize). Все то же самое, что и с рекордом (если, конечно, не программировать "в лоб").

> Итого:
> Жить стало лучше?
> Нет, жить стало просто веселей.

Лучше. Например, потому что теперь мы можем использовать уже готовый ObjectList и будем избавлены от необходимости освобождения памяти при удалении элементов списка (как это было бы с рекордами).

← →
art36 © (2008-03-24 22:43) [27]

Нужно заюзать! Благодарю за активность!

← →
Reindeer Moss Eater © (2008-03-24 22:45) [28]

Не-а, снова фигушки. Считываем найденный (по предыдущей схеме) объект, делаем seek назад, записываем объект (InstanceSize). Все то же самое, что и с рекордом (если, конечно, не программировать "в лоб").

чот я не понял.
был экземпляр объекта с полем-строкой длиной 100 символов.
считали его из файла, заменили значение в поле на строку длиной 200 символов.

и после сериализации экземпляр занимает ровно столько же места на устройстве хранения?

Нужно заюзать! Благодарю за активность!

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

...и так всю жизнь.

← →
Семеныч (2008-03-25 00:44) [30]

> Reindeer Moss Eater © (24.03.08 22:45) [28]

> чот я не понял.
Угу.

> был экземпляр объекта с полем-строкой длиной 100 символов.
ОК, был.

> считали его из файла, заменили значение в поле на строку длиной 200
> символов.
Это невозможно по определению. См. [18]. Все то же самое, что и с рекордами - там могут быть только ShortString. Иначе типизированный файл не катит.

> и после сериализации экземпляр занимает ровно столько же места на
> устройстве хранения?
Угу, ровно столько же. И в памяти, и на устройстве хранения.

> Reindeer Moss Eater © [29]
>
> осваивай xml. в жизни пригодится.
> а то будешь для каждой задачи изобретать свой велосипед на базе обджектлиста...

Да, конечно)

← →
Семеныч (2008-03-25 00:52) [32]

> art36 © (24.03.08 22:43) [27]

Если скорость неважна, то xml для этой задачи неплох. Правда, я не уверен, что xml позволит сделать изменение записи в файле или удаление записи из него более удобными, чем это было с Record - но тут, повторюсь, все зависит от того, что Вы понимаете под словом "удобно".

А если скорость важна, то однозначно нужно использовать прямую запись участка памяти и чтение в него же. С xml будет намного медленнее.

> art36 © (25.03.08 00:50) [31]
>
>

Кстати. А вот интересно было бы привести пример записи типа Tmytype. И конкретные примеры "неудобств" работы с типизированными файлами file of Tmytype. А то может холивар раздутый в сей ветке вообще бессмысленный?

← →
Семеныч (2008-03-25 00:57) [34]

> Reindeer Moss Eater © (24.03.08 22:56) [29]

Освоить xml, конечно, неплохо, но запись участка памяти в файл и обратное чтение я бы не стал называть изобретением велосипеда. Нормальное использование известного метода, никаких изобретений.

← →
Семеныч (2008-03-25 01:01) [35]

> Германн © (25.03.08 00:55) [33]

> А то может холивар раздутый в сей ветке вообще бессмысленный?

Стопудово. Я бы взял рекорд и за час написал класс-список таких рекордов, а в этот класс ввел все нужные мне методы. После чего все вопросы с удобством отпадают сами собой.

По крайней мере, в моем понимании этого слова. А что под ним понимает автор - это ему самому и решать.

> Семеныч (25.03.08 01:01) [35]

В моём понимании типизированного файла вообще не нужно ничего дополнительно писАть. Эта штука так давно нормально работает, что и не нужно ничего менять. Но вот "рекорд" в типизированном файле - это несколько иное. (После ТП и Д1). И вот тут желательны разъяснения автора. Он ведь хочет оптимизации. Но "абсолютной" оптимизации не было, нет и не будет.

> Reindeer Moss Eater © (24.03.08 22:56) [29]
>
> Нужно заюзать! Благодарю за активность!
>
> осваивай xml. в жизни пригодится.
> а то будешь для каждой задачи изобретать свой велосипед
> на базе обжектлиста, для каждого велосипеда придумывать
> свой насос, а для каждого насоса свой воздух.
>
> ...и так всю жизнь.

Про велосипед и воздух - поржал, спасибо.
Про xml: хоть и не имею ничего против, тем-не-менее каким образом xml решает задачу удаления нода из середины файла без открытия файла целиком? :)

Свободная беспроблемная версионность формата. Вот что даст xml по сравнению с сериализцией объектов и типизированными файлами.
+ остальные преимущества описанные выше.

тем-не-менее каким образом xml решает задачу удаления нода из середины файла без открытия файла целиком? :)

не решает. я говорил.
только весь фукнкционал уже реализован добрым дядей в виде savetofile.
примерно то же самое имеем при обжектлисте, но там поиск никакой, а в xml нам дан xpath. если же рекорды просто заменять сериализованными объектами, то вообще приплыли. перезапись нужно изобретать самому (это про воздух).

под версионностью формата я вот что подразумеваю.
где-то есть старый код, работающий с форматом версии 1.
ему встречатеся файл более старшей версии.

имеем:

если это xml, все будет гладко. файл считается и при необходимости отредактируется без потери атрибутов, появившихся в версии 2.

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

Это невозможно по определению. См. [18]. Все то же самое, что и с рекордами - там могут быть только ShortString. Иначе типизированный файл не катит.

А! Понял. то есть все строковый поля в типе будут короткими строками.

Итого:
что мы дополнительно получили от переписывния кода? :
-ничего, кроме возможности не делать Dispose.

Что использовать вместо RECORD? Найти похожие ветки