Как лучше хранить мелкие данные в базе?

Question

[ddwedwedewdw]

На сайте есть различные небольшие блоки (о нас и тд). Встречаются они единожды, но должны редактироваться менеджером -> храниться в базе. Вопрос заключается в следующем: лучше создавать под каждый такой блок отдельную таблицу или завести одну большую, в которую будут сваливаться все такие данные и помечаться каким-нибудь свойством. Например type: about, advantages, etc...

Comments

[Сергей delphinpro]

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

spoiler

и одна с привязками

spoiler

[ddwedwedewdw]

Сергей delphinpro, спасибо, такой вариант отлично подойдет

[d'Ivan]

Сергей delphinpro, лучше оформить как ответ.

Answer 1

[alexalexes]

В самом кратком варианте у вас будет одна таблица, которая будет отвечать за дерево страниц.
Таблица pages:
id - идентификатор страницы;
parent_id - идентификатор родителя страницы;
title - Название страницы
short_name - Краткое наименование (обычно используются для пунктов меню)
alias - имя алиаса для построения url страницы (то что вы указали как type: about, advantages, etc...)
create_date - дата-время создания страницы
update_date - дата-время изменения страницы
content - тело страницы
is_hidden - флаг скрытости страницы (удобно использовать для устаревания страниц)
PS: Посмотрите как это реализовано в любой популярной CMS, похожая таблица и свойства таблиц есть в любой из реализаций.

Answer 2

[mayton2019]

на сайте есть различные небольшие блоки (о нас и тд). Встречаются они единожды, но должны редактироваться менеджером -> храниться в базе.

Это различные небольшие блоки по смыслу ближе к обычным файлам в файловой системе.
Файловая система - наиболее гибкая и толерантная в данном варианте использования.

Но поскольку у вас стоит такое требование как хранить в базе - отсюда и возникает вопрос.
А с каким ключом туда это все ложить? Ключ должен быть осмысленным настолько чтобы эти
блоки потом найти и не потерять. И это даже не с нормализацией а скорее просто с особенностями
подобных хранилищ. Key-Value очень быстро захламляется и превращается в свалку или кладбище
документов без внятного понимания нужны они или нет.

Если url будет ключом - то это хорошо.

Comments

[d'Ivan]

Между прочим, многие k/v хранилища поддерживают истечение срока жизни ключа.
Но лучше не плодить k/v там, где без них можно обойтись.

[d'Ivan]

Это различные небольшие блоки по смыслу ближе к обычным файлам в файловой системе.

Сомнительно, что в этой задаче имеет смысл использовать файлы.

[mayton2019]

Román Mirilaczvili, time-to-live - это интересная опция но она совершенно бесполезна в данной задаче. Ведь никто на уровне тех-задания не говорит о каких-то временнЫх параметрах. Речь идет только о порядке доступа.

[mayton2019]

Сомнительно, что в этой задаче имеет смысл использовать файлы.

С точки зрения современных WebAPI, файловая система давно уже стала метафорой. Мы не знаем
что стоит по ту сторону от веб-интерфеса. Файловая система? Или иерархическая таблица? У нас даже нет возможности проверить если мы не знаем архитектуры. И я в своём месседже выше говорю только о структурности хранения. Тоесть о сущностях таких как фолдеры и файлы. Но я ничего не говорю о физической реализации.