Сравнительный анализ реализации SQL в Microsoft Access и Microsoft SQL Server для академической работы

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

Целью данной курсовой работы является проведение глубокого сравнительного анализа языка SQL и его реализации в двух популярных продуктах от Microsoft: Microsoft Access и Microsoft SQL Server. Исследование направлено на выявление фундаментальных сходств и различий, охватывающих архитектурные особенности, поддержку типов данных, механизмы обеспечения целостности, работу с индексами и представлениями, а также специфику синтаксиса DDL (Data Definition Language) и DML (Data Manipulation Language). Адресованная студентам IT-специальностей, эта работа призвана стать структурированным академическим исследованием, предоставляющим исчерпывающие знания для осознанного выбора и эффективного использования этих СУБД в различных прикладных задачах.

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

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

• SQL (Structured Query Language): Стандартизированный язык программирования, предназначенный для управления реляционными базами данных, выполнения операций по определению данных, их манипуляции, контролю и определению транзакций.
• СУБД (Система управления базами данных): Комплекс программных средств, предназначенный для создания, хранения, обновления, поиска и организации данных в базе данных, а также для обеспечения их целостности и безопасности.
• DDL (Data Definition Language): Подмножество SQL, используемое для определения и изменения структуры базы данных, включая создание, изменение и удаление объектов базы данных, таких как таблицы, индексы, представления и схемы.
• DML (Data Manipulation Language): Подмножество SQL, используемое для манипулирования данными в базе данных, включая выборку, вставку, обновление и удаление записей.

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

Архитектурные и функциональные особенности СУБД

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

Microsoft Access: Файловая СУБД и Jet/ACE Database Engine

Microsoft Access представляет собой уникальное решение, сочетающее в себе функционал СУБД и мощный инструмент для быстрой разработки приложений (RAD tool). Его сердцевиной является Jet Database Engine (в более поздних версиях известный как Access Database Engine или ACE), который по своей сути является файловым движком. Это означает, что база данных Access хранится в одном файле (с расширением .mdb для старых версий или .accdb для новых) на локальном диске или сетевом ресурсе.

Архитектура Jet Database Engine основана на методе индексированного последовательного доступа (ISAM). Это эффективно для небольших объемов данных и ограниченного числа одновременных пользователей. Access идеально подходит для:

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

Однако файловая природа Access накладывает существенные ограничения. Наиболее заметное из них — ограничение по размеру базы данных, составляющее около 2 ГБ для одной базы данных. При превышении этого порога производительность резко падает, а риск повреждения данных возрастает. Кроме того, Jet Database Engine менее эффективен для многопользовательского доступа, так как каждый пользователь должен иметь установленный драйвер Access и напрямую подключаться к общему файлу базы данных, что при интенсивных операциях записи может приводить к блокировкам и деградации производительности.

Microsoft SQL Server: Клиент-серверная СУБД

В противоположность Access, Microsoft SQL Server — это мощная, высокопроизводительная, транзакционная клиент-серверная система баз данных, разработанная для работы с сотнями и даже тысячами пользователей одновременно. В отличие от Access, SQL Server функционирует как служба операционной системы, работая в фоновом режиме и ожидая запросы от клиентских приложений.

Ключевые характеристики SQL Server:

• Масштабируемость: Способен хранить значительно большие объемы данных, достигающие терабайтов и петабайтов, что делает его идеальным для корпоративных приложений и больших данных.
• Высокая производительность: Разработан для эффективной обработки большого количества параллельных запросов и транзакций.
• Надежность и безопасность: Обеспечивает собственные, более сложные и гранулированные механизмы безопасности, арбитражные слои и кэширование, что критически важно для защиты конфиденциальных данных и обеспечения непрерывной работы.
• Транзакционность: Полностью поддерживает свойства ACID (Atomicity, Consistency, Isolation, Durability), гарантируя надежность и целостность данных даже при сбоях.

SQL Server является выбором по умолчанию для:

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

Сравнительный анализ архитектур

Наиболее яркое различие между двумя СУБД лежит в их архитектурных моделях: файл-серверной (Access) против клиент-серверной (SQL Server).

Характеристика	Microsoft Access (Файловая СУБД)	Microsoft SQL Server (Клиент-серверная СУБД)
Архитектура	Файл-серверная	Клиент-серверная
Движок БД	Jet Database Engine (ACE)	SQL Server Engine
Хранение данных	Один файл (.mdb/.accdb)	Централизованный серверный процесс
Обработка запросов	На клиентской машине (данные передаются по сети)	На сервере (клиенту передается только результат)
Многопользовательский доступ	Менее эффективен, подвержен блокировкам, ограничено количество пользователей	Высокоэффективен, сотни/тысячи пользователей, механизмы блокировок и параллелизма
Размер базы данных	До 2 ГБ	Терабайты и выше
Производительность	Хороша для небольших объемов, падает при масштабировании	Высокая, оптимизирована для больших нагрузок
Безопасность	Ограниченные встроенные механизмы, файловая система	Расширенные механизмы аутентификации, авторизации, шифрования
Роль продукта	RAD-инструмент, клиентское приложение, бэкенд для простых задач	Высокопроизводительный бэкенд, платформа для корпоративных решений

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

В клиент-серверной архитектуре SQL Server, напротив, обработка данных происходит непосредственно на сервере. Клиенту передается только конечный результат запроса. Это значительно снижает сетевой трафик и позволяет более эффективно использовать ресурсы сервера, обеспечивая лучшую производительность и масштабируемость.

Интересно, что Access может быть масштабирован для корпоративных решений путем связывания с несколькими базами данных или использования серверной базы данных, такой как Microsoft SQL Server. В этом сценарии MS Access может функционировать как клиентское приложение (фронтенд), предоставляя удобный графический интерфейс для пользователя, и взаимодействовать с SQL Server, который выступает в роли мощного бэкенда для хранения и обработки данных. В таких «проектах Access» (файлы .adp) хранятся только объекты приложения (формы, отчеты, макросы, модули), а данные и структуры объектов базы данных (таблицы, схемы, представления) отображаются из SQL Server.

Инструменты администрирования

Различия в архитектуре также проявляются в инструментах администрирования:

• Microsoft Access: Предлагает обширный набор мастеров и графических конструкторов для разработки приложений и работы с данными, что упрощает взаимодействие для пользователей с разным уровнем подготовки. Это соответствует его роли RAD-инструмента.
• Microsoft SQL Server: Основным инструментом для администрирования, разработки и управления SQL Server является SQL Server Management Studio (SSMS). Это профессиональный инструмент, предоставляющий мощные возможности для создания баз данных, написания запросов, администрирования безопасности, мониторинга производительности и многих других задач, требующих более глубоких технических знаний.

В заключение, выбор между Access и SQL Server определяется не только текущими потребностями, но и планами на будущее. Access — это быстрый старт для малых проектов, а SQL Server — прочная основа для масштабируемых, высокопроизводительных и безопасных корпоративных решений.

Типы данных и их поддержка

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

Сравнение стандартных типов данных

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

Категория	Описание	Microsoft Access (Jet/ACE)	Microsoft SQL Server (T-SQL)	Примечание
Целые числа	Целые числа различного диапазона	Байт, Целое, Длинное целое, Большое число	tinyint, smallint, int, bigint	Access «Большое число» соответствует SQL Server bigint.
Дробные числа	Числа с плавающей точкой	Одинарное с плавающей точкой, Двойное с плавающей точкой	float, real	real в SQL Server обычно соответствует «Одинарное с плавающей точкой».
Денежные	Точные денежные значения	Денежный	money, smallmoney	money в обеих СУБД предназначен для финансовых расчетов.
Даты и время	Дата и время	Дата и время	datetime, smalldatetime, date, time, datetime2	SQL Server предлагает более гранулированные типы для даты и времени.
Строки	Текстовые данные	Текстовый, Длинный текст (Memo)	char, varchar, nchar, nvarchar, text, ntext, varchar(MAX), nvarchar(MAX)	Access «Текстовый» до 255 символов, свыше — «Длинный текст» (Memo).
Бинарные	Двоичные данные	Двоичный	binary, varbinary, image, varbinary(MAX)	image и varbinary(MAX) для больших бинарных объектов.
Логические	Булевы значения	Да/Нет	bit	В Access отображается как флажок или текстовое «Истина/Ложь».
Автоинкремент	Автоматически генерируемые уникальные числа	Счетчик	identity (для int, bigint и др.)	В SQL Server реализуется свойством IDENTITY для числовых типов.
Прочие	OLE Object, Гиперссылка, Вложение, Вычисляемое	OLE Object, Гиперссылка, Вложение, Вычисляемое	xml, uniqueidentifier, geography, geometry, hierarchyid, sql_variant, rowversion	SQL Server имеет значительно более широкий набор специализированных типов.

