LINUX.ORG.RU

Помощь с архитектурой базы данных

 , ,


0

1

Привет всем. В продолжении моей предыдущей темы по выбору языка и библиотек/фреймворков, в которой вы мне очень помогли.

Сейчас тренируюсь на всяких простых вещах, понемного переходя на более сложные. Но, как я понял, в любом случае независимо от языка, работа с базой данных будет. Я почитал про РБД, тыкаю sqlite из терминала и через sqlitebrowser. Имитирую архитектуру приложения, которое будет, допустим, предоставлять поиск музыкальных групп по жанру, участникам, альбомам и прочему.

В базе данных 4 таблицы:

  • Названия исполнителей.
  • Имена участников.
  • Названия и год альбомов.
  • Названия песен.

Скажем, есть альбомы, которые пишут несколько исполнителей совместно. Есть случаи, когда люди были в нескольких группах-исполнителях. И так далее. Как в такой ситуации правильно создать связи на примере альбомов?

Есть альбом, его писала одна группа. Значит в таблице альбомы, в поле «Исполнитель» я добавляю ID исполнителя из таблицы исполнителей. Но как быть, если исполнителей несколько и их кол-во заранее неизвестно? Их может быть 2, 3 или 10 (конкретно в моем примере не так много, но могут быть другие немузыкальные направленности, где связей может быть и сто, и миллион). Вместо указания в виде числа ID в таблице альбомов указывать текст с чем-то типа списка с ID с учетом того, что это поле не будет ключевым? Какие-то другие варианты?


Один к одному: обе таблицы ссылаются друг на друга. Ссылки делают по primary key — просто кладут id.

Один ко многим: ссылается только одна таблица, а вторая не ссылается.

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

Также нужно учесть удаление записей. Может случится так, что по сохранённому id уже ничего нет. Существуют разные стратегии на этот счёт:

  • Ничего не делать. Тогда везде нужны проверки, чтобы не упасть с исключением.
  • Сделать поле null, когда запись удаляется — занулять его. Тоже понадобятся проверки, но уже на null, что гораздо эффективнее и занимает меньше места в коде.
  • Удалить все ссылающиеся записи.

Для примера можно посмотреть на любую современную ORM, там это делают на уровне фреймворка, включая обработку связей в случае удаления записи. В Django весьма удобная ORM.

Предположу, что следующим вопросом будут миграции. Вот на них тоже лучше посмотреть в Django. Вручную они делаются легко:

  • Заводим таблицу, где строковой ключ — имя другой, целевой таблицы, а второе поле integer — её версия.
  • В коде пишем проверку, если версия не совпадает — применяем соответствующую миграцию.

Это можно сделать даже на уровне SQL в навороченных СУБД, таких как Postgres.

InterVi ★★★★★
()
Ответ на: комментарий от InterVi

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

Немного экспрессивно-маргинально, но чтобы обозначить разнообразие :)

Paka_RD
()
Последнее исправление: Paka_RD (всего исправлений: 1)
Ответ на: комментарий от Paka_RD

Зависит от СУБД. Не все так умеют, вот у него sqlite, в ней минимум фич. Когда возможно, ORM сами используют правильные привязки.

Но для опыта конечно полезно прописать их руками в сыром SQL.

InterVi ★★★★★
()
Ответ на: комментарий от Pinkbyte

так и делают в полноценных СУБД, где такие фичи есть

InterVi ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.