Как быть на одной волне с разработчиками и понимать их страшные диалоги, если ты системный аналитик? 🧠💡 Изучать технические детали проектирования систем, смотреть “под капот” (детали реализации) ваших “автомобилей” (проектов). Базы данных - один из первых шагов погружения в технические детали.

Что дает понимание технических деталей проекта:

✨ Единый язык
Почти во всех IT-проектах (кроме простых сайтов) есть БД. Представьте, вы обсуждаете с друзьями последний фильм, который все посмотрели, - вам легче находить общие темы.
Точно так же, понимая основы баз данных, вы можете на одном языке общаться с разработчиками - вы тоже на БД посмотрели 😎

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

✨ Понимание взаимосвязей данных и улучшение требований
Зная, как данные связаны между собой, вы можете лучше понимать их структуру. Это как когда ты пытаешься найти фото на своем телефоне, и вспоминаешь, с кем ты был на ней, и где это было. А потом смотришь в информации. Работаем с данными и связями. Когда знаешь как, куда и на что смотреть - все сразу легче и понятнее))

✨ Повышение производительности
Понимание того, как хранятся и обрабатываются данные, может помочь ускорить многие процессы, связанные с чтением и записью данных, улучшить производительность и уменьшить нагрузку на систему.
Это как когда вы знаете, как закрыть все фоновые приложения на своем телефоне, чтобы сохранить заряд батареи.


Развивайтесь. Больше читайте и разбирайте практику. Улучшайте понимание что “под капотом” систем, коммуникации с разработчиками, понимание обсуждений коллег на митингах. Повышайте качество ваших требований и делайте работу интереснее! 🔍🤝🙌

📝 Для чего нужна ER-диаграмма?

ER-диаграмма помогает разработчикам и аналитикам понять структуру данных и спроектировать БД. Это модель, на которой тестируют сценарии работы системы до начала разработки. Это, по сути, карта нашего "дома".

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

В проекте для Зоомагазина PetCo, это картинка, где показано, что "Клиент" может сделать "Заказ", а "Заказ" создается на основании "Корзины". Попробуйте сами почитать картинку к посту - это наша ER-модель на концептуальном уровне 🙂 Получается продумать историю?)

📌 Entity-Relationship в переводе с английского Сущности-Отношения.
И сейчас я предлагаю просто выучить перевод этих двух слов. И каждый раз, когда вам будут задавать этот теоретический вопрос, то идите по цепочке:

Entity.
Relationship.
Entity - это сущность.
Relationship - это про отношения (в социальных сетях типа ВК, если они у вас были на английском, чтобы его учить, то наверняка видели в графе “Отношения/Семейное положение” это слово, так было у меня).
Получается, это про сущности и отношения… а! А отношения - связи между ними.

Эврика! ER-диаграмма показывает все сущности (таблицы базы данных, их поля / атрибуты) и как они связаны друг с другом.

Это моя последовательность мыслей, когда я устраивалась на первую работу системным аналитиком и мой будущий руководитель спросил меня определение “Что такое ER-диаграмма?”. Самое страшное для меня было, что нарисовать я могла, а объяснить с ходу теорию - нет. Но он дал подсказку с английским и ровно по этой цепочке мыслей всё получилось 😄 Оффер на стажера был получен.

‼️Начинаем строить сильную ассоциацию с ER-диаграммой в вашем сознании:
это английский и что-то про отношения relationships в vk 😄
Entity - это сущность.
Relationship - это про отношения.
Устрою вам тестирование!

P.S. Еще раз: очень прошу не путать её с диаграммой классов UML.

Теперь готовы отвечать на вопросы собеседований:
▫️Какую нотацию используют для моделирования баз данных?
▫️Что такое ER-диаграмма и для чего она используется?
▫️Какие основные компоненты ER-диаграммы вы можете выделить?

Да? ❤️Есть еще вопросы - в комментарии 🙂

Сущность и атрибут в контексте ER-диаграммы

Сущность (Entity):
В контексте ER-диаграммы сущности представляют собой ключевые объекты или понятия, которые мы хотим описать и с которыми работать в рамках системы. Мы их извлекаем при вычитке требований.
Примеры:
🔵В библиотеке, сущностью может быть Книга.
🔵В рамках IT-инфраструктуры компании, сущностью может быть Сервер с конкретным номером.
🔵В нашем проекте PetCo, одной из сущностей является Заказ — комплексное представление о том, что клиент хочет приобрести.