Как видно из таблицы, даже для базовых типов наблюдаются не только различия в именовании (int в SQL Server соответствует «Длинному целому» в Access), но и в концептуальном подходе. Например, тип bit в SQL Server, хранящий 0 или 1, аналогичен типу «Да/нет» в Access, который на уровне пользовательского интерфейса может отображаться как флажок. Строковый тип «Текстовый» в Access ограничен 255 символами, а для более длинных строк требуется «Длинный текст» (Memo), что эквивалентно varchar (до 255 символов) и varchar(MAX)/text в SQL Server соответственно.

Особенности и ограничения поддержки типов данных

Microsoft SQL Server значительно превосходит Access по широте и глубине поддержки типов данных. Он предлагает более гранулированные типы для дат и времени, такие как date, time, datetime2 (с большей точностью и диапазоном, чем datetime). Также доступны специализированные типы данных для различных нужд:

• decimal и numeric: для хранения точных десятичных чисел с фиксированной точностью и масштабом, что критически важно для финансовых расчетов.
• nvarchar(MAX): для хранения очень длинных строковых данных Unicode.
• xml: для хранения данных в формате XML.
• uniqueidentifier: для хранения глобально уникальных идентификаторов (GUID).
• Геопространственные типы (geography, geometry): для работы с географическими и геометрическими данными.

Microsoft Access, напротив, имеет более ограниченный набор встроенных типов. В то время как Access поддерживает OLE Object и Attachment для хранения файлов или объектов, Jet Database Engine, используемый в Access, возможно, не поддерживает полный набор типов данных, которые может поддерживать SQL Server, в частности, некоторые сложные бинарные объекты (BLOBs) или специализированные типы. Например, Access DDL не позволяет создавать поля типов Hyperlink, Attachment или комплексные типы данных напрямую.

При переносе базы данных из Access в SQL Server или при работе в гибридной среде (Access как фронтенд к SQL Server) важно тщательно сопоставлять типы данных, чтобы избежать потери информации, ошибок округления или проблем совместимости. Нередко требуется вручную преобразовывать типы данных или выбирать наиболее подходящие эквиваленты. Этап анализа и сопоставления типов данных является критическим для обеспечения целостности и функциональности системы.

Создание таблиц и определение ключей

Проектирование и создание таблиц являются основополагающими этапами в разработке любой базы данных, а определение ключей и ограничений целостности данных служит каркасом для обеспечения надежности и корректности хранимой информации. Хотя обе СУБД, Microsoft Access и Microsoft SQL Server, используют стандартные принципы реляционных баз данных, их реализации синтаксиса DDL (Data Definition Language) и механизмы определения этих элементов имеют свои особенности.

Инструкция CREATE TABLE

Инструкция CREATE TABLE является центральной для определения структуры новой таблицы, её полей и связанных ограничений.

В Microsoft Access (Jet/ACE SQL) синтаксис CREATE TABLE позволяет определять поля и некоторые ограничения:

CREATE TABLE Студенты (
    КодСтудента COUNTER PRIMARY KEY,
    Фамилия TEXT(50) NOT NULL,
    Имя TEXT(50) NOT NULL,
    ДатаРождения DATETIME,
    СреднийБалл SINGLE
);

Синтаксис Access DDL имеет свои специфические расширения, например, COUNTER для автоинкрементного поля и указание размера для текстовых полей TEXT(50). Также поддерживаются опции [TEMPORARY] для временных таблиц и [WITH COMPRESSION | WITH COMP], хотя последняя опция в современных версиях Access используется редко, так как сжатие данных обычно управляется на уровне движка.

В Microsoft SQL Server (Transact-SQL) синтаксис CREATE TABLE более строг и гибок одновременно, позволяя определять широкий спектр свойств столбцов и ограничений:

CREATE TABLE Students (
    StudentID INT IDENTITY(1,1) PRIMARY KEY,
    LastName NVARCHAR(50) NOT NULL,
    FirstName NVARCHAR(50) NOT NULL,
    DateOfBirth DATE,
    GPA REAL
);

Здесь INT IDENTITY(1,1) означает автоинкрементное поле, начинающееся с 1 и увеличивающееся на 1. NVARCHAR(50) используется для хранения Unicode-строк. SQL Server поддерживает более широкий спектр типов данных и более детализированное управление их свойствами.

Важно отметить, что в Access DDL-инструкции имеют некоторые ограничения: невозможно установить такие свойства, как «Allow Zero Length» (Разрешить нулевую длину), «Display Control» (Элемент управления), «Format» (Формат) через DDL. Также нельзя создавать поля типов Hyperlink, Attachment или комплексные типы данных с помощью DDL, что часто требует использования графического интерфейса.

Ограничение NOT NULL

Ограничение NOT NULL — это базовое правило, гарантирующее, что столбец не может содержать пустое значение (NULL).

• В Access: NOT NULL указывается как свойство поля «Обязательное» в конструкторе таблиц или явно в инструкции CREATE TABLE.

  CREATE TABLE Продукты (
      КодПродукта COUNTER PRIMARY KEY,
      НазваниеПродукта TEXT(100) NOT NULL,
      Цена MONEY
  );
  

• В SQL Server: NOT NULL указывается как атрибут столбца при его создании.

  CREATE TABLE Products (
      ProductID INT IDENTITY(1,1) PRIMARY KEY,
      ProductName NVARCHAR(100) NOT NULL,
      Price MONEY
  );
  

Первичный ключ (PRIMARY KEY)

Первичный ключ (PRIMARY KEY) однозначно идентифицирует каждую запись в таблице и не может содержать NULL значения. Каждая таблица может иметь только один первичный ключ.

• В Access: Первичный ключ может быть определен с использованием CONSTRAINT в CREATE TABLE или путем создания индекса первичного ключа после создания таблицы через конструктор. Access автоматически создает индекс для первичного ключа.

  CREATE TABLE Отделы (
      КодОтдела INTEGER,
      НазваниеОтдела TEXT(50) NOT NULL,
      CONSTRAINT PK_Отделы PRIMARY KEY (КодОтдела)
  );
  

  Или через конструктор: выбрать поле, нажать «Первичный ключ».

• В SQL Server: Первичный ключ определяется с использованием ключевого слова PRIMARY KEY в CREATE TABLE. Ядро СУБД автоматически создает уникальный кластеризованный индекс (если кластеризованный индекс еще не существует) для столбцов первичного ключа, что оптимизирует поиск данных по этому ключу.

  CREATE TABLE Departments (
      DepartmentID INT PRIMARY KEY,
      DepartmentName NVARCHAR(50) NOT NULL
  );
  

Внешний ключ (FOREIGN KEY)

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

• В Access: Внешний ключ определяется с помощью CONSTRAINT в CREATE TABLE или через графический интерфейс («Схема данных»). При этом требуется совпадение типов данных между связываемыми полями.

  CREATE TABLE Сотрудники (
      КодСотрудника COUNTER PRIMARY KEY,
      Фамилия TEXT(50) NOT NULL,
      КодОтдела INTEGER,
      CONSTRAINT FK_Отдел FOREIGN KEY (КодОтдела) REFERENCES Отделы (КодОтдела)
  );
  

  Через «Схему данных» пользователь просто перетаскивает поле первичного ключа на соответствующее поле в связанной таблице.

• В SQL Server: Внешний ключ определяется с помощью FOREIGN KEY в CREATE TABLE и может ссылаться на столбцы с PRIMARY KEY или UNIQUE ограничениями в связанной таблице. SQL Server предлагает более мощные возможности управления каскадными операциями.

  CREATE TABLE Employees (
      EmployeeID INT IDENTITY(1,1) PRIMARY KEY,
      LastName NVARCHAR(50) NOT NULL,
      DepartmentID INT,
      CONSTRAINT FK_Department FOREIGN KEY (DepartmentID) REFERENCES Departments (DepartmentID)
  );
  

Ограничение UNIQUE

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

• В Access: UNIQUE ограничение может быть создано как часть CREATE TABLE или ALTER TABLE инструкции.

  CREATE TABLE Пользователи (
      UserID COUNTER PRIMARY KEY,
      ИмяПользователя TEXT(50) NOT NULL UNIQUE,
      Email TEXT(100)
  );
  

• В SQL Server: UNIQUE определяется аналогично:

  CREATE TABLE Users (
      UserID INT IDENTITY(1,1) PRIMARY KEY,
      Username NVARCHAR(50) NOT NULL UNIQUE,
      Email NVARCHAR(100)
  );
  

Ограничение CHECK

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

• В Access: CHECK ограничения в Access имеют свою специфику. Их нельзя напрямую определить в CREATE TABLE через стандартный SQL-интерфейс Access или конструктор запросов с использованием DAO. Для добавления CHECK ограничения к существующей таблице часто требуется использовать инструкцию ALTER TABLE через ADO-соединение.

  -- Пример добавления CHECK ограничения в Access (через ADO)
  ALTER TABLE Заказы ADD CONSTRAINT Chk_Количество CHECK (Количество > 0);
  

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

  CREATE TABLE Orders (
      OrderID INT PRIMARY KEY,
      OrderDate DATE,
      Quantity INT CHECK (Quantity > 0)
  );
  

Ограничение DEFAULT

Ограничение DEFAULT устанавливает значение по умолчанию для столбца, если при вставке новой записи значение для этого столбца не указано.

• В Access: DEFAULT значение может быть задано в конструкторе таблиц или в CREATE TABLE.

  CREATE TABLE Задачи (
      КодЗадачи COUNTER PRIMARY KEY,
      Описание TEXT(255),
      ДатаСоздания DATETIME DEFAULT Date()
  );
  

• В SQL Server: DEFAULT также определяется при создании или изменении столбца.

  CREATE TABLE Tasks (
      TaskID INT IDENTITY(1,1) PRIMARY KEY,
      Description NVARCHAR(255),
      CreationDate DATETIME DEFAULT GETDATE()
  );
  

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

Механизмы обеспечения целостности данных и их различия

Целостность данных — это краеугольный камень любой надежной системы управления базами данных. Она гарантирует, что данные остаются корректными, согласованными и непротиворечивыми на протяжении всего их жизненного цикла. Microsoft Access и Microsoft SQL Server, будучи реляционными СУБД, предоставляют механизмы для обеспечения различных типов целостности, но их реализация и возможности значительно отличаются, что имеет практические последствия для разработчика, влияя на стабильность и надежность всей системы.

Ссылочная целостность

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

• В Microsoft Access: Access частично поддерживает SQL-команды для определения ссылочной целостности, но ее мощь проявляется в графическом интерфейсе («окно Схема данных»). Через этот интерфейс пользователь может легко визуально устанавливать связи между таблицами, определяя первичные и внешние ключи, и активировать каскадные операции. Это делает управление ссылочной целостностью интуитивно понятным даже для начинающих разработчиков. Access требует совпадения типов данных между связываемыми полями для установки ссылочной целостности.
• В Microsoft SQL Server: SQL Server предлагает широкий набор инструментов для обеспечения целостности данных, включая как декларативные ограничения (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK), так и более сложные программные механизмы, такие как триггеры (Triggers). Триггеры позволяют реализовать сложную бизнес-логику для поддержания целостности, которая не может быть выражена простыми ограничениями. SQL Server является более строгим в применении ссылочной целостности, что способствует созданию более надежных баз данных.

Каскадные операции

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

• В SQL Server: Поддерживается полный набор каскадных операций для внешних ключей:
  • ON DELETE CASCADE: При удалении строки из родительской таблицы автоматически удаляются все связанные строки в дочерней таблице.
  • ON UPDATE CASCADE: При изменении значения первичного ключа в родительской таблице автоматически обновляются соответствующие значения внешнего ключа в дочерней таблице.
  • ON DELETE SET NULL: При удалении строки из родительской таблицы значения внешнего ключа в связанных строках дочерней таблицы устанавливаются в NULL (при условии, что столбец внешнего ключа допускает NULL).
  • ON UPDATE SET NULL: При изменении первичного ключа в родительской таблице значения внешнего ключа в дочерней таблице устанавливаются в NULL (при условии, что столбец внешнего ключа допускает NULL).

  Пример использования каскадных операций в SQL Server:

  CREATE TABLE Departments (
      DepartmentID INT PRIMARY KEY,
      DepartmentName NVARCHAR(50) NOT NULL
  );
  
  CREATE TABLE Employees (
      EmployeeID INT IDENTITY(1,1) PRIMARY KEY,
      LastName NVARCHAR(50) NOT NULL,
      DepartmentID INT,
      CONSTRAINT FK_Department_Employees FOREIGN KEY (DepartmentID)
      REFERENCES Departments (DepartmentID)
      ON DELETE CASCADE -- Удаление отдела приведет к удалению всех сотрудников этого отдела
      ON UPDATE CASCADE  -- Изменение ID отдела обновит ID у сотрудников
  );
  

• В Access: Access также поддерживает каскадные операции (ON DELETE CASCADE, ON UPDATE CASCADE) при определении связей через графический интерфейс. Однако возможность определения ON DELETE SET NULL или ON UPDATE SET NULL может быть не всегда очевидной через стандартные SQL-инструкции и чаще реализуется через интерфейс «Схемы данных» или, в сложных случаях, через VBA-код или триггеры на стороне сервера (если Access используется как фронтенд к SQL Server).

Целостность домена и сущностей

Помимо ссылочной целостности, существуют и другие важные типы целостности:

• Целостность домена (Domain Integrity): Определяет допустимый набор значений для поля. Она может быть обеспечена с помощью:
  • CHECK ограничений (как было рассмотрено, с нюансами в Access).
  • Правил проверки значений и масок ввода в Access.
  • Типов данных (например, числовое поле не может содержать текст).
  • DEFAULT ограничений.
• Целостность сущностей (Entity Integrity): Требует, чтобы все строки в таблице имели уникальный идентификатор (первичный ключ), который не может быть NULL. Это базовое правило, которое строго соблюдается в обеих СУБД через механизм первичных ключей.

Проверка данных при добавлении ограничений

Различия также проявляются в поведении СУБД при добавлении новых ограничений к уже существующим таблицам с данными:

• В SQL Server: При добавлении ограничений (например, CHECK или FOREIGN KEY) к существующей таблице SQL Server автоматически проверяет существующие данные на соответствие новым правилам. Если какие-либо данные нарушают новое ограничение, оно не будет добавлено, и система выдаст ошибку. Это гарантирует, что база данных остается согласованной. Для того чтобы добавить ограничение без предварительной проверки существующих данных (что может быть полезно для очень больших таблиц, где проверка займет много времени, и вы уверены в целостности данных), можно использовать опцию WITH NOCHECK в инструкции ALTER TABLE.

  ALTER TABLE Orders WITH NOCHECK ADD CONSTRAINT FK_CustomerOrders FOREIGN KEY (CustomerID) REFERENCES Customers (CustomerID);
  

• В Access: При добавлении связей или ограничений через графический интерфейс, Access также выполняет проверку существующих данных. Если обнаруживаются нарушения, он предлагает либо отменить создание связи/ограничения, либо создать её, но с отключенной ссылочной целостностью (что крайне нежелательно). Для CHECK ограничений, как было упомянуто, механизм менее прозрачен и требует ADO-соединения для определения через SQL, что усложняет автоматическую проверку существующих данных.

В целом, SQL Server предоставляет более robustные, стандартизированные и программно управляемые механизмы обеспечения целостности данных, что соответствует его роли корпоративной СУБД. Access, с его интуитивным графическим интерфейсом, делает базовые аспекты целостности данных доступными, но для сложных сценариев или при работе с большим объемом данных его возможности оказываются ограниченными.

Индексы и оптимизация производительности запросов

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

Общее назначение индексов

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

Использование индексов особенно эффективно для ускорения выполнения запросов, которые включают:

• Фильтрацию данных (предложение WHERE): Быстрый доступ к строкам, соответствующим определенным условиям.
• Сортировку данных (предложение ORDER BY): Устранение необходимости в динамической сортировке, так как данные уже отсортированы в индексе.
• Группировку данных (предложение GROUP BY): Ускорение агрегатных вычислений, если сгруппированные поля индексированы.
• Объединение таблиц (предложение JOIN): Оптимизация поиска соответствий между таблицами по индексированным полям внешних ключей.

Однако за эти преимущества приходится платить. Создание и поддержание индексов требует дополнительных ресурсов:

• Дисковое пространство: Индексы представляют собой отдельные структуры данных, которые занимают место на диске.
• Производительность операций DML: Операции добавления (INSERT), обновления (UPDATE) и удаления (DELETE) данных замедляются, так как при каждом изменении данных в таблице СУБД должна также обновлять все связанные индексы, чтобы они оставались актуальными.

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

Индексы в Microsoft Access

В Microsoft Access индексы играют важную роль в оптимизации производительности, особенно для небольших и средних баз данных.

• Автоматическое создание индексов: Access автоматически создает индексы для любого поля или полей, назначенных первичным ключом. Это логично, поскольку первичные ключи часто используются для поиска и связывания таблиц.
• Пользовательские индексы: Пользователь Access может создавать индексы для одного или нескольких полей через конструктор таблиц (в режиме «Конструктор») или с помощью SQL-инструкции CREATE INDEX.

  Пример CREATE INDEX в Access:

  CREATE INDEX IX_ФамилияИмя ON Сотрудники (Фамилия, Имя);
  

  Access также может автоматически индексировать поля, имена которых начинаются или заканчиваются определенными символами (например, ID, key, code, num), если включена опция «Автоматическое индексирование при импорте/создании».

• Ограничения на индексируемые типы полей: В Access нельзя индексировать поля с типами данных OLE Object, Calculated (вычисляемые) или Attachment (вложения). Это связано с их природой: OLE Object и Attachment хранят большие двоичные объекты, которые не подходят для индексации, а Calculated поля вычисляются динамически.
• Рекомендации по оптимизации запросов в Access: Для повышения производительности в Access рекомендуется индексировать поля, которые часто используются в запросах для поиска, сортировки, группировки и объединения с другими таблицами. Однако, для эффективной работы оптимизатора запросов Access важно избегать вызовов функций VBA в условиях WHERE или в предложениях ORDER BY, так как это может помешать использованию индексов и привести к полному сканированию таблицы. При сортировке по составному индексу в Access сортировка происходит сначала по первому полю, затем по второму и так далее.

Индексы в Microsoft SQL Server: Глубокое погружение

В SQL Server концепция индексов значительно более сложна и гибка, что отражает его ориентацию на высокопроизводительные и масштабируемые решения. Индексы в SQL Server организованы в виде B-деревьев (или B+ деревьев), где каждая страница данных имеет размер 8 КБ. Это обеспечивает эффективный поиск и обход данных.

SQL Server различает два основных типа индексов: кластеризованные и некластеризованные.

Кластеризованные индексы

Кластеризованный индекс (CLUSTERED INDEX) является фундаментальным для физической организации данных в SQL Server.

• Физический порядок хранения: Кластеризованный индекс определяет физический порядок хранения строк данных в таблице или представлении на диске. Это означает, что строки данных фактически отсортированы в соответствии с ключом кластеризованного индекса.
• Один на таблицу: Таблица в SQL Server может иметь только один кластеризованный индекс, поскольку данные могут быть физически отсортированы только одним способом.
• Автоматическое создание: По умолчанию, при создании PRIMARY KEY в таблице SQL Server автоматически создает кластеризованный индекс, если он еще не существует. Если кластеризованный индекс уже есть, для PRIMARY KEY создается некластеризованный индекс.
• Листовые узлы: Листовые узлы кластеризованного индекса в SQL Server содержат сами строки данных таблицы.
• Идеален для диапазонов: Кластеризованные индексы идеально подходят для запросов, которые извлекают диапазоны данных или выполняют поиск по ключу индекса, поскольку данные уже упорядочены.

Пример создания кластеризованного индекса:

CREATE CLUSTERED INDEX IX_Employees_LastName ON Employees (LastName ASC);

Некластеризованные индексы

Некластеризованный индекс (NONCLUSTERED INDEX) имеет структуру, отдельную от строк данных таблицы.

• Отдельная структура: Некластеризованный индекс содержит значения ключа индекса и указатели (row locators) на фактические строки данных в таблице. Эти указатели могут быть либо указателем на кластеризованный ключ (если таблица имеет кластеризованный индекс), либо RID (Row ID) для кучи (таблицы без кластеризованного индекса).
• Множество индексов: Таблица в SQL Server может иметь до 999 некластеризованных индексов.
• Не влияет на физический порядок: Некластеризованные индексы не влияют на физический порядок хранения данных в таблице.
• Листовые узлы: Листовые узлы некластеризованного индекса в SQL Server содержат ключи и указатели, а не сами данные.
• Эффективны для других столбцов: Некластеризованные индексы эффективны для оптимизации запросов, использующих столбцы, не покрытые кластеризованным индексом, для фильтрации, сортировки и операций JOIN.

Пример создания некластеризованного индекса:

CREATE NONCLUSTERED INDEX IX_Employees_DepartmentID ON Employees (DepartmentID ASC);

Специализированные индексы

SQL Server также поддерживает ряд специализированных индексов для специфических сценариев:

• Полнотекстовые индексы (Full-Text Indexes): Для быстрого поиска по тексту в больших текстовых полях.
• Индексы XML (XML Indexes): Для эффективного запроса данных в XML-столбцах.
• Пространственные индексы (Spatial Indexes): Для работы с геопространственными данными.
• Колоночные индексы (Columnstore Indexes): Оптимизированы для аналитических запросов и хранилищ данных, обеспечивая высокую степень сжатия и производительность для агрегатных функций.
• Фильтруемые индексы (Filtered Indexes): Применяются только к подмножеству строк в таблице, что позволяет уменьшить размер индекса и улучшить производительность запросов к этому подмножеству.

Покрывающие индексы

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

Пример покрывающего индекса:

CREATE NONCLUSTERED INDEX IX_Employees_NameEmail
ON Employees (LastName, FirstName) INCLUDE (Email);
-- Запрос SELECT LastName, FirstName, Email FROM Employees WHERE LastName = 'Smith' может быть полностью удовлетворен этим индексом.

Оптимизатор запросов и фрагментация

В SQL Server ключевую роль играет оптимизатор запросов. Он автоматически анализирует несколько возможных планов выполнения запроса, оценивает стоимость каждого (на основе статистики о распределении данных и индексах) и выбирает план с наименьшей стоимостью. Правильно спроектированные индексы предоставляют оптимизатору больше вариантов для выбора эффективного плана.

Важной проблемой, влияющей на производительность, является фрагментация индексов. Чрезмерная фрагментация возникает, когда логический порядок страниц индекса не соответствует их физическому порядку на диске. Это значительно снижает производительность операций ввода-вывода. SQL Server предоставляет инструменты для мониторинга фрагментации и механизмы для ее устранения (операции REORGANIZE и REBUILD индекса).

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

Представления (VIEW): Сравнение и функциональные ограничения

Представления, или VIEW, являются одним из ключевых механизмов в реляционных базах данных, позволяющих абстрагироваться от сложной физической структуры данных и предоставлять пользователям или приложениям упрощенный, настраиваемый взгляд на информацию. Несмотря на схожесть основной концепции, их реализация и функциональные возможности в Microsoft Access и Microsoft SQL Server имеют существенные различия.

Концепция и назначение представлений

Представление (VIEW) — это виртуальная таблица, содержимое которой определяется запросом к одной или нескольким базовым таблицам или другим представлениям. Важнейшая характеристика VIEW заключается в том, что они не хранят данные физически. Вместо этого, данные извлекаются динамически из базовых таблиц при каждом обращении к представлению. Это означает, что представления всегда отображают актуальные данные.

Основные цели использования представлений:

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

Создание представлений осуществляется с использованием инструкции CREATE VIEW view_name AS SELECT_statement.

Представления в Microsoft Access (сохраненные запросы)

В мире Microsoft Access, особенно для баз данных, не основанных на ядре СУБД Microsoft Access (Jet/ACE), инструкции CREATE VIEW (и другие DDL-инструкции) не поддерживаются напрямую в том виде, как это реализовано в SQL Server.

Вместо полноценных VIEW, в Access используются «сохраненные запросы» (QueryDef objects), которые выполняют аналогичную функцию виртуальных таблиц. Сохраненные запросы Access — это объекты, которые хранятся в файле .accdb и содержат определение SQL-запроса. Они могут быть:

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

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

Представления в Microsoft SQL Server

Microsoft SQL Server предоставляет полноценную поддержку представлений, которые являются мощным и гибким инструментом для работы с данными.

• Создание VIEW: Представления в SQL Server создаются с использованием инструкции CREATE VIEW view_name AS SELECT_statement. Важно отметить, что CREATE VIEW должна быть первой инструкцией в пакете запросов. Также представления можно создавать и управлять ими через графический интерфейс SQL Server Management Studio (SSMS).
• Разрешения: Для создания представления в SQL Server требуются разрешения CREATE VIEW на базу данных и ALTER на схему, в которой создается представление.
• Дополнительные опции: SQL Server поддерживает специфические опции при создании представлений:
  • WITH ENCRYPTION: Шифрует текст определения представления в системных таблицах, предотвращая его просмотр.
  • WITH SCHEMABINDING: Привязывает представление к схеме базовых объектов. Это гарантирует, что базовые таблицы не могут быть изменены таким образом, чтобы нарушить определение представления (например, удаление столбца, на который ссылается представление). Это также позволяет создавать индексированные представления.

Пример создания представления в SQL Server:

CREATE VIEW View_ActiveEmployees AS
SELECT EmployeeID, FirstName, LastName, DepartmentName
FROM Employees e
JOIN Departments d ON e.DepartmentID = d.DepartmentID
WHERE e.IsActive = 1;

Обновляемость представлений

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

• Общие условия обновляемости: Представления могут быть обновляемыми, если они удовлетворяют определенным ограничениям. В целом, представление не может быть обновляемым, если оно содержит:
  • TOP, DISTINCT
  • UNION
  • Агрегатные функции (SUM, AVG, COUNT и т.д.)
  • Предложения GROUP BY, HAVING
  • Подзапросы
  • Производные столбцы (вычисленные)
  • Обращения к нескольким таблицам одновременно через JOIN (хотя в некоторых случаях SQL Server может поддерживать обновление через JOIN для одной из таблиц).
• В Access: Если сохраненный запрос Access является обновляемым (например, он основан на одной таблице и не содержит агрегатных функций), то и «представление» является обновляемым. Для форм Access, связанных с SQL Server, для редактирования данных предпочтительнее использовать представления или связанные таблицы, а не сквозные запросы (pass-through queries), которые обычно доступны только для чтения.
• В SQL Server: Правила обновляемости более строгие. Если представление основано на нескольких таблицах с использованием JOIN, обычно можно обновлять только столбцы из одной базовой таблицы. Для обновления данных через сложные представления часто используются INSTEAD OF триггеры.

