Структура для хранения данных

← →
VladSel (2008-01-21 08:02) [0]

Задача:
Хочу создать структуру (числа, даты строки, ...) для (хранения, добавления, изменения, сортировка, ...)

данных, параметры структуры (размер, число полей) заранее не известны, размеры этих структур будут большие

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

строк, в каждой из которых есть integer - 2-3 поля, string (~150 символов) - 2-3 поля, TDateTIme - 2-3 поля

(в сумме~500Мб)). Предполагаю что 80-85% работы будет заключаться в сортировке и поиске нужной строки.

Вопрос 1:
У кого Какие есть идеи по этой подобной структуре, что в ней использовать (массивы, списки).

Как варианты я хотел использовать:
1. динамические массивы, Плюсы: быстрый доступ к любому элементу; минусы: медленное изменение размеров

(например вставка в начало)
2. связные списки, плюсы: быстрые вставки, изменение последовательности строк,

Вопрос 2:
Если использовать динамические массивы всё понятно, объявил массив с нужным типом и сразу с ним работай, а

если использовать связные списки, то как я понимаю я имею в списке кучу указателей, а вот на что эти

указатели? создавать для каждой записи(строки) массив указателей для каждого типа данных (тока тогда для

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

занимает 4 байта) и быстродействие будет наверно низкое) или есть какие-то другие методы. Может кто-то уже

удачно делал что-то подобное.

← →
Сергей М. © (2008-01-21 08:21) [1]

Самый верный в данных условиях Вариант 3 - использование СУБД

← →
VladSel (2008-01-21 09:41) [2]

В сторону СУБД смотреть не хочу, т.к. СУБД уже используется, я хочу брать данные с сервака по возможности меньшее количество раз (хочу уменьшить сетевой трафик), при проблемах с сетью хочу чтобы никакие данные не терялись, и данные на клиенте хочу где-то сохранить (не в DataSet-ах), а затем своими классами вытаскивать данные в том виде в котором они нужны. Массивы не хочется использовать т.к. одни и теже данные надо в нескольких местах показывать по разному (разная сортировка и разные фильтры), в списках как я предполагаю можно было бы создать для каждого случая свои связи при этом данные хранились бы всего один раз, только со списками мне не понятно где хранить сами данные и как их связать со списком.

← →
Ega23 © (2008-01-21 09:48) [3]

> УБД уже используется, я хочу брать данные с сервака по возможности
> меньшее количество раз (хочу уменьшить сетевой трафик),
> при проблемах с сетью хочу чтобы никакие данные не терялись,
> и данные на клиенте хочу где-то сохранить (не в DataSet-
> ах), а затем своими классами вытаскивать данные в том виде
> в котором они нужны.

Чувак, ты думаешь, что если ты будешь свою инфу хранить в файле, это будет быстрее работать?
Лично у меня по этому поводу - офигенные сомнения.

Не хочешь использовать серверную СУБД - используй embedded-решение.

← →
MBo © (2008-01-21 09:52) [4]

1. создаем структуру данных для хранения - если добавление-удаление будет редко - то массив, если часто - список
2. чтобы не тасовать сами данные - создаем структуры для косвенной сортировки - например, бинарные деревья (сбалансированные, например - красно-черные), содержащие указатели на данные (или индексы в случае массивов). Для сортировки и отбора по нескольким полям - можно несколько деревьев

Итого получаем некий аналог базы данных - так не лучше ли воспользоваться готовыми решениями?

← →
Сергей М. © (2008-01-21 09:54) [5]

> В сторону СУБД смотреть не хочу

А придется.

> хочу уменьшить сетевой трафик

См. 3-хзвенную архитектуру распределенных СУБД-приложений.

← →
Jeer © (2008-01-21 09:54) [6]

> VladSel (21.01.08 09:41) [2]
>
> В сторону СУБД смотреть не хочу,

Если хочется идти своим путем - иди. Большинству же вполне понятен совет в посте[1].

Что же касается дополнительной обработке на клиенте, то так называемые ROLAP-системы (OLAP-системы, построенные на реляционных базах), используют ее для дополнительной агрегации, вращения сечений многомерного куба и т.п.

← →
Sergey13 © (2008-01-21 10:18) [7]

А еще можно велосипед изобретать - тоже нужное дело.

VladSel (21.01.08 09:41) [2]
> В сторону СУБД смотреть не хочу

Можно использовать Recordset не связывая его с СУБД. Сортировать, фильтровать, сохранять в файл и загружать из файла в виде XML, отображать в DBGrid. Если данных немного, то это будет не так уж и медленно.
Но лучше, конечно, делать через СУБД. Слишком много там понаделано такого, что в противном случае придется писать самому.

> engine © (21.01.08 10:21) [8]
>
> > [7] Sergey13 © (21.01.08 10:18)
>
> Ага, только обязательно с квадратными колесами )
>

А с круглыми и не получится ...

Структура для хранения данных Найти похожие ветки