Подскажите уважаемые мастера...

← →
Sairex © (2008-02-26 15:17) [0]

Вообщем ломаю голову как сохранить инфу такого типа:
---------------
Наименование
Код
Описание
Примечание
---------------
БД (BDE и т.п.) не предлагать. Думал использовать ИНИ, но через 4 дня файлик будет весить свыше 64 Кб. Может кто подскажет как лучше это все сделать?

← →
Джо © (2008-02-26 15:19) [1]

> [0] Sairex © (26.02.08 15:17)
> Вообщем ломаю голову как сохранить инфу такого типа:
> ---------------
> Наименование
> Код
> Описание
> Примечание
> ---------------
> БД (BDE и т.п.) не предлагать. Думал использовать ИНИ, но
> через 4 дня файлик будет весить свыше 64 Кб. Может кто подскажет
> как лучше это все сделать?

А в чем проблема? Так и записывай в файл: Наименование, Код, Описание, Примечание.

← →
Palladin © (2008-02-26 15:20) [2]

Тайп
ТИнфаТакогоТипа=Рекорд
Наименование:какогото_типа;
Код:еще_какогото_типа;
Описание:еще_какогото_другого_типа;
Примечание:вообще_непонятного_типа;
Энд;

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

← →
tesseract © (2008-02-26 15:22) [3]

> Думал использовать ИНИ, но через 4 дня файлик будет весить
> свыше 64 Кб.

Это что много ? Оптимально просто структурированная табличка. Можешь индексы прикрутить, если не лень.

BlockWrite(File,MyREcord[i],Sizeof(MyRecord));

← →
Sairex © (2008-02-26 15:34) [4]

Спасибо ребят я чет совсем забыл про типизированый файл...

← →
Правильный_Вася (2008-02-26 15:35) [5]

> БД (BDE и т.п.) не предлагать.

забобоны какие-то, что ли?

ps bde - это не бд

← →
Reindeer Moss Eater © (2008-02-26 15:51) [6]

Думал использовать ИНИ, но через 4 дня файлик будет весить свыше 64 Кб. Может кто подскажет как лучше это все сделать?

Любой будет больше 64к

← →
Sairex © (2008-02-26 15:55) [7]

> Reindeer Moss Eater © (26.02.08 15:51) [6]
>
> Любой будет больше 64к

Да мне размер файла до лампочки. Насколько я помню у Ини ограничение на 64 кб

← →
Palladin © (2008-02-26 16:11) [8]

только для win9x

← →
Sairex © (2008-02-26 16:22) [9]

> Palladin © (26.02.08 16:11) [8]
> только для win9x

Интересно а кто сейчас Юзает Win9x ? За последний год встречал только 2к, ХП или 2к3 и Висту

← →
Sergey13 © (2008-02-26 16:25) [10]

> [0] Sairex © (26.02.08 15:17)
> но через 4 дня файлик будет весить свыше 64 Кб

А через 4 месяца?

← →
Sairex © (2008-02-26 16:33) [11]

ну если даже метров 60, я думю эт не страшно ;)

← →
Palladin © (2008-02-26 16:39) [12]

страшно, это страшно, это страшно медленно

← →
asail (2008-02-26 16:43) [13]

XML спасет?

← →
Sairex © (2008-02-26 16:50) [14]

> asail (26.02.08 16:43) [13]
> XML спасет?
>

+1

← →
Sergey13 © (2008-02-26 16:53) [15]

> [11] Sairex © (26.02.08 16:33)
> ну если даже метров 60, я думю эт не страшно

И что предполагается с ними делать?

← →
Правильный_Вася (2008-02-26 17:04) [16]

> И что предполагается с ними делать?

велосипед с квадратными колесами

← →
Marser © (2008-02-26 17:20) [17]

> Правильный_Вася (26.02.08 15:35) [5]
> > БД (BDE и т.п.) не предлагать.забобоны какие-то, что ли?
> ps bde - это не бд

Тогда АДО! ;-))))

← →
Marser © (2008-02-26 17:23) [18]

Вот подумалось - а как давно выпали бы в осадок парадоксы с дбейсами, если бы не Борланд с BDE?

← →
VirEx © (2008-02-26 18:05) [19]

