Статьи

Прекратить утверждать, что вы используете базу данных без схемы

Февраль 15, 2019

Одним из аргументов MongoDB при евангелизации MongoDB является тот факт, что MongoDB является базой данных «без схемы» :

Почему без схемы?

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

И это правда. Но это не значит, что схемы нет. На самом деле существуют различные схемы:

  • Тот, который у вас в голове, когда вы проектировали структуры данных
  • Тот, который ваша база данных действительно реализовала для хранения ваших структур данных
  • Тот, который вы должны были реализовать, чтобы выполнить ваши требования

Каждый раз, когда вы понимаете, что допустили ошибку (см. Пункт три выше) или когда ваши требования меняются, вам нужно будет перенести ваши данные. Давайте еще раз рассмотрим точку зрения MongoDB здесь:

При использовании базы данных без схемы 90% временных настроек базы данных становятся прозрачными и автоматическими. Например, если мы хотим добавить GPA к объектам ученика, мы добавляем атрибут, сохраняем, и все хорошо — если мы ищем существующего студента и ссылаемся на GPA, мы просто возвращаем нуль. Кроме того, если мы откатим наш код, новые поля GPA в существующих объектах вряд ли вызовут проблемы, если наш код был хорошо написан.

Все выше тоже верно.

«Без схемы» против «Схемы»

Но давайте переведем это в SQL (или вместо этого воспользуемся любой другой «схематичной» базой данных):

1
ALTER TABLE student ADD gpa VARCHAR(10);

И мы сделали! Ну и дела, мы добавили столбец, и мы добавили его во все строки. Это было прозрачно. Это было автоматически. Мы «просто возвращаемся к нулю» на существующих студентов. И мы можем даже «откатить наш код»:

1
ALTER TABLE student DROP gpa;

Мало того, что существующие объекты вряд ли могут вызвать проблемы, мы фактически откатили наш код И базу данных.

Подведем итоги:

  • Мы можем сделать то же самое в «безсхемных» базах данных, как и в «схематичных».
  • Мы гарантируем, что миграция будет иметь место (и она тоже мгновенная)
  • Мы гарантируем целостность данных при откате изменений

А как насчет реального реального DDL?

Конечно, в начале проектов, когда они все еще напоминают типичный пример приложения «кошка / собака / зоомагазин, книга / автор / библиотека», мы просто добавим столбцы. Но что произойдет, если нам нужно изменить отношения ученик-учитель 1: N на отношения ученик-учитель М: N? Внезапно все меняется, и реляционная модель данных не только окажется намного лучше иерархической, которая просто дает тонны дублирования данных, но и будет умеренно легко перенастроена, и результат гарантированно будет правильным и аккуратным!

1
2
3
4
5
6
CREATE TABLE student_to_teacher
AS
SELECT id AS student_id, teacher_id
FROM student;
 
ALTER TABLE student DROP teacher_id;

… и мы закончили! (конечно, мы будем добавлять ограничения и индексы)

Подумайте об утомительной задаче, которую вы будете выполнять, преобразовывая свой JSON в новый JSON. У вас даже нет XSLT или XQuery для этой задачи, только JavaScript!

Давайте посмотрим правде в глаза

Бессмысленность — это вводящий в заблуждение термин так же, как и NoSQL :

И снова, сообщение в блоге MongoDB говорит правду (и интересную тоже):

Как правило, существует прямая аналогия между этим стилем «без схемы» и динамически типизированными языками. Конструкции, подобные приведенным выше, легко представить в PHP, Python и Ruby. Здесь мы пытаемся сделать это отображение в базу данных естественным.

Когда вы говорите «без схемы», вы фактически говорите «динамически типизированная схема» — в отличие от статически типизированных схем, поскольку они доступны из баз данных SQL. JSON по-прежнему является полностью свободным от схемы стандартом структуры данных, в отличие от XML, который позволяет вам указывать XSD, если вам нужно, или работать с ориентированными на документы схемами без схемы (то есть с динамической типизацией).

(И не говорите, что есть JSON-схема . Это нелепая попытка имитировать XSD)

Это важно понимать! У вас всегда есть схема, даже если вы не вводите ее статически. Если вы пишете JavaScript, у вас все еще есть типы, которые вы должны полностью осознавать в своей ментальной модели кода. За исключением того, что нет компилятора (или IDE), который может помочь вам вывести типы со 100% уверенностью.

Пример:

… и более:

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

Но позвольте мне сказать вам ужасную правду:

Все, что может пойти не так, делает

— Мерфи

Мы желаем вам удачи с вашими динамически типизированными языками и вашими динамически типизированными схемами баз данных — пока мы будем придерживаться типа безопасного SQL.

Ссылка: Прекратите утверждать, что вы используете базу данных без схемы от нашего партнера по JCG Лукаса Эдера из блога JAVA, SQL и JOOQ .
35
Share: