Ответ 1
SQL - это теория множеств или, вернее, реляционная алгебра. Прочтите краткое руководство по этому вопросу. И научитесь думать в наборах, а не в процедурах.
С практической стороны существует четыре фундаментальных операции:
- выбирает, который показывает некоторую проекцию данных таблицы (ов)
- удаляет, удаляет некоторое подмножество строк таблицы,
- вставки, которые добавляют строки в таблицу,
- обновления, которые (возможно) изменяют данные в таблице
(Под подмножеством подразумевается любое подмножество, включая пустое множество, а не обязательно собственное подмножество.)
В любом месте я могу написать имя столбца в DDL (за исключением цели обновления), я могу написать выражение, которое использует имена столбцов, функции или константы.
select 1, 2, 3 from table вернет набор результатов "1 2 3", один раз для каждой строки в таблице. Если столбец с именем create_date имеет дату типа, а функция month возвращает номер месяца с датой, select month( create_date) from table покажет мне номер месяца для каждого create_date.
A where - предикат, который ограничивает выбранные или удаленные строки или обновляется для тех строк, для которых предикат является истинным. А где причина может состоять из произвольного числа предикатов, связанных логическими операторами and or и not. Подобно списку столбцов в select, я могу использовать имена столбцов, функции и константы в моем предложении where. Как вы думаете, какой результирующий набор возвращается из select * from table where 1 = 1;?
В запросе таблицы связаны соединением, в котором некоторые данные или ключ в одном связаны оператором с базой данных или ключом в другой таблице. Реляционный оператор часто является равенством, но на самом деле может быть любым двоичным оператором или даже функцией.
Таблицы связаны, как я уже упоминал выше, с ключами; строка в таблице может относиться к нулевой, одной или нескольким строкам в другой таблице; это называется мощностью отношения. Отношения могут быть "один к одному", "один ко многим", "многие ко многим" . Существуют стандартные способы представления каждого отношения. Прежде чем искать стандартные способы сделать это, подумайте о том, как вы будете представлять каждый из них, каковы минимальные требования каждого вида. Вы увидите, что отношение "многие ко многим" на самом деле может также моделировать "один ко многим" и "один к одному"; спросите себя, почему, учитывая это, все отношения не многие-ко-многим.
EF Codd, среди прочего, впервые выдвинул идею нормальной формы в реляционных базах данных. Обычно принято считать пять или шесть нормальных форм, но самое важное резюме нормальной формы прост: каждый объект, который ваши модели баз данных должен быть представлен одной строкой и одной строкой, каждый атрибут должен зависеть от ключа строки и каждая строка должна моделировать сущность или отношения. Прочитайте праймер в обычной форме и поймите, почему вы можете получить несоответствия данных, если ваша база данных не нормализована.
Во всем этом постарайтесь понять, почему мне нравится говорить ", если вы лжете базе данных, это будет вам" . Под этим я не имею в виду плохие данные, я имею в виду плохой дизайн. Например, если вы моделируете отношение "один-ко-многим" как много-ко-многим, то что "ложь" может быть записано? Что "ложь" может произойти, если ваши таблицы не нормализованы?
В практическом плане вид представляет собой запрос выбора, заданный имя и хранящийся в базе данных. Если я часто присоединяюсь к таблице student к таблице major через отношение "многие ко многим" student_major, возможно, я могу написать представление, которое выбирает столбцы, представляющие интерес для этого соединения, и использовать представление вместо того, чтобы переписывать присоединиться.
Практические советы: сначала, напишите представление. что бы вы ни делали, будет проще и понятнее, если вы напишете представление для каждого расчета или подсчета, который вы делаете. Напишите представление, которое инкапсулирует каждое соединение, напишите представление, которое инкапсулирует каждое преобразование. Почти все, что вы хотите сделать, можно сделать в представлении.
Разделение запроса на представления имеет те же самые черты, что и функциональный декомпозит, который служит в процедурном коде: он позволяет вам сосредоточиться на том, чтобы делать что-то одно, сделать его более легко проверенным и позволять вам создавать более сложные функции из простых операций. Вот пример, когда я использую представления для преобразования таблицы в формы, которые более легко позволяют применить последовательные преобразования, чтобы достичь цели.
Не конфликтовать данные. Каждая таблица должна однозначно моделировать одну вещь (один вид сущности) и только одну вещь; каждый столбец должен выражать один и только один атрибут этой вещи. Различные типы объектов относятся к разным таблицам.
Метаданные - ваш друг, Ваша платформа базы данных предоставит некоторые метаданные; что он не дает вам добавить. Поскольку метаданные являются данными, применяются все правила моделирования данных. Вы можете получить, например, имена всех объектов в вашей базе данных из таблицы sytem sysobjects; syscolumns содержит все столбцы. Чтобы найти все столбцы в одной таблице, вы присоедините sysobjects и syscolumns к id и добавьте предложение where, ограничивающее набор результатов, к определенному имени таблицы: where sysobjects.name = 'mytable'.
Эксперимент. Сядьте в базу данных и спросите себя: "Как я могу представить людей с цветами волос, профессиями и резиденциями? Какие таблицы и отношения подразумеваются при моделировании?" Тогда модель, которая, как таблицы.
Затем спросите себя: "Как я могу показать всех блондинок, которые живут в Атланте", и напишите запрос, который делает это. Составьте его вместе, написав взгляды, которые покажут вам всех блондинок, всех врачей и всех людей, которые проживают в Атланте.
Вы обнаружите, что при запросе "как я могу найти это" вы обнаружите недостатки в своей модели, и вы обнаружите, что хотите или даже хотите изменить способ работы вашей модели. Внесите изменения, посмотрите, как они упрощают или затрудняют ваши запросы.