GUID в роли быстрого первичного ключа для разных БД

Эта статья раскрывает подходы по использованию GUID в роли первичного ключа или кластерного индекса при этом описываются способы обхода основных неудобств связанных с GUID, на основании COMB модели для последовательных значений GUID разработанных в статье Джимми Нильсона. Большинство реализаций являются специфичными для MS SQL Server, в то время как основная идея похоже используется во многих библиотеках и фреймворках(включая NHibernate). В статье предпринимается попытка использовать общий гибкий подход для возможности использования COMB в других популярных базах данных: Oracle, PostgreSQL, MySQL. Так же мы рассмотрим некоторые особенности .net в свете наших задач.

Проблематика GUID

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

Тем не менее, есть некоторое количество ситуаций, когда такой подход не будет хорош. При широком применении ORM фреймворков большинство пользователей стараются избежать лишних сложностей на стороне БД, а формирование ключа на стороне БД к таким сложностям можно отнести. Репликация баз данных так же становится затруднительной, если полагаться только на единственный внутрибазовый сервис для генерации ключей. Требуется внешний источник для минимизации зависимостей от того, как генерируются ключи.

Одной из альтернатив становится использование GUID в роли первичного ключа. GUID — это 128-битное значение, которое поддерживает разумно-гарантированную уникальность независимо от времени и пространства. Стандарт для создания GUID описан в документе RFC 4122, но большинство современных алгоритмов по созданию GUID используют либо очень большое случайное число, либо формируют значение исходя из некоторой случайной информации комбинированной с чем-то локальным (ранее такое формирование было у MS, они создавали GUID на основе MAC адреса, но в последствии это было не безопасно и так же нарушало privacy).

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

Так в чем же проблема?

Подробнее

Eloquera V

краткое описание / немного истории / установка / режимы работы базы: service, inmemory, desktop / восстановление базы
конфигурация / программная конфигурация / простейшие операции CRUD / insert / update / refreshMode / delete
построение запросов / joins / параметры / массивы / шаблонные контейнеры / order by / доступные функции / almos
хранимые процедуры
родные и динамические объекты / работа с массивами / контейнеры / фильтрация типов, свойств и полей / backup and restore / эволюция типов / fulltext search / индексация / под капотом

«Родные» и динамические объекты

Под родными объектами в данном случае подразумеваются любые типы принадлежащие CLR или созданные вами. Eloquera может на лету (в runtime) конвертировать динамические объекты в «родные» и обратно.

Внимание!

Для использования этого функционала должно быть открыто соединение к базе.

Основные методы для конвертации:

  • ToNative<ConcretType>()
  • FromNative(variable)

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

При обновлении данных применяются следующие схемы работы:

  • Обновление через родной тип

0    Динамический тип переводим в «родной» тип

0    Изменяем «родной» тип

0    Обновляем (синхронизируем) динамический тип с помощью FromNative

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

0    Существует переменная конкретного типа с данными динамического

0    Изменяем динамический тип

0    Обновляем (синхронизируем) «родной» тип с помощью ToNative<T>(variable)

Подробнее

Eloquera IV

краткое описание / немного истории / установка / режимы работы базы: service, inmemory, desktop / восстановление базы
конфигурация / программная конфигурация / простейшие операции CRUD / insert / update / refreshMode / delete
построение запросов / joins / параметры / массивы / шаблонные контейнеры / order by / доступные функции / almos
хранимые процедуры

Хранимые процедуры

Начиная с версии 4.0 Eloquera поддерживает хранимые процедуры. Я думаю, не стоит расписывать все прелести и возможности хранимых процедур. Те, кто работают с базами и так их знают. Хочу только заметить, что результат выполнения хранимой процедуры остается, связан с контекстом базы, а значит, полученные данные можно изменять и обновлять объекты в базе.

Хранимые процедуры могут рассматриваться как методы расширения к основной базе. Они пишутся с использованием C#, за что благодарность создателям, за то, что они не выдумали какой-либо свой интерпретируемый диалект для этого дела. Получается, что можно использовать все возможность .Net при написании процедур.

Итак, хватит слов, лучше показать, как создаются хранимые процедуры на деле.

Первым делом надо объявить интерфейс  с желаемыми процедурами. Данный интерфейс должен находиться на стороне клиента и сервера.

Затем создаем класс, который нужен будет только на стороне сервера. При этом библиотеку с реализацией процедуры надо поместить в папку Lib в директории базы, либо настроить путь до библиотек с хранимыми процедурами с помощью параметра StoredProceduresPath.

Добавление новых процедур не требует перезапуска сервиса базы данных.

Подробнее

Eloquera III

краткое описание / немного истории / установка / режимы работы базы: service, inmemory, desktop / восстановление базы
конфигурация / программная конфигурация / простейшие операции CRUD / insert / update / refreshMode / delete
построение запросов / joins / параметры / массивы / шаблонные контейнеры / order by / доступные функции / almos

Построение запросов

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

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

  • ExecuteQuery(string query)
  • ExecuteScalar(string query)

Обе функции имеют перегруженные варианты для возможности указания глубины запрашиваемых объектов, параметров.  Да-да, можно строить параметризированные запросы.

Общий вид и порядок служебных слов в запросе тот же, что и в «обычном» SQL . Если делается запрос к одной сущности, то слово from можно опустить. Например:

Eloquera поддерживает операторы TOP, SKIP, Order by (подробно будет чуть позже).

Запросы можно строить не только для собственных полей класса, но и обращаться к составным полям, массивам. Сложный объект может содержать другие объекты или массивы, например:

Подробнее

Eloquera II

краткое описание / немного истории / установка / режимы работы базы: service, inmemory, desktop / восстановление базы
конфигурация / программная конфигурация / простейшие операции CRUD / insert / update / refreshMode / delete

Конфигурация

Файл конфигурации в поставке для автономной работы (Desktop mode) по умолчанию выглядит следующим образом:

 

Прошу обратить внимание на то, что путь для баз данных не указан. Для корректной работы надо будет его дописать, используя атрибут DatabasePath в узел Server.

Внимание!

С версии 4.0 можно полностью игнорировать файл настройки и задание директории для хранения баз данных. Eloquera самостоятельно все определит и настроит.

Подробнее

Eloquera I

краткое описание / немного истории / установка / режимы работы базы: service, inmemory, desktop / восстановление базы

Краткое описание базы

База данных Eloquera с самого начала была написана для хранения объектов  на основе .Net Framework, что сделало возможным попытаться вобрать в себя все лучшее от объектных и реляционных баз данных одновременно, преодолев многие их различия. Теоретически Eloquera может работать с любыми объектами из семейства .Net Framework, однако на практике работа проверялась пока только с C#. Главная ориентированность разработчиков на enterprise сегмент, а не на embedded решения.

Отличительные особенности Eloquera весьма внушительны и постоянно пополняются, вот их примерный список:

  • Сохраняет C# объекты (любые объекты любого языка на .Net платформе) без необходимости реализации специальных интерфейсов и адаптеров.
  • Сохраняет Dynamic объекты с любыми полями\свойствами и может сопоставить их объектам любого типа.
  • Язык запросов максимально приближен к SQL, при этом не требуется наличие какой либо реляционной SQL базы.
  • Поддержка LINQ.
  • Возвращает объекты в том виде, в котором они были сохранены (включая перечислимые типы)
  • Поддержка параметров в виде списков и массивов. В свою очередь массивы могут быть многомерными – синтаксис запросов остается неизменным.
  • Поддержка функций и выражений в запросах и конструкции ORDER BY.
  • Стандартный и расширенный ORDER BY.
  • Регулярные выражения в запросах.
  • Индексация и оптимизация запросов.
  • Пакетная вставка и обновление данных.
  • Поддержка шаблонных объектов.
  • Восстановление Read-only полей и свойств.
  • Учет классов наследников в запросах. Select ParentClass вернет и ParentClass и ChildClass.
  • Возможность построения запросов относительно указанного типа. Select ONLY ParentClass вернет только ParentClass без ChildClass.
  • Поддерживается частичный возврат объектов. Например, если вам требуется класс ForumTopic, тогда можно не подтягивать все ссылки на ForumMessages.
  • Можно указать глубину объекта для возврата в запросе.
  • Клиент-серверная архитектура.
  • Возможность одновременной работы с несколькими пользователями. Запросы выполняются одновременно и независимо.
  • Аутентификация через Windows аккаунты или через механизмы Eloquera.
  • Поддержка х86 и х64.
  • Уникальные идентификаторы для каждого объекта – отлично подходит для работы в системах не хранящих состояние и ASP.NET.
  • Поддержка культур. Например WHERE dates BETWEEN[‘en-US’] @d1 and @d2 будет интерпретировано в US формате, даже если текущий язык системы русский.
  • Нестрогий поиск c использованием конструкции ALMOST.
  • Хранимые процедуры.

