Правильно ли я делаю структуру бд PostgreSQL?

Question

[BestJS]

Решил сделать сайт, начал со структуры бд. За два дня у меня уже накопилось 18 таблиц, это согласно правилам структурирования данных, связей один к одному, один ко многим. Думаю всего будет примерно 25 таблиц.
Что бы подгрузить одну страницу сайта нужны будут данные из этих всех таблиц и sql запрос(с под запросами) наверно будет на 50-100 строк.
Это нормально?
Как быстро будет думать над одним запросом PostgreSql, если правильно настроить связи и индексы?
Заранее благодарен за ваши ответы, комментарии.

Comments

[DevMan]

BestJS если вопрос по постгресу, то что в тегах делает мускуль?

[BestJS]

DevMan: Там могут быть люди которые разбираются в структурировании данных в бд, и возможно они смогут ответить на вопрос "Это нормально?"

[DevMan]

BestJS: не дружбан, ты превратно понимаешь назначение тегов.

[Dmitry MiksIr]

Начал готовить пирог. Если делать все правильно, нужно 25 ингредиентов. Вопрос - будет ли он вкусным и как долго будет готовиться, если я правильно выставлю температуру духовки?

[BestJS]

Dmitry MiksIr: Когда первый раз делаешь большой пирог(сайт)(особенно для себя) без точного рецепта, походу дела задаешься тупыми вопросами, что бы потом не получить расстройство желудка, а наоборот получилось произведение искусства ;)

[Александр Шелеметьев]

BestJS:
Чтобы создать произведение искусства для начала неплохо бы просто научиться корректно отображать то, что задумано. Можно представить гениальную картину, но если всё, что в результате выходит, - это "вид кошки сзади", в этом будет немного толку. Пусть ваша реализация - пока не произведение искусства, а лишь корректно отображает замысел, - она уже имеет бОльшую ценность в отличие от глюкавых поделий с претензией на "модность", "современность" и т.д., которые окружают нас сплошь и рядом.
Приобретая опыт решения конкретных инженерных задач, всё глубже понимая и учась использовать ваши инструменты, вы в конечном итоге будете приближаться к созданию шедевров.

Answer 1

[DevMan]

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

Comments

[BestJS]

Делаю музыкальный портал, есть три главные сущности: артисты треки альбомы. и доп сущности которые требуют отдельной таблицы в бд: кринки, видео, типы, полные именна, страны, псевдонимы, тексты песен, жанры

[DevMan]

BestJS: все верно.
только никто в здравом рассудке не дергает все таблицы постоянно.
данные, или готовая страница, кладутся в кеш. при внесении изменений в страницу, кеш инвалидируется.

[BestJS]

DevMan: Всё понял, спасибо за идею.

[DevMan]

BestJS: пожалуйста)

[Артём Каретников]

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

Answer 2

[Александр Шелеметьев]

Присоединись к Артём Каретников .
Сначала сделайте столько таблиц, сколько требуется для нормализации данных. Этим вы обеспечите целостность данных. На количество связанных таблиц в одном запросе не обращайте внимания.
Если вдруг в будущем заметите тормоза, разбирайтесь с ними отдельно. Оптимизация запросов - отдельная большая тема.
Конечно, более опытные архитекторы/разработчики могут сразу почуять, где будет тормозить, и спроектировать архитектуру с учётом этого чутья. Но это не ваш случай.

Comments

[x67]

но автор как раз про архитектуру и спросил, что бы не проектировать тормоза да костыли

[Александр Шелеметьев]

В реальной жизни часто приходится искать компромиссы между нормализацией и скоростями выборки и вставки. Всё сразу оптимизировать не получается. В каждом конкретном случае нужно смотреть на требования к информационной системе.
Например, если нам критична скорость конкретной выборки, но менее критична скорость вставки данных и при этом важно сохранять ссылочную целостность нормализованных данных, можно добавить дополнительные ненормализованные поля в таблицу и вычислять их триггером при вставке/изменении записи. Либо создать отдельную таблицу (материализованное представление) с ненормализованными данными, готовыми для отображения.
Если, наоборот, важна скорость записи, и мы готовы пожертвовать скоростью выборки, можно сохранять данные в одном поле типа JSON, а при выборке его парсить. Но тут столкнёмся с возможными проблемами нормализации и целостности данных. Их можно решить, запуская в отдельном (от вставки данных) потоке процедуру, которая обрабатывает JSON из таблицы и раскидывает данные по нормализованным таблицам. Естественно, могут встретиться данные, которые не смогут быть корректно обработаны. Надо решать вопрос, что с ними делать.
Вообще, тема оптимизации очень обширная.
В любом случае, чтобы не получить "помойку" в данных считаю, что сначала надо обеспечить их целостность и непротиворечивость. И только потом, только при необходимости, решать вопросы оптимизации, так как любая оптимизация - отступление от штатного механизма обеспечения целостности данных реляционной БД.
Да, и могу дать совет: используйте для выдачи во фронтэнд представления (view). Тогда изменения структуры БД проводятся значительно проще.

[BestJS]

Александр Шелеметьев: Спасибо за такой обширный ответ.
Больше склоняюсь к этому варианту, сделать кэш таблицу:

Либо создать отдельную таблицу (материализованное представление) с не нормализованными данными, готовыми для отображения.

[Александр Шелеметьев]

BestJS: Для начала создайте обычное представление (view) для этих данных. Потом, если будет тормозить, сможете без проблем преобразовать его в материализованное. Но следует понимать, что в настоящий момент PostgreSQL не умеет автоматически обновлять данные материализованных представлений. Нужно будет запускать такое обновление по таймеру или событию. Вместо материализованного представления можно использовать отдельную таблицу, в которую писать данные при добавлении/обновлении данных основной таблицы. Тут придётся навернуть систему триггеров, что скажется на скорости вставки/изменения данных. Либо, как в ситуации с материализованным представлением, обновлять эту таблицу по событию/таймеру. Попробуйте разные варианты, благо, если фронтэнд завяжете на представление, то практически безболезненно сможете заменить его на материализованное или таблицу.
Если что, обращайтесь.