Курс по SQL

[rockclimber]

Purus_Idiota в сообщении #1322495 писал(а):

а что это за таблица такая "dual" в запросе "SELECT true FROM dual"? Откуда она взялась или вы её сами создали?

Это такая специальная таблица в Oracle. Единственная таблица, которая удостоена аж отдельной статьи в Википедии: https://en.wikipedia.org/wiki/DUAL_table
Все дело в том, что концептуально в Oracle принято, что данные нельзя взять из ниоткуда, надо обязательно брать из какого-то источника. Поэтому для запросов вида 1 + 1, или запросов текущего пользователя, времени и прочего применяется эта таблица.

select 1 + 1 from dual;
select current_user from dual;
select current_date from dual;

В PostgreSQL можно брать из ниоткуда:

select 1 + 1;
select current_user;
select current_date;

Purus_Idiota в сообщении #1322495 писал(а):

И как проверить вот это вот "NULL OR True" без чего-либо вспомогательного?

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

[realeugene]

Собственно, по операциям реляционной алгебры. Перечислю основные простейшие. Эти и выразимые через них более сложные операции в некотором виде и с некоторыми расширениями/модификациями поддержаны SQL. Далее предполагается, что ячейки таблиц не содержат значение NULL.

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

Первая операция - это переименование столбцов. Можно взять таблицу и построить из неё другую таблицу, просто, переименовав её столбцы. Имена столбцов, разумеется, должны остаться уникальными.

Вторая операция - это объединение двух таблиц. Можно взять две таблицы с совпадающими именами столбцов и совпадающими доменами у пар столбцов с одинаковыми именами и получить таблицу, состоящую из объединения строк исходных таблиц. Полные дубликаты строк, при этом, выкидывают, а ключи исходных таблиц могут перестать быть ключами в результирующей таблице.

Третья операция - это пересечение двух таблиц. Аналогично объединению, только с пересечением множеств строк.

Четвёртая операция - это проекция. Выбираем из таблицы часть её столбцов. Для одной таблицы строится новая таблица из значений её строк из подмножества её столбцов и выкидываются образовавшиеся дубликаты.

Пятая операция - это декартово произведение двух таблиц. У двух таблиц должны быть различны имена всех столбцов. Строится таблица, состоящая из объединения столбцов исходных таблиц, а строки которой состоят из всех возможных сочетаний значений одной строки из первой таблицы и одной строки из второй таблицы.

Шестая операция - это ограничение. Берётся таблица и оставляются в ней только строки, удовлетворяющие некоторому предикату (логическому условию на значение строки).

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

Вот теперь можно и переходить к запросам SQL, как мне кажется.

[rockclimber]

realeugene в сообщении #1322468 писал(а):

Но как можно отделить язык запросов от модели представления данных?

Да легко! Вот таблицы, вот так мы берем из них данные, а вот почему они так структурированы - оставить на потом.
Я собирался сказать пару слов о теории, потом про нормальные формы (первые три), и ограничения, потом уже точно можно углубляться в SQL.
Только со временем на выходных вышел облом.

[realeugene]

rockclimber в сообщении #1322525 писал(а):

потом про нормальные формы (первые три),

Пятая нормальная форма - наше всё.

[beroal]

rockclimber в сообщении #1322456 писал(а):

SQL как язык запросов тесно связан с реляционной моделью данных, которая имеет под собой какую-никакую, а математическую теорию … В общем, если никто не возражает, я буду сразу объяснять простые вещи, чтобы не затягивать "скучную теоретическую часть” и дать возможность слушателям попрактиковаться.

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

[rockclimber]

beroal в сообщении #1322736 писал(а):

rockclimber в сообщении #1322456 писал(а):

SQL как язык запросов тесно связан с реляционной моделью данных, которая имеет под собой какую-никакую, а математическую теорию … В общем, если никто не возражает, я буду сразу объяснять простые вещи, чтобы не затягивать "скучную теоретическую часть” и дать возможность слушателям попрактиковаться.

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

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

[beroal]

rockclimber в сообщении #1322740 писал(а):

Проблема в том, что там не над чем напрягать мозг. Реляционная алгебра по сложности соответствует ну максимум дифференцированию/интегрированию, изложенному на школьном уровне.

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

Abiteboul, Serge, Richard Hull, and Victor Vianu. Foundations of Databases. Reading: Addison-Wesley, 1995. Print.

[rockclimber]

beroal в сообщении #1322751 писал(а):

rockclimber в сообщении #1322740 писал(а):

Проблема в том, что там не над чем напрягать мозг. Реляционная алгебра по сложности соответствует ну максимум дифференцированию/интегрированию, изложенному на школьном уровне.

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

Abiteboul, Serge, Richard Hull, and Victor Vianu. Foundations of Databases. Reading: Addison-Wesley, 1995. Print.

А мне кажется, вам стоит перечитать стартовый пост, примечание 3.

Хотите напрячь мозг - вот, напрягайте: «Алгоритм разбиения на группы двух связанных множеств» (я решил в итоге ).

[mustitz]

realeugene в сообщении #1322498 писал(а):

У строк в таблице нет ни имён, ни номеров (если только номер строки не добавили специально как отдельный обычный столбец с числом - номером строки, но и тогда нет никаких гарантий, что они будут идти в порядке и без пропусков).