Функциональные ограничения и особенности

Сравним некоторые специфические ограничения и особенности:

• Количество столбцов и таблиц:
  • Представление в SQL Server может содержать максимум 1024 столбца.
  • Представления в SQL Server могут обращаться не более чем к 256 таблицам.
• Уровень вложенности: В SQL Server можно создавать представления на основе других представлений (вложенные представления), но уровень вложенности не может превышать 32.
• Параметры:
  • Представления в SQL Server не могут принимать параметры. Для параметризованных запросов рекомендуется использовать хранимые процедуры или функции.
  • В Access сохраненные запросы, напротив, могут использовать параметры, что является одним из их преимуществ для интерактивных приложений.
• ORDER BY в определении VIEW: В SQL Server инструкция SELECT в определении представления не может содержать ORDER BY, за исключением случаев, когда также используется TOP или OFFSET...FETCH. Сортировка данных, извлекаемых из представления, должна применяться в команде SELECT, которая обращается к этому представлению.
• Сложные типы данных: В Access сохраненные запросы могут иметь ограничения при работе с некоторыми сложными типами данных или выражениями, которые легко обрабатываются в SQL Server.

Индексированные представления в SQL Server

Одной из уникальных и мощных особенностей SQL Server являются индексированные представления (Indexed Views), также известные как материализованные представления.

• Материализация данных: Индексированные представления — это специальные представления, для которых создается уникальный кластеризованный индекс. При создании такого индекса данные представления физически хранятся на диске (материализуются), подобно обычной таблице.
• Ускорение сложных запросов: Они используются для ускорения запросов, которые включают сложные агрегации (SUM, COUNT) или многотабличные объединения, поскольку результаты этих вычислений уже предварительно рассчитаны и сохранены.
• Стоимость: Поддержание индексированных представлений требует дополнительных ресурсов, так как при каждом изменении данных в базовых таблицах индексированное представление также должно быть обновлено, что влияет на производительность операций DML.

В итоге, хотя Access предлагает удобный интерфейс для создания «виртуальных таблиц» (сохраненных запросов), SQL Server предоставляет более формализованный, мощный и масштабируемый механизм представлений, включая уникальные возможности, такие как индексированные представления, что соответствует его роли корпоративной СУБД.

Особенности синтаксиса SQL (DDL, DML) в Access и SQL Server

Хотя SQL является стандартизированным языком, каждая СУБД имеет свой диалект, добавляя проприетарные расширения и специфические синтаксические нюансы. Сравнение диалектов Access SQL (Jet/ACE SQL) и Transact-SQL (T-SQL) в SQL Server раскрывает эти отличия, которые критически важны для кросс-платформенной разработки и миграции, поскольку неверное использование синтаксиса может привести к ошибкам или неожиданному поведению системы.

Общие принципы DDL и DML

Начнем с базовых определений:

• DDL (Data Definition Language): Включает команды для определения и управления структурой базы данных. К ним относятся CREATE (создание объектов), ALTER (изменение объектов) и DROP (удаление объектов) для таблиц, индексов, представлений, схем и т.д.
• DML (Data Manipulation Language): Включает команды для манипулирования данными внутри таблиц. Основные команды: SELECT (выборка данных), INSERT (вставка данных), UPDATE (изменение данных) и DELETE (удаление данных).

Большинство SQL-баз данных, включая Access и SQL Server, поддерживают основные команды DML (SELECT, UPDATE, DELETE, INSERT, WHERE) аналогичным образом, но имеют свои проприетарные расширения.

Синтаксические различия в DDL

CREATE TABLE

• Access SQL (Jet/ACE):

  CREATE TABLE [Заказы] (
      [КодЗаказа] COUNTER PRIMARY KEY,
      [ДатаЗаказа] DATETIME DEFAULT Date(),
      [Сумма] CURRENCY,
      [Описание] MEMO WITH COMPRESSION
  );
  

  Особенности:

  • Использование COUNTER для автоинкрементного поля.
  • Типы данных могут быть специфическими для Access (например, MEMO).
  • Опции, такие как WITH COMPRESSION, могут быть частью определения поля.
  • DDL в Access имеет ограничения: невозможно установить свойства, такие как «Allow Zero Length», «Display Control», «Format», «Required» (хотя NOT NULL поддерживается), или создать поля типов Hyperlink, Attachment или комплексные типы данных. Эти операции часто требуют использования графического интерфейса Access.
• SQL Server (Transact-SQL):

  CREATE TABLE Orders (
      OrderID INT IDENTITY(1,1) PRIMARY KEY,
      OrderDate DATETIME DEFAULT GETDATE(),
      Amount MONEY,
      Description NVARCHAR(MAX)
  );
  

  Особенности:

  • Использование IDENTITY(seed, increment) для автоинкрементного поля.
  • NVARCHAR(MAX) для длинных текстовых полей, способных хранить до 2 ГБ данных.
  • Более широкий и стандартизированный набор типов данных.

ALTER TABLE

• Access SQL: Поддерживает ADD COLUMN, DROP COLUMN, ALTER COLUMN (для изменения типа/размера поля) и ADD CONSTRAINT. CHECK ограничения в Access, как было упомянуто, должны быть добавлены после создания таблицы с помощью ALTER TABLE и выполняться через ADO-соединение, а не напрямую в CREATE TABLE или через конструктор запросов Access с использованием DAO.

  ALTER TABLE [Заказы] ADD COLUMN [Статус] TEXT(20) DEFAULT 'Новый';
  ALTER TABLE [Заказы] ALTER COLUMN [Сумма] DECIMAL(10, 2);
  ALTER TABLE [Заказы] ADD CONSTRAINT CHK_Сумма CHECK ([Сумма] > 0); -- Выполняется через ADO
  

• SQL Server (Transact-SQL):

  ALTER TABLE Orders ADD Status NVARCHAR(20) DEFAULT 'New';
  ALTER TABLE Orders ALTER COLUMN Amount DECIMAL(10, 2);
  ALTER TABLE Orders ADD CONSTRAINT CHK_Amount CHECK (Amount > 0);
  

  SQL Server предоставляет более прямой и предсказуемый механизм для изменения структуры таблицы.

DROP TABLE

Синтаксис одинаков:

• Access SQL: DROP TABLE table_name;
• SQL Server (T-SQL): DROP TABLE table_name;

CREATE INDEX

• Access SQL:

  CREATE UNIQUE INDEX IX_Email ON Клиенты (Email) WITH DISALLOW NULL;
  

  Особенности:

  • Опции WITH { PRIMARY | DISALLOW NULL | IGNORE NULL } для управления поведением NULL значений в индексе.
  • DISALLOW NULL — не допускает NULL в индексированных полях (по сути, делает поле NOT NULL).
  • IGNORE NULL — игнорирует строки с NULL значениями при создании индекса, что позволяет экономить место.
• SQL Server (T-SQL):

  CREATE UNIQUE NONCLUSTERED INDEX IX_Customers_Email ON Customers (Email);
  

  Особенности:

  • Явное указание CLUSTERED или NONCLUSTERED.
  • UNIQUE индекс в SQL Server может содержать одно NULL значение, если столбец допускает NULL.

Синтаксические различия в DML

INSERT INTO

• Access SQL:

  INSERT INTO [Сотрудники] ([Фамилия], [Имя]) VALUES ('Иванов', 'Иван');
  INSERT INTO [Сотрудники] SELECT [Фамилия], [Имя] FROM [НовыеСотрудники]; -- Ключевое слово INTO необязательно
  

  Особенности:

  • Ключевое слово INTO является необязательным перед оператором SELECT при добавлении данных из другой таблицы.
  • Если в запросе INSERT не указано поле с типом AutoNumber, Access автоматически перенумеровывает добавляемые записи.
• SQL Server (T-SQL):

  INSERT INTO Employees (LastName, FirstName) VALUES ('Петров', 'Петр');
  INSERT Employees (LastName, FirstName) VALUES ('Сидоров', 'Сергей'), ('Козлов', 'Андрей'); -- Вставка нескольких строк
  INSERT INTO Employees (LastName, FirstName) SELECT LastName, FirstName FROM NewEmployees;
  

  Особенности:

  • Ключевое слово INTO также является необязательным.
  • Поддерживает вставку нескольких строк с одним предложением VALUES (начиная с SQL Server 2008).
  • Поддерживает предложение OUTPUT для извлечения информации о вставленных строках (например, сгенерированных ID).

UPDATE

• Access SQL:

  UPDATE [Товары] SET [Цена] = [Цена] * 1.10 WHERE [Категория] = 'Книги';
  UPDATE [Заказы] AS O INNER JOIN [Клиенты] AS C ON O.[КодКлиента] = C.[КодКлиента] SET O.[Скидка] = 0.05 WHERE C.[Статус] = 'VIP';
  

  Особенности:

  • Позволяет изменять значения в одном или нескольких полях одной или нескольких таблиц одновременно.
  • Операции UPDATE в Access не могут быть отменены после выполнения, что требует осторожности.
  • Для UPDATE запросов, которые должны сохранять условие «обновляемости», часто исключается прямое использование агрегатных запросов в предложении SET, что может потребовать использования сохраненных агрегатных запросов или доменных агрегатных функций, таких как DLookUp().
• SQL Server (T-SQL):

  UPDATE Products SET Price = Price * 1.10 WHERE Category = 'Books';
  UPDATE O SET Discount = 0.05
  FROM Orders O JOIN Customers C ON O.CustomerID = C.CustomerID
  WHERE C.Status = 'VIP';
  UPDATE TOP (10) Employees SET Salary = Salary * 1.05 WHERE DepartmentID = 10;
  

  Особенности:

  • Поддерживает использование TOP для ограничения количества обновляемых строк.
  • UPDATE может выполняться на основе SELECT запросов с использованием JOIN или MERGE (для SQL Server 2008 и выше).
  • UPDATE выполняется в рамках транзакции и может быть отменен (ROLLBACK).

DELETE

• Access SQL:

  DELETE FROM [АрхивныеЗаказы] WHERE [ДатаЗаказа] < Date() - 365;
  DELETE R.* FROM [Проекты] AS P INNER JOIN [Задачи] AS R ON P.[КодПроекта] = R.[КодПроекта] WHERE P.[Статус] = 'Завершен';
  

  Особенности:

  • Если предложение WHERE опущено, удаляются все записи из таблицы.
  • Операции DELETE в Access не могут быть отменены.
  • Удаляет целые записи, а не только данные в конкретных полях (для удаления данных в отдельных полях следует использовать UPDATE с присвоением NULL).
  • Для удаления записей из нескольких таблиц на основе условий объединения необходимо явно указывать таблицу, из которой удаляются записи (например, DELETE R.* FROM ...).
• SQL Server (T-SQL):

  DELETE FROM ArchivedOrders WHERE OrderDate < DATEADD(year, -1, GETDATE());
  DELETE FROM Tasks WHERE ProjectID IN (SELECT ProjectID FROM Projects WHERE Status = 'Completed');
  DELETE TOP (100) FROM Logs WHERE LogDate < GETDATE() - 30;
  

  Особенности:

  • Если предложение WHERE опущено, все записи в таблице будут удалены.
  • Поддерживает использование TOP для ограничения количества удаляемых строк.
  • DELETE выполняется в рамках транзакции и может быть отменен (ROLLBACK).

Обработка литералов и подстановочные символы

