Вопрос про архитектуру баз данных SQL

Question

Допустим, есть таблица students. В ней хранятся: имя студента, возраст и т.д. С этим всё понятно. А теперь допустим, что есть элемент techs в котором лежат технологии которыми овладел студент. Как мне правильно сконструировать базу данных? То есть, нужно ли мне создавать отдельную таблицу techs и закинуть туда id студента или можно как-то это всё запихнуть в единственную таблицу students? Речь идёт о реляционных базах данных

Answer 1

В классическом SQL, обычно, создается таблица-связка, в которую записываются пары связей: id студента - id технологии. Таким образом, каждый студент сможет с легкостью владеть никакой, одной или многими технологиями.

Answer 2

Создавать надо две отдельные таблицы для Students и Techs, а также необходимо определить связь между ними по полю, которое уникальное (как правило это и есть id).

Большинство высокоуровневых языков имеют библиотеки, модули или фреймворки для работы с базами данных. В том числе и автоматического создания таблиц и отношений между ними. То есть для программиста это выглядит, как написание классов в ООП, а при миграции в базу данных создаются таблицы.

Тут важно отметить, что отношение между таблицами могут строиться с использованием дополнительных таблиц (посредников), которые для осваивающих, могут быть не очевидны, то есть за кулисами при миграции создается таблица, которая хранит отношения для двух других, например.

Answer 3

В теории РСУБД это называется отношение многие ко многим. Есть две сущности: Студенты и Технологии. Для реализации отношение многие ко многим вводится третья сущность: Студеет-Технология, которая содержит ссылки на обе сущности.

Пример:

CREATE TABLE Students(
  id int PRIMARY KEY;
  Name text;
  Group text;
....
) ;

CREATE TABLE Techs(
  id int  PRIMARY KEY,
  Name text;
  ...
);

Таблица связка:

 CREATE TABLE Students2Tech(
   student_id int;
   tech_id int;
   experience int; -- как хорошо изучил 
   . . . -- ghjxbt ljg gjkz
   -- здесь определяется внешний ключ на табл студентов
   FOREIGN KEY (student_id) REFERENCES students(id)
   -- на тбл. технологий
   FOREIGN KEY (tech_id) REFERENCES techs(id) 
   )

Если не придерживаться третьей нормальной формы, то для реализации отношения многие ко мнноогим можно использовать массивы или JSON поле, все зависит от возможности БД, типа запросов, требуемой нагрузки и поставленной задачи.

Когда-то в 2004, в эпоху MySQL 3.23 я реализовывал отношение многие ко многим используя текстовое поле, в котором был список id. Это работало быстрее, чем джоин из трех таблиц.

БЛОГ НА HUSL

Вопрос про архитектуру баз данных SQL

Ответы (3 шт):