По мере приближения к концу моего учебного курса по программированию в Green Fox Academy я предлагаю вам кое-что, о чем я еще не упомянул, но это важно для любого backend-программиста: базы данных и взаимосвязи.

База данных - это набор таблиц, каждая из которых содержит данные о разном, но связанном предмете. Таблица состоит из записей и полей, содержащих данные. Каждая строка в таблице - это запись, а каждый столбец - это поле этой записи.

В реляционной базе данных, в которой данные связаны с другой информацией в базах данных, необходимо однозначно идентифицировать каждую запись в таблице. Это достигается за счет использования первичного ключа. Первичный ключ - это столбец или комбинация столбцов, которые уникальны для каждой записи и не могут содержать нулевые значения, что позволяет правильно идентифицировать каждую запись. Первичный ключ может быть строкой (например, адрес электронной почты) или, как в большинстве случаев, числом, скорее всего, длинным. В последнем случае его можно сгенерировать автоматически, чтобы разработчик не беспокоился о создании уникального идентификатора для каждой записи. Для этого мы бы сделали что-то вроде этого (пример взят из нашего проекта):

Также обратите внимание на аннотацию @Entity. Это специализация аннотации @Component, информирующая о том, что этот класс является Entity, то есть таблицей в базе данных.

Как мы уже говорили ранее, данные в разных таблицах базы данных связаны. Поэтому неудивительно, что иногда нам нужно связать две таблицы вместе, и мы делаем это с помощью внешнего ключа. Внешний ключ - это поле в одной таблице, которое ссылается на первичный ключ в другой таблице. Мы рассмотрим это более подробно, когда рассмотрим отношения «один ко многим».

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

Индивидуальные встречи

Этот тип связи возникает, когда экземпляр сущности существует в таблице и связан с другим экземпляром сущности, но только с одним. У нас нет такого случая в нашем проекте, но давайте представим другой пример ... В школе у ​​ученика есть ученический идентификатор, и эта взаимосвязь уникальна: ученик может иметь только один ученический номер, а этот ученический идентификатор может принадлежать только одному студенту.

Один ко многим

Такая связь существует, когда экземпляр объекта в одной из таблиц может быть связан с несколькими записями в другой таблице. Например, в нашем проекте значок имеет отношение @OneToMany с уровнем BadgeLevel, потому что один значок может иметь несколько уровней.

С другой стороны, BadgeLevel имеет обратную связь @OneToMany, то есть @ManyToOne, потому что многие BadgeLevels относятся только к одному значку. И здесь мы используем упомянутый выше внешний ключ, создавая для него столбец в нашей таблице BadgeLevel (badge_id).

Многие-ко-многим

Наконец, давайте посмотрим на самые сложные отношения - многие-ко-многим. Например, в нашем проекте у архетипа (сущности) есть список уровней значка, потому что у него их может быть много. С другой стороны, уровни значков могут быть частью многих архетипов. Это отношения «многие-ко-многим», потому что обе стороны могут иметь несколько экземпляров друг друга. Вот как выглядит код:

На самом деле отношения «многие-ко-многим» - это, по сути, два отношения «один-ко-многим». В этом случае у одного архетипа может быть много BadgeLevels, а BadgeLevel может соответствовать многим архетипам. Чтобы представить это, отношение «многие-ко-многим» будет генерировать соединительную таблицу, состоящую из первичных ключей обеих упомянутых сущностей. И уникальна именно эта комбинация ключей (или, как мы могли бы считать, Первичный ключ этой таблицы). И это то, что мы определяем с помощью аннотаций @JoinTable и @JoinColumn в приведенном выше коде.

Наконец, я хотел бы напомнить вам, как и в моей прошлой статье, что я работаю над этим проектом в команде, и все, что я здесь написал, является результатом не только моей работы, но, что очень важно, моих товарищей по команде ». также.

Проверьте последнюю статью через две недели, пока я все еще хожу на буткемп!

📝 Прочтите этот рассказ позже в Журнале.

🗞 Просыпайтесь каждое воскресенье утром и слышите самые интересные истории, мнения и новости недели, ожидающие в вашем почтовом ящике: Получите заслуживающий внимания информационный бюллетень›