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 делает ...

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

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

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

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

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

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]

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

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

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

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