SQL запросы
 

Обсуждение запросов на SQL и проблем с ними.

начну с бонального и распространенного:

есть две связаные таблицы -
users
__________________________
id | name | vozrost | profesia
------------------------------
1 | Федя | 21 год | 2
2 | Нина | 18 лет | 3
3 | Гена | 24 года| 5

t_profesia
__________________________
id | prof_name
------------------------------
1 | Программист
2 | Строитель
3 | Доктор
4 | Артист
5 | Учитель

Вопрос - как составить запрос чтоб результат был таков:
__________________________
id | name | vozrost | profesia
------------------------------
1 | Федя | 21 год | Строитель
2 | Нина | 18 лет | Доктор
3 | Гена | 24 года| Учитель

А в какой программе?

В мускле должно сработать:
SELECT u.id, u.name, u.vozrost, p.prof_name FROM users AS u
LEFT JOIN t_profesia AS p ON p.id=u.profesia

можно и без джойнов обойтись
SELECT id, name, vozrost, (select prof_name from t_profesia where id=u.profesia) profesia
FROM users u

да но как правило то такие запросы тормозят!
такчто предыдущий вариант более подходящий

SELECT u.id, u.name, u.vozrost, p.name FROM users u, t_profesia p WHERE u.profesia = p.id

:yees: я думаю это оптимальный.

С джойнами тоже случаются тормоза на больших пересечениях

Попробовал на таблицах ~4млн. х 1млн.
Простые подсчёты:
мой вариант вариант 24 сек.
EvroStandart - 11 сек.
nikotano - 2мин.37сек.

:eek: .. да ладно, на какой пралформе тестил.. ?
это серьезный момент - о скорости..

- по твоим словам, EvroStandart - самы нормальный.. запрос составил..
EvroStandart - о как.. :)

На самом деле вопрос стоит так - даешь ли ты оптимизацию запроса на откуп оптимизатору движка или "тыкаешь его носом". В данном случае важно есть ли индексы по связанным полям, вес индексов, наполненность таблицы и т.п. Если данных мало или наоборот много, оптимизатор может решить что ему проще отобрать нужные значения простым перебором. В общем случае варианты nokitano и evro почти одинаковы, но у nikotano более "универсальный" - считается что оптимизатор умнее и лучше знает что ему надо ;)

- как же быть с результатами тестирования? проведенными _Lynx_
Почему "умный" отимизатор не додумался их оптимизировать и вывести равное время..? :confused:

Стоит отметить что запросы EvroStandart и nikotano различаються. В наведеном примере они вернут одинаковый результат. Но н-р, если не указывать професию (тоесть поставить Null) у юзера, то запрос EvroStandart его выберет, а nikotano - нет.

В любом случае более правильным подходом в таких случаях (обьединения таблиц), лучше исспользовать джоины. И не только в соображениях производительности, но и в восприятии запроса человеком. Запросы с джоинами более читабельные (особенно если нужно обьединять несколько таблиц + разнообразные условия по выборке)

Gunslinger
Не согласен!!! запрос nikotano болиее универсальный и логически верный. Зачем нам записи пиплов без професий... ето раз.
Во вторых запросы через джоин болиее сложны в чтение
В третьих если юзать движок без внешн. ключей, таким образом ожно добавить ищо один пункт к однозначности запесей.

yan_kos
А что насчет теста _Lynx_??? Полностью согласен с Gunslinger.

В vbulletin повсеместно, например, используются join. Был один запрос как у nikotano, так в новой версии mysql он стал приводить к ошибке.

Прогнал все три запроса по два раза в IBExpert.
Firebird 1.0.2.
Записей в основной таблице > 1100000, во второй ~ 350000.
Вот результаты:

nikotano
_Lynx_
EvroStandart
Система:
Windows XP Prof
Intel P4 2.4 GHz, 512RAM.

Это решается при помощи внешнего ключа.

Потому! Это зависит от нескольких параметров:
какие данные задействованы в тесте (наполненность таблиц)
что за сервер - оптимизаторы "умные" поразному, одни больше, другие меньше ;)
Какие ключи/индексы есть и в каком состоянии.
И т.п.
Я имел ввиду, что при равных условиях результаты будут близки.
Но один "универсальнее" - больше дает свободы оптимизатору, соответственно переносимее с платформы на платформу и менее зависит от данных и структуры.

PS: Погляди на среднее время фетча в предыдущем письме...

