Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

выборка

Страницы: 1 2 3 4 >
sqler © (2012-12-19 12:16:00)
для таблицы на 10 млн записей, что будет быстрее: три SELECT-запроса (SELECT..FROM..WHERE) или 1 SELECT запрос (SELECT * FROM table) и перебор полученного рекордсета?

sniknik (2012-12-24 08:11:00) [1]
> и всячески пытается выкрутится.
я даже не пытался проверить, так как у тебя, с акцесс... т.к. методы определения тобой не были раскрыты до..., фактичеси вот этого поста.

могу предположить, на скорую руку, без опять проверок, что 1 - аксесс не подходящая для этого дела база... т.к. локальная (локальными методами поведение должно исправится) . 2 - тип OLE у него нестандартный блоб, контейнер под ActivX обработка отличается от стандартной. 3 - возможно, опять из-за типа, дельфя не определяет его как блоб (т.к. старая, тип могли позже ввести) а например как длинную строку с соответствующей обработкой. 4 - ADO пытается включить поле в идентификатор записи (опять возможно из-за типа), с тем же результатом.
проверить могу позже, на работе (если работы не будет).

Jeer (2012-12-22 02:38:00) [2]
Удалено модератором

stas (2012-12-21 16:25:00) [3]
Игорь Шевченко © (21.12.12 16:00) [69]

Ну, так пора бы признать, что ваш "мастер" в [4] сказал бред и всячески пытается выкрутится.

Игорь Шевченко (2012-12-21 16:00:00) [4]
stas © (21.12.12 15:57) [67]

Успокойся уже

stas (2012-12-21 15:58:00) [5]
*в архиве база пустая

stas (2012-12-21 15:57:00) [6]
Написал приложение для теста.
Используется база акцесса, состоящая и 1-й таблицы, в ней 2 поля, первое счетчик, второе memo

1. Загружаем в него список файлов, общим размером 223 мб
http://piccy.info/view3/3880841/37f0b9edc922795de500e923aa68efd0/orig/

2. Для чистоты эксперемента, закрываем приложение, и открываем по новой, смотрим размер занимаемой ОЗУ приложением
http://piccy.info/view3/3880863/d215a6efd932408f2fdfdb7cad2e82a1/orig/

3. Открываем базу без блоб поля, (в запросе выборка только 1-го поля - счетчика)
http://piccy.info/view3/3880871/70381f130abb10fd5ef9cd44434079cb/orig/
как видим, размер приложения особо не изменился

4. Открываем базу с блоб полем в запросе
http://piccy.info/view3/3880876/04c776576d019111a1fb6b5b42ffd5a0/orig/

и наблюдаем сколько занимает места программа в ОЗУ - 248 мб.

Кому интересно или сомневается, качаем программу с исходниками и проверяем.
http://narod.ru/disk/64673449001.95e00ed1c23e4990fc07505a255b198b/prog.rar.html

Ega23 (2012-12-21 08:50:00) [7]

> Спор о том что человек назвав чушью, то что блоб поля забьют
> ОЗУ при открытии таблицы в 10 млн. записей.

Я же выше привёл пример. 21 Гиг. 15.000 записей. 8 секунд. Никакого забития памяти.
Тебе для MSSQL аналогичное написать?

sniknik (2012-12-21 01:20:00) [8]
> Спор о том что человек назвав чушью, то что блоб поля забьют ОЗУ при открытии таблицы в 10 млн. записей.
чушь она и есть чушь, сказана безапелляционно в общем (т.е обо всем), что усложняет "диагноз".
сказал бы, что это на некоторых (тобой писанных например) компонентах доступа, и я бы не стал возражать...

ты кстати открытие таблицы и запрос на данные не путаешь? разные вещи однако. ... на файл серверных/(аналогах открытия на сервере, курсорах к примеру) открытие не то что блоб, даже обычных данных в озу не "забьет".

Игорь Шевченко (2012-12-20 22:02:00) [9]

> Спор о том что человек назвав чушью, то что блоб поля забьют
> ОЗУ при открытии таблицы в 10 млн. записей

При открытии никто ничего не забьет.
Написать пример ?

stas (2012-12-20 21:33:00) [10]
Ega23 © (20.12.12 17:00) [61]
Зачем? о 20Гб и речи не было.

Ega23 © (20.12.12 17:02) [62]
Спор о том что человек назвав чушью, то что блоб поля забьют ОЗУ при открытии таблицы в 10 млн. записей. Сказал еще большую чушь и не хочет этого признать.
Если бы сказал что зависит от компонентов доступа, я бы и слова ему не сказал.

Ega23 (2012-12-20 17:02:00) [11]

> Согласен. Это даже указано в документации.

Ну а раз согласен, то зачем тогда этот спор

