Курс по SQL

[iifat]

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

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

Да вроде бы нет. Как понимаю, для SQLite есть соответствующая, уж не знаю, насколько удобная утилита.

[rockclimber]

Ну хорошо, если так. А если файл с данными и метаданные с комментариями содержит, то просто отлично.

[realeugene]

iifat в сообщении #1322283 писал(а):

Да вроде бы нет. Как понимаю, для SQLite есть соответствующая, уж не знаю, насколько удобная утилита.

И эта утилита называется sqlite3.exe, как это не удивительно.
Ну, как "удобная". Командно-строчный интерпретатор SQL. https://www.sqlite.org/cli.html

[arseniiv]

В любом случае она есть обёртка над библиотекой (я правильно понимаю, или они сделали что-то страшное в обход такой простой стратегии?), и можно всегда написать свою и поглядеть в чужие базы. Хм, а там есть шифрование? (Ой, простите за оффтоп.)

[iifat]

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

Командно-строчный интерпретатор SQL

Да вроде видел и графическое чего-то.

arseniiv в сообщении #1322330 писал(а):

Хм, а там есть шифрование?

Наверняка можно включить. Ну дык мы ж не взлом секретных баз обсуждаем, а инструмент отладки. Зная ключ, пароль и т.п...

[realeugene]

Зачем может потребоваться шифрование в однопользовательской СУБД? Полное шифрование диска в параноидальных случаях вполне спасет.

СУБД свободная, независимые графические утилиты, разумеется, для неё есть. Вот эта, например, успешно показывает локальную базу сообщений Скайпа: https://sqlitebrowser.org/

[realeugene]

http://www.sqlitetutorial.net/ - мне понравился. Выглядит, как хороший тьюториал для начинающих. С хорошей структурой и картинками. К тому же, SQLite выглядит несомненно доступнее и проще в освоении новичками, чем "взрослые" СУБД.

(Оффтоп)

В SQLite нет жесткой типизации доменов столбцов. Наверное, типизация - это не самое главное в SQL. А что же самое главное? Может быть, нужно начинать с самой реляционной модели?

[rockclimber]

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

Наверное, типизация - это не самое главное в SQL. А что же самое главное? Может быть, нужно начинать с самой реляционной модели?

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

Также очень хотелось бы, что те люди, которые "записались на курс”, зашли сюда и оставили хоть какие-нибудь отзывы. А то непонятно, они все еще тут или уже нет. А с теми, кто тут, тоже непонятно. Они, судя по вопросам, уже знают больше, чем написано.

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

В SQLite нет жесткой типизации доменов столбцов.

А можно подробнее, что вы под этим понимаете?

[arseniiv]

(Оффтоп)

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

А можно подробнее, что вы под этим понимаете?

Так понял, имелось в виду, что в одном столбце могут храниться и числа, и строки, и что угодно. Однако совершеннейше уверен, что это не должно быть правдой.

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

Зачем может потребоваться шифрование в однопользовательской СУБД?

Затем, что файл .sqlite с базой вот он, открывай кто хочет. Некоторым программам может быть полезно, чтобы в их базе/базах могли копаться только некоторые.

[realeugene]

arseniiv в сообщении #1322462 писал(а):

Затем, что файл .sqlite с базой вот он, открывай кто хочет. Некоторым программам может быть полезно, чтобы в их базе/базах могли копаться только некоторые.

Существует расширение "SQLite Encryption Extension" - https://www.sqlite.org/see/doc/trunk/www/readme.wiki Но оно не фришное.
Если рядом с базой лежит приложение, открывающее стандартный интерфейс секретным известным ему ключом, то несложно вытащить и ключ, как мне кажется. В общем, если нет выделенного сервера для СУБД, то секретность не может быть полноценной.

[kotenok gav]

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

А то непонятно, они все еще тут или уже нет.

Я почти уже нет.

[realeugene]

arseniiv в сообщении #1322462 писал(а):

Так понял, имелось в виду, что в одном столбце могут храниться и числа, и строки, и что угодно. Однако совершеннейше уверен, что это не должно быть правдой.

А это правда: https://www.sqlite.org/datatype3.html

