Я люблю базы данных. Мне нравится организация, структура, простота. Мне нравится разбивать сложную концепцию на отдельные части, что в конечном итоге раскрывает ее основную суть. Мне доставляет удовольствие определять четко определенные связи. Здесь нет места двусмысленности или избыточности. Это наилучшим образом способствует моему ОКР.

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

На SQL или NoSQL?

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

Базы данных SQL содержат реляционные наборы данных:

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

Базы данных NoSQL содержат нереляционные или распределенные наборы данных:

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

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

Итак, теперь вы готовы строить, верно? Но КАК вы строите свою базу данных и запрашиваете ее? Это в конечном итоге поднимает еще одну горячую тему ...

ORM или традиционный SQL?

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

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

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

  • Разработайте базу данных - создайте схему или коллекцию с учетом потребностей вашей системы. Определите каждый столбец и его тип данных, определите любые значения по умолчанию или автоматически обновляемые значения, такие как отслеживание даты и времени, определите первичные ключи или индексированные значения, которые помогают ускорить выполнение поисковых запросов, и определите внешние ключи, которые сопоставляют таблицы для реляционных баз данных.
  • Создание базы данных. Запустите сценарий выполнения из командной строки, чтобы создать базу данных. Вы также можете запускать его из своего кода, если вы устанавливаете исключения, чтобы избежать запуска при каждом запуске программы.
  • Заполнить базу данных - используйте образцы данных или начальный набор для заполнения базы данных. Это поможет вам убедиться, что схема настроена правильно. Это также позволяет вам начать выполнение и тестирование запросов.
  • Резервное копирование базы данных - настройте процесс и расписание для резервного копирования ваших данных. Это важно, чтобы избежать проблем в будущем, если база данных или данные будут повреждены или потеряны. Во время цикла разработки также полезно разрешить откат кода в случае ошибки.
  • Установите соединение с базой данных. База данных, создаваемая либо непосредственно с вашего сервера, либо через ORM, должна быть инициализирована в вашем коде при запуске приложения. Вам также необходимо убедиться, что ваша база данных запускается локально на вашем компьютере. Возможно, вам придется объединить соединения в пул, учитывая вашу конкретную настройку.
  • Создание запросов. Чтобы извлечь данные из базы данных, вам нужно будет либо создавать запросы на необработанном SQL, либо обращаться к документации ORM, чтобы определить лучший способ извлечения данных.
  • Оптимизируйте! . Один из способов оптимизации - это учитывать временную сложность при построении необработанных SQL-запросов. Я оставлю вам один пример того, как порядок выполнения может улучшить ваши запросы.

Рассмотрим ниже:

SELECT count(id), date(created_at, 'weekday 1'), status FROM records WHERE created_at >= '2017-07-01' AND created_at <= '2017-09-01' GROUP BY date(created_at, 'weekday 1'), status;

Вышеупомянутый запрос вполне приемлем. Как написано, WHERE будет выполняться перед GROUP BY, поэтому он будет выполняться для каждой записи в таблице. Это нормально, если у вас есть 20 или 100 записей. Но по мере роста набора данных это может создать нагрузку на систему.

Теперь попробуйте другой подход:

SELECT count(id), date(created_at, 'weekday 1'), status FROM records GROUP BY status
HAVING date(created_at, 'weekday 1') BETWEEN '2017-07-01' AND '2017-09-01';

В этом случае HAVING будет выполняться после предложения GROUP BY. Таким образом, он будет выполняться только для пост-агрегированных записей. Вы сэкономите время выполнения, но получите тот же результат. Эта небольшая экономия времени может накапливаться по мере роста вашего набора данных. Так что будьте бдительны!

А теперь иди и завоюй эти данные!