@Asmodeux

Можно ли создать базу данных на одной таблице?

Я слышал о нескольких проектах, когда пытались создать унифицированную базу данных, в которую бы поместилось все-все бизнес-сущности проекта.
Пример из начала девяностых описан здесь: https://www.red-gate.com/simple-talk/opinion/opini...
Там разработчики делали систему учета продаж на единственной таблице и закончилось это таблицей из 240+ полей с 40+ индексами.
Какие есть более изящные решения такой задачи?
Какой практический лимит записей в таком решении?
  • Вопрос задан
  • 431 просмотр
Решения вопроса 1
mayton2019
@mayton2019
Bigdata Engineer
Да. Такие эксперименты были. Лет 5 назад когда был еще жив sql.ru, один человек продвигал
модель т.н. квинтетов. Это таблица с 5 полями которая полностью описывала любую
доменную область. Я к сожалению не могу нигде найти следов описания этой системы
но возможно это оно https://cyclowiki.org/wiki/QDM . Читайте смотрите.

Второе. В эпоху новых версий DBMS (Oracle/PG/MySQL) когда мы можем использовать
JSON/XML внутри ячейки, сама идея EAV теряет смысл. Поле атомарно? Атомарно.
Значит законы реляционной алгебры мы не нарушаем и JSON совершенно легальный
тип для реляционок. Хотя лет 30 назад его использование было-бы кощунством
в БД. Но это можно было списать на жесткую экономию ресурсов и чрезмерную
математичность моделей Бойса-Кодда. Сегодня все используют JSON и нет никаких
архитектурных доводов против. Поэтому создавайте NoSQL табличку где есть
key и есть значение в виде либерального типа документа. Как делают MongoDb, CouchDb.
И если связать их в иерархию то получится вполне себе те-же самые квинтеты.

Про EAV лучше забудьте. Их любят преподаватели SQL и теоретики. Но практически EAV
слишком медленно работает чтобы развивать его в бизнес-приложении или в промышленности.
Мир тяготеет к упрощению. И поэтому JSON - это упрощение EAV. И работает быстрее.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
vabka
@vabka
Токсичный шарпист
Какие есть более изящные решения такой задачи?

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

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

Какой практический лимит записей в таком решении?

Сколько максимум в одной таблице можешь поддержать СУБД.
Ответ написан
ipatiev
@ipatiev
Потомок старинного рода Ипатьевых-Колотитьевых
"Унифицированная база данных, в которую бы поместилось все-все бизнес-сущности проекта" где под базой данных имеется в виду таблица - это какой-то нелепый бред. И с какого боку тут EAV - совершенно непонятно.

Если эта бредовая идея является попыткой решить проблему из предыдущего вопроса, то вам там дали ответ , причем сразу же. Для поиска надо не базу данных корёжить, а прикрутить к ней специальный поисковый движок.
Движок. Поисковый. Специальный. Прикрутить. Рядом.
И искать с его помощью. А саму базу данных оставить в покое.
Если исходная проблема - это поиск, то и решение над искать для поиска.
Л - Логика.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы