проектирование БД

[Adelf]

Такой вот вопрос. Люди хотят зарегистрироваться на девконф. выбирают там.. количества участников. и потом метод оплаты. Если выберут, например, яндекс деньги, то нам никакой доп инфы от них не надо.
Но если выберут оплата Сбербанком, то нам для распечатки квитанции нужно знать его ФИО, фамилию и имя мы спросили еще на этапе регистрации, а вот отчества - нет. Не вопрос, спросим. Вопрос - как хранить? Есть таблица заказов. там сумма, user_id... Отчество туда пихать некрасиво.
Будут и другие типы оплаты. Безналичный вариант. Там нужно будет сохранить кучу инфы о компании, которая будет оплачивать.
Вариантов куча. Поле в orders - и там в JSON формате хранить все что душе угодно. Заводить таблицы для каждого такого вида оплаты, линкованные с orders и туда сохранять. Предлагали мне еще пару экзотичных вариантов
Кто поможет советом?

 

[Hello]

EAV

 

[Adelf]

Этот вариант я как раз отнес к экзотике.
Мне фильтровать/сортировать по ним не надо будет. Лучше уж тогда вообще в JSON сериализованным хранить.

 

[флоппик]

В конкретном этом случае я за поле с json в orders.
Неструктурированные данные, которые больше нигде не нужны, кроме как для оформления заказа, формат и набор которых может изменится к следующей конфе.

 

[Adelf]

Я тоже хочу json. Но тут некоторые любители "правильных" таблиц меня укоряют.

 

[WMix]

а тебе оно нужно отдельные поля для фио, просто одно поле, не? все хуже, user_id это пользователь. но купил я по просьбе брата, он оплатит, а вообще это подарок, получатель мама. у меня таблица адресов, и в заказе есть отправитель, получатель, покупатель. при создании формы можно презаполнить форму из данных пользователя, но сохраняется отдельно

 

[Adelf]

Я скорее всего для сбера попрошу полное ФИО, но фамилию и имя "подскажу". Вопрос то в другом.

 

[WMix]

сейчас читаю ddd, и вот они на протяжении всей книги учат выделять сущьность, но оставлять весь ненужный мир снаружи.
ну тоесть для себя в базе сконкатинетил данные, и лежат они в описании. к примеру для оплат есть конечная таблица типа account: (сумма, откуда, куда, групповая трансакция и описание, куда все остальное г.о. сконкатинетю). эти данные уже не меняются и это часть основной бизнеслогики. но к примеру для сбербакнка будет печататься квитанция или хз, для этого буду складывать данные отдельной табличкой. но к основной программе она уже никакого отношения не имеет.

 

[Adelf]

ну колонка с additional data.. ее тоже можно мысленно исключить из бизнес логики. и никаких проблем

 

[WMix]

можно, но что с этой additional data делать после? crud не залепишь, пойск по фамилии опять исключение, и оно пойдет затык за затыком, мешает табличка?, ну создай отдельную базу, и кидай туда все лишнее..

 

[Adelf]

После? Просто использовать! CRUD на нее лепить не надо. Она фактически readonly. Таблицы мне не мешают. Сделать - не проблема. Проблема - решить как правильнее и красивее.

 

[WMix]

ну мое мнение я высказал. мне проще работать со структурой по максимуму одинаковой. crud или печать или ... не имеет значения, когда есть наработки и гдет к примеру нужно просто табличку, id и шаблон передать чтоб свершилось чудо, а additional data становится исключением

 

[Adelf]

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

 

[Вурдалак]

Отчество туда пихать некрасиво

У меня сложилось мнение, что «красиво» должно быть в модели, а вот эти вот таблицы/JSON — это детали реализации, где иногда вообще насрать. Хоть JSON, хоть через запятую и т.д. Если вдруг по объективным причинам такая инфраструктура перестанет удовлетворять, то можно будет переделать без изменения кода приложения.

 

[Adelf]

без изменения кода приложения

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

В моделях так и так будет красиво. Каждый PaymentType сам будет знать, как хранить и как доставать нужные ему данные. Ну ок. Спасибо всем. Вопрос будем считать закрытым.

 

[AmdY]

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

 

[Adelf]

Да ладно, дай к словам попридираться

 

[Вурдалак]

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

Я кодом приложения называю domain layer, application layer. Инфраструктура в отдельной папочке, это всякие адаптеры, конфиги и т.д.

 

[Adelf]

- Красивые сиськи!
- о_О
- Я сиськами глаза называю!

 

[grigori]

Я пробовал все возможные варианты.
EAV нужен когда у нас условно бесконечное число вариантов, как в характеристиках товаров.

Когда число комбинаций небольшое, как со способами оплаты, лучше сделать одну таблицу с 20ю полями, и столбец типа enum с типом.
В ней будут все нужные данные. В большинстве полей будет null.
Члены DICK-клуба могут привести данные в формат конкретной DOM-модели через стратегию.

Это лучше, чем JSON потому что легко выбрать всю инфу по нужному типу и отфильтровать по значению, сконвертить, вывести в форму и отредактировать.
JSON сам по себе не имеет преимуществ, но все недостатки сериализации остаются.
Куча пустых колонок не мешают.