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

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

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

SQL [D7, XP]

Страницы: 1 2 3 >
Alex Ford © (2008-05-21 14:54:00)
Привет!

Давно не работал с SQL. Простые вещи из головы вылетели.
Мастера напомните пожалуйста
Здесь мы получаем все данные полей таблицы
form1.Query1.SQL.Add('select * from "DataBase.db"');

Как получить конкретное значение, указанное в Edit1 таблицы конкретного плояуказанной таблицы

ANB (2008-05-22 10:34:00) [1]

> причем не просто стрингов, а всяких там тримов, кастов,
> конвертов и пр. из 10 таблиц.

Ежли 0 записей, то есть вероятность (невеликая), что быстро. А вот если тебе в этой связке нужно посчитать сумму хотя бы по одному полю и ее вернуть и при этом план будет - связки нестед лупсом, то скорее всего первый запрос будет работать намного дольше, чем второй. И еще скорее всего первый запрос завалится по снапшот ту олд.

> Я считаю, что серверу пофиг, какое поле обрабатывать, лишь
> бы размер не сильно гулял.

+1

Игорь Шевченко (2008-05-22 10:03:00) [2]
MsGuns © (22.05.08 09:10) [46]

> Сервер на то он и сервер, что, сволочь, использует кэши
> ;)
> Опять подтасовываем ?

я тебе открою секрет - view all_objects оно в кеше чуть ли не при старте сервера.

> а) Все выполнять на "гуляющем" сервере

Незнаком с термином, поясни.

> б) Рвать коннект после каждого запроса и устанавливать заново
> дперед следующим

Нафига ? Приложения, они, знаешь ли, подобным поведением не отличаются.

> в) В качестве подопытных таблиц не брать те, у которых 2-
> 3 инт-поля

desc all_objects
Name Null? Type
----------------------------------------- -------- ---------------
OWNER NOT NULL VARCHAR2(30)
OBJECT_NAME NOT NULL VARCHAR2(30)
SUBOBJECT_NAME VARCHAR2(30)
OBJECT_ID NOT NULL NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(19)
CREATED NOT NULL DATE
LAST_DDL_TIME NOT NULL DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)

Как бы не 2-3 инт поля.

> Про стринги.
> Ты всерьез счиатешь, что серверу пофиг, какое поле обрабатывать
> - числовое или стринговое ..сот байт длиной - на скорости
> выборок это не сказывается

Я считаю, что серверу пофиг, какое поле обрабатывать, лишь бы размер не сильно гулял.
А соединять по стрингам длиной несколько сот байт - ну может задача такая...Всякое бывает.

Впрочем, можем провести еще пару экспериментов.

MsGuns (2008-05-22 09:10:00) [3]
Охохонюшки..
Сервер на то он и сервер, что, сволочь, использует кэши ;)
Опять подтасовываем ?

Для чистоты эксперимента надо:
а) Все выполнять на "гуляющем" сервере
б) Рвать коннект после каждого запроса и устанавливать заново дперед следующим
в) В качестве подопытных таблиц не брать те, у которых 2-3 инт-поля

Про стринги.
Ты всерьез счиатешь, что серверу пофиг, какое поле обрабатывать - числовое или стринговое ..сот байт длиной - на скорости выборок это не сказывается ?

Игорь Шевченко (2008-05-21 23:27:00) [4]
Кстати о времени:

TEST@ora10> create table foo as select * from all_objects where (1=0);

Table created.

TEST@ora10> set timing on
TEST@ora10> insert into foo select * from all_objects;

40772 rows created.

Elapsed: 00:00:09.87
TEST@ora10> commit;

Commit complete.

Elapsed: 00:00:00.01
TEST@ora10> insert into foo select * from foo union all select * from foo;

81544 rows created.

Elapsed: 00:00:02.37
TEST@ora10> commit;

Commit complete.

Elapsed: 00:00:00.01
TEST@ora10> insert into foo select * from foo union all select * from foo;

244632 rows created.

Elapsed: 00:00:07.78
TEST@ora10> commit;

Commit complete.

