Хранение табличных данных в файлах

← →
Lamerr © (2003-05-07 09:22) [0]

Необходимо сохранить в файле прямоугольную таблицу с заголовками столбцов и данными в Real(в ячейках находятся переменные типа Real).
Что-то вроде екселевского файла...
Количество строк и столбцов не известно заранее.
С текстовыми файлами работать долго и муторно.
Идеальным было бы создание файла из записей, в которых хранились бы заголовки столбцов и динамические массивы с данными с тем.
Но динамические массивы в файлах хранить нельзя...
Просмотрел несколько книжек, но решения так и не принял.
Подскажите, пожалуйста, в каком направлении вести поиск?
Нужно получить файл, который можно было бы БЫСТРО прочитать и обработать.
Исплользовать потоки? Может статьи есть на эту тему...
Спасибо заранее. :о)

← →
Digitman © (2003-05-07 09:32) [1]

Чем тебя BDE + Paradox не устраивает для этой цели ?

← →
Anatoly Podgoretsky © (2003-05-07 09:33) [2]

Текстовые файлы, очень просто и дадут гибкость, а работает очень быстро.

← →
Lamerr © (2003-05-07 09:40) [3]

Вообще-то мне нужно потом эти данные в TChart запихать...
А если у меня 5-10 тысю строк, то искать разделители, переделывать каждую в строку в Real...
Долго очень.:о)

← →
Lamerr © (2003-05-07 09:44) [4]

to Digitman:
BDE + Paradox не устраивает тем, что во-первых файл должен иметь максимально низкий объем и, во-вторых все это должно работать на ЛЮБОМ компе, где есть моя прога (прога работает сама и ничего больше не просит).

← →
Anatoly P (2003-05-07 09:48) [5]

А TFileStream чем плох?

← →
evvcom © (2003-05-07 09:48) [6]

> Но динамические массивы в файлах хранить нельзя...

Почему нельзя? Все можно. Формат твой, что хочешь в него, то и пиши. Определись для себя, что например, первым числом пойдет размерность массива, а далее данные, и в ПУТЬ!

← →
Lamerr © (2003-05-07 09:49) [7]

Текстовые файлы - хорошо, согласен. Однако, мне нужно получить минимальный объем и максимально быстрое чтение...

← →
Anatoly Podgoretsky © (2003-05-07 09:49) [8]

Lamerr © (07.05.03 09:40)
Искать разделители не нужно, прочитай в старых учебниках про текстовые файлы.

← →
Lamerr © (2003-05-07 09:54) [9]

to Anatoly Podgoretsky
В старых учебниках? В каких именно, не посоветуете? Был бы благодарен... :о)

← →
Lamerr © (2003-05-07 09:56) [10]

to evvcom:
Это если используется поток можно. А в стандартный типизированный файл записей - нельзя.

← →
Lamerr © (2003-05-07 09:58) [11]

Прошу прощения, мне придется удалиться на час-полтора. Но я обязательно вернусь. Спасибо всем. :о)
Буду очень рад, если увижу вас снова. :о)

← →
evvcom © (2003-05-07 09:58) [12]

> А в стандартный типизированный файл записей - нельзя.

В вопросе этого не звучало.

> Это если используется поток можно.

Ну и используй поток, кто мешает?

← →
Anatoly Podgoretsky © (2003-05-07 10:01) [13]

Lamerr © (07.05.03 09:56)
Нельзя, или текстовый иди двоичный нетипизированный.

← →
ND (2003-05-07 10:42) [14]

Ini - файл не пробовал и писать и читать очень просто.

← →
Mikelson (2003-05-07 10:51) [15]

Еще XML. Универсальнее не придумаешь.

← →
kull © (2003-05-07 11:13) [16]

> Anatoly Podgoretsky © (07.05.03 09:33)
> Текстовые файлы, очень просто и дадут гибкость, а работает
> очень быстро.

Насчет гибкости, тогда уж ADO лучше.
Тогда вообще формат хранения беспокоить не будет.

← →
Lamerr © (2003-05-07 11:35) [17]

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

← →
evvcom © (2003-05-07 11:41) [18]

Какие разделители? Есть жестко заданный формат: 4 байта - длина буфера, далее сам буфер. А в буфере данные лежат по 4 (или 8, или 10 байт, как угодно) безо всяких разделителей.

← →
Lamerr © (2003-05-07 11:53) [19]

to evvcom:
Речь идет о текстовых файлах, в которых столбцы разделются определенными смволами.

← →
evvcom © (2003-05-07 11:54) [20]

Ты ж вроде уже на потоки согласился.

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

← →
Lamerr © (2003-05-07 12:00) [21]

to evvcom:
На потоки-то я согласился, но у них есть одна неприятная особенность - их нельзя посмотреть по F3, или сразу открыть в Ексель. :о)

← →
Palladin © (2003-05-07 12:09) [22]

определись что тебе надо

← →
evvcom © (2003-05-07 12:13) [23]

Тогда может тебе еще и html формат предложить, тогда еще и в IE посмотреть сможешь. Действительно, определись, чего тебе надо, потом вопросы и задавай.

← →
REA © (2003-05-07 12:16) [24]

Еще есть микрософтовский Structured Storage формат. Но в принципе Т.З. нужно сформулировать точнее.

← →
Reindeer Moss Eater (2003-05-07 12:18) [25]

TStream, TWriter + его методы WriteListBegin + WriteListEnd + WriteInteger + WriteString.

← →
Lamerr © (2003-05-07 12:20) [26]

Господа, вся эта дискуссия и затеяна для того чтобы разобраться что использовать ВЫГОДНЕЕ и РАЦИНАЛЬНЕЙ.
И Т.З. сформулировано как раз исходя их этих соображений...

← →
Palladin © (2003-05-07 12:26) [27]

Гибкость => свой формат файла => потоки

← →
REA © (2003-05-07 12:29) [28]

Единого ответа нет, но чаще всего имеет смысл применять базы данных. Для задач поменьше подходят любые другие варианты (в зависимости от объемов данных и скорости работы с ними).

to REA:
Базы в моем случае не подходят. Слишком тяжеловесно.

← →
Erik Ivanov (2003-05-07 12:47) [30]

Зачем мучится?! Береш DBF ставиш прямой компонент доступа Halcon или еше чего и вперед. Никаких проблем, занимать немного будет и в excel можно открыть. А если делать свой формат то это дополнительный месяц разработки (для тебя).

to Erik Ivanov:
А подробнее? :о)

> Lamerr

все-таки - подумай о DBF) ... BDE - да, тяжеловато ... но есть Halcon ! Есть CodeBase ! Да мало ли компактных и эффективных готовых "движков" существует для прямого доступа к DBF-формату) ... с другой стороны, и Excel без проблем импортирует этот формат ... подумай !)

← →
Serginio (2003-05-07 14:08) [35]

Ar:Array of array of Double;
Запись
f:=TFileStream.Create("C:\Proba.txt",fmCreate or fmOpenReadWrite);
f.Seek(0,soFromBeginning);
len:=Length(ar);
f.Write(len,SizeOf(len));
For i:=0 to Length(ar) Do
Begin
len:=Length(ar[i]);
f.Write(len,SizeOf(len));
f.Write(ar[i][0],SizeOf(double)*len)
end;
чтение
f:=TFileStream.Create("C:\Proba.txt",fmCreate or fmOpenReadWrite);
f.Seek(0,soFromBeginning);
len:=Length(ar);
f.Read(len,SizeOf(len));
SetLength(ar,Len);
For i:=0 to Length(ar) Do
Begin
f.Read(len,SizeOf(len));
SetLength(ar[i],len);
f.Read(ar[i][0],SizeOf(double)*len);
end;

И все дела

> Lamerr

ну и что ? почему ты считаешь, что использование тех же Halcon или CodeBase сделают зависимым твое приложение от чего-то еще ? Это вполне самодостаточные движки ! По ресурсоемкости и эффективности они превосходят BDE, ибо изначально проектировались для высокоэффективной работы конкретно с DBF-форматом.
А собственно DBF-файл по внутр.структуре и объему вполне отвечает предъявляемым тобой требованиям.

to Digitman:
А на сколько возрастет размер exeшника? :о)

Из форума на DK:
Вообще говоря, для работы с dbf, достаточно вытащить из BDE 4 файла: Bantam.dll, Idapi32.dll, Iddbas32.dll, Idr20009.dll упаковать их AsPack"om (получится 575 кб, естественно что ODBC должен присутсвовать на компе) и слить их в каталог с вашей прогой, далее достаточно TTable, filter тоже будет работать, а еще в свете ускорения процессоров можно подключить rar.dll(30 кб) и запаковывать/распаковывать базы.
А если добавить idbat32.dll и idsql32.dll (239 кб после AsPaсk"a), то и TQuery с SQL можно использовать.
И между прочем получается прога которая памяти жрет гораздо меньше и грузится быстрее, чем допустим при использовании ADO или Halcon (для сравнения dbf файл с телефонной базой на 52000 номеров, и с индексом по каждому полю (весом 12 метров, rar"ом жмется до 1,3 мег), в предлагаемой компоновке из dll отожрал 3,5 и 7 метров в Физ. и Swp памяти соответсвенно, тогда как ADO 7 и 14 мег.), да и скорость поиска более чем приличная (конечно для для телефонной базы можно обойтись вообще без индексов, особенно при использовании TQuery и SQL, и получить еще меньшие затраты ресурсов, или использовать загрузку по частям). Так что Borland"oвские программисты тоже на модульность ставку делали при создании BDE как и Microsoft на модульность ADO.
Ну и на крайний случай можно odbc32.dll и odbcint.dll упаковать и тоже слить. А можно сливать и в Windows\System, на будущее типа делать Upgrade одной двумя dll, но не советую, черевато зубодробительными проблемами.
Те же манипуляции можно проделывать и с dll"ками paradox (правда к базе индекс нужен полюбому). С остальными типами баз думаю тоже можно делать что-то подобное. Хотя для некоторых, например микросовтовского mdb, без алиасов не обойтись.

Я думаю, иcпользовать такой подход все же лучше, чем куча гемороя с Halcon и ему подобным (особенно когда у тебя D5, а Halcon для D4). Тем более что BDE не один год отлаживают.

P.S.
А получился не плохой справочник весом 1,70 мб с очень быстрым поиском(фильтровкой), и независящий от базы, но без режима редактирования.

=RNZ=
icq # : 113833174

> Lamerr

Вот дался тебе этот "размер экзешника" !
Ну уж если даже так критичен он - так вынеси ты сам движок в дин.библиотеку ! Или - в пэкэдж .. И всех делов)

Хранение табличных данных в файлах Найти похожие ветки