SQL

[d4s]

А вот скажет -- разница при обучении сабжу версии начала 2000-х и современных -- она действительно колоссальная?

Comments

[falcrum.livejournal.com]

Мне кажется, не слишком.

[shaman237.livejournal.com]

SQL92 живее всех живых
а дальше уже плюшки конкретной базы

[sponeg.livejournal.com]

+1.

[w-human.livejournal.com]

+1000 и даже больше

[captain-hell.livejournal.com]

Вот Шаман, Демид нас на первом курсе тоже кашкой кормил, как ПОИТ и Информатику паскалем?
Или мы влезли в особенности x86 по самые гланды, а?

[captain-hell.livejournal.com]

SQL без привязки к базе - полное говно, которое не пригодится в жизни... Разница настолько разница, что...

[sponeg.livejournal.com]

в целях обучения только и подходит..

[captain-hell.livejournal.com]

Например:

Оракель
WITH t AS
(SELECT 1 ID, 'A' i1, 'X' i2, 'B' i3 FROM dual UNION ALL
SELECT 2 ID, NULL i1, 'X' i2, 'Z' i3 FROM dual UNION ALL
SELECT 3 ID, NULL i1, 'X' i2, 'B' i3 FROM dual UNION ALL
SELECT 4 ID, 'A' i1, NULL i2, 'B' i3 FROM dual UNION ALL
SELECT 5 ID, 'A' i1, NULL i2, NULL i3 FROM dual)
, t2 AS
(
SELECT ID, i1, i2, i3, CONNECT_BY_ROOT ID start_id FROM t
CONNECT BY NOCYCLE
((nvl(i2,0)=PRIOR nvl(I2,0) AND nvl(i3,0)=PRIOR nvl(i3,0) AND i1 IS NULL)
OR (nvl(i1,0)=PRIOR nvl(I1,0) AND nvl(i3,0)=PRIOR nvl(i3,0) AND i2 IS NULL)
OR (nvl(i1,0)=PRIOR nvl(I1,0) AND nvl(i2,0)=PRIOR nvl(i2,0) AND i3 IS NULL))
AND LEVEL<=2 -- одного уровня иерархии достаточно
AND ID!=PRIOR ID)
SELECT
MAX(ID) KEEP (DENSE_RANK FIRST ORDER BY start_id) ID,
MAX(i1) KEEP (DENSE_RANK FIRST ORDER BY start_id) i1,
MAX(i2) KEEP (DENSE_RANK FIRST ORDER BY start_id) i2,
MAX(i3) KEEP (DENSE_RANK FIRST ORDER BY start_id) i3
FROM t2
HAVING COUNT(start_id)=1
GROUP BY start_id;

Майкрософт:

select x.n2, datediff(mi, time_out,case when time_in < time_out then time_in+1 else time_in end)
from trip t
inner join company cp on cp.id_comp=t.id_comp
inner join
(select distinct q.n2 from
(select a.name as n1, b.name as n2, count(b.plane) as c from (select name, plane
from company c
inner join trip t on c.id_comp=t.id_comp
group by name, plane) a
inner join (select name, plane
from company c
inner join trip t on c.id_comp=t.id_comp
group by name, plane) b on a.name<>b.name and a.plane=b.plane
group by a.name, b.name) q
where q.c=(select count(distinct plane)
from company c
inner join trip t on c.id_comp=t.id_comp
where name=q.n2)) x on x.n2=cp.name
where datediff(mi, time_out,case when time_in < time_out then time_in+1 else time_in end) <= ALL(
select datediff(mi, time_out,case when time_in < time_out then time_in+1 else time_in end)
from trip t
inner join company cp on cp.id_comp=t.id_comp
inner join
(select distinct q.n2 from
(select a.name as n1, b.name as n2, count(b.plane) as c from (select name, plane
from company c
inner join trip t on c.id_comp=t.id_comp
group by name, plane) a
inner join (select name, plane
from company c
inner join trip t on c.id_comp=t.id_comp
group by name, plane) b on a.name<>b.name and a.plane=b.plane
group by a.name, b.name) q
where q.c=(select count(distinct plane)
from company c
inner join trip t on c.id_comp=t.id_comp
where name=q.n2)) x2 on x2.n2=cp.name and x2.n2=x.n2)

group by x.n2, datediff(mi, time_out,case when time_in < time_out then time_in+1 else time_in end)

[metaclass.livejournal.com]

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

[avr-forever.livejournal.com]

Базовые конструкции те же. Небазовые --- это обычно СУБД-зависимые расширения.

[captain-hell.livejournal.com]

То-то мы для каждой базы переписываем генераторы этих "базовых" конструкций ;-)))

[max-posedon.livejournal.com]

Ага, конструкции те же, а query plan-ы совершенно разные:

SELECT field1 FROM table1 WHERE field2 IN ( SELECT field2 FROM table2 );

Вот эта базавая конструкция работает совершенно по разному в MySQL и PosgtreSQL, хоть и выдаёт одинаковый результат.

[metaclass.livejournal.com]

Нет. В конкретных реализациях и расширениях разница знатная, а сам по себе SQL остался как был.

[d4s.livejournal.com]

хм... просто на... хм... одном мероприятии... была такая безапеляционная фраза, про то, что дескать "бедных студентов заставляют учить sql по махровым методичкам аж от начала 2000-х". Меня покоробило -- решил спросить, а тут смотрю единого мнения и нету ;-) Хотя с тобой всецело согласен -- при понимании фундаментальных принципов остальное освоится достаточно быстро.
Это как в C, имхо, не смотря на то, что на дворе стандарт '11 -- вещи, изученные еще в 90-х не утратили своей актуальности.
Глянул википедию по sql -- я правильно понял, что со времен стандарта '99 фундаментальных изменений не вносилось?

[max-posedon.livejournal.com]

Я более того скажу, обучение сабжу между современными MySQL и PostgreSQL - разница колоссальная.

[captain-hell.livejournal.com]

Еще бы, за каждым условным словом лежит не просто абстракция, а и то, как данные лежат, как вынимаются, как обрабатываются. И это еще в условиях конкурентности.

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

[captain-hell.livejournal.com]

Дэн, учи одному диалекту, но полностью. Пускай это будет DB2, Postgresql, Oracle, MSSQL. Не важно ;-)

Главное не mysql, это прививает неверные понимания баз данных, транзакций, целостности данных и вообще)

[inhate.livejournal.com]

А что такого плохого в MySQL как в БД для обучению основам РСУБД?

[tzirechnoy.livejournal.com]

Никакой, труды Мейера и Дейкстры не менялись ужэ два десятка лет.

[captain-hell.livejournal.com]

т.е. вариант, когда для поиска надо склеить все столбцы в одну строку и полностью убить нормальность ими тоже рассмотрен?

[enternet.livejournal.com]

Нет никакой разницы. Пусть начинающие учатся думать соединениями. Научатся, всё остальное будет легко.

[shaman237.livejournal.com]

Дэн, знатно ты говнецо на вентилятор кинул ;)

[d4s.livejournal.com]

"да я просто спросил!" (с) ;-)
http://d4s.livejournal.com/210142.html?thread=1064926#t1064926

[jdevelop.livejournal.com]

SQL не нужен

[d4s.livejournal.com]

+1 ;-)

[darafei praliaskouski (from livejournal.com)]

SQL, да.
Кто там хочет страшный SQL из продакшена? :)

http://code.google.com/p/kothic/source/browse/src/komap.py#217

https://github.com/Komzpa/Mapnik-Sheets/blob/master/3d-buildings/3dbuil.xml#L55

[max-posedon.livejournal.com]

SQL не Дискретная математика, в курсе теории дискретной математики нужно учить множествам, кортежам, доменам, пересечению объеденению, декартовому произведению и т.д.

В рамках SQL нужно учить _практическим_ основам. У нас в вузе полугодовой курс был на базе DB2, не худший вариант. На данный момент идельный считаю PostgreSQL. Почему? да хотябы потому, что query plan-ы там analyze печает алгоритмически понятные.

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

[tzirechnoy.livejournal.com]

>SQL не Дискретная математика

Безусловно. SQL -- это реляцыонная алгебра, а никакая не дискретная математика.

[sponeg.livejournal.com]

Вот уж Дэн тролль.. вот уж подбросил :)

[norguhtar.livejournal.com]

Нет никакой разницы если учить не SQL, а реляционную алгебру и общую теорию по СУБД. Я к примеру считаю весьма годным материалом вот этот курс лекций
http://citforum.ru/database/osbd/contents.shtml

В этом курсе про сам SQL начинают говорить ну очень потом.