Я тоже вот попробовал сериализацией воспользоваться:

object TInventory User = "user" Password = "pass" Limit = -1 object THost Name = "host1" Caption = "caption1" object TItem Name = "nameee" Caption = "caption1.1" object TValue Name = "Name" Caption = "caption1.1.1" LastUpdate = 39504.488267557870000000 Values.Strings = ( "abc" "cdf") LastValues.Strings = ( "bcd" "efg") end object TValue Name = "Caption" Caption = "dgfdfg" LastUpdate = 39504.488266469910000000 Values.Strings = ( "xyz" "xyz") LastValues.Strings = ( "xyz" "xyz") ................... ................... ................... end end object THost Name = "host2" Caption = "caption2" end end

только вот ~20 хостов, по 7 Item"ов заполненных текстовой информацией тянут на 2Мб и открывается/закрывается всё это жуть как медленно

← →
DiamondShark © (2008-02-26 18:20) [20]

> Вот подумалось - а как давно выпали бы в осадок парадоксы
> с дбейсами, если бы не Борланд с BDE?

Дык они и выпали. Вместе с BDE. Этим мёртворождённым чудищем пользовались разве что записные бдсмщики.

← →
isasa © (2008-02-26 18:23) [21]

В TADODataSet, у него есть метод SaveToXML, не?
Правда, этот XML только этот датасет понимает, но ...

← →
@!!ex © (2008-02-26 18:29) [22]

> [21] isasa © (26.02.08 18:23)

И в чем преимущество XML перед типизированным файлом?

← →
VirEx © (2008-02-26 18:54) [23]

преимущество только в наглядности и открытом виде

← →
@!!ex © (2008-02-26 18:58) [24]

> [23] VirEx © (26.02.08 18:54)

Если файлик на 60 метров, использование XML принесет только проблемы... ИМХО

← →
isasa © (2008-02-26 19:06) [25]

Загрузил/выгрузил двумя вызовами, остальное, как с обычным DataSet-ом.
Никаких велосипедов.

← →
isasa © (2008-02-26 19:09) [26]

:)
Да, если юзать типизованый файл, то не забудь предохраняться(packed record) ...

← →
AndreyV © (2008-02-26 19:47) [27]

> [0] Sairex © (26.02.08 15:17)
> БД (BDE и т.п.) не предлагать.

Так в чём, всё-таки, причина антипатии к БД?

← →
Palladin © (2008-02-26 19:51) [28]

>isasa © (26.02.08 19:09) [26]

ну и в чем заключается это предохранение? позвольте поинтересоваться.

> Дык они и выпали. Вместе с BDE. Этим мёртворождённым чудищем
> пользовались разве что записные бдсмщики.

Эх молодёж. SQL перекушали, теперь не знают, как курсоры с индексами работают....

> :)Да, если юзать типизованый файл, то не забудь предохраняться(packed
> record) ...

Строки определённой длины надо устанавливать, packed тут ну ни в какую не впился.

такое чувство, что некоторые товарищи понятия не имеют что такое packed, но где то слышали что оно чем то помогает при сохранении/чтении записи...

И в чем преимущество XML перед типизированным файлом?

В XPATH

← →
Strate (2008-02-26 23:16) [32]

Palladin © (26.02.08 20:30) [30]
packed

А что это такое?) Точнее чем отличается обычный рекорд, от пакет рекорда?

И кстати никак понять не могу зачем иногда case внутри рекордов встречается, как работет он там?

> Точнее чем отличается обычный рекорд, от пакет рекорда?

Могу ошибаться, но по-моему в ТР была опция компилятора "выравнивать переменные по слову", т.е. байт, фактически занимал 2. Таким образом, добиться байт = байт можно было 2-мя способами: выставлением опций компилятора или объявив рекорд как packed. Второе работало при любых опциях. А case внутре рекордов не "работает", он даёт возможность по разному к одному и тому же типу обратиться: Rect.Left, Rect.Top или Rect.TopLeft.X, TopLeft.Y

> Могу ошибаться, но по-моему в ТР была опция компилятора "выравнивать переменные по слову",

угу, только не опция, а директива {$A} + F1 и она и сейчас есть, выравнивание по умолчанию два двойных слова ({$A8}), но на самом деле выравнивание для рекордов идет по размеру самого большого его поля.

