запросы на sql
мануал по мускулю - там все это написано на примере собак или каких-то зверей
нету такого мануала под рукой, к сожалению.
можешь код написать?
можешь код написать?
или где этот мануал в инете скачать.
или кинь его на мыло bk.ru
или кинь его на мыло bk.ru
что никто не петрит?
или где этот мануал в инете скачать.находится в гугле по запросу mysql manual элементарно
вывести список сотрудников, у которых заработная плата выше:среднего по компании;че-нить типа
select EmployerFullName, avg(Salary) from Employers
group by EmployerFullName having salary > avg(Salary)
среднего в рамках отдела, где работает сотрудник.тот же запрос только будет inner join с Deps
вывести те отделы, где работает хотя бы один сотрудник.select distinct DepName from Employers e
inner join Deps d on e.DepID=d.DepID
не то, к сожалению.
я помню код приблизительно, там таблица сама с собой сравнивается.
я помню код приблизительно, там таблица сама с собой сравнивается.
давай таблицы ща напишу 
запросы по первой прикидке корректны
запросы по первой прикидке корректны
таблицы нарисую схематично, куда картинку отправить?
пость сюда
А я бы так сделал:
>>вывести список сотрудников, у которых заработная плата выше:
>>среднего по компании;
>>среднего в рамках отдела, где работает сотрудник.
вывести те отделы, где работает хотя бы один сотрудник.
>>вывести список сотрудников, у которых заработная плата выше:
>>среднего по компании;
select Name from Employee where Salary > (select avg(Salary) from Employee)
>>среднего в рамках отдела, где работает сотрудник.
select Name from Employee e where Salary > (select avg(Salary) from Employee where Department=e.Department)
вывести те отделы, где работает хотя бы один сотрудник.
select Name from Department d where (select count(*) from Employee where Department=d.Id) >= 1
мой запрос третий отработает в разы быстрее 
Ага, человеку так гораздо понятнее, а парсеру запросов придётся думать (ему это преобразовывать в те же джойны, внутри-то он с ними работает). Это-то неважно, но не все парсеры такое понимают (это не по стандарту вообще-то). Возможно, с такими запросами вообще работает только mysql (точно не скажу).
Возможно, с такими запросами вообще работает только mysql (точно не скажу).мсскл тоже такое схавает и постгрес схавает
За парсер запросов бабки заплачены. Пусть работает.
Я это проверил на Access-е.
Существует более убогая БД?
Я это проверил на Access-е.
Существует более убогая БД?
Зато если задача встанет "не менее двух сотрудников", я поменяю один символ, а ты перепишешь весь запрос.
Интересно, кстати, что получится...
Интересно, кстати, что получится...
подъебал, но обычно таких задач не стоит в данном случае.
заметь я решал конкретную задачу а ты ее расширение
заметь я решал конкретную задачу а ты ее расширение
Хорошо бы сравнить стоимость твоего варианта и варианта 'a.
Что-то у меня такое чувство, что как ты лучше не писать - по началу может это более понятно, но будет не везде работать (напр. BDE
) и, после получения некоторого опыта, вариант 'a по-моему лучше воспринимается.
Что-то у меня такое чувство, что как ты лучше не писать - по началу может это более понятно, но будет не везде работать (напр. BDE
) и, после получения некоторого опыта, вариант 'a по-моему лучше воспринимается.Хорошо бы сравнить стоимость твоего варианта и варианта 'a.нужна база. и взвесить можно. но бля буду inner join сработает быстрее чем подзапрос
и быстрее что очевидно чем
select distinct DepName from Employers e
left join Deps d on e.DepID=d.DepID
where d.DepName is not null
разница на небольших данных не заметна. а запросы вернут одно и тоже
select distinct DepName from Employers e
left join Deps d on e.DepID=d.DepID
where d.DepName is not null
разница на небольших данных не заметна. а запросы вернут одно и тоже
но бля буду inner join сработает быстрее чем подзапросВот такой запрос будет быстрее, ибо будет преобразовываться в соединение и соединятся будет меньше записей.
select DName from Dept where Deptno in (select distinct Deptno from Emp )
А твои запросы с inner join и left join полностью эквивалетны.
Запрос `а скорее всего тоже будет быстрее, по крайней мере Oracle показывает меньшую стоимость. 
Существует ANSI SQL. То, что какие-то *sql-серверы поддерживают такие запросы - ещё не означает, что эти запросы - на sql.
Подзапросы как минимум в ANSI SQL 1992 есть. За 15 лет можно было научится их поддерживать.
Мой суппортить попроще будет
Я от SQL-я стараюсь держаться подальше, потому глаз у меня не наметан и кучу LEFT/INNER джойнов, идущих вперемешку, я воспринимаю строго негативно. Причины:
1. В них надо долго втыкать, чтобы понять общий смысл запроса.
2. Они решают не поставленную задачу "найти таких-то чуваков", а задачу "из декартова произведения ... выбрать элементы, удовлетворяющие ..."
3. Никто не даст гарантии, что запросы с 6-10 джойнами (постоянно такие в работе попадаются) правильны + тестированию они не поддаются из-за огромного количества граничных условий (null - not null, exists - not exists) и единственного в каждый момент времени набора тестовых данных.
Реляционная алгебра - это, конечно, хорошо и круто, но я считаю, что предпочтительнее СУБДе как можно более высокоуровнево объяснить, что от нее реально надо, а она внутри пусть преобразует, оптимизирует и т.п.
В конце концов, ее делали умные мужики n человеко-лет, за нее заплачены бабки, дебагу поддаются только простейшие SQL-запросы, а на работе лучше выйти погулять по парку, чем сидеть искать баги (в том смысле, что мало багов - это для всех хорошо).
1. В них надо долго втыкать, чтобы понять общий смысл запроса.
2. Они решают не поставленную задачу "найти таких-то чуваков", а задачу "из декартова произведения ... выбрать элементы, удовлетворяющие ..."
3. Никто не даст гарантии, что запросы с 6-10 джойнами (постоянно такие в работе попадаются) правильны + тестированию они не поддаются из-за огромного количества граничных условий (null - not null, exists - not exists) и единственного в каждый момент времени набора тестовых данных.
Реляционная алгебра - это, конечно, хорошо и круто, но я считаю, что предпочтительнее СУБДе как можно более высокоуровнево объяснить, что от нее реально надо, а она внутри пусть преобразует, оптимизирует и т.п.
В конце концов, ее делали умные мужики n человеко-лет, за нее заплачены бабки, дебагу поддаются только простейшие SQL-запросы, а на работе лучше выйти погулять по парку, чем сидеть искать баги (в том смысле, что мало багов - это для всех хорошо).
В задаче про скорость ничего не сказано.
Будет тормозить - позовем грамотного ораклиста, пусть оптимизит
Будет тормозить - позовем грамотного ораклиста, пусть оптимизит
В общем и целом +1.
В последнее время сам склоняюсь к этому мнению.
В последнее время сам склоняюсь к этому мнению.
В конце концов, ее делали умные мужики n человеко-лет
если не ошибаюсь основатель оракла в 10ке форбса
where (select count(*) from Employee where Department=d.Id) >= 1а почему не
where exists (select * from Employee where Department=d.Id)
и короче и понятнее
Потому что если вопрос будет "не менее двух человек", exists начнет усложняться.
Более того, я думаю, что оптимизатор должен сгенерить абсолютно одинаковые запросы с exitst и count(*)>0.
Более того, я думаю, что оптимизатор должен сгенерить абсолютно одинаковые запросы с exitst и count(*)>0.
А вот как это делается в кошерной БД:
emps:([id:til 10] name: -10?`4; sal: 10?1000; dep: 10?4)
id| name sal dep
--| ------------
0 | kgoi 530 2
1 | bafh 779 0
2 | inba 996 1
3 | iecf 629 1
4 | mhjf 190 2
5 | keap 859 3
6 | nafo 401 2
7 | ibhh 766 0
8 | glmk 386 2
9 | bhfm 642 2
deps:([id: til 6] name: -6?`2)
id| name
--| ----
0 | kp
1 | fh
2 | ei
3 | md
4 | gm
5 | kg
среднего по компании:
select name from emps where sal>avg(sal)
среднего в рамках отдела, где работает сотрудник:
select name from emps where sal>(avg;sal) fby dep
вывести те отделы, где работает хотя бы один сотрудник:
select name from deps where not id in exec distinct dep from emps
че за бд?
kdb+
Простой Syntax Sugar в языке запросов.
Хотя удобно, не спорю!
Хотя удобно, не спорю!
Простой Syntax Sugar в языке запросов.Нет. Это пример того, как работают умные люди, а не низкооплачиваемые индусы (как в Оракл)
кстати ахуенное дб. седня в действии попробовал. КЛАСС. почитал также послужной список сотрудников компании тоже впечатляет
кстати ахуенное дб. седня в действии попробовал. КЛАСС. почитал также послужной список сотрудников компании тоже впечатляетЯ и говорю, когда продукт сделан профессионально и с любовью, так сказать, с ним просто приятно работать. А где ты ее попробовал?
А где ты ее попробовал?просто покапался с ней. реальные задачи не делал. кстати а как у нее с клиентами например из того же дотнета
кстати а как у нее с клиентами например из того же дотнетаЕсть native интерфейс и для C# и для Java. Т.е. передать/принять данные просто.
Можно через http еще работать.
Оставить комментарий
niki1236333
нужен код на типовые запросы:вывести список сотрудников, у которых заработная плата выше:
среднего по компании;
среднего в рамках отдела, где работает сотрудник.
вывести те отделы, где работает хотя бы один сотрудник.