Если не надо то вместо Left join пишем inner join, и не будет здесь пиплов без професий. Тоесть всего-то меняем одно слово, а если нам вдруг понадобяться пиплы без професий, то в запросе nikotano придеться добавить еще одно условие, что менее универсально согласитесь.

Вот как раз легче в чтении джоины, так как именно по ним мы видим какие таблицы связываються и по каким условиям. Да, если нам всего-то надо связать две таблицы без каких либо условий, то это значения не имеет. А если нам надо связать шесть таблиц + разнообразные критерии отбора, то как раз джоины намного более читабельны
Всмысле?

Внешний ключ + NOT NULL.
Неточно выразился.

NOT NULL тебе не даст возможность ввести нулловое значение (и внешний ключ тут ни при чем), а иногда как раз нуловое и надо. Даже в нашем случае можно сказать, н-р, что если нулл, тогда значит професия не указана.

Логично.
Но я обычно вношу системную запись "Не указано" с идентификатором 0 и ставлю 0 как дефолтовое значение.

Ну это дело вкуса.

Позволь не согласиться.
Как раз условия в запросе более универсальны при переносе между разными платформами/версиями/и т.п.
Кроме того куча софта, использующего QBE умеет парсить/модифицировать именно условия.
Ну и кроме прочего, говоря join ты указываешь оптимизатору что к чему цепляется (left\right join). Что в общем случае не универсально.

PS: заметь - я не говорю, что join это плохо, сам пользуюсь ;) но речь о универсальности идет, а это другая песня...

Я вот всегда думал что джоины - это стандарт ANSI, а значит должен поддерживаться всемя платформами/версиями/и т.п. или это не так?

Подскажите пожалуйста, с чего можно и нужно начать изучать SQL, :idontnow: заранее спасибо! :help:

Мартин Грубер. Понимание SQL.
Книга просто супер (вышла в 93 году).
Можно пользоваться и как учебником, и как справочником.
Поищи в Интернете. Должна быть.

Так-то оно так, и поддерживается всеми, только вот "диалекты" бывают разные. Сталкивался я пару раз с тем, что чисто синтаксически написание отличается. А вот с WHERE ни разу проблем не было ;)

..?
 

Ладно терь все это знают, а как быть если нужно выбрать разные записи с разных таблиц да еще и с нескольких баз ЗА ОДНО обращение к базе (один запрос) ??? :confused:
(для Mysq)

За мыскль не поручусь, но в нормальных серверах запросы к разным таблицам интегрируются либо через UNION, если структура одинакова или ее можно "усреднить", либо хранимыми процедурами. Ну бывают еще варианты с представлениями (VIEW).
Что касаемо запросов к разным базам, то обычно для серверов, где понятие "база" существует, такие штуки решаются многозвенкой, а где не существует - поддерживается самим сервером...

Проблемма:
Есть прога, к базе данных которой я могу подключиться при помощи ibExpert (установился с прогой, есть логин, пароль). Где что храниться в базе разобрался сам. Необходимо в одну из таблиц периодически добавлять несколько записей. В ручном режиме сделать это могу.
Хотелось бы автоматизировать процесс.
1 Я не знаю где, в каком разделе можно писать скрипты и как их сохранить
2 Сам скрипт.
таблица comment. поля cart (числовое) и dDate (дата-время) остальные не важны

Сначала надо выбрать данные за какой то период по полю dDate и по полю cart=3. Сделать копию этих данных и заменить поле cart на значение 4. Остальные поля соответственно оставить как в источнике.

Подсобите плиз

Непонятно что за база, ибо ibexpert с разными работать может.
Предположу, что это interbase/firebird.

Тогда по второму вопросу - запрос выглядит примерно так:где D1 и D2 - параметры или значения дат нужного периода

По первому вопросу сложнее - скрипты как правило это обычные текстовые файлы. Другое дело как их выполнять - в самой базе нет самоисполняемых механизмов. Все действия инициируются извне какой-либо программой. Например консольной утилитой ISQL входящей в состав firebird, или ibexpert`ом, или твоей прикладной программой. В составе ibexpert`а есть утилита ibscript, можно попробовать ее зашедулить.
А если в базе есть хранимые процедуры или триггеры, которые периодически вызываются твоей программой, можно включить этот запрос туда. Вот только запрос у тебя с параметрами получается... Нужно либо вычислять эти параметры "на лету", либо передавать их. ну и наконец можно просто скидать небольшую программку которая будет выполнять нужные тебе действия. Это в общем. Более конкретные рекомендации требуют более конкретного изучения вопроса.