В некоторых СУБД есть ROWID или аналоги.

realeugene в сообщении #1322498 писал(а):

В реляционной модели все строки одной таблицы должны быть попарно различными, т. е. таблица - это множество значений строк. Так как все строки в таблице уникальны, идентификатором строки служит само значение всех ячеек этой строки. В отдельных практических случаях в СУБД используются и мультимножества строк с очевидными сложностями по идентификации отдельных строк и повторами.

Либо для решения надо использовать ROWID.

[realeugene]

mustitz в сообщении #1322870 писал(а):

Либо для решения надо использовать ROWID.

Описывалась реляционная модель. В том же SQLite по умолчанию добавляется такой скрытый столбец для rowid, но можно создать таблицу и без него.

[rockclimber]

mustitz в сообщении #1322870 писал(а):

realeugene в сообщении #1322498 писал(а):

У строк в таблице нет ни имён, ни номеров (если только номер строки не добавили специально как отдельный обычный столбец с числом - номером строки, но и тогда нет никаких гарантий, что они будут идти в порядке и без пропусков).

В некоторых СУБД есть ROWID или аналоги.

Давайте не будем запутывать читателей больше, чем нужно. Реляционная модель данных предполагает, что таблица - это неупорядоченное множество строк. Сами строки, конечно, лежат на диске в каком-то порядке, но модель данных не накладывает на этот порядок никаких ограничений. Соответственно, если пользователь хочет получить строки в упорядоченном виде, он должен явно указать, каким образом упорядочить элементы. Если способ не указан явно, СУБД имеет полное право возвращать строки в любом порядке, в том числе каждый раз в разном.
Что касается ROWID (если мы про Oracle говорим) и аналогов, это идентификатор, присваиваемый строке движком СУБД. Он, конечно, имеет некоторое отношение к физическому порядку хранения, но слишком полагаться на него нельзя, и СУБД не гарантирует его неизменность.

mustitz в сообщении #1322870 писал(а):

realeugene в сообщении #1322498 писал(а):

В реляционной модели все строки одной таблицы должны быть попарно различными, т. е. таблица - это множество значений строк. Так как все строки в таблице уникальны, идентификатором строки служит само значение всех ячеек этой строки. В отдельных практических случаях в СУБД используются и мультимножества строк с очевидными сложностями по идентификации отдельных строк и повторами.

Либо для решения надо использовать ROWID.

Чтобы решить задачу, ее надо сформулировать. realeugene вроде бы говорил об идентификации строки? В реляционной модели данных идентификатором строки является первичный ключ. ROWID является идентификатором физического места хранения, но СУБД не гарантирует его неизменность, а еще оно не имеет отношения к модели данных.

[mustitz]

rockclimber
Есть гарантия неизменности в пределах сессии. Иначе зачем бы он вообще был нужен?

[realeugene]

mustitz в сообщении #1322924 писал(а):

Есть гарантия неизменности в пределах сессии. Иначе зачем бы он вообще был нужен?

Ещё раз: в реляционной модели его нет. Это - расширение в некоторых СУБД. Которое может быть реализовано по-разному.

[rockclimber]

mustitz в сообщении #1322924 писал(а):

Иначе зачем бы он вообще был нужен?

Без понятия, зачем. Единственное существенное свойство, если верить документации - "They are the fastest way to access a single row". То есть выжать все соки (в плане производительности), когда другие средства исчерпаны? Не знаю, ни разу не сталкивался с какой-либо необходимостью использовать этот столбец. Ну еще APEX (и, возможно, другие оракловые инструменты) может использовать ROWID вместо первичного ключа, если пользователь забыл его сделать в таблице.

[mustitz]

rockclimber в сообщении #1322931 писал(а):

mustitz в сообщении #1322924 писал(а):

Иначе зачем бы он вообще был нужен?

Без понятия, зачем. Единственное существенное свойство, если верить документации - "They are the fastest way to access a single row". То есть выжать все соки (в плане производительности), когда другие средства исчерпаны?

Если писать бизнес-логику на PL/SQL, то использовать первичные ключи — закладывать алгоритм маляра Шлемиэля. Поиск по первичному ключу у нас $O(\ln n)$, и мы на это никак не можем повлиять. Так что если мы где-то сохраняем id, потом выполняем по ним поиск, то... накапливаются потери производительности... Поэтому ROWID очень полезен для этого. Простой пример — параллельная обработка строк таблицы:

Используется синтаксис SQL

dbms_parallel_execute.create_chunks_by_rowid(
        task_name => 'xxx',
        table_owner => USER,
        TABLE_NAME => 'yyy',
        by_row => TRUE,
        chunk_size => 1000);

    dbms_parallel_execute.run_task(
        task_name => 'xxx',
        sql_stmt => 'update /* +rowid(yyy) */ yyy set x = complicate_calculations() where rowid between :start_id and :end_id',
        language_flag => DBMS_SQL.NATIVE,
        parallel_level => 16);

-- 27.06.2018, 15:56 --

realeugene в сообщении #1322929 писал(а):

Ещё раз: в реляционной модели его нет. Это - расширение в некоторых СУБД. Которое может быть реализовано по-разному.

Ну... реляционная модель это теоретическая абстракция, в которой много чего нет :) И строить курс SQL основываясь исключительно на ней... Ну не знаю...