> А я поддержу https://t.me/pgsql/268012 ;) И добавлю проблемы с

Question

> А я поддержу https://t.me/pgsql/268012 ;) И добавлю проблемы с

консистентностью (в JSON легко "сохранить" всё что угодно вместо корректных данных).
> А почему не нормализованная схема? Даже с учётом "ибо ответ может быть bool/timestamp/int/string" — что там получается, если спроектировать, Вы смотрели?

В логике программы там всё равно будут методы приведения типов. То есть и так и так, то, что достанется из базы данных конвертировать в типы языка (тут go). Если это json, то сама анкета хранит информацию о типах и прога к нормальным типам привести сможет, даже с учётом всяких деталей типа 32/64 бита, деятичные знаки float и т.д.. Вся разница в двух подходах лишь в том, что с json все нюансы продумывать самому, а с "нормальной" моделью частично драйвер. Но там всё равно, либо делать колонки под каждый тип, либо в базу заливать бинарные значения, а потом их расшифровывать. Логику и так и так писать.

И разница получается такая. В случае с JSON одну запись БД по сути можно представить как BINARY, которая парсится в программе. Я получаю строку JSON, которую потом обрабатываю. Это одна строка БД на одну заполненную анкету.

С другой стороны, когда храню ключ-значение в BINARY, мне всё равно надо парсить это BINARY. Даже если хранить не BINARY, а делать в БД одну колонку на каждый тип (что тоже такое себе...), то всё равно в программе надо будет собирать кусками всё. Но при этом добавляются индексы, существенно увеличивается число записей БД. А логика программы такая, что доставать всё равно надо будет целиком данные анкеты. То есть не надо доставать два ответа на первые вопросы, а остальные ответы не доставать.

Вот в результате таких рассуждений пришёл к выводу, что JSON больше подходит.

#backend #devops #pgsql #programming #russian

0

04.12.2020

1 ответов

12 просмотров

Yaroslav Schekin · Accepted Answer

> То есть и так и так, то, что достанется из базы данных конвертировать в типы языка (тут go). Хмм... и что, у go существенные проблемы с типами данных (я просто не в курсе)? > Вся разница в двух подходах лишь в том Не только же? С нормализованной моделью "нюансы" может взять на себя СУБД, и определяются они декларативно или являются частью модели (CHECK, FK и т.п.). > Но там всё равно, либо делать колонки под каждый тип, То есть Вы уже пробовали моделировать? И только такая (примерно) схема получается? > Логику и так и так писать. Но сложность написания разная, см. выше. > С другой стороны, когда храню ключ-значение в BINARY, мне всё равно надо парсить это BINARY. Нет, если СУБД должно быть всё равно, что там хранится (если для PostgreSQL это не более чем blob), то можно хоть bytea использовать, хоть text, хоть JSON — то, с чем удобнее работать приложению (при условии, что оно будет только одно). Т.е. если PostgreSQL используется "тупо для хранения" — почему нет?

172 похожих чатов

> А я поддержу https://t.me/pgsql/268012 ;) И добавлю проблемы с

1 ответов

Похожие вопросы