Загрузка записей из таблицы БД

← →
js2 (2009-04-23 15:31) [0]

имеется постоянно корректируемая таблица БД (записей от 2 000 000 до 6 000 000). Задача состоит в том чтобы грузить все записи или в список или в массив. Что посоветуете:

1. Написать наследник Tlist который будет работать с record
2. Грузить в массив типа record

Какие плюсы\минусы этих вариантов?

← →
Медвежонок Пятачок © (2009-04-23 15:38) [1]

Что посоветуете:

удалить все записи

← →
js2 (2009-04-23 15:41) [2]

> Медвежонок Пятачок © (23.04.09 15:38) [1]
> Что посоветуете:удалить все записи

Смешно.... А если по делу?

← →
Медвежонок Пятачок © (2009-04-23 15:42) [3]

Зачем грузить 6 миллионов записей в рекорды, если все они уже и так загружены в таблицу БД.

← →
Сергей М. © (2009-04-23 15:43) [4]

> Задача состоит в том чтобы грузить все записи или в список
> или в массив

За каким лешим грузить-то ?
Что, без этого никак не обойтись ?

← →
js2 (2009-04-23 15:44) [5]

не моя прихоть. сам в принципе не понимаю, сказали - приходится делать

← →
Ega23 © (2009-04-23 15:45) [6]

Зачем тебе на клиенте 2 лимона записей? Что ты с ними будешь делать?

← →
Amoeba © (2009-04-23 15:46) [7]

> js2 (23.04.09 15:44) [5]
>
> не моя прихоть. сам в принципе не понимаю, сказали - приходится
> делать

И теперь хочешь найти консультантов для реализации предельно идиотского задания.

← →
Sergey13 © (2009-04-23 15:47) [8]

> [6] Ega23 © (23.04.09 15:45)
> Зачем тебе на клиенте 2 лимона записей?

Чай с лимонами пить. 8-)

> [5] js2 (23.04.09 15:44)

Курсовой? А на лекции наверное не ходил? Но пиво наверное любишь.

← →
js2 (2009-04-23 15:47) [9]

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

← →
Сергей М. © (2009-04-23 15:50) [10]

> не моя прихоть

Ну тогда не все ли равно, куда все это "добро" грузить ?

> Какие плюсы\минусы этих вариантов?

С учетом озвученных объемом загружаемых данных оба варианта дурные на всю голову того, у кого возникла эта блажь.

← →
Сергей М. © (2009-04-23 15:51) [11]

> пишу определенный компонент

Не надо ничего писать, все уже написано - TClientDataSet.

← →
Anatoly Podgoretsky © (2009-04-23 15:56) [12]

Теперь прикинем расходы на хранение 6 000 000 записей в любом виде.

← →
stas © (2009-04-23 15:59) [13]

js2 (23.04.09 15:47) [9]
что вы понимаете под списками?

← →
Ega23 © (2009-04-23 16:01) [14]

> но и со списком этих же данных

6 миллионов записей по 1 байту дадут тебе чуть меньше 6 мегабайт памяти.
тупое сочетание id-Name (пусть Name в среднем 10 символов) даст тебе уже 15 байт на запись. Соответственно - 90 метров в опрервтивке (это если всё предельно аккуратно расписать).
Про время доставки этих записей на клиент - я вообще молчу.

← →
Anatoly Podgoretsky © (2009-04-23 16:03) [15]

> Ega23 (23.04.2009 16:01:14) [14]

Name при размере 10 символов для строк займет минимум 22 байта, плюс расходы на поддержку списка

← →
Медвежонок Пятачок © (2009-04-23 16:08) [16]

1. Написать наследник Tlist который будет работать с record
2. Грузить в массив типа record

Какие плюсы\минусы этих вариантов?

Минусы и плюсы в обоих случаях одинаковые

TList = class(TObject)
private
FList: PPointerList;
.......

PPointerList = ^TPointerList;
TPointerList = array[0..MaxListSize - 1] of Pointer;

← →
Ega23 © (2009-04-23 16:16) [17]

> для строк займет минимум 22 байта

Почему?
Если считать, что строка не больше 255 символов, то запись будет выглядеть
id - 4 байта
NameSize - byte
NameChars - буфер символов.
И всё это одной цепочкой пустить.
Навигация, правда, будет просто никакая.

← →
Anatoly Podgoretsky © (2009-04-23 16:19) [18]

> Ega23 (23.04.2009 16:16:17) [17]

Ты сделай нормальное объявление

NameChars: string

← →
Медвежонок Пятачок © (2009-04-23 16:22) [19]

Name при размере 10 символов для строк займет минимум 22 байта, плюс расходы на поддержку списка

15

StrNew allocates a copy of Str on the heap.
.....
The allocated space is the length of Str + 5 bytes.

← →
Anatoly Podgoretsky © (2009-04-23 16:26) [20]

Это не string, а уродец из Си к тому же backward compatibility routines и все равно добавь еще 4 байта для хранения указателя. Это же PChar

← →
Медвежонок Пятачок © (2009-04-23 16:29) [21]

Я к тому, что если

s : string;
begin
s:= "мама";
end;

то на s будет потрачено 4 + 5 байт. даже если не было ни стрнью ни страллок.

← →
sniknik © (2009-04-23 16:33) [22]

> 15
реально больше
> length of Str + 5 bytes.
это собственно под данные строки, т.е. еще 4 байта под префикс (где находится длинна строки), и 1 байт на завершение #0 -ем, на случай приведения типа к PChar.
но тут не учитывается размер самой переменной, т.е. указателя на эти данные, + при выделении блока памяти там тоже есть служебные данные (та же длинна но уже блока, + как то они там в цепочку организуются. не помню точно...)

т.е. я бы сказал даже не 22, а 23 байта нужно... имхо. + есть еще и выравнивание блоков по границе 8(? 16) байт. опять смутно все... ;(

← →
Ega23 © (2009-04-23 16:34) [23]

> Ты сделай нормальное объявление
>
> NameChars: string

Да нафига мне оно надо? Я же не стринг храню.

procedure StreamAddRecord(stream : TStream; const id : Integer; const aStr : shortstring); var strLen : Byte; begin stream.WriteBuffer(id, 4); strLen := aStr[0]; stream.WriteBuffer(strLen, 1); stream.WriteBuffer(PAnsiChar(aStr[1])^, strLen); end;

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

← →
Ega23 © (2009-04-23 16:35) [24]

Это, естественно, при String[255]

← →
Anatoly Podgoretsky © (2009-04-23 16:36) [25]

> Медвежонок Пятачок (23.04.2009 16:29:21) [21]

Будет потрачено 5 на строку + 4 байта на переменную и + 8 байт на скрытую часть строки, то есть к каждой строке добавлять 12 байт накладных расходов.

> sniknik (23.04.2009 16:33:22) [22]

Правильно про завершающий байт я забыл и я еще не уверен за системную часть, раньше невидимая часть составляла 12 а не 8 байт, сейчас один показатель убрали из объявления.

и 1 байт на завершение #0 -ем

Он уже в тех пяти байтах. счетчик ссылок + нулевой

> Ega23 (23.04.2009 16:34:23) [23]

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

> Это, естественно, при String[255]

String[10] или 5, мы про эти две длины говори.

> Но все равно добавь 4 байта на указатель, если конечно это
> не будет реализовано через массив.

Так я же и говорил - это просто по минимуму, дальше некуда. Если по-хорошему надо делать - то да, на простейшую структуру места гораздо больше будет отводиться. Ну и на 6 лимонов помножить.. :)

> Ega23 (23.04.2009 16:45:30) [30]

Наконец шаги навстречу друг другу и вывод, нифига ему памяти не хватит.

> Он уже в тех пяти байтах. счетчик ссылок + нулевой
упс. а счетчик ссылок то я и не учел... а нулевой то да, это я там расписал эти 5 байт как я их понимаю.
тогда еще + 4 байта (ну или они как то совмещают и считают длину строи от длинны блока памяти, тогда остается как есть)

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

-----------------
- дети, давайте позовем того без кого не обходится ни один новый год.
- милиция!!!!

т.е. нет Юрий Зотов, Юра!!! а ууу!!! ;о))

> нифига ему памяти не хватит.

Не, ну если памяти 3 гига, структура таблицы (id int, name varchar(10)), то хватит... :)

> Не, ну если памяти 3 гига
программе все одно выделится 2 гига... так вроде?

> Ega23 (23.04.2009 17:18:33) [33]

Во первых только 2 гб. во вторых как писать, например через StringGrid

> программе все одно выделится 2 гига...

меньше

Загрузка записей из таблицы БД Найти похожие ветки