Сопоставление и замена регулярных выражений Python

Выбор базы данных больше зависит от того, что и как вы хотите запрашивать нечто большее, чем то, что вы хотите сохранить. Все БД позволят вам хранить практически все, что захотите.

РСУБД особенно хороши при выполнении запросов на основе реляционной модели, и делать это разумно произвольно. С помощью специальных фильтров и объединений вы можете творить всевозможные чудеса.

БД ​​NOSQL, как правило, менее гибки в своих запросах, но хорошо справляются с другими задачами (например, лучше работают с «неструктурированными» данными).

Учитывая то, что вы здесь разместили, я бы просто использовал базу данных SQL и определял таблицы так, как пользователь хочет, чтобы они были определены. Настроить индексы, настроить запросы. Для меня это звучит как реальная и ежу понятно. Базы данных SQL легко справляются со всеми этими «определениями полей на лету», потому что ... это то, что они делают. Так что используйте это.

Если ваши данные довольно хорошо подходят для реляционной модели, но вам нужно хранить некоторые динамически отформатированные данные, которые не являются огромными, тогда вам, вероятно, будет лучше хранить JSON, XML или аналогичные данные в столбец. Хотя при этом вы теряете некоторые преимущества первоклассной типизации SQL (индексирование, проверка ограничений внешнего ключа, проверка типов и т. Д.), Это хорошо для хранения динамически структурированных документов, когда ваши запросы не заботятся об их внутреннем устройстве.

Если вы заинтересованы в хранении в основном реляционных данных с использованием JSON / XML и т. Д., Я рекомендую обратиться к PostgreSQL.PostgreSQL имеет тип данных XML, но я не рекомендую его использовать, так как ненавижу XML: P. Никто не мешает вам хранить JSON в поле TEXT, но PostgreSQL скоро получит тип данных JSON с поддерживающими функциями. Модуль hstore contrib обеспечивает эффективный способ хранения пар ключ / значение, а также обеспечивает поддержку полнотекстового индекса.

Хотя вставка JSON или аналогичного файла в столбец базы данных SQL противоречит реляционной модели, обычно лучше сделать это в любом случае (когда это имеет смысл!). В противном случае вам придется объяснить всю схему вашего приложения базе данных, что приведет к появлению большого количества кода SQL и сопоставления базы данных, который на самом деле ничего не делает.