MS SQL 2011 (Denali) – Автономная база данных

В течение последних лет Microsoft внедрила множество интересных технологий, которые прочно вошли в арсенал разработчиков. Кардинальные изменения были включены в SQL Server 2005, после чего SQL Server 2008 развил и укрепил успех. Denali несет в себе множество новых инструментов, а так же расширений функционала для существующих. В этой статье в деталях рассмотрим один из новых инструментов, который, я уверен, придется по душе разработчикам баз данных. Этот инструмент, фича ­ – автономные базы данных (Contained Database). Рассмотрим что они собой представляют, как с ними работать, к чему можно применить и другие вещи.

Что не так с текущими базами?

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

Вот некоторые из ключевых проблем:

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

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

Подробнее

SQL Change Master — II

Работа в консольном режиме

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

Changecontroller.exe alias=dev log=”c:\temp\log.txt” showlog

Данная запись говорит, что надо найти и запустить обновление для окружения dev, лог выполнения записать в файл log.txt в папке c:\temp и после выполнения обновления показать лог. На мой взгляд, все достаточно просто и применимо в различных ситуациях, как для Continuous Integration, так и для работы в студии. Можно и просто вставлять в батнички для обновления многих настроек окружения.

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

Changecontroller.exe alias=dev base=testbasea

Данная запись говорит, что надо найти обновление для окружения dev, для базы testbasea и запустить скрипты обновлений.

Если вы что-то указали неверно, или же программа не может найти указанное окружение или базу данных, то SQL Change Master запуститься в графическом режиме.

Работа в студии

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

Итак, для работы нам понадобится SQL Change Master и датабазный проект от МS.

Настройка датабазного проекта

Создаем новый проект. File > New Project…

В появившемся окне выбираем шаблоны для баз данных для SQL Server и в них находим, к примеру, SQL Server 2008 Database Project.

Обратите внимание, что название проекта должно в точности совпадать с названием базы данных, которое было указано в SQL Change Master.

Подробнее

SQL Change Master — I

Из истории вопроса

Прежде чем приступить к описанию программы, я бы хотел осветить сам вопрос работы с базой данных по гибким методологиям. Или лучше сказать итеративное развитие базы данных, когда изменения в базу вносятся тогда, когда они нужны. Когда база развивается одновременно с приложением и, по сути, идет модель Code First, тогда база отвечает потребностям кода, а не код старается подстроиться под базу.

Я думаю, что для большинства, вполне очевидно, что модель хранения данных, и модель работы с данными, это две слабо пересекающиеся модели. Еще было бы замечательно поделить это все на модели/структуры для чтения и модели/структуры для  записи. Но это отдельная огромная тема, которую я не готов раскрыть.

Итак, в начальных условиях у нас в идеале новый проект, green field, или как минимум еще не выпущенный в релиз (разработчики любят начинать все с нуля). Но ничто по большому счету не мешает применить практики итеративного обновления данных и для выпущенного проекта. Если вы используете у себя итеративную поставку, то почему база должна отличаться?

На тему подходов к разработке БД и хранению ее скриптов в системе контроля версий сломано немало копий. Многие крупные разработчики предлагают свои решения, как программные, так и организаторского плана. Хороший обзор получился у  Outcoldman’а, описываются основные подходы к решению обновления БД и хранению истории с помощью проектов от Microsoft, Red Gate, еще каких-то разработчиков. Есть у всех свои слабые и сильные стороны. Я, так же как и Outcoldman, придерживаюсь мнения, что надо писать собственные скрипты обновления и использовать либо готовые решения, либо самому написать простейшие управляющие вещи, по выполнению этих скриптов.

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

  • Миграция данных
  • Переименование через drop\create
  • Атомарность обновлений
  • Однозначное определение текущего состояния базы

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

Подробнее

SQL Changes Master

В данном видео (подкатом) я рассказываю о программе для итеративного обновления баз данных.

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

Подробнее