Как реализовать набор таблиц?

Question

[djEban]

- Есть разделы
- У разделов есть блоки
- У блока есть тип либо "description", либо "video"
- В зависиомсти от типа, содержимое блока меняется

Как реализовать такой набор таблиц, где в зависимости от типа записи контент меняется?
На скрине есть моя реализация

Стоит ли написать триггер на добавление, чтобы была проверка, что блок, к которому мы обращаемся по block_id, имеет правильный тип (для block_videos - "video", а для block_descriptions - "description")?

Comments

[Akina]

Вопрос ни о чём. Структура зависит от того, как эти данные будут использовться.

[djEban]

Akina, по запросу клиента буду генерировать json со списком блоков, где каждый состоит из типа и соответствующих этому типу данных

[Akina]

djEban, а если все данные блока хранить в JSON? Вам же, получается, просто нужно все эти блоки, JSON-объекты, фактически свалить в один массив или объект, ну может с дополнительным уровнем ака раздел да сортированные в некоем порядке - а для этого вполне достаточно какого-нибудь вульгарного json_object_agg(). Если для каких-то надобностей ещё нужны и отдельные свойства - так есть вычисляемые столбцы, не проблема.

Answer 1

[elderl]

Дополнительные таблицы не нужны. В таблице блока (объединённой) у неиспользуемых полей будет значение "неопределённо" (NULL).

Comments

[Akina]

Скорее, в таблице будет поле типа description/video, и поля, не характерные для блока данного типа, просто игнорируются, что бы там не лежало.

[djEban]

Akina, вы же просто перефразировали

[Akina]

djEban, формально - да. Реально - ну не будешь же ты делать CHECK constraint, чтобы проверять, что в неподходящем поле именно NULL, а не хрень какая значащая, верно? А коли так, то это уже не NULL, а именно игнор.

[djEban]

Akina, я пока только учусь работать с базами данных и задумвался как раз сделать check constraint. А что с ним не так?

Что-то типа такого

CHECK (type != "video" OR video_url IS NOT NULL)
CHECK (type != "description" OR title IS NOT NULL AND text IS NOT NULL)

[Akina]

djEban, какой смысл рисовать несколько CHECK? Это же однократно вычисляемое выражение, к тому же вычисляемое гарантированно на данных в памяти, т.е. очень быстрое. Впрочем, беды большой не будет...

А вот "типа такого" - неправильно. CHECK constraint разрешает сохранение записи, если его значение равно TRUE либо NULL:
https://dev.mysql.com/doc/refman/8.4/en/create-tab...

expr specifies the constraint condition as a boolean expression that must evaluate to TRUE or UNKNOWN (for NULL values) for each row of the table. If the condition evaluates to FALSE, it fails and a constraint violation occurs.

Так что при type IS NULL запись будет сохранена.

[djEban]

Akina, у type стоит NOT NULL в определении столбца (забыл указать на схеме на скрине). CHECK всегда будет срабатывать правильно, если я все верно понимаю

Я почитал, что CHECK советуют использовать ради сохранения целостности данных. Думаете, будет какая-то проблема от двух внутренних if'ов (правда, я не знаю, как оно на самом деле под капотом)? Конечно, я могу на уровне логики приложения гарантировать целостность, но не думаю, что это "правильно"

[Akina]

djEban, ну правильно пишут. CHECK - это проверка условия при сохранении записи (новой или обновлённой) на предмет соответствия условию, и ошибка сохранения при невыполнении. То есть у тебя это

CHECK (type IN ("video", "description")),
CHECK ( (type = "video" AND video_url IS NOT NULL) 
        OR
        (type = "description" AND title IS NOT NULL AND text IS NOT NULL)
      )

Проблем там никаких нет.

Хотя я бы не делал отдельные поля video_url и title, а сделал бы одно поле base_value и поле additional_value для text при description. Но это так, к слову. И то - если оставлять их текстовыми. По описанию, как я говорил выше, я бы хранил в JSON, тем более с учётом того, что значение хоть и зависит от пользовательского ввода, но формируется и валидируется программно..