❗️Уже через 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) будет использовать индекс для быстрого нахождения записи.

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

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

Индекс, как и другие функции, зависит от СУБД, и вот почему:

1. Типы индексов:
У разных СУБД могут быть свои уникальные типы индексов. Например, PostgreSQL предлагает B-tree, Hash, GiST, SP-GiST, GIN и BRIN, в то время как другая СУБД может предлагать другой набор типов индексов или даже свои эксклюзивные типы.

2. Оптимизация:
Каждая СУБД имеет свой собственный оптимизатор запросов. Оптимизатор принимает решение о том, когда и как использовать индекс. В разных СУБД этот процесс может отличаться.

3. Создание и обслуживание:
Процесс создания, обновления и удаления индексов может немного отличаться в зависимости от СУБД. Некоторые системы могут автоматически реорганизовать индексы, чтобы поддерживать их эффективность, в то время как другие могут требовать ручного вмешательства.

4. Ресурсные требования:
Индексы могут иметь разное влияние на производительность и потребление ресурсов в разных СУБД. В одной системе индекс может быстро создаваться и требовать небольшого дискового пространства, а в другой — создание индекса может быть более ресурсозатратным.

5. Ограничения и возможности:
В зависимости от СУБД могут быть определенные ограничения на количество индексов, их размер или другие характеристики. Также некоторые СУБД могут предлагать дополнительные возможности, связанные с индексами, например, индексы на выражениях или частичные индексы.

Последний десяток лет тема инвестиций особенно популярна🏅

Сейчас можно вложиться в:
💸 акции и облигации множество крупных и не очень компаний,
💸 драгоценные металлы,
💸 недвижимость,
💸 стартапы / готовые бизнесы,
и прочее, прочее.

Это всё здорово и очень интересно, это даже работает. Кроме этого, я считаю, что самая важная и необходимая инвестиция — образование 🙌

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

На личном опыте я убедилась, что самая надёжная инвестиция — это инвестиции в саморазвитие!
Вложение средства и времени в обучение и развитие навыков — залог моего будущего. Где бы я ни оказалась, в какую страну или город бы не переехала, со мной всегда буду я и мои знания.

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

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

Получение качественной информации останется трендом и лучшим стартапом для инвестирования. И стартап тут - наша жизнь, которую мы улучшаем.