Атрибут (Attribute):
Атрибуты описывают характеристики или свойства сущности. Это подробности, которые помогают нам лучше понять и описать каждую сущность.
Примеры:
🔵Книга: Название, Автор и Год издания.
🔵Сервер: IP-адрес, Тип оборудования и Местоположение.
🔵Заказ в PetCo: Номер заказа, Дата заказа, Статус заказа и Список товаров.

Есть ли отличия между сущностью и атрибутом в ER-диаграмме и без ER-диаграммы?
Нет.


Фиксируем ключевые определения:

Сущность — любой реальный или воображаемый (абстрактный) объект этого мира (стол, стул, мяч и т.д.).

Таблица — это физическая структура в базе данных, которая хранит данные конкретной сущности. Каждая запись в таблице представляет экземпляр сущности.
Одна сущность чаще всего представлена одной таблицей. Однако в сложных системах одна сущность может быть разделена между несколькими таблицами (например, из-за нормализации базы данных).

Свойство (атрибут) — характеристика сущности, описывающая конкретный объект (цвет, материал, размер).
Поле БД — это место в таблице БД, где хранится конкретное значение атрибута для конкретной записи.

Объект — сущность с конкретным набором атрибутов (зеленая железная большая машина; красный резиновый маленький мяч, желтое шелковое размера S платье) 🙌

Типы связей - моя любимая тема! Поэтому рассказываю, показываю лайфхаки, и мы переходим к логической модели БД 🙂

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

Есть три основных типа связей и остальные, в зависимости от системы и ситуации. Не усложняйте при проектировании. Как правило трех основных достаточно. Крайне редко можно встретить связь “один-к-двум”, но она есть в реальных проектах и часто без неё никуда.

🔶 Один-к-одному (1:1)
Каждому экземпляру сущности A соответствует не более одного экземпляра сущности B и наоборот.
Пример: Представьте, что в проекте PetCo каждый магазин имеет только одного администратора, и каждый администратор руководит только одним магазином. Здесь между магазином и администратором устанавливается связь 1:1.

🔶 Один-ко-многим (1:N) = Многие-к-одному (N:1) - разницы нет, только порядок чтения.
Один экземпляр сущности A может иметь отношение ко многим экземплярам сущности B, но каждый экземпляр сущности B связан с не более чем одним экземпляром сущности A.
Пример: Один клиент может сделать множество заказов в зоомагазине PetCo, но каждый заказ принадлежит только одному клиенту.

🔶 Многие-ко-многим (M:N)
Один экземпляр сущности A может иметь отношение ко многим экземплярам сущности B, и наоборот, один экземпляр сущности B может иметь отношение ко многим экземплярам сущности A.
Пример: В корзине по заказу может быть множество товаров из ассортимента, при этом один и тот же товар может быть включен в различные корзины разных клиентов.

На ER-диаграмме эти связи отображаются линиями между сущностями. Есть разные варианты обозначений. На картинке вы видите примеры связей ER и из UML (мне обозначения UML ближе - они понятнее).

🌟Лайфхак по определению кратностей связей 🌟

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

Помним, что кратности определяются всегда между двумя сущностями за один прогон алгоритма.


1. Читаем связь между сущностями с двух сторон первый раз.
Начинаем читать с “одного”.
Я обычно читаю слева-направо или сверху-вниз.
Пример: У одного Клиента может быть много Заказов.
У одного Клиента также может быть и один Заказ, но наиболее мощная (самая широкая по диапазону возможных значений) кратность побеждает.
Ставим рядом с Клиентом “1”, с Заказом “много”=*.


2. Читаем связь между сущностями с двух сторон второй раз, но уже наоборот, начиная с другой сущности.
Начинаем читать с “одного”.
Теперь справа-налево или снизу-вверх.
Пример: У одного Заказа может быть только один Клиент.
У одного Заказа не может быть много Клиентов. По бизнесу договариваемся и считаем, что Клиент (контактное лицо для доставки товаров из Зоомагазина) всегда один.
Ставим рядом с Заказом “1”, с Клиентом тоже “1”.


3. Получаем итог: нужно выбрать самые мощные (широкие) связи.

3.1. У Клиента в обоих случаях 1. Выбора нет. Ставим 1.
На всякий случай уточняем обязательность: могут быть Заказы без Клиентов?
Нет. Поэтому оставляем “1”.
А вот если бы Заказы без Клиентов были, то мы бы сделали кратность “0..1”, что значило бы: у одного Заказа может быть либо 1 Клиент, либо отсутствовать. Это можно было проверить и на шаге 2.


3.2. У Заказа в одном случае “1”, во втором “многие”. Побеждает наиболее мощная связь “многие”.
Уточняем обязательность: могут быть Клиенты без Заказов.
Да, которые зарегистрировались в системе, но пока Заказы не оформляли, работали только с корзиной. Оставляем “*”.
Но! Если бы у Клиентов обязательно должен был бы быть минимум один Заказ, то кратность мы бы поставили “1..*”. Вот так 🙂


4. Определяем связь: “1-к-1”, “1-ко-многим”, “многие-ко-многим”.
Итог: с одной стороны “1”, с другой “*”.
Получена связь Один-ко-многим (1:N).

Новая фишка для вас? Ставим ❤️ и сохраняем пост!

+ еще одна картинка лайфхака для проектирования БД 👀

Пример для связи “многие-ко-многим”.

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

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

Приятные ощущения от этих мыслей, да? Я хочу помочь вам сделать шаг в ваше реальное будущее.

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

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

Что я жду от вас:
✅ Готовность работать со мной в прямом эфире и не бояться задавать вопросы.
✅ Подготовка в течение недели по теории и инструментам.
✅ Не отвлекаться в процессе и заранее подготовиться к тому, что у вас реальное обучение.


Готовы получать опыт? Регистрируемся и отмечаем любой реакцией здесь, что вы в деле!
Жду в следующий вторник онлайн ❤️️

💠 Логическая модель БД 💠 (2 / 3-х уровней проектирования БД)

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

Зачем это нужно?

Логическая модель помогает:
1️⃣ Продумать, какие именно данные будут храниться.
2️⃣ Определиться с атрибутами (характеристиками) для каждой сущности.
3️⃣ Уточнить связи между сущностями и задать первичные и внешние ключи для обеспечения целостности данных.

Что нового по сравнению с концептуальной моделью?

▫️ Для каждой сущности появляются свойства. Например, у "Клиента" может быть "ФИО", "Телефон", "Email" и так далее.
▫️ Уточняются связи, и вводятся понятия первичного и внешнего ключей. Первичный ключ – это уникальный идентификатор записи в таблице. Внешний ключ – это атрибут, который ссылается на первичный ключ другой таблицы, обеспечивая связь между таблицами.

Пример для проекта PertCo:
▫️ Клиент: ID (первичный ключ), ФИО, Телефон, Email
▫️ Заказ: ID (первичный ключ), ID_Клиента (внешний ключ Клиент_ID), Дата, Сумма
▫️ Ассортимент: ID (первичный ключ), Наименование, Цена, Описание
... и так далее для всех сущностей.

Связи теперь выглядят более детализированно и с учетом ключей:
🔵 Один клиент (1) может сделать несколько (N) заказов. У заказа есть ссылка на клиента через внешний ключ. (1:N)

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

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

Многие из нас ошибочно представляют себе системных аналитиков как специалистов, работающих исключительно в техническом направлении. Но на деле их деятельность гораздо шире и охватывает не только техническую, но и организационную часть IT. Итог их труда - это качественное техническое задание и аналитические отчеты, адаптированные под требования и интересы заказчика. 📑


✨ 24 сентября мы отмечаем День системного аналитика! Этот праздник празднуют не только аналитики, но и системные администраторы, специалисты IT, технические директора и многие другие!

🔍 Немного истории: 20 сентября 2000 года в пригороде Чикаго на пикнике Т. Кекатос предложил отмечать этот день в знак благодарности системным аналитикам за их вклад. Россия поддержала эту традицию, признав день профессиональным праздником!

🧠 Системный аналитик – это человек, способный творить, созидать и преобразовывать идеи в реальные проекты. Успешный аналитик должен быть грамотным, профессиональным и всегда быть на шаг впереди!

🎉 Интересный факт: в 2009 году было выявлено, что профессия системного аналитика относится к числу наименее стрессовых, разделяя места с диетологами, астрономами и инженерами-программистами.

Дорогие коллеги! Команда GetAnalyst я, Екатерина Ананьева, подзравляем вас с прошедшим вчера профессиональным праздником! Пусть ваша работа всегда приносит удовлетворение, ваша карьера растет, а проекты всегда будут успешными! 💼🎉🥂

Логическая модель базы данных 🎓

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

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

Для системных аналитиков логическая модель БД важна, потому что она:
▫️ Дает четкое представление о структуре данных.
▫️ Помогает предсказать, как изменения в одной части системы могут повлиять на другие.
▫️ Стимулирует критическое мышление при анализе требований и поиске оптимальных решений.

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

Логическая модель базы данных позволяет углубиться в детали и увидеть все "ловушки" требований еще до начала реализации проекта 🚀

✨Практическое задание перед вебинаром!

Представьте, что вы работаете над проектом онлайн-библиотеки. У вас есть следующие требования:

✨ Читатели могут зарегистрироваться, указав своё имя, email и дату регистрации.
✨ Книги в библиотеке имеют название, автора и год издания.
✨ Читатели могут взять на время несколько книг.
✨ Нужно отслеживать, какие книги на руках у читателей и когда они должны вернуть их.

Как будет выглядеть ваша логическая модель?

1. Таблицы: Читатели, Книги, Взятые_книги. Где "Взятые_книги" связывает "Читатели" и "Книги", а также содержит дату возврата.
2. Таблицы: Читатели, Книги. В каждой книге есть поле "Читатель" и дата возврата.
3. Таблицы: Читатели, Авторы, Книги. Где "Авторы" - отдельная таблица, и в "Книгах" ссылка на автора, а у каждого читателя список книг и дата возврата.

Ответ (нажмите, чтобы увидеть): Правильный вариант - 1. Почему 2 и 3 неверные - пишите в комментарии!

---

Уже завтра на практическом вебинаре мы разберём, как правильно проектировать логические модели и другие темы, связанные с базами данных:

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

Присоединяйтесь к нам, чтобы углубить свои знания и умения в области проектирования баз данных. Отмечайте реакции, если вы готовы и завтра будете с нами! ❤️️

Считаю, что системный анализ невозможен без творческой составляющей.

Объясню на своём примере почему.

Я люблю рисовать👩‍🎨
Это способ реализации моей творческой стороны.
Мне нравится в процессе представлять какие-то образы и воплощать их на холсте.

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

Я уделяю большое внимание деталям при проектировании системы - “прорисовываю” их. Вижу её и в целом представляю, как будут работать отдельные компоненты. Это помогает создавать эффективные и надёжные системы.

Да, рисование и СА - две разные области, но они объединены общим подходом к творчеству🤗

Обе сферы требуют креативности, умения мыслить нестандартно и находить новые решения. Кроме того, как и в СА, в рисовании важно уметь работать с деталями и учитывать композицию.

Поэтому рекомендую ценить своё гуманитарное мышление и периодически прокачивать творческий потенциал 🖌

P.S. Нарисовала в прошлые выходные 🙌

🔑Первичный ключ в модели базы данных: раскрываю технические детали

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

Обычно его именуют как:
🔑 id - системный идентификатор, генерируется и присваивается записям автоматически, для человека может вообще ничего не значить. Это может быть порядковый номер или случайный набор символов созданный по определенному алгоритму (UUID).
🔑 number - уникальный номер записи внутри таблицы. Можно придумать для генерации уникального номера любой алгоритм. Обычно делают порядковый номер. Кстати, иногда для маркетинговый целей в системах с нуля номера заказов делают по порядку и начинают с 1000, например.
🔑 name - когда для уникальности используют какое-то имя или название, в зависимости от того, о какой сущности мы говорим.

Это самые распространенные варианты. И, кстати, работу с порядковыми номерами я не очень люблю. Если нужно будет делать параллельную обработку запросов в системе с распределенной архитектурой (где много баз данных, которые синхронизируются между собой), то есть шанс поймать проблем. Поэтому UUID - моя любовь!

В нашем проекте PetCo мы будем использовать системные идентификаторы формата UUID, которые за счет алгоритма генерации обеспечивают уникальность при каждом новом создании для всех записей, всех таблиц, всей базы 🙌 (пример: 5b1a48de-118c-4c2d-98b2-ada850322154). Это поможет нам избежать проблем для распределенных систем.

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

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


🔑 Обычный ключ:
Состоит из одного поля: 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 и данных в БД, и я даю инструмент для его генерации.