> stas © (19.12.12 13:09) [6]
>
> sniknik © (19.12.12 13:02) [4]
> 1. Блоб закачивается на клиента полностью

?

Ega23 (2012-12-20 17:00:00) [12]

> т.е. ты предлагаешь мне засунуть 20ГБ в блоб поле?
> с таким размером экспериментируй сам.
> И где я или кто-то предлагал такую глупость?

Засунь 20 Мб в 1000 записей, в чём проблема?

stas (2012-12-20 16:54:00) [13]
Inovet © (20.12.12 16:26) [58]
т.е. ты предлагаешь мне засунуть 20ГБ в блоб поле?
с таким размером экспериментируй сам.
И где я или кто-то предлагал такую глупость?

Даже при размере блоба в 800 кб. видем, то что не 2-3 байта грузится, а полный объем.

Ну, видимо не предусмотрели...

Jeer ©
Не знаю и спорить не буду.

Ega23 © (20.12.12 16:14) [56]
Согласен. Это даже указано в документации.

Jeer (2012-12-20 16:28:00) [14]
В DBISAM (f/s) данные из блобов подгружаются только при запросе их содержимого в те или иные контейнеры.

// Вот так не загружается ни один
SELECT * FROM TEST;
SELECT MEM FROM TEST;

А, к примеру, после селекта и последующем
memo.lines.text := qu.FieldByName('MEM').AsString;

идет очевидная подгрузка.

P.S.
Собственно, аналогично и с блобами. Многократно проверено.

Inovet (2012-12-20 16:26:00) [15]
> [55] stas © (20.12.12 15:30)

Я вот читаю и не пойму: ты уже понял свою неправоту и теперь выкручиваешься или таки не понял. Вот почему ты взял 800 кБ а не 20 ГБ, как предлагалось? Так что похоже на первое предположение - выкручиваешься.

Ну и по БЛОБам. Как-то было бы глупо со стороны разработчиков тащить по-умолчанию (может и можно настроить иначе) БЛОБы на клиента. А загружать их по мере необходимомсти - неглупо, если необходимость не возникла, то и не загрузятся ненужные. Вот с такой логикой без конкретной реализации ты согласен? Если согласен, то вопрос: зачем разработчикам конкретного сервера может понадобиться поступать иначе, какие такие могут быть веские причины?

Ega23 (2012-12-20 16:18:00) [16]
Забыл дописать: всего документов с doc is not null - 15185

Ega23 (2012-12-20 16:14:00) [17]

> 2. Я только увидел что мне пытаются доказать что я не прав,
> не признавая своей не правоты см. [49] где приведен не
> оспоримый факт, того что человек не прав.

Я нихрена не понял.
Могу сказать только одно: в gds32 BLOB подгружается по факту обращения к нему.
Точка.

З.Ы. FireBird 2.1 База ~ 30Гб.
Общий размер документов в базе - 21.086.972.740 байт
Код:
tc := GetTickCount; try ds := FDB.OpenDataSet('select id, doc from docs where doc is not null', []); try while not ds.Eof do ds.Next; finally ds.Free; end; finally ShowMessage(IntToStr(GetTickCount - tc)); end;

Время выполнения - 8672 мс.
Если просто сохранять каждый стрим в файлы - работает ~ 10 минут.
Вопросы?

stas (2012-12-20 15:30:00) [18]
Ega23 © (20.12.12 15:14) [51]
1. Я написал что не мне
2. Я только увидел что мне пытаются доказать что я не прав, не признавая своей не правоты см. [49] где приведен не оспоримый факт, того что человек не прав.
Я понимаю что я здесь редко, а sniknik © постоялец так же как и ты, и пиво с вами не пью. И доказывать будете всей толпой долго и нудно лишь бы не запятнать честную репутацию друга.
Но признать свои ошибки нужно!

sniknik (2012-12-20 15:26:00) [19]
> размером 800 кб,
что так скромно? давай по 100 мег как говорил.

> 900x7 = 6,3 мб
знаешь что такое оле обьект в акцесс? префикс постфикс самой структуры, сколько занимает знаешь? как хранится и представляется инфа в рекордсете?
"чистое" арифметическое говорит реально НИ О ЧЕМ.

к примеру строки в акцессе хранятся в юникоде (по дефаулту, если ничего не менять), а по твоему ты будешь именно то что записал в ansi?

stas (2012-12-20 15:18:00) [20]
sniknik © (20.12.12 15:10) [50]
А я и не писал что мне, поддержать имидж сайта, так сказать.
А я тут раз в пол года.
Поместил в MS ACCESS в 7 записей, ole объект (rar архив) размером 800 кб, ну добавим еще 100 для служебной инф. 900x7 = 6,3 мб. Прирост после открытия 12 мб...

Страницы: 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »