SQL Server для [закрытых] программистов C#

SQL - это теория множеств или, вернее, реляционная алгебра. Прочитайте краткое руководство по этому вопросу. И учитесь думать в наборах, а не в процедурах.

С практической точки зрения, есть четыре фундаментальные операции,

• , которые выбирают, которые показывают некоторую проекцию таблицы (-ов), удаляемых данными (1289), которые удаляют некоторое подмножество. из строк таблицы
• вставляет, которые добавляют строки в таблицу, обновляет
• , что (возможно) изменяет данные в таблице

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

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

select 1, 2 , 3 из таблицы вернет набор результатов "1 2 3", по одному разу для каждой строки в таблице. Если столбец с именем create_date имеет тип date, а функция month возвращает номер месяца с заданной датой, выберите месяц (create_date) из таблицы , покажет мне номер месяца для каждого create_date.

Предложение where является предикатом, который ограничивает строки, выбранные, или удаленные, или обновленные теми строками, для которых предикат имеет значение true. Причина может быть составлена ​​из произвольного числа предикатов, связанных логическими операторами и или и , а не . Так же, как список столбцов в select , я могу использовать имена столбцов, функции и константы в моем предложении где . Как вы думаете, какой набор результатов возвращается из select * из таблицы, где 1 = 1; ?

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

Таблицы связаны, как я упоминал выше, ключами; строка в таблице может относиться к нулю, одной или нескольким строкам в другой таблице; это называется кардинальностью отношения. Отношения могут быть один к одному, один ко многим, многие ко многим. Существуют стандартные способы представления каждого отношения. Прежде чем искать стандартные способы сделать это, подумайте, как бы вы представляли каждый из них, каковы минимальные требования каждого вида. Вы увидите, что отношение «многие ко многим» может фактически моделировать «один ко многим» и «один к одному»; Спросите себя, почему, учитывая это, все отношения не многим ко многим.

Э. Ф. Кодд, среди прочего, Пионер идея нормальной формы в реляционных базах данных. Обычно считается, что существует пять или шесть нормальных форм, но наиболее важная сводка нормальной формы проста: каждый объект, который модели вашей базы данных должны представлять только одной строкой и одной строкой, каждый атрибут должен зависеть от ключа строки, и каждая строка должна моделировать сущность или отношения. Прочитайте учебник для начинающих в нормальной форме, и поймите, почему вы можете получить несоответствия данных, если ваша база данных не нормализована.

Во всем этом постарайтесь понять, почему мне нравится говорить «если ты лжешь в базу данных, она тебе врет ". Под этим я не подразумеваю плохие данные, я имею в виду плохой дизайн. Например, если вы смоделируете отношение «один ко многим» как «многие ко многим», какую «ложь» можно записать? Какая «ложь» может случиться, если ваши столы не t нормализовано?

Представление, в практических терминах, является запросом выбора с заданным именем и сохраненным в базе данных. Если я часто присоединяю таблицу student к таблице major через отношение «многие ко многим» student_major , возможно, я могу написать представление, которое выбирает интересующие столбцы из которые объединяют и используют представление вместо того, чтобы всегда переписывать объединение.

Практические советы: сначала напишите представление . что бы вы ни делали, это будет проще и понятнее, если вы напишите представление для каждого вычисления или под-вычисления, которое вы делаете. Написать представление, которое инкапсулирует каждое соединение, написать представление, которое инкапсулирует каждое преобразование. Почти все, что вы хотите сделать, может быть сделано в представлении.

Декомпозиция запроса на представления служит тем же целям, что и функциональная декомпозиция в процедурном коде: он позволяет вам сконцентрироваться на выполнении одной задачи, упрощает ее тестирование и позволяет создавать более сложные функции из более простых операций. Вот пример, в котором я использую представления для преобразования таблицы в формы, которые позволяют мне легче применять последовательные преобразования для достижения цели.

Не объединяйте данные. Каждая таблица должна однозначно моделировать одну вещь (один вид сущности) и только одну вещь; каждый столбец должен выражать один и только один атрибут этой вещи. Различные виды сущностей принадлежат разным таблицам.

Метаданные - ваш друг . Ваша платформа базы данных предоставит некоторые метаданные; что он не дает, вы должны добавить. Поскольку метаданные являются данными, применяются все правила для моделирования данных. Вы можете получить, например, имена всех объектов в вашей базе данных из таблицы систем sysobjects ; syscolumns содержит все столбцы. Чтобы найти все столбцы в одной таблице, вы должны объединить sysobjects и syscolumns по идентификатору и добавить предложение где , ограничив набор результатов конкретным именем таблицы. : где sysobjects.name = 'mytable' .

Эксперимент. Сядьте за базу данных и спросите себя: «Как я могу представлять людей с цветами волос, профессиями и местожительствами? Какие таблицы и отношения подразумеваются при моделировании этого?» Затем смоделируйте это в виде таблиц.

Затем спросите себя: «Как я могу показать всех белокурых докторов, которые проживают в Атланте», и напишите запрос, который это делает. Соберите это вместе, написав взгляды, которые покажут вам всех блондинок, все врачи и все люди, которые проживают в Атланте.

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