Elapsed: 00:00:00.01
TEST@ora10> insert into foo select * from foo union all select * from foo;

733896 rows created.

Elapsed: 00:00:28.84
TEST@ora10>

Первый запрос выполнялся 9 секунд для получения 40 тысяч записей, потому что

select * from all_objects where (1=0);

no rows selected

Elapsed: 00:00:00.00

Execution Plan
----------------------------------------------------------
Plan hash value: 2338933161

----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 86 | 0 (0)| |
|* 1 | TABLE ACCESS BY INDEX ROWID | SUM$ | 1 | 8 | 1 (0)| 00:00:01 |
|* 2 | INDEX UNIQUE SCAN | I_SUM$_1 | 1 | | 0 (0)| 00:00:01 |
|* 3 | FILTER | | | | | |
|* 4 | FILTER | | | | | |
|* 5 | HASH JOIN | | 59458 | 4993K| 183 (13)| 00:00:03 |
| 6 | TABLE ACCESS FULL | USER$ | 75 | 1125 | 3 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | OBJ$ | 59458 | 4122K| 178 (12)| 00:00:03 |
|* 8 | TABLE ACCESS BY INDEX ROWID | IND$ | 1 | 8 | 2 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | I_IND1 | 1 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 24 | 2 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | I_OBJAUTH1 | 1 | 11 | 2 (0)| 00:00:01 |
|* 12 | FIXED TABLE FULL | X$KZSRO | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 14 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 15 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 16 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 17 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 18 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 19 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 20 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 21 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 22 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 23 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 24 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 25 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 26 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 27 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 28 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 29 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 30 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 31 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 32 | FIXED TABLE FULL | X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
|* 33 | FIXED TABLE FULL| X$KZSPR | 1 | 26 | 0 (0)| 00:00:01 |
| 34 | VIEW | | 1 | 13 | 2 (0)| 00:00:01 |
| 35 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------

второй запрос на получение 80000 строк выполнялся уже 2 секунды.

Игорь Шевченко (2008-05-21 23:16:00) [5]
MsGuns © (21.05.08 23:13) [41]

> и даже (Боже оборони !) по стринговым связкам

А какая разница, по чему связывать ?

Игорь Шевченко (2008-05-21 23:16:00) [6]
MsGuns © (21.05.08 23:13) [41]

> Вопрос на засыпку - какой запрос выполнится шустрее ?

Неизвестно.

Loginov Dmitry (2008-05-21 23:15:00) [7]
> Вопрос на засыпку - какой запрос выполнится шустрее ?

Второй выполнится за 0 мс?

MsGuns (2008-05-21 23:13:00) [8]
Короче, просто пример.

Запрос 1. Море джоинов, причем не по ключам и даже (Боже оборони !) по стринговым связкам, причем не просто стрингов, а всяких там тримов, кастов, конвертов и пр. из 10 таблиц. Однако запрос заведомо не должен вернуть НИ ОДНОЙ записи ! Каждая из 10 таблиц содержит мульен записей

Запрос 2. Классика жанра 'Select * from Table' из тэйбла размером 10 000000 записей.

Вопрос на засыпку - какой запрос выполнится шустрее ?

;)

Игорь Шевченко (2008-05-21 23:12:00) [9]
MsGuns © (21.05.08 23:08) [39]

> Ни фиганюшки ! За одним исключением - если в результате
> "внутришних" селекций не будут выбираться и кучковаться
> на сервере же хучи отуенные промежуточных записей.

Так от количества возвращаемых запросом записей или от количества шагов обработки запроса и записей, участвующих в получении результирующего множества ? :)

А то мне не составит труда написать запрос, возвращающий одну запись и работающий пару суток :)

MsGuns (2008-05-21 23:08:00) [10]
>Игорь Шевченко © (21.05.08 23:00) [38]
>Можно я тоже скажу (не менее провокационным шепотом): "не всегда и не везде". От количества и вычурности условий, а в особенности джойнов, очень сильно зависит.

Совсем тихо, почти не слышно:

Ни фиганюшки ! За одним исключением - если в результате "внутришних" селекций не будут выбираться и кучковаться на сервере же хучи отуенные промежуточных записей.