Type // казалось бы выравнивание должно быть по qword, ан нет по dword TMR32=Record a:Integer; b:Byte; c:Integer; d:Byte; End; //оптимизированная по размеру версия записи TOptimizedMR32=Record a:Integer; c:Integer; b:Byte; d:Byte; End; // казалось бы выравнивание должно быть по qword, ан нет по word TMR16=Record a:Word; b:Byte; c:Word; d:Byte; End; //а этоо пример упакованной записи меньшей по размеру, н с более медленным доступом к полям TMPR32=Packed Record a:Integer; b:Byte; c:Integer; d:Byte; End; // казалось бы выравнивание должно быть по int64, ан нет по int TMR32=Record a:Integer; b:Byte; c:Integer; d:Byte; End; ShowMessage(IntToStr(SizeOf(TMR16))); ShowMessage(IntToStr(SizeOf(TMR32))); ShowMessage(IntToStr(SizeOf(TOptimizedMR32))); ShowMessage(IntToStr(SizeOf(TMPR32)));

так, второй TMR32 лишний :) тяжело с мобил девайса писать :)

Palladin © (26.02.08 20:30) [30]

такое чувство, что некоторые товарищи понятия не имеют что такое packed, но где то слышали что оно чем то помогает при сохранении/чтении записи...

Не только понятия не имеют, но и в гробу видели это выравнивание при перетаскивании типизованного файла из под одной версии в другую.
Тем более что "выравнивание по умолчанию два двойных слова ({$A8}), но на самом деле выравнивание для рекордов идет по размеру самого большого его поля" ...

> Palladin (27.02.2008 01:34:34) [34]

Выравнивание оно сложнее, чем ты думаешь и ты это доказал примерами.
Выравнивание по A8 не значит выравнивания каждого члена по qword, оно гарантирует (должно гарантировать) начальный адрес на границу выравнивания.

И все же xml. Это наше все.
Преимущества:
- легко редактировать сторонними средствами.
- легко визуализировать (превращая xml в text, rtf, html)
- можно так же легко превратить любой xml в datapacket и получить таким образом датасет.
- над данными в xml можно выполнять sql-подобные запросы с помошью xpath
...

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

Кроме этого, я использовал практику, при окончательно не сформированной структуре записи

record
... //work space
space: array[1..totalLen-workLen] of byte;
end;

totalLen - const

> Anatoly Podgoretsky © (27.02.08 08:51) [37]

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

int64
integer

при будет выравнено по qword (и будет 16б)

а при $A4 будет выравнено по dword (и будет положенные 12б)

правда я и правда недоговорил, про то как размещаются поля записи (класса, object"а)
компилятор всегда старается оптимизировать размещение, например два последовательных байта и один word будут размещаться в одном dword, но byte,word,byte будут уже размещаться в трех word, суть одна - последовательность разная, и это лишь часть айсберга, и $A играет здесь не последнию роль. и не только "гарантирует (должно гарантировать) начальный адрес на границу выравнивания". вот пример:

Type {$A4} TMR64_4=record b:byte; c:word; e:int64; End; {$A8} TMR64_8=record b:byte; c:word; e:int64; End; ShowMessage(IntToStr(SizeOf(TMR64_4))); ShowMessage(IntToStr(SizeOf(TMR64_8)));

т.е. компилятор расположил e:int64 в одном случае по dword, а в другом по qword

вообще об расположении полей записи можно целую статью написать :)
да и речь не совсем об этом, а о полезности использования packed records при чтении/записи: ну да, с одной стороны оно конечно полезно для переносимости, с другой стороны оно нифика не полезно при доступе по скорости обращения к ним в файле. так что говорить, об каком либо предхранении нужно предметно, предохранении от граблей - да, но тоже самое предохранение от тех же граблей выполняется "насильной" установкой директивы $A на другом компиляторе с другим выравниванием по умолчанию, выигрыш в скорости более чем заметен при интенсивной работе с большими объемами данных. это все касается рекордов состоящих из ordinal types и/или массивов и коротких строк. другие types это совсем другой разговор. там выравнивание куда более пофигистично...

Подскажите уважаемые мастера... Найти похожие ветки