Я вроде бы не писал ещё ни разу про реляционные базы данных. Для новых читателей напомню, что в моём более старом проекте, Микоризе, никакая база данных не используется, вместо этого там набор дурных JSON- и INI-документов и нелепый автоматически манипулируемый Git-репозиторий; об этом технологическом решении я глубоко сожалею, но от гита уже нельзя уйти: у Микоризы достаточно много пользователей, чтобы не менять такую фундаментальную вещь. В более новом проекте, Бетуле, база данных у меня уже есть. Также с базами данных сталкиваюсь на работе, правда, там мне не приходится их дизайнить, этим занимаются аналитики (привет, коллеги!).

Ещё я слышал про некий RDF. Модель представления данных о чём-нибудь в виде триплетов субъект + предикат + объект. Для жертв российской лингвистической терминологии могут быть более знакомыми слова подлежащее + сказуемое + дополнение.

А что, если игнорировать все эти реляционные модели, и всё хранить в RDF-модели? Вот, смотрите, пусть будет вот такая таблица:

create table Facts (Subject not null, Predicate text not null, Object);

NB. В SQLite у столбиков может быть динамическая типизация, в данном случае она у первого и третьего столбиков. В других диалектах SQL это вроде бы невозможно. Да и в целом так делать не любят. А я сделаю.

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

create table Tags (ID integer primary key, Name text not null);

create table Documents (
ID integer primary key,
Title text not null,
Contents text not null
);

create table Documents_to_Tags (
DocumentID integer references Documents,
TagID integer references Tags
);

Возможное содержимое анонимный читатель представит самостоятельно.

Смелый дизайнер баз данных на такие таблицы и не смотрит. Он всё запихнёт в RDF-таблицу. Там могут лежать, например, вот такие триплеты:

1, DOC HAS NAME, Narcissus and Goldmund
1, DOC HAS CONTENTS, Outside the entrance...
1, TAG HAS NAME, Book
1, DOC HAS TAG, 1

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

Ещё можно добавить столбик Attribute, а если совсем скучно, то и Adverbial. Для простоты модели пока не будем.

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

Уютная тумбочка

Я вроде бы не писал ещё ни разу про реляционные базы данных. Для новых читателей напомню, что в моём более старом проекте, Микоризе, никакая база данных не используется, вместо этого там набор дурных JSON- и INI-документов и нелепый автоматически манипулируемый Git-репозиторий; об этом технологическом решении я глубоко сожалею, но от гита уже нельзя уйти: у Микоризы достаточно много пользователей, чтобы не менять такую фундаментальную вещь. В более новом проекте, Бетуле, база данных у меня уже есть. Также с базами данных сталкиваюсь на работе, правда, там мне не приходится их дизайнить, этим занимаются аналитики (привет, коллеги!).

Ещё я слышал про некий RDF. Модель представления данных о чём-нибудь в виде триплетов субъект + предикат + объект. Для жертв российской лингвистической терминологии могут быть более знакомыми слова подлежащее + сказуемое + дополнение.

А что, если игнорировать все эти реляционные модели, и всё хранить в RDF-модели? Вот, смотрите, пусть будет вот такая таблица:

create table Facts (Subject not null, Predicate text not null, Object);

NB. В SQLite у столбиков может быть динамическая типизация, в данном случае она у первого и третьего столбиков. В других диалектах SQL это вроде бы невозможно. Да и в целом так делать не любят. А я сделаю.

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

create table Tags (ID integer primary key, Name text not null);

create table Documents (
ID integer primary key,
Title text not null,
Contents text not null
);

create table Documents_to_Tags (
DocumentID integer references Documents,
TagID integer references Tags
);

Возможное содержимое анонимный читатель представит самостоятельно.

Смелый дизайнер баз данных на такие таблицы и не смотрит. Он всё запихнёт в RDF-таблицу. Там могут лежать, например, вот такие триплеты:

1, DOC HAS NAME, Narcissus and Goldmund
1, DOC HAS CONTENTS, Outside the entrance...
1, TAG HAS NAME, Book
1, DOC HAS TAG, 1

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

Ещё можно добавить столбик Attribute, а если совсем скучно, то и Adverbial. Для простоты модели пока не будем.

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

hottg.com/bpblog/1319

1.4K viewsJul 19, 2024 at 10:19