Есть знания про ключи, которые не часто нужны, но иногда оказываются жизненно необходимыми 😰
Я помню, что на программе БД каждый поток встречаю этот вопрос про два вида первичных ключей. Давайте разберемся что это и как выглядит на практике.


🔑 Обычный ключ:
Состоит из одного поля: id, number, name или любой другой вариант.
Например, в нашем проекте PetCo каждый заказ может иметь уникальный номер.. Этот номер заказа можно использовать как первичный ключ. Но!!! Мы договорились использовать системный идентификатор id. Так что именно его мы будем определять как первичный ключ таблицы 😎

🔑 Составной ключ:
Состоит из двух или более полей. Составные ключи используются реже, но в определенных случаях они могут быть очень полезными.
Представьте, что у нас есть таблица, в которой отслеживается история покупок клиентов в разных магазинах сети PetCo. В этом случае составной ключ может быть создан на основе идентификатора клиента и идентификатора магазина 🤝


Основное отличие обычного ключа от составного заключается в том, что первый состоит из одного поля, в то время как последний — из двух или более. Это может влиять на производительность, структуру данных и сложность запросов.

А для того, чтобы погрузиться в тему проектирования БД глубже, жду вас сегодня на практическом вебинаре:
📚 От проектирования БД до SQL-запросов
📅 26 сентября, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Коллеги, перед практическим вебинаром сегодня, пожалуйста, скачайте и установите DBeaver Community.

Мы сегодня будем работать с реальной СУБД через него.

Ссылка на загрузку:
https://dbeaver.io/download/

❗️Уже через 3 часа❗️

Практический вебинар с Екатериной Ананьевой!

📹 От проектирования БД до SQL-запросов
⏰ 19:00 - 21:00 Мск

Ссылку на прямой эфир пришлем в канал за 15 минут до начала.

Время на вебинарах для меня летит очень быстро! Столько моментов, столько деталей - и все это благодаря нашему совместной работе по проектированию БД и SQL!

✨Анализировали требования,
✨Выделяли ключевые сущности,
✨Использовали chatGPT,
✨Строили логическую модель,
✨Поработали с физической и SQL-запросами, посмотрели DBeaver!
И это всё для небольшой задачи - с нуля до видимого результата! Вы крутые! 😊

Я хочу выразить свою искреннюю благодарность каждому из вас за поддержку и участие. Ваш интерес, ваши вопросы, ваше стремление к пониманию - все это делает такие вебинары действительно особенными.

И хотя наш вебинар завершился, наш путь с командой по БД только начинается! 😊 Уже 3 октября стартуем предобучение на проекте по Проектированию БД и SQL. Это будет насыщенный и интересный процесс, и я уверена, что с вашим участием он пройдет на высшем уровне!

До скорых встреч и еще раз спасибо за ваше доверие! ❤️️

😎 UUID: уникальность без границ 😎

Когда речь идет о генерации уникальных идентификаторов, в современном мире IT одним из наиболее популярных выборов является UUID (Universally Unique Identifier). Но что это такое и почему это так важно?

UUID — это 128-битное число, используемое для уникальной идентификации информации в компьютерных системах. Вот как это выглядит:


f47ac10b-58cc-4372-a567-0e02b2c3d479

🤓Почему бы не использовать простой порядковый номер?

Давайте вернемся к нашему проекту PetCo. Представим, что мы все же решили генерировать порядковые номера id заказов.
Но что, если у нас есть множество независимых серверов или даже различные системы, генерирующие заказы?! В этом контексте порядковые номера могут стать проблемой из-за возможных пересечений. Именно тут на помощь приходит UUID ❤️

Продолжение... 👇

Преимущества UUID:
❤️Глобальная уникальность: Независимо от того, где и когда вы генерируете UUID, вероятность его совпадения с другим UUID крайне мала.
❤️Простота интеграции: При слиянии данных из разных источников или систем нет необходимости перегенерировать идентификаторы.
❤️Безопасность: UUID может быть предпочтительным, если вы не хотите раскрывать последовательность или количество записей в вашей системе.

Недостатки использования UUID:
🙁 Размер: UUID длиннее и занимает больше места в базе данных по сравнению с простыми целочисленными идентификаторами.
🙁 Сложности в чтении: Для человека сложно читать и запоминать UUID по сравнению с простыми номерами. Но он для машин. И если что, его всегда можно оформить в виде QR-код!


В больших и масштабируемых проектах, где уникальность идентификатора критична, использование UUID может быть лучшим и оптимальным решением.

В заключение, выбор между UUID и традиционными порядковыми номерами зависит от конкретных требований проекта. UUID предлагает высокую степень уникальности и гибкость, делая его отличным выбором для сложных систем и распределенных приложений ❤️ Все кто работал со мной на проектах GetAnalyst знают о том, что я всегда за реальный мир, мы всегда делаем UUID для примеров запросов REST API и данных в БД, и я даю инструмент для его генерации.

Для тех, кто не смог подключиться вчера в онлайн!

Практический вебинар:

От проектирования БД до SQL-запросов
🔍 Анализ требований и выявление ключевых сущностей.
📐 Проектирование БД с нуля на концептуальном, логическом и физическом уровнях.
💻 Реализация созданной модели базы данных в SQLite.
⌨️ Выполнение на ней SQL-запросов.
🤖 Лайфхаки от Кати: применение ChatGPT для проектирования БД и SQL-запросов.

Повторы:
📅 28 СЕНТЯБРЯ, 15:00 МСК - ЧТ
📅 1 ОКТЯБРЯ, 10:00 МСК - ВСК
📅 1 ОКТЯБРЯ, 15:00 МСК - ВСК
📅 2 ОКТЯБРЯ, 10:00 МСК - ПН
📅 2 ОКТЯБРЯ, 18:00 МСК - ПН
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Регистрируйтесь 1 раз и приходите в один из указанных дней по ссылке в ответном письме 🙂

🔑 Внешний ключ в БД: теория и практика

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

Помните, в прошлом посте я писала про id (UUID)? Так вот. В БД PetCo таблицы будут связаны за счет этих уникальных системных идентификаторов.

Пример:
В проекте PetCo у нас есть таблица "Клиент" - client (с полями id, name, и так далее) и таблица "Заказы" order (с полями id, client_id, order_date и так далее).
Здесь client_id (Клиент_id) в таблице "Заказы" является внешним ключом, который ссылается на id в таблице "Покупатели".

То есть:
order.client_id = client.id
(перед точкой название таблицы)

🔑 client_id - это ссылка в таблице order полностью соответствующая идентификатору клиента. Это позволяет нам понять, какой клиент сделал каждый заказ.

🔑 Внешний ключ в БД: теория и практика. Часть 2

На уровне СУБД (PostgreSQL, MySQL и других), внешний ключ обеспечивает две важные функции:

1. Предотвращает действия, которые могут разрушить связи между таблицами.
Когда пытаешься кодом или через специальную программу (пример DBeaver) удалить запись, на которую ссылаются другие таблицы, то система отображает ошибки: “так делать нельзя”!
Пример:
Есть клиент с id = 777.
У него есть заказы с id=1, id=2 и id=3. В таблице order client_id=777 у этих заказов.
Когда я попытаюсь удалить из таблицы строку с информацией о клиенте с id=777, то не смогу сделать это. Будет ошибка.

2. Устанавливает связь между двумя таблицами, обеспечивая ссылочную целостность данных. По сути просто логический вывод из п.1.

-------------------

🪲 Ошибки в реализации:
Я сталкивалась с ситуациями, когда разработчики создавали связь между таблицами только на логическом уровне, забыв установить внешний ключ на уровне СУБД. По логике - связь есть, но в реальной физической базе - её нет.
Это может вызвать проблемы, когда, например, вы пытаетесь удалить запись из главной таблицы, на которую есть ссылка в другой. Пример описала в п.1.

🔑 Правила именования:
Встречались разные варианты: order_id, pet_id, client_id или id_client, id_pet и т.д. Согласна, что есть разные подходы к именованию, и каждый проект может иметь свои стандарты. Главное делать все единообразно для внешних ключей по всей БД. А то потом можно будет запутаться. Рекомендуется создавать гайд по дизайну БД.

Кто из вас слышал это в своей голове? 👻

😓«Таких аналитиков с такими же скилами как у меня - полный рынок. Конкуренция. Я вряд ли сменю работу.»
😓«Пока я здесь без движения, другие идут вперёд. Смотрю на коллег, и кажется, что я мне никогда не догнать их. Я тупой.»
😓«А если я допущу ошибку, и всё рухнет? Это будет конец моей карьере! Лучше я помолчу, пусть они как-то сами решат, мое слово ничего не решит.»

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

Помните ли вы моменты, когда родители, учителя или друзья ставили вам в пример кого-то другого? "Смотри на Васю, у него всё идеально!" или "Ты и это не можешь?". Это было так обидно! Ведь и ты тоже старался со всей душой.

А что если бы в такие моменты кто-то приговаривал: "Ты потрясающий! Посмотри, сколько ты уже достиг! Я тобой горжусь, это твои лучшие результаты и я вижу, ты способен на большее!!" 💖

Оценил свои небольшие достижения? — устрой праздник и своди себя в ресторан 🎉
Сложная задача на работе не поддалась сразу? — угости себя чем-нибудь вкусным, прогуляйся и вернись к решению чуть позже, на свежую голову 🍦

Всё, что ты делаешь, имеет значение. На ошибки не стоит смотреть как на провал, это шаг к целям. Это опыт. Пробуй. Всё получится. Я в тебя верю.

Многие из нас слышали термины "БД" и "СУБД", но иногда они путают их, особенно в волнительные моменты собеседований. 🤔

😅«Что такое БД? Это то, что хранит все мои данные, верно?»
😅«СУБД... это как БД, только сложнее? Или это одно и то же?»
😅«Я слышал про MySQL, но это БД или СУБД? Ой, запутался!»

Разберемся! 🧐


БД, или база данных, – это место структурированного хранения информации. Это конкретные данные и структура их хранения в виде таблиц или в виде файлов определенного формата.

БД - огромный шкаф с файлами. Представьте себе шкаф в библиотеке, где каждый ящик – это таблица, а каждая папка в ящике – это запись. Например, в БД "Библиотека" может быть таблица "Книги", где каждая запись – это конкретная книга. 📚


Теперь СУБД! Это система управления базами данных. Если БД – это шкаф, то СУБД – это библиотекарь, который знает, какие папки где лежат, как их добавлять, удалять или изменять.
MySQL, PostgreSQL, Oracle – это примеры СУБД. Они помогают нам работать с нашими "шкафами" (БД).


Так что, когда ты слышишь о MySQL, это СУБД, которая управляет БД! 💡

Физическая модель реляционной БД – это финальный чертеж для вашей будущей базы данных. Остаётся только воплотить её в жизнь с помощью SQL-запросов или других полезных инструментов СУБД и готово! 💻 Можно писать логику систему, работать с функциями на получение и хранение данных.

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

Физическая модель дополняет и конкретизирует логическую модель.

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

Продолжаем разбираться с физической моделью БД. Переходим к нашему примеру:
🐶 Мы рассматриваем онлайн-зоомагазин "petCo". Мы хотим хранить информацию о товарах для животных.

В логической модели у нас могла бы быть таблица:
▫️Товар
- id - системный идентификатор
- Название
- Тип животного
- Цена
- Описание
- Штрихкод

Теперь, преобразуем это в физическую модель для СУБД PostgreSQL:
▫️Product
- id (UUID, Not Null, Unique)
- name (varchar(128), Not Null)
- pet_type (varchar(64), Not Null)
- price (integer, Not Null, default: 0)
- description (varchar(512))
- barcode (varchar(64), Not Null)

Я уточнила СУБД PostgreSQL, так как ее типы данных я использую для перехода к физической модели.
Понимание как переходить логической к физической модели – это путь к пониманию того, как именно данные будут храниться и обрабатываться в реальной БД.

Работая над физической моделью, аналитики и разработчики объединяют свои усилия. Часто в работе переход от логической к физической модели это задача разработчиков. Особенно договоренности по выбору именования полей и типов данных - их зона ответственности. Бывают крутые дебаты)) И круто, когда можешь твердо аргументировать свою точку зрения!

Знание и понимание физической модели БД помогает аналитику оптимизировать хранение данных, улучшать производительность и экономить серверные ресурсы.

Когда мы говорим о больших объемах данных, производительность запросов становится ключевым моментом. Чтобы ускорить выборку данных из таблицы, мы используем индексы 🌟
Представьте их как оглавление в книге. Вместо того чтобы перебирать каждую страницу, вы можете быстро перейти к нужной вам, зная ее номер.

Для нашего магазина "PetCo" наиболее часто задаваемые запросы могут касаться поиска товара по названию, типу животного или штрихкоду. Создадим для этого индексы:
CREATE INDEX idx_product_name ON Product(name);
CREATE INDEX idx_product_pet_type ON Product(pet_type);
CREATE INDEX idx_product_barcode ON Product(barcode);

Теперь, когда запрос будет искать товар по названию или другому индексированному полю, СУБД (например, PostgreSQL) будет использовать индекс для быстрого нахождения записи.

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

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