Игорь Шевченко (2008-05-21 23:00:00) [11]
MsGuns © (21.05.08 21:47) [35]

> Скорость выполнения запроса в большей степени зависит от
> кол-ва возвращаемых записей, чем от кол-ва и вычурности
> условий и джоинов. Другими словами, сервер не столько ищет,
> сколько "упаковывает" и "отправляет" "посылочки".

Можно я тоже скажу (не менее провокационным шепотом): "не всегда и не везде". От количества и вычурности условий, а в особенности джойнов, очень сильно зависит.

MsGuns (2008-05-21 22:51:00) [12]
>Johnmen © (21.05.08 22:24) [36]

BDE, верояетно, выругается, а вот мсскл прожует намана.

>Или это простое желание помочь правильным кодом ламеру? :)))

Я просто показал, где СКОРЕЕ ВСЕГО у него ошибка, заодно намекнув на необходимость обрамление стринговых констант в запросах апострофами.
Думаю, как видоизменить как сам запрос (в случае динамического), так и код подстановки (в случае параметрического), он как-нибудь догадается сам

Johnmen (2008-05-21 22:24:00) [13]

> MsGuns © (21.05.08 17:23) [32]
> form1.Query1.SQL.add('select [TabNo] from "DataBase.db" where '+QuotedStr(edit1.Text));

К примеру, в edit1.Text находится field1 = 666, или просто 666
И что это будет?
Или это простое желание помочь правильным кодом ламеру? :)))
Который, видимо от нервничания (сроки поджимают), ещё и нагло врёт.

MsGuns (2008-05-21 21:47:00) [14]
>ANB (21.05.08 17:43) [34]
>Это явный плюс к явному списку полей. Глядишь, что то и ускорится.

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

ANB (2008-05-21 17:43:00) [15]

> Естественно. Ведь при такой постановке таблица вообще не
> учавствует в выборке.

Дык и я о чем.

Это явный плюс к явному списку полей. Глядишь, что то и ускорится.

Дополнительно могу назвать :
1. Снижение трафика при передаче набора данных на клиента
2. Снижение нагрузки на оперативку и временное табличное пространство сервера (особенно при обработке хранимками)
3. Большая читаемость запроса

MsGuns (2008-05-21 17:27:00) [16]
И еще пара советов:

1. Не надо называть таблицы БД словом DataBase - очень по-дилетантски звучит
2. Почитать что-нибудь, и не только по SQL, а по делфи тоже

;)

MsGuns (2008-05-21 17:23:00) [17]
>Alex Ford (21.05.08 15:26) [16]
>Что не парвильно пишу?
>form1.Query1.SQL.add('select [TabNo] from "DataBase.db" where'+ edit1.Text);

form1.Query1.SQL.add('select [TabNo] from "DataBase.db" where '+QuotedStr(edit1.Text));

Однако лучше использовать параметрический запрос:

В OnCreate или в дизайне прописать в св-во SQL квери строку

'Select <Список полей> From Table Where <Проверяемое поле>=:pFld'

function FetchOrderedPool(Sample: string): boolean; begin with Form1.Query1 do try if Actie then Close; ParamByName('pFld').AsString := Sample; Open; result := true; except result := false; end; end;

Вызов:

p rocedure TForm1.Button1Click(Cender: TObject); begin if FetchOrderedPool(Form1.Edit.Text) then ShowMessage('Замечательно') else ShowMessage('Не сложилось :o('); end;

Anatoly Podgoretsky (2008-05-21 16:59:00) [18]
Мне тоже кажется, что так, поскольку для обработки достаточно только покрывающего индекса.

Sergey13 (2008-05-21 16:55:00) [19]
> [27] ANB (21.05.08 16:34)
> будут весьма отличаться планами выполнения, причем второй
> может оказаться шустрее вдвое.

Естественно. Ведь при такой постановке таблица вообще не учавствует в выборке.

Big Joe (2008-05-21 16:54:00) [20]

> да пиши на здоровье, только clear делай перед ним

Зачем ? Он же не Add делает ...

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

Наверх

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