• Строковые литералы:
  • Access: Заключаются в двойные кавычки (").
  • SQL Server: Заключаются в одинарные кавычки (').
• Значения дат:
  • Access: Окружаются символами решетки (фунта) (#). Пример: #2025-10-23#.
  • SQL Server: Заключаются в одинарные кавычки ('), часто в каноническом формате ODBC (гггг-мм-дд чч:мм:сс). Пример: '2025-10-23 14:30:00'.

• Подстановочные символы LIKE:
  Access поддерживает два набора подстановочных символов для оператора LIKE:
  • ANSI-89 (для файлов .mdb/.accdb):
    • *: Любое количество символов.
    • ?: Любой одиночный символ.
    • [ ]: Любой одиночный символ в скобках.
    • [! ]: Любой одиночный символ, не в скобках.
    • [ - ]: Любой одиночный символ в диапазоне.
  • ANSI-92 (для проектов Access, подключенных к SQL Server, и в самом SQL Server):
    • %: Любое количество символов (соответствует * в ANSI-89).
    • _: Любой одиночный символ (соответствует ? в ANSI-89).
    • [ ]: Любой одиночный символ в скобках.
    • [^ ]: Любой одиночный символ, не в скобках.
    • [ - ]: Любой одиночный символ в диапазоне.

  Пример:

  • Access (ANSI-89): SELECT * FROM Customers WHERE FirstName LIKE "J*"
  • SQL Server (ANSI-92): SELECT * FROM Customers WHERE FirstName LIKE 'J%'

Конкатенация строк и условные выражения

• Конкатенация строк:
  • Access: Использует оператор амперсанд (&). Пример: SELECT FirstName & " " & LastName FROM Employees;
  • SQL Server: Использует оператор плюс (+) или функцию CONCAT(). Пример: SELECT FirstName + ' ' + LastName FROM Employees; или SELECT CONCAT(FirstName, ' ', LastName) FROM Employees;
• Условные выражения:
  • Access: Для простых условных выражений часто используется функция IIF(condition, true_value, false_value).
  • SQL Server: Рекомендуется использовать оператор CASE, который является стандартным SQL и более универсальным для сложных условий. Функция IIF() была добавлена в SQL Server 2012 для совместимости с Access, но функционально идентична простому CASE.

  Пример IIF в Access:

  SELECT IIF(Stock > 0, 'В наличии', 'Нет в наличии') AS Status FROM Products;
  

  Пример CASE в SQL Server:

  SELECT CASE WHEN Stock > 0 THEN 'In Stock' ELSE 'Out of Stock' END AS Status FROM Products;
  

Функции работы с датами и агрегатные функции

• Функции работы с датами:
  • Access: Использует функции, такие как DateAdd(), DateDiff(), DatePart(), Format() (для форматирования даты).
  • SQL Server (Transact-SQL): Использует функции DATEADD(), DATEDIFF(), DATENAME(), DATEPART(), GETDATE() (для текущей даты/времени) и другие.
  • Важное отличие: DATEADD и DATEDIFF в T-SQL используют ключевое слово значения без кавычек (например, year), в отличие от строкового выражения в Access (например, "yyyy").

  Пример DATEDIFF в Access: DateDiff("yyyy", [ДатаРождения], Date())
  Пример DATEDIFF в SQL Server: DATEDIFF(year, DateOfBirth, GETDATE())

• Агрегатные функции:
  • Access: Поддерживает стандартные SQL-агрегатные функции (AVG(), COUNT(), MAX(), MIN(), SUM()) в SQL-запросах. Также имеет доменные агрегатные функции (DAvg(), DCount(), DSum()), которые могут вызываться из VBA-кода и использоваться в выражениях запросов, но SQL-агрегатные функции обычно более эффективны в SQL-запросах.
  • SQL Server: Поддерживает стандартные агрегатные функции и имеет значительно более широкий набор аналитических и оконных функций, которые обеспечивают мощные возможности для сложных вычислений и отчетности.

Ограничение выборки записей

• Access SQL: Для ограничения выборки записей используется SELECT TOP n [PERCENT] ... FROM table [ORDER BY ...]. Если ORDER BY не указан, возвращаются произвольные записи.

  SELECT TOP 10 [НазваниеПродукта], [Цена] FROM [Товары] ORDER BY [Цена] DESC;
  

• SQL Server (T-SQL): Также используется SELECT TOP (expression) [PERCENT] ... FROM table [ORDER BY ...]. Рекомендуется всегда использовать ORDER BY для предсказуемых результатов. SQL Server 2012 и более поздние версии также поддерживают предложение OFFSET N ROWS FETCH NEXT M ROWS ONLY для реализации постраничной выборки, которое обязательно требует наличия предложения ORDER BY.

  SELECT TOP (10) ProductName, Price FROM Products ORDER BY Price DESC;
  SELECT ProductName, Price FROM Products ORDER BY Price DESC OFFSET 10 ROWS FETCH NEXT 5 ROWS ONLY; -- 5 записей, начиная с 11-й
  

Транзакции

Транзакции — это последовательность операций, которая выполняется как единое целое, обеспечивая свойства ACID.

• Access SQL: Поддерживает явные транзакции с использованием BEGIN TRANSACTION, COMMIT [TRANSACTION | WORK] и ROLLBACK [TRANSACTION | WORK]. Транзакции не запускаются автоматически и могут быть вложенными до пяти уровней. Они не поддерживаются для связанных таблиц.

  BEGIN TRANSACTION;
  INSERT INTO [Заказы] ...;
  UPDATE [Склад] ...;
  COMMIT TRANSACTION;
  

• SQL Server (T-SQL): Явные транзакции управляются командами BEGIN TRANSACTION (или BEGIN TRAN), COMMIT TRANSACTION (или COMMIT TRAN) и ROLLBACK TRANSACTION (или ROLLBACK TRAN). SQL Server обеспечивает выполнение свойств ACID (Атомарность, Согласованность, Изолированность, Долговечность). Он также поддерживает неявные (implicit) и автоматические (autocommit) транзакции, а также SAVEPOINT для частичного отката. Некоторые операции DDL могут быть запрещены в явном блоке транзакции или иметь специфическое поведение (например, авто-коммит).

  BEGIN TRANSACTION;
  INSERT INTO Orders ...;
  UPDATE Stock ...;
  COMMIT TRANSACTION;
  -- Или ROLLBACK TRANSACTION;
  

Хранимые процедуры, пользовательские функции и параметры

• Access:
  • Хранимые процедуры: В Access нет встроенной поддержки хранимых процедур в том смысле, как в SQL Server. VBA-код может вызывать серверные хранимые процедуры (если Access работает как фронтенд к SQL Server).
  • Пользовательские функции: Обычно реализуются на VBA.
  • Параметры: Для создания параметризованных запросов, запрашивающих ввод пользователя, используется объявление PARAMETERS. Параметры могут быть переданы в запросы Access, которые затем могут быть отправлены на SQL Server через связанные таблицы или сквозные запросы.

  PARAMETERS [НачальнаяДата] DATETIME, [КонечнаяДата] DATETIME;
  SELECT * FROM [Заказы] WHERE [ДатаЗаказа] BETWEEN [НачальнаяДата] AND [КонечнаяДата];
  

• SQL Server:
  • Хранимые процедуры (Stored Procedures): Широко используются. Могут выполнять DML-операции (INSERT, UPDATE, DELETE), содержать сложную бизнес-логику, управлять транзакциями и возвращать несколько результирующих наборов. Могут иметь как входные, так и выходные параметры. Не могут быть напрямую использованы в SELECT, WHERE или JOIN предложениях.
  • Пользовательские функции (User-Defined Functions — UDF): Предназначены для вычислений, возвращают одно скалярное значение или табличный результат. Не могут выполнять DML-операции и принимают только входные параметры. Могут быть использованы в SELECT, WHERE или JOIN предложениях.

  Пример хранимой процедуры в SQL Server:

  CREATE PROCEDURE GetOrdersByDateRange
      @StartDate DATE,
      @EndDate DATE
  AS
  BEGIN
      SELECT * FROM Orders WHERE OrderDate BETWEEN @StartDate AND @EndDate;
  END;
  

  Пример пользовательской функции в SQL Server:

  CREATE FUNCTION GetFullName (@FirstName NVARCHAR(50), @LastName NVARCHAR(50))
  RETURNS NVARCHAR(101)
  AS
  BEGIN
      RETURN @FirstName + ' ' + @LastName;
  END;
  SELECT dbo.GetFullName(FirstName, LastName) FROM Employees;
  

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

Заключение

Проведение глубокого сравнительного анализа реализации языка SQL в Microsoft Access и Microsoft SQL Server позволило выявить как фундаментальные сходства, так и критически важные различия между этими двумя системами управления базами данных. Это исследование подтверждает, что, несмотря на общее происхождение и принадлежность к экосистеме Microsoft, Access и SQL Server предназначены для решения качественно разных задач и предлагают существенно отличающиеся подходы к управлению данными.

Основные сходства заключаются в базовой поддержке реляционной модели данных и стандарта SQL для выполнения типовых операций DML (SELECT, INSERT, UPDATE, DELETE) и основных аспектов DDL (CREATE TABLE, PRIMARY KEY, FOREIGN KEY). Обе СУБД стремятся обеспечить целостность данных и предлагают механизмы для оптимизации запросов с помощью индексов.

Однако ключевые различия проявляются на всех уровнях:

1. Архитектура: Access функционирует как файловая СУБД с движком Jet/ACE, оптимальная для небольших, однопользовательских настольных приложений, с ограничением размера базы данных в 2 ГБ. SQL Server — это мощная клиент-серверная система, разработанная для высокопроизводительных, масштабируемых корпоративных решений с поддержкой терабайтов данных и тысяч пользователей.
2. Типы данных: SQL Server предлагает значительно более широкий и детализированный набор стандартных и специализированных типов данных, что обеспечивает большую гибкость и точность хранения информации, в то время как Access имеет более ограниченный набор и специфические названия.
3. Ограничения целостности: Обе СУБД поддерживают первичные, внешние, уникальные и NOT NULL ограничения. Однако SQL Server предоставляет более robustные механизмы, включая полный спектр каскадных операций (CASCADE, SET NULL) и программные триггеры, а также автоматическую проверку данных при добавлении ограничений. В Access некоторые ограничения, такие как CHECK, требуют обходных путей через ADO.
4. Индексы: Access автоматически индексирует первичные ключи и позволяет создавать простые пользовательские индексы. SQL Server, напротив, предлагает сложную и гибкую систему индексирования, включая кластеризованные (определяющие физический порядок данных) и некластеризованные индексы, а также специализированные и покрывающие индексы, работающие в тандеме с мощным оптимизатором запросов.
5. Представления: В Access аналогом представлений являются «сохраненные запросы», которые могут быть параметризованными и интегрированы с графическим интерфейсом. SQL Server предоставляет полноценные VIEW с опциями шифрования и привязки к схеме, а также уникальную возможность создания индексированных (материализованных) представлений для ускорения сложных аналитических запросов.
6. Синтаксис SQL (DDL, DML): Несмотря на общую базу, диалекты Access SQL и Transact-SQL имеют многочисленные различия в именовании типов, синтаксисе DDL-операций, использовании литералов (кавычки для строк, решетки для дат в Access), подстановочных символах, функциях работы с датами, методах конкатенации строк и условных выражений (IIF vs. CASE). SQL Server также предлагает более продвинутые функции для ограничения выборки (OFFSET...FETCH), расширенные транзакционные возможности и мощную поддержку хранимых процедур и пользовательских функций, отсутствующих в Access как встроенные объекты.

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

Практические рекомендации

Выбор между MS Access и MS SQL Server должен основываться на тщательном анализе требований к проекту:

• Microsoft Access является идеальным выбором для:
  • Небольших локальных баз данных: Для личных нужд, малых отделов или проектов с ограниченным числом пользователей.
  • Быстрой разработки приложений (RAD): Когда необходимо оперативно создать прототип или инструмент с простыми формами и отчетами.
  • Обучения основам баз данных: Благодаря интуитивно понятному графическому интерфейсу и упрощенному SQL.
  • Фронтенда к серверной СУБД: В качестве клиентского приложения, предоставляющего графический интерфейс для данных, хранящихся в SQL Server.
• Microsoft SQL Server незаменим для:
  • Крупных корпоративных систем: Где требуются высокая производительность, масштабируемость, надежность и безопасность для большого числа одновременных пользователей и объемов данных.
  • Веб-приложений и распределенных систем: К��к мощный бэкенд для критически важных бизнес-приложений.
  • Сложной бизнес-логики и аналитики: С поддержкой хранимых процедур, функций, триггеров и продвинутых аналитических возможностей.
  • Систем, требующих строгой целостности данных и отказоустойчивости: Благодаря полной поддержке транзакций ACID и развитым механизмам резервного копирования/восстановления.

Дальнейшие исследования

Данная курсовая работа заложила основу для понимания различий между Access и SQL Server. Возможные направления для дальнейших исследований включают:

• Анализ миграции данных: Детальное исследование процессов и инструментов для миграции баз данных из Access в SQL Server, включая сопоставление схем, типов данных и оптимизацию запросов.
• Совместимость приложений: Глубокий анализ того, как приложения, разработанные для Access, могут быть адаптированы для работы с SQL Server в качестве бэкенда, и какие изменения в коде VBA могут потребоваться.
• Сравнение производительности: Проведение серии контролируемых тестов производительности для различных операций (выборка, вставка, обновление, удаление) на базах данных Access и SQL Server с сопоставимыми объемами данных.
• Сравнение с другими СУБД: Расширение сравнительного анализа на другие популярные реляционные СУБД, такие как MySQL, PostgreSQL или Oracle, для получения более широкой перспективы.

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

Список использованной литературы

1. Comparison of different SQL implementations. Хабрахабр – «К» – (http://troels.arvin.dk/db/rdbms/)
2. Eisenberg A., Melton J., Kulkarni K., Michels J.-E., Zemke F. SQL:2003 Has Been Published. ACM SIGMOD Record. 2004. Vol. 33, № 1.
3. Астахова И. Ф., Толстобров А. П., Мельников В. М. SQL в примерах и задачах. М.: Новое знание, 2002. 176 с.
4. Виейра Р. Программирование баз данных Microsoft SQL Server 2005 для профессионалов. М.: ООО «И.Д. Вильямс», 2008. 1072 с.
5. Гандерлой М., Джорден Д., Чанц Д. Освоение Microsoft SQL Server 2005. М.: ООО «И.Д. Вильямс», 2007. 1104 с.
6. Грабер М. SQL. Описание SQL92, SQL99 и SQLJ. М.: Лори, 2001. 644 с.
7. Грабер М. SQL. Справочное руководство. М.: Лори, 2001. 354 с.
8. Грабер М. Понимание SQL. М.: Лори, 1993. 420 с.
9. Грабер М. Справочное руководство по SQL. М.: Лори, 1997. 291 с.
10. Грофф Дж., Вайнберг П. Н. SQL: Полное руководство. Киев: Издательская группа BHV, McGraw–Hill Companies, 2001. 816 с.
11. Грофф Дж. Энциклопедия SQL. 3-е изд. СПб.: Питер, 2003. 896 с.
12. Дворжецкий А. SQL: Structured Query Language. Руководство пользователя. М.: Познавательная Книга Плюс, 2001. 416 с.
13. Дейт К. Введение в системы баз данных. 7-е изд. М.: Издательский дом «Вильямс», 2001. 1072 с.
14. Кириллов В. В., Громов Г. Ю. Структуризированный язык запросов. Кузнецов С. Д. Санкт-Петербургский Государственный институт точной механики и оптики (технический университет) Кафедра вычислительной техники – «К». – (http://www.citforum.ru/database/sql_kg/index.shtml)
15. Кириллов В. В. Структурированный язык запросов (SQL). СПб.: ИТМО, 1994. 80 с.
16. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е изд. М.: Издательский дом «Вильямс», 2003. 1440 с.
17. Костюк А. И. Базы данных и знаний. Таганрог: Изд-во ТРТУ, 1999. 177 с.
18. Кузнецов С. SQL. Язык реляционных баз данных. М.: Майор, 2001. 192 с.
19. Кузнецов С. Д. Введение в стандарты языка баз данных SQL. Центр Информационных Технологий – «К». – (http://www.citforum.ru/database/sqlbook/index.shtml)
20. Кузнецов С. Д. Язык реляционных баз данных SQL и его стандарты. Центр Информационных Технологий – «К». – (http://www.citforum.ru/database/articles/art_18.shtml)
21. Кузнецов С. Д. Три манифеста баз данных: ретроспектива и перспективы. URL: http://www.citforum.ru/database/articles/manifests/ (дата обращения: 23.10.2025).
22. Кузнецов С. Д. Наиболее интересные новшества в стандарте SQL:2003. Центр Информационных Технологий – «К». – (http://www.citforum.ru/database/sql/sql2003/)
23. Мамаев Е. В. Microsoft SQL Server 2000. СПб.: БХВ-Петербург, 2001. 1280 с.
24. Нильсен П. MS SQL Server 2005. Библия пользователя. М.: ООО «И.Д.Вильямс», 2008. 1232 с.
25. Работа с базами данных для пользователей. Академия специальных курсов по компьютерным технологиям – «К» – (http://www.askit.ru/custom/db_basics/db_basics_plan.htm)
26. Райордан Р. Основы реляционных баз данных. М.: Издательско-торговый дом «Русская Редакция», 2001. 384 с.
27. Сичкаренко В. А. SQL–99. Руководство разработчика баз данных. М.: ДиаСофтЮП, 2002. 816 с.
28. Сравнение языков запросов microsoft access SQL и ansi SQL. Microsoft Office Access. URL: http://office.microsoft.com/ru-ru/access/HA012314361049.aspx (дата обращения: 23.10.2025).
29. Федоров А., Елманова Н. Введение в язык SQL. Введение в базы данных – «К». – (http://www.lib.csu.ru/dl/bases/prg/kompress/articles/2000_10_DBMS6/)
30. Хичкок Б. Настольная книга администратора. М.: ЛОРИ, 2000.
31. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных. 4-е изд., доп. и перераб. СПб.: КОРОНАпринт, 2004. 736 с.
32. Simplilearn.com. What is Transact SQL (T-SQL) and Its Type of Functions? URL: https://www.simplilearn.com/what-is-transact-sql-article (дата обращения: 23.10.2025).
33. Microsoft Support. Use wildcards in queries and parameters in Access. URL: https://support.microsoft.com/en-us/office/use-wildcards-in-queries-and-parameters-in-access-77114251-8761-4696-a82e-9d0c6487b322 (дата обращения: 23.10.2025).
34. Tutorials Point. MS Access — Wildcards. URL: https://www.tutorialspoint.com/ms_access/ms_access_wildcards.htm (дата обращения: 23.10.2025).
35. Microsoft Support. Access wildcard character reference. URL: https://support.microsoft.com/en-us/office/access-wildcard-character-reference-5272a9df-6d74-42f0-9118-20817032179f (дата обращения: 23.10.2025).
36. Tutorials Point. T-SQL — Functions. URL: https://www.tutorialspoint.com/t-sql/t_sql_functions.htm (дата обращения: 23.10.2025).
37. Microsoft Learn. String Functions (Transact-SQL) — SQL Server. URL: https://learn.microsoft.com/en-us/sql/t-sql/functions/string-functions-transact-sql (дата обращения: 23.10.2025).
38. Programiz. SQL Wildcards (With Examples). URL: https://www.programiz.com/sql/wildcards (дата обращения: 23.10.2025).
39. GeeksforGeeks. SQL Wildcard Characters. URL: https://www.geeksforgeeks.org/sql-wildcard-characters/ (дата обращения: 23.10.2025).
40. Microsoft Support. Access Functions (by category). URL: https://support.microsoft.com/en-us/office/access-functions-by-category-72504953-2900-410a-912a-63795b583f7a (дата обращения: 23.10.2025).
41. W3Schools. MS Access Functions. URL: https://www.w3schools.com/sql/sql_ref_msaccess.asp (дата обращения: 23.10.2025).
42. SQLServerCentral. Fine-grained Access Control for Stored Procedures. URL: https://www.sqlservercentral.com/articles/fine-grained-access-control-for-stored-procedures (дата обращения: 23.10.2025).
43. W3Schools. SQL Stored Procedures. URL: https://www.w3schools.com/sql/sql_stored_procedures.asp (дата обращения: 23.10.2025).
44. Microsoft Access Visual Basic Documentation. CREATE TABLE statement (Microsoft Access SQL). URL: https://learn.microsoft.com/en-us/office/vba/access/concepts/structured-query-language/create-table-statement-microsoft-access-sql (дата обращения: 23.10.2025).
45. Great Learning. SQL Commands: DML and DDL in SQL. URL: https://www.greatlearning.in/blog/sql-commands/ (дата обращения: 23.10.2025).
46. IIF VS CASE VS CHOOSE | STATEMENTS IN SQL SERVER. URL: https://www.youtube.com/watch?v=R9j0mX2gJzU (дата обращения: 23.10.2025).
47. W3Schools. SQL Introduction. URL: https://www.w3schools.com/sql/default.asp (дата обращения: 23.10.2025).
48. Scribd. CREATE TABLE Statement (Microsoft Access SQL) — Microsoft Docs PDF. URL: https://www.scribd.com/document/349479326/CREATE-TABLE-Statement-Microsoft-Access-SQL-Microsoft-Docs-pdf (дата обращения: 23.10.2025).
49. YouTube. Differences in SQL Syntax Between Microsoft Access and SQL Server. URL: https://www.youtube.com/watch?v=Fj-e67c8y9g (дата обращения: 23.10.2025).
50. DBA Stack Exchange. sql server — Is select case when null better than iif(exists)? URL: https://dba.stackexchange.com/questions/21351/is-select-case-when-null-better-than-iifexists (дата обращения: 23.10.2025).
51. Quora. Can you use the IIF function and CASE statement together in an SQL query? URL: https://www.quora.com/Can-you-use-the-IIF-function-and-CASE-statement-together-in-an-SQL-query (дата обращения: 23.10.2025).
52. Why DateAdd() and DATEDIFF() gives different result and which is better in performance? URL: https://www.youtube.com/watch?v=yW81f-fX324 (дата обращения: 23.10.2025).
53. Microsoft Learn. DATEADD (Transact-SQL) — SQL Server. URL: https://learn.microsoft.com/en-us/sql/t-sql/functions/dateadd-transact-sql (дата обращения: 23.10.2025).
54. Microsoft Access Visual Basic Documentation. PARAMETERS declaration (Microsoft Access SQL). URL: https://learn.microsoft.com/en-us/office/vba/access/concepts/structured-query-language/parameters-declaration-microsoft-access-sql (дата обращения: 23.10.2025).
55. Microsoft Access Visual Basic Documentation. Domain Aggregate Functions. URL: https://learn.microsoft.com/en-us/office/vba/access/concepts/functions/domain-aggregate-functions (дата обращения: 23.10.2025).
56. Microsoft Support. Use parameters to ask for input when running a query. URL: https://support.microsoft.com/en-us/office/use-parameters-to-ask-for-input-when-running-a-query-588482a5-429a-41d3-9799-73f139f13110 (дата обращения: 23.10.2025).
57. Built In. SQL Functions with Examples. URL: https://builtin.com/data-science/sql-functions (дата обращения: 23.10.2025).
58. Access Experts. Alternative Solution to DCount and DLookup with MS SQL Server Backend. URL: https://accessexperts.com/blog/2014/11/04/alternative-solution-to-dcount-and-dlookup-with-ms-sql-server-backend/ (дата обращения: 23.10.2025).
59. SQLTeam.com. pass parameter from access to sql server — SQL Server Forums. URL: https://www.sqlteam.com/forums/topic.asp?TOPIC_ID=158784 (дата обращения: 23.10.2025).
60. Microsoft Support. SQL Aggregate Functions. URL: https://support.microsoft.com/en-us/office/sql-aggregate-functions-36814c8d-7132-4d2d-947f-8d77c4125d08 (дата обращения: 23.10.2025).