Как лучше хранить заявки из форм в БД?

Question

[VladislavNaida]

Дорого дня. Поделитесь пожалуйста мнением по данному вопросу. Учитывая тот момент, что мы не знаем сколько уникальных форм будет на сайте и с какими полями.

Я вижу 2 варианта:

1. Используя "один ко многим".
В основную записываем допустим имя, а в сводную то что придёт в формате ключ - значение.

2. Сохранять данные в json

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

Answer 1

[Антон Неверов]

1) Всегда можно рассмотреть использование нереляционной базы данных на подобие MongoDB/YDB/CouchDB. Записи в таких базах подобны JSON-документам и не имеют строгой табличной структуры, как у реляционных аналогов.
2) Ваш вариант с Many-to-many связями вполне неплох, если хотите использоваться всё же реляционную БД. Он не нарушает нормальных форм.

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

Comments

[tukreb]

зачем тащить целую СУБД только для хранения JSON, когда давно MySQL это умеет делать? А PostgreSQL так вообще самый первый кто научился хранить JSON и работать с ними так же быстро как и любая NoSQL, и даже быстрее
Да и вообще www.sarahmei.com/blog/2013/11/11/why-you-should-ne...

[Антон Неверов]

tukreb, потому что хранить JSON в MySQL это нарушение первой нормальной формы. Это если принципиально хранить именно JSON, что является спорным решением в данном случае.
Я уже молчу о том, что когда вы на реальном проекте столкнётесь даже в 8 версии с JSON-полем у вас такие проблемы огромные появятся при глубоких JOIN запросах и аналитике.

[tukreb]

Антон Неверов, а хранить их в MongoDB или любой другой NoSQL не нарушает первую форму получается?

[Антон Неверов]

tukreb, пожалуйста, изучите вопрос прежде чем писать такие глупости. Нормальные формы - это требования предъявляемые только к реляционным базам данных.
Именно поэтому базы и делят на типы: реляционные и не таковые. В первых данные хранятся в таблицах, что накладывает определённые обязательства при разметке. Если бы всё было так просто, то к чем все эти таблицы были бы нужны? Можно было бы всё скинуть в один JSON в одной таблице в одной ячейке и радоваться жизни. Но вы же так не делаете. Вы заботитесть об отношениях, индексах, поисках, оптимизациях и т.д.

[tukreb]

Антон Неверов, Реляционные БД давно умеют работать с нереляционными данными. Они на столько хорошо с ними умеют работать, что сейчас практически нет никакого смысла тащить ещё одну БД только ради NoSQL. Особенно хорошо с этим работает PostgreSQL, MySQL, лишь с 8 версии пытается нагнать упущенные годы.

[ThunderCat]

tukreb, Табличное хранение вообще ортоганально по применению к JSON. Смысл таблиц в упорядоченности и строгой типизации данных, а JSON предназначен больше для неоднородных данных, поиск по которым не является приоритетом.

Реляционные БД давно умеют работать с нереляционными данными.

Вопрос в том как они с ними работают, и стоит ли так делать(для справки - внутри JSON полей сложная структура преобразования в группу таблиц, хотя для пользователя это прозрачное преобразование и выглядит как работа с JSON "напрямую"). Ответ очень простой: Если можно задать готовую структуру - лучше использовать табличное хранение, если данные имеют большую неоднородность - JSON.

[tukreb]

ThunderCat, так я и не спорю с этим. Я лишь интересуюсь, зачем автор ответа рекомендует рассматривать NoSQL СУБД, когда задавшему вопрос с головой хватит существующих решений и даже отстающего от PostgreSQL, решения в MySQL 8 версии. Конечно, если его данные ложатся в нормальную форму, то нет никакого смысла в JSON.

[Антон Неверов]

tukreb, откуда вам известны потребности автора вопроса? Я на кофейной гуще не гадаю. Моё дело предложить варианты.

Answer 2

[alexalexes]

А что вы так боитесь сделать в таблице кучу колонок?
У записи заявки будет type_id - тип заявки, и в зависимости от этого будет использоваться разный набор колонок. Все колонки, которые опционально будут использоваться только в определенных типах будут с допущением null значениями.

В основную записываем допустим имя, а в сводную то что придёт в формате ключ - значение.

Имеет право на жизнь, но для разработчика будет сложнее сопровождать запросы. При написании запроса, если нужно вытащить или сравнить свойства заявок, будете писать на каждый такой момент подзапрос. Если захочется получать выборки с результатами в одну строку, то придется тоже использовать кучу подзапросов, возможно, сам текст запроса нужно будет формировать динамически.
С точки зрения производительности. План запроса усложнится, нужно будет использовать индексы.

2. Сохранять данные в json

Если не будете использовать свойства, которые запишите в json для связывания таблиц, и формирования условий выборки, то можно использовать.

Comments

[Михаил Ливач]

А что вы так боитесь сделать в таблице кучу колонок?

Это же неэффективно. Зачем Вам хранить кучу null, если можно вынести в отдельную таблицу и джойнить её?

Answer 3

[Владимир Коротенко]

Дорого дня. Поделитесь пожалуйста мнением по данному вопросу. Учитывая тот момент, что мы не знаем сколько уникальных форм будет на сайте и с какими полями.

Тут вопрос такого плана, вы сами разработчики или пользователь может наклепать свою форму?

Если сами то просто накатывайте миграции и делайте свою таблицу/ы под каждую форму.

Если пользователь то вам нужно переработать архитектуру:
таблицы следующие
fieldtype - описание всех типов полей строка, телефон, подстановка, выбор, вычисляемое
forms - простая табличка с айдишниками названием и мета данными
formfields - описание полей для форм, тип данных подставляется из fieldtype , так же тут метаданные
formfieldsresult - собственно результаты заполнения, особое внимание уделите типу подстановки он хранится в виде [e-mail]#;Тестовый пользователь, где [e-mail] это ключ для подстановки а #; разделитель