SQL

← →
Alex Ford (2008-05-21 14:54) [0]

Привет!

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

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

← →
ANB (2008-05-21 14:57) [1]

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

Переведи на русский.

> form1.Query1.SQL.Add("select * from "DataBase.db"");

И вот так больше не пиши.

form1.Query1.SQL.Text := "select * from "DataBase.db"";

← →
Alex Ford (2008-05-21 14:59) [2]

Переведи на русский.
Извини, нервничаю немного...

Забыл как извлчечь запись, указанную в Edit1 посредством sql из таблицы

И вот так больше не пиши
form1.Query1.SQL.Text := "select * from "DataBase.db"";

Почему?

← →
Palladin © (2008-05-21 15:01) [3]

да пиши на здоровье, только clear делай перед ним, раз уж тебе нравится две строчки вместо одной...

> Забыл как извлчечь запись, указанную в Edit1 посредством
> sql из таблицы

что такое "запись указанная в Edit1"?

← →
Alex Ford (2008-05-21 15:05) [4]

Предположим, что у меня есть такия даные: test1, test2, test3, test4.
Необходимо вытащить из базы строчку test2. через некоторое время test4 и т.д.
Просто я немного синтаксис sql забыл - все перемешалось в голове. А книги сейчас как на зло - нет....

← →
Anatoly Podgoretsky © (2008-05-21 15:07) [5]

form1.Query1.SQL.Add("select [поле] from "DataBase.db" where Условие");

← →
Palladin © (2008-05-21 15:07) [6]

select "test2"

← →
Alex Ford (2008-05-21 15:08) [7]

т.е. вместо этого кода
form1.Query1.SQL.Text:="select * from "DataBase.db"";

должен быть код, примерно такого содержания
form1.Query1.SQL.Text:="select * здесь указываем что ищем в Edit1from "DataBase.db"";

← →
Anatoly Podgoretsky © (2008-05-21 15:09) [8]

> Почему?

Для Парадокса можешь писать, хотя и тут тоже не совсек красиво, зачем тянуть 100 полей, когда нужно всего одно поля.
А для большинства серверов ты этим ставишь сервер на колени.

← →
ANB (2008-05-21 15:09) [9]

> Alex Ford (21.05.08 15:05) [4]

У тебя в таблице всего одно поле ?

> все перемешалось в голове

Не, ты не SQL забыл. А принципы работы с БД. Тут SQL не всегда нужен.

В принципе все просто :

select список_полей_через_запятую from имя_таблицы where условие_по_которому_отбирать_записи

Ну эт если таблица одна. А если таблиц много, то . . . То лучше сначала почитать книжки.

← →
Sergey13 © (2008-05-21 15:10) [10]

> [0] Alex Ford (21.05.08 14:54)

Долго же ты не работал с SQL, если такие вещи забыл? 8-)
Запрос конретизируется с помощью секции
WHERE условия
Если сначала вытаскивается все на клиента, имеет смысл фильтровать результат, а не перезапрашивать БД.

← →
ANB (2008-05-21 15:13) [11]

> А для большинства серверов ты этим ставишь сервер на колени.

Да ладно. Прям уж таки * на колени поставит.

Намного скорее поставит нестед лупс по 15 миллионам записей. Да еще в связке с таблицами, в которых под миллиард записей.

А * - при разборе запроса раз обработается, в процедурный кэш запишется и всех делов то.

← →
Alex Ford (2008-05-21 15:19) [12]

чёта не работает....

form1.Query1.Active:= false; form1.Query1.SQL.Clear; form1.Query1.SQL.add("select TabNo from "DataBase.db" where"+ edit1.Text); form1.Query1.Active:= true; form1.Query1.Open;

← →
Anatoly Podgoretsky © (2008-05-21 15:20) [13]

> Sergey13 (21.05.2008 15:10:10) [10]

А разве это можно забыть?
Мозно забыть только то, что не знал.

← →
Palladin © (2008-05-21 15:24) [14]

> Alex Ford (21.05.08 15:19) [12]

чета за метлой пора... )

← →
Anatoly Podgoretsky © (2008-05-21 15:25) [15]

> ANB (21.05.2008 15:13:11) [11]

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

← →
Alex Ford (2008-05-21 15:26) [16]

Ребят, может укажите где ошибка в коде?
Что не парвильно пишу?
form1.Query1.SQL.add("select [TabNo] from "DataBase.db" where"+ edit1.Text);

← →
Sergey13 © (2008-05-21 15:28) [17]

> [12] Alex Ford (21.05.08 15:19)
> form1.Query1.SQL.add("select TabNo from "DataBase.db" where"+ edit1.Text);

А что у тебя в edit1.Text?

> [13] Anatoly Podgoretsky © (21.05.08 15:20)

Вот я и подивился долголетию. 8-)

← →
ANB (2008-05-21 15:29) [18]

> Что не парвильно пишу?
> form1.Query1.SQL.add("select [TabNo] from "DataBase.db"
> where"+ edit1.Text);

Все.

Составь сначала запрос в среде выполнения запросов для своей субд, добейся его работы, а потом пихай в делфи и наворачивая свои эдиты.

← →
Alex Ford (2008-05-21 15:30) [19]

В Edit пытаюсь указать условие выборки. Скажем так.

← →
Sergey13 © (2008-05-21 15:32) [20]

> [19] Alex Ford (21.05.08 15:30)
> Скажем так.

А ты не говори загадками - ты конкретно напиши.

← →
Anatoly Podgoretsky © (2008-05-21 15:32) [21]

Скажем как?

← →
ANB (2008-05-21 15:34) [22]

> А это реально, напишет такую фигню и распространит например
> по институту и все приплыли.

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

Кстати, где ты откопал, что запрос со * перепарсивается кажный раз ? Хэш то вроде как не меняется.

← →
ANB (2008-05-21 15:35) [23]

> В Edit пытаюсь указать условие выборки. Скажем так.

пробел в строку после where добавь.

← →
Alex Ford (2008-05-21 15:42) [24]

Спасибо всем!

так никто толком не объяснил на нормальном языке. Кроме ANB - спасибо тебе за внимание и поддержку!

эх......

← →
Anatoly Podgoretsky © (2008-05-21 15:49) [25]

> ANB (21.05.2008 15:34:22) [22]

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

← →
Anatoly Podgoretsky © (2008-05-21 15:50) [26]

> Alex Ford (21.05.2008 15:42:24) [24]

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

← →
ANB (2008-05-21 16:34) [27]

> Я себе позволяю звездочку только при отладке запроса

Ну, в принципе, я тоже. За исключением работы с ROWTYPE. Тут уж * - самое удобное. И код не ломается, если структура поменялась.

Да. Чет мне говорит, что в оракле озвученная проблема со * менее актуальна. Оракл с 9-ки даже начал пытаться непараметризованные запросы пытаться приводить на лету к параметризованному виду. Правда, не очень успешно.

А вот у меня есть клевый пример, когда * сильно повлияет на производительность.

Имеем таблицу

Table1
(
ID,
DocDate,
DocSum
)

Имеем индекс
create index Table1_DateSum on (DocDate, DocSum)

Хотим : получить суммы документов за день.

Так вот запросы

select * from table1 where DocDate = :DocDate

и

select DocSum from table1 where DocDate = :DocDate

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

← →
Anatoly Podgoretsky © (2008-05-21 16:45) [28]

Ну я не могу говорить конкретно об Оракле.
А вот в общем случае говорить можно.
А покрывающий индекс может весьма повысить производительность, что у тебя и происходит. У меня такое же наблюдается и на MS SQL покрывающий индекс позволил повысить производительность примерно раз в 60.

← →
Big Joe (2008-05-21 16:54) [29]

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

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

← →
Sergey13 © (2008-05-21 16:55) [30]

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

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

← →
Anatoly Podgoretsky © (2008-05-21 16:59) [31]

Мне тоже кажется, что так, поскольку для обработки достаточно только покрывающего индекса.

← →
MsGuns © (2008-05-21 17:23) [32]

>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;

Вызов:

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

← →
MsGuns © (2008-05-21 17:27) [33]

И еще пара советов:

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

;)

← →
ANB (2008-05-21 17:43) [34]

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

Дык и я о чем.

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

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

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

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

> 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
И что это будет?
Или это простое желание помочь правильным кодом ламеру? :)))
Который, видимо от нервничания (сроки поджимают), ещё и нагло врёт.

>Johnmen © (21.05.08 22:24) [36]

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

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

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

MsGuns © (21.05.08 21:47) [35]

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

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

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

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

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

MsGuns © (21.05.08 23:08) [39]

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

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

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

Короче, просто пример.

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

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

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

;)

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

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

Кстати о времени:

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 секунды.

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

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

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

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 инт поля.

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

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

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

← →
ANB (2008-05-22 10:34) [48]

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

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

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

+1

SQL Найти похожие ветки