Цитата:

In order to maximize compatibility between SQLite and other database engines, and so that the example above will work on SQLite as it does on other SQL database engines, SQLite supports the concept of "type affinity" on columns. The type affinity of a column is the recommended type for data stored in that column. The important idea here is that the type is recommended, not required. Any column can still store any type of data.

-- 25.06.2018, 14:27 --

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

Но это будет уже курс далеко не только по SQL.

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

Наверное, нужно сказать, что есть такая сущность - "база данных" (БД), которая обычно перманентно хранит интересные пользователю в контексте определённой решаемой им задачи массивы данных (если БД не временная, организованная только в оперативной памяти). Чтобы работать с данными нужно подключиться к БД, выполнить желаемые операции по извлечению/ изменению данных в БД и потом отключиться. Все операции манипулирования с данными выполняются в рамках одной определённой БД (за исключением архивирования/импорта/экспорта). В реляционной БД вся хранимая информация организована в виде некоторого количества таблиц и связанных с ними индексов. В том числе, и служебная информация хранится в служебных же таблицах. Индексы - это вспомогательные таблицы, которые служат исключительно для ускорения выполнения запросов к БД. Как именно организовано перманентное хранение таблиц БД зависит от устройства Системы Управления Базой Данных (СУБД). В SQLite все таблицы хранятся в рамках одного файла, разбитого внутри на страницы - единицы хранения. В большинстве случаев пользователь СУБД не знает деталей хранения таблиц БД на диске: ему это не интересно до тех пор, пока не потребуется заняться оптимизацией/администрированием БД.

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

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

[arseniiv]

Понятно. Ну хорошо хоть рекомендуемый тип указать можно.

[Purus_Idiota]

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

Также очень хотелось бы, что те люди, которые "записались на курс”, зашли сюда и оставили хоть какие-нибудь отзывы. А то непонятно, они все еще тут или уже нет.

Всё ещё здесь, читают отзывы более опытных участников и пытаются не докучать глупыми вопросами типа: а что это за таблица такая "dual" в запросе "SELECT true FROM dual"? Откуда она взялась или вы её сами создали? И как проверить вот это вот "NULL OR True" без чего-либо вспомогательного?

[realeugene]

Продолжу про таблицы.

Таблица в реляционной СУБД - это, как ни удивительно, прямоугольная таблица. Которая состоит из столбцов и строк. Порядки столбцов и строк в таблице в общем случае не важны и могут изменяться со временем. Чтобы различать столбцы, каждому столбцу присваивается имя. У строк в таблице нет ни имён, ни номеров (если только номер строки не добавили специально как отдельный обычный столбец с числом - номером строки, но и тогда нет никаких гарантий, что они будут идти в порядке и без пропусков). Количество столбцов в таблице фиксировано (можно изменять, но это долго и иногда сложно), а количество строк не ограничено (ограничено только возможностями СУБД и аппаратуры).

В ячейках таблицы хранятся атомарные значения, которые могут быть числами, строками или даже бинарными чёрными ящиками. Множество всех возможных атомарных значений, которые могут быть записаны в ячейках таблицы в определённом столбце, называется доменом столбца. У различных столбцов могут быть различные домены. В SQLite домен универсальный для всех столбцов, так как типизация значений динамическая; в других СУБД обычно требуется аккуратно указывать домен для каждого столбца - тип его значений. Значения ячеек из одного домена можно непосредственно сравнивать друг с другом как минимум на равенство и, как следствие, можно сравнивать на совпадение различные строки одной таблицы. Некоторые домены могут содержать выделенное универсальное значение NULL - отсутствие значения. В других доменах это значение может быть запрещено.

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

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

-- 25.06.2018, 15:39 --

(Оффтоп)

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

Всё ещё здесь, читают отзывы более опытных участников и пытаются не докучать глупыми вопросами типа: а что это за таблица такая "dual" в запросе "SELECT true FROM dual"? Откуда она взялась или вы её сами создали? И как проверить вот это вот "NULL OR True" без чего-либо вспомогательного?

Простите, а вы с какой целью интересуетесь?

-- 25.06.2018, 15:51 --

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