GETANALYSTSA-GetAnalyst-G-Food-online-1.0.0-resolved.yaml
4.9 KB
Исходник для Swagger по проекту G-Food 🔗
🔥9👍1
Невозможно не поделиться ещё одной историей нашей студентки Маргариты.
Маргарита работает в Сбербанке системным аналитиком уже 3-й год, но профильное образование имеет по бизнес-анализу.Необходимо было подтянуть знания по REST API.
Далее со слов Маргариты ⤵️
Как нередко случается у студентов GetAnalyst, Маргарита почувствовала больше уверенности в себе, проявила знания в работе и её перевели в новую команду на проекте 🔥🔥🔥
От себя хочу дополнить:
▪️ Каждую встречу мы включаем в рабочий процесс каждого участника, чтобы он смог получить максимальный результат.
▪️ Радуемся, что среди бытовых дел и работы вы находите силы прийти на вебинары.
▪️ После каждого отзыва гордимся, как вы раскрываетесь как специалисты, двигаетесь к целям и достигаете больше, чем планировали 🚀
Я счастлива, что могу собрать таких людей вокруг себя.
Спасибо, что выбираете GetAnalyst ❤
#студентыGetAnalyst
Маргарита работает в Сбербанке системным аналитиком уже 3-й год, но профильное образование имеет по бизнес-анализу.Необходимо было подтянуть знания по REST API.
Далее со слов Маргариты ⤵️
«На курсе получила всё, на что рассчитывала!
Программа ёмкая с большим количеством теоретического материала. Мы его закрепляли на практике на вебинарах.
Освоила Postman — очень классный, полезный инструмент, который обязательно буду использовать.»
Как нередко случается у студентов GetAnalyst, Маргарита почувствовала больше уверенности в себе, проявила знания в работе и её перевели в новую команду на проекте 🔥🔥🔥
От себя хочу дополнить:
▪️ Каждую встречу мы включаем в рабочий процесс каждого участника, чтобы он смог получить максимальный результат.
▪️ Радуемся, что среди бытовых дел и работы вы находите силы прийти на вебинары.
▪️ После каждого отзыва гордимся, как вы раскрываетесь как специалисты, двигаетесь к целям и достигаете больше, чем планировали 🚀
Я счастлива, что могу собрать таких людей вокруг себя.
Спасибо, что выбираете GetAnalyst ❤
#студентыGetAnalyst
❤15👏4👍3🔥3🎉2😴1
При проектировании REST API есть два места, на которые мы активно смотрим:
👉 Потребности клиента.
Это дизайн экранов или требовани от внешних систем, котрые будут подключаться к нам, чтобы получать данные.
Отсюда мы получаем информацию ЧТО нам нужно вернуть в ответе API или записать в БД.
👉 БД нашей системы.
Мы можем вернуть клиенту API только те данные, которые хранятся в БД, которые могут быть получены с помощью интеграций или расчитаны алгоритмом внутри системы.
На основе модели БД мы получаем ориентир - В КАКОЙ СТРУКТУРЕ данные могут быть представлены в формате JSON.
Поэтому понимание БД проекта важно перед началом работы с дизайном методов REST API.
А подробнее про то, как строить JSON-структуры на основе БД рассказыаю здесь 🔗
👉 Потребности клиента.
Это дизайн экранов или требовани от внешних систем, котрые будут подключаться к нам, чтобы получать данные.
Отсюда мы получаем информацию ЧТО нам нужно вернуть в ответе API или записать в БД.
👉 БД нашей системы.
Мы можем вернуть клиенту API только те данные, которые хранятся в БД, которые могут быть получены с помощью интеграций или расчитаны алгоритмом внутри системы.
На основе модели БД мы получаем ориентир - В КАКОЙ СТРУКТУРЕ данные могут быть представлены в формате JSON.
Поэтому понимание БД проекта важно перед началом работы с дизайном методов REST API.
А подробнее про то, как строить JSON-структуры на основе БД рассказыаю здесь 🔗
YouTube
Связь базы данных и дизайна REST API / Вебинар 17.02.2022
На вебинаре сделали модель базы данных и дизайн REST API:
— построили логическую модель базы данных
— описали JSON-объекты и методы REST API
— разобрали, какие бывают ошибки и как их избежать
Бесплатные вебинары GetAnalyst:
https://getanalyst.ru/events
…
— построили логическую модель базы данных
— описали JSON-объекты и методы REST API
— разобрали, какие бывают ошибки и как их избежать
Бесплатные вебинары GetAnalyst:
https://getanalyst.ru/events
…
❤15👍6🔥4
Media is too big
VIEW IN TELEGRAM
Типичное демо приложения заказчику. Багов точно нет, всё по плану 👌
🤣76💯5🔥4😁3
Проектируем БД для PostgreSQL 🚀
Продолжим историю с проектом G-Food по учету калорий, на котором разбирали методы REST API. Хочу затронуть тему проектирования БД и показать, как понимание БД помогает в создании JSON-объектов.
Базовые определения, важные для БД:
🔺 Сущность
Любой реальный или абстрактный объект этого мира, у которого есть набор характеристик.
Примеры:
- стол (имеет цвет, высоту, длину, ширину, материал, изготовителя),
- компьютер (имеет цвет, производителя, диагональ экрана, ОС и т.д.),
- продукт (имеет название, калории, белки, жиры, углеводы, описание, размеры порций - в контексте нашего проекта G-Food).
🔺 Свойство / Атрибут / Параметр / Поле
Характеристики сущности.
В примерах выше перечисляются в скобках: цвет, высота, длина, описание, и т.д. При проектировании систем всегда выделяются только те характеристики, которые реально будут использоваться в системе.
В примере выше у меня для сущности “Стол” ошибка, если я проектирую Интернет-магазин. Нет цены в характеристиках (свойствах сущности).
🔺 Объект
Сущность с конкретными характеристиками.
Примеры для сущности "Продукт":
- Овсяные хлопья, калории = 364, Б=12, Ж=6, У=61, Описание = Еда на завтрак, Размеры порций = [45 г, 60 г, 100 г],
- Овсяные хлопья, калории = 364, Б=12, Ж=6, У=61, Описание = Еда на завтрак - Геркулес традиционный, Размеры порций = [30 г, 60 г, 100 г],
- Банан, калории = 96, Б=1, Ж=0.5, У=21, Описание = Желтый фрукт, Размеры порций = [75 г, 150 г],
и т.д.
Объекты - это то, что мы можем увидеть, измерить, пощупать, познать. Воспринимайте это так. И помните, что объеты бывают не только физические. Например - сериал или файл в компьютере.
Разница между сущностью и объектом:
Сущность - обобщение группы объектов с одинаковым набором характеристик, которые будут храниться в будущей системе.
Объект - сущность с конкретными характеристиками.
Эти 3 определения важно знать, чтобы:
✔️ общаться с разработчиками,
✔️ определять потоки данных из бизнес-процессов, не теряя важные требования,
✔️ проектировать БД.
Продолжим историю с проектом G-Food по учету калорий, на котором разбирали методы REST API. Хочу затронуть тему проектирования БД и показать, как понимание БД помогает в создании JSON-объектов.
Базовые определения, важные для БД:
🔺 Сущность
Любой реальный или абстрактный объект этого мира, у которого есть набор характеристик.
Примеры:
- стол (имеет цвет, высоту, длину, ширину, материал, изготовителя),
- компьютер (имеет цвет, производителя, диагональ экрана, ОС и т.д.),
- продукт (имеет название, калории, белки, жиры, углеводы, описание, размеры порций - в контексте нашего проекта G-Food).
🔺 Свойство / Атрибут / Параметр / Поле
Характеристики сущности.
В примерах выше перечисляются в скобках: цвет, высота, длина, описание, и т.д. При проектировании систем всегда выделяются только те характеристики, которые реально будут использоваться в системе.
В примере выше у меня для сущности “Стол” ошибка, если я проектирую Интернет-магазин. Нет цены в характеристиках (свойствах сущности).
🔺 Объект
Сущность с конкретными характеристиками.
Примеры для сущности "Продукт":
- Овсяные хлопья, калории = 364, Б=12, Ж=6, У=61, Описание = Еда на завтрак, Размеры порций = [45 г, 60 г, 100 г],
- Овсяные хлопья, калории = 364, Б=12, Ж=6, У=61, Описание = Еда на завтрак - Геркулес традиционный, Размеры порций = [30 г, 60 г, 100 г],
- Банан, калории = 96, Б=1, Ж=0.5, У=21, Описание = Желтый фрукт, Размеры порций = [75 г, 150 г],
и т.д.
Объекты - это то, что мы можем увидеть, измерить, пощупать, познать. Воспринимайте это так. И помните, что объеты бывают не только физические. Например - сериал или файл в компьютере.
Разница между сущностью и объектом:
Сущность - обобщение группы объектов с одинаковым набором характеристик, которые будут храниться в будущей системе.
Объект - сущность с конкретными характеристиками.
Эти 3 определения важно знать, чтобы:
✔️ общаться с разработчиками,
✔️ определять потоки данных из бизнес-процессов, не теряя важные требования,
✔️ проектировать БД.
❤22🔥8👍5🥰1
Чтобы начать работу с проектированием БД, необходимо определить сущности. Это делается в процессе сбора и анализа требований.
Приложение для учета калорий "G-Food" включает в себя несколько ключевых сущностей:
🔸 Пользователь (User): Эта сущность содержит информацию о пользователях приложения. Атрибуты могут включать имя пользователя, электронную почту, пароль, возраст, пол, вес, рост, уровень активности и желаемую цель (например, похудение, поддержание веса, набор массы).
🔸 Продукт питания (Food Item): Здесь хранится информация о различных продуктах питания. Атрибуты могут включать название продукта, количество калорий на 100 грамм/единицу продукта, белки, жиры, углеводы, витамины, минералы и т.д.
🔸 Прием пищи (Meal Entry): Связывает пользователей и продукты питания. В каждой записи может содержаться информация о конкретном количестве употребленного продукта, времени приема пищи и т.д.
🔸 Физическая активность (Physical Activity): В этой сущности могут храниться данные о физической активности пользователя, включая тип активности (бег, ходьба, велоспорт и т.д.), продолжительность и приблизительное количество сожженных калорий.
Эти сущности могут быть связаны друг с другом. Например, каждый "Прием пищи" будет связан с "Пользователем". "Физическая активность" также будет связана с "Пользователем" и может влиять на дневное количество калорий.
Эта информация о сущностях G-Food потребуется для создания БД PostgreSQL 🙌
Приложение для учета калорий "G-Food" включает в себя несколько ключевых сущностей:
🔸 Пользователь (User): Эта сущность содержит информацию о пользователях приложения. Атрибуты могут включать имя пользователя, электронную почту, пароль, возраст, пол, вес, рост, уровень активности и желаемую цель (например, похудение, поддержание веса, набор массы).
🔸 Продукт питания (Food Item): Здесь хранится информация о различных продуктах питания. Атрибуты могут включать название продукта, количество калорий на 100 грамм/единицу продукта, белки, жиры, углеводы, витамины, минералы и т.д.
🔸 Прием пищи (Meal Entry): Связывает пользователей и продукты питания. В каждой записи может содержаться информация о конкретном количестве употребленного продукта, времени приема пищи и т.д.
🔸 Физическая активность (Physical Activity): В этой сущности могут храниться данные о физической активности пользователя, включая тип активности (бег, ходьба, велоспорт и т.д.), продолжительность и приблизительное количество сожженных калорий.
Эти сущности могут быть связаны друг с другом. Например, каждый "Прием пищи" будет связан с "Пользователем". "Физическая активность" также будет связана с "Пользователем" и может влиять на дневное количество калорий.
Эта информация о сущностях G-Food потребуется для создания БД PostgreSQL 🙌
👍16❤3
📚 3 последовательных уровня проектирования БД и зоны ответственности - самое важное 📚
🗝 Концептуальный - БА, СА
+ отражает только сущности и связи между ними, их кратности,
++ поверхностный,
++ используется редко,
++ не связан с СУБД (у нас PostgreSQL).
🗝 Логический - БА, СА
+ отражает сущности и связи между ними, их кратности,
+ показывает свойства каждой сущности,
+ в свойствах выделены ключи: первичные и внешние,
+ на этом уровне рекомендуется убрать сложные связи между сущностями (многие-ко-многим),
+ названия полей и таблиц могут быть на русском,
++ детальное проектирование,
++ используется часто,
++ не связан с СУБД.
🗝 Физический - СА, разработчики, архитекторы
+ отражает сущности и связи между ними, их кратности,
+ показывает свойства каждой сущности,
+ в свойствах выделены ключи: первичные и внешние,
+ на этом уровне НУЖНО убрать сложные связи между сущностями (многие-ко-многим),
+ названия полей и таблиц ЛУЧШЕ НА АНГЛИЙСКОМ,
+ включает типы данных,
+ есть информация об уникальности, обязательности, индексах (для оптимизации запросов),
++ детальное проектирование,
++ используется часто,
++ связан с СУБД (у нас PostgreSQL).
Из всех трех уровней нам наиболее интересен физический для работы с моделированием под PostgreSQL. Именно он отражает реальную модель БД.
🗝 Концептуальный - БА, СА
+ отражает только сущности и связи между ними, их кратности,
++ поверхностный,
++ используется редко,
++ не связан с СУБД (у нас PostgreSQL).
🗝 Логический - БА, СА
+ отражает сущности и связи между ними, их кратности,
+ показывает свойства каждой сущности,
+ в свойствах выделены ключи: первичные и внешние,
+ на этом уровне рекомендуется убрать сложные связи между сущностями (многие-ко-многим),
+ названия полей и таблиц могут быть на русском,
++ детальное проектирование,
++ используется часто,
++ не связан с СУБД.
🗝 Физический - СА, разработчики, архитекторы
+ отражает сущности и связи между ними, их кратности,
+ показывает свойства каждой сущности,
+ в свойствах выделены ключи: первичные и внешние,
+ на этом уровне НУЖНО убрать сложные связи между сущностями (многие-ко-многим),
+ названия полей и таблиц ЛУЧШЕ НА АНГЛИЙСКОМ,
+ включает типы данных,
+ есть информация об уникальности, обязательности, индексах (для оптимизации запросов),
++ детальное проектирование,
++ используется часто,
++ связан с СУБД (у нас PostgreSQL).
Из всех трех уровней нам наиболее интересен физический для работы с моделированием под PostgreSQL. Именно он отражает реальную модель БД.
❤14🔥8👍3
Если быть упертым бараном ставить цели, то будут результаты 🦄
Январь прошёл продуктивно. Сейчас период, когда в очередной раз прокачиваю себя в профессиональной сфере. И одним из достижений января стало признание меня в международной ассоциации IEEE как эксперта в сфере разработки программного обеспечения.
IEEE - международная некоммерческая профессиональная организация, предназначенная для продвижения технологий, связанных с электротехникой, электроникой, компьютерными науками и смежными областями. За этой организацией стоят стандарты Ethernet и Wi-Fi.
Вчера пришло письмо с поздравлениями. Чтож. Теперь у меня есть 👇
Recognition: The professional recognition of your peers for technical and professional excellence.
Признание: профессиональное признание коллег за техническое и профессиональное мастерство.
Сейчас задач очень много. По всем направлениям. И я искренне благодарю
команду, кто помогает мне вывезти это всё,
близких, кто слушает моё нытьё, после которого я иду и делаю,
и людей, на которых я равняюсь, и которые дают мне ценные советы из своего опыта.
Сложно бывает, очень, но я вывожу))
Много грандиозных планов, много всего получается, и это круто. Но очень много работы и выхода за границы возможностей. Иногда хочется просто спрятаться под одеялом и ничего не делать.
Так что на фото еще можно увидеть мини-отпуск с прошлой недели, потому что баланс работа-отдых должен быть 🌴 Путешествия заряжают меня энергией и положительными эмоциями.
Хотите меняться и двигаться вперёд? Ставьте четкие цели и дейстуйте. А чтобы всё получалось, держите рядом группу поддержки и кумиров, которые вдохновляют идти вперёд! И не забывайте делать перерывы - нам всем нужно уметь вовремя расслабиться и собрать сил на новые шаги. Это важно.
Всё получится и всё возможно! Я верю))
Желаю вам прекрасных выходных ❤️
Январь прошёл продуктивно. Сейчас период, когда в очередной раз прокачиваю себя в профессиональной сфере. И одним из достижений января стало признание меня в международной ассоциации IEEE как эксперта в сфере разработки программного обеспечения.
IEEE - международная некоммерческая профессиональная организация, предназначенная для продвижения технологий, связанных с электротехникой, электроникой, компьютерными науками и смежными областями. За этой организацией стоят стандарты Ethernet и Wi-Fi.
Вчера пришло письмо с поздравлениями. Чтож. Теперь у меня есть 👇
Recognition: The professional recognition of your peers for technical and professional excellence.
Сейчас задач очень много. По всем направлениям. И я искренне благодарю
команду, кто помогает мне вывезти это всё,
близких, кто слушает моё нытьё, после которого я иду и делаю,
и людей, на которых я равняюсь, и которые дают мне ценные советы из своего опыта.
Сложно бывает, очень, но я вывожу))
Много грандиозных планов, много всего получается, и это круто. Но очень много работы и выхода за границы возможностей. Иногда хочется просто спрятаться под одеялом и ничего не делать.
Так что на фото еще можно увидеть мини-отпуск с прошлой недели, потому что баланс работа-отдых должен быть 🌴 Путешествия заряжают меня энергией и положительными эмоциями.
Хотите меняться и двигаться вперёд? Ставьте четкие цели и дейстуйте. А чтобы всё получалось, держите рядом группу поддержки и кумиров, которые вдохновляют идти вперёд! И не забывайте делать перерывы - нам всем нужно уметь вовремя расслабиться и собрать сил на новые шаги. Это важно.
Всё получится и всё возможно! Я верю))
Желаю вам прекрасных выходных ❤️
❤36🔥21
📌 ER-диаграмма для проектирования БД 📌
Для проектирования баз данных используют ER-диаграммы (Entity-Relationship Diagram). В резюме аналитиков, в разделе “Навыки”, работодатели часто ищут этот инструмент.
ER-диаграмма — это схема, которая помогает визуализировать структуру базы данных и показывает, как различные элементы (сущности) базы данных связаны между собой.
ER-диаграммы для концептуального, логического и физического уровня моделей БД различаются. Соответственно её элементы зависят от того, какой уровень она показывает.
Подвохи, о которых следует помнить:
🔺 Диаграмма классов UML и ER-диаграмма про разное.
- ER-диаграмма показывает схему БД.
- UML классов показывает классы программного кода.
🔺 Только ER-диаграмма физического уровня показывает схему реальной БД.
Концептуальный и логический уровень - это этапы исследования и анализа данных, чтобы дойти до физического уровня. Хотя логический уровень может быть похож на реальную БД.
Популярные инструменты для создания ER-диаграмм:
🔧 Draw.io - любимый инструмент, в котороом можно сделать всё! В нём буду вам показывать как создавать ER-диаграмму. Бесплатный.
Чтобы работать с ER:
Вкладка Сущность-Связь / Entity Relation на левой боковой панели.
Если её нет, активируем через “Больше элементов” / “More Shape”.
🔧 Microsoft Visio - инструмент от Microsoft, часто используемый для создания различных диаграмм, включая ER. Платный.
Заменяется Draw.io более чем на 100%.
🔧 Lucidchart - онлайн-инструмент, который позволяет создавать ER-диаграммы. Тоже аналог Draw.io. Есть бесплатная версия с ограничениями.
🔧 DBeaver (Community Edition) - позволяет визуализировать ER-диаграмму реальной БД, подключившись к ней. Второй важный для меня инструмент помимо Draw.io. Он подходит для просмотра готовой модели, но не для проектирования БД. Бесплатный. Постоянно обновляется и улучшается.
ER-диаграмма — это не просто красивая картинка, а ключевой инструмент IT-специалиста для проектирования БД, которая является основой любой системы.
Для проектирования баз данных используют ER-диаграммы (Entity-Relationship Diagram). В резюме аналитиков, в разделе “Навыки”, работодатели часто ищут этот инструмент.
ER-диаграмма — это схема, которая помогает визуализировать структуру базы данных и показывает, как различные элементы (сущности) базы данных связаны между собой.
ER-диаграммы для концептуального, логического и физического уровня моделей БД различаются. Соответственно её элементы зависят от того, какой уровень она показывает.
Подвохи, о которых следует помнить:
🔺 Диаграмма классов UML и ER-диаграмма про разное.
- ER-диаграмма показывает схему БД.
- UML классов показывает классы программного кода.
🔺 Только ER-диаграмма физического уровня показывает схему реальной БД.
Концептуальный и логический уровень - это этапы исследования и анализа данных, чтобы дойти до физического уровня. Хотя логический уровень может быть похож на реальную БД.
Популярные инструменты для создания ER-диаграмм:
🔧 Draw.io - любимый инструмент, в котороом можно сделать всё! В нём буду вам показывать как создавать ER-диаграмму. Бесплатный.
Чтобы работать с ER:
Вкладка Сущность-Связь / Entity Relation на левой боковой панели.
Если её нет, активируем через “Больше элементов” / “More Shape”.
🔧 Microsoft Visio - инструмент от Microsoft, часто используемый для создания различных диаграмм, включая ER. Платный.
Заменяется Draw.io более чем на 100%.
🔧 Lucidchart - онлайн-инструмент, который позволяет создавать ER-диаграммы. Тоже аналог Draw.io. Есть бесплатная версия с ограничениями.
🔧 DBeaver (Community Edition) - позволяет визуализировать ER-диаграмму реальной БД, подключившись к ней. Второй важный для меня инструмент помимо Draw.io. Он подходит для просмотра готовой модели, но не для проектирования БД. Бесплатный. Постоянно обновляется и улучшается.
ER-диаграмма — это не просто красивая картинка, а ключевой инструмент IT-специалиста для проектирования БД, которая является основой любой системы.
❤17👍8🔥5🤩1
🟨 Проектирование БД: пример ER-диаграммы - концептуальный уровень 🟨
Это первый и самый абстрактный уровень проектирования. Он почти не похож на реальную БД.
На практике я его использую только при работе с заметками по проекту на встречах. В работе всегда стартую с логического или сразу иду на физический.
На этом этапе мы определяем, какие данные будут храниться в БД и как они связаны друг с другом, не углубляясь в технические детали.
Концептуальная модель отражает:
🔸 основные сущности будущей БД (например, продукты, пользователи, прием пищи - запись об употребленных калориях),
🔸 связи между ними (как пользователи связаны с приемами пищи, как продукты связаны с пользователями и т.д.).
Важно понимать, что в контексте концептуальной модели БД:
- Сущности это не таблицы БД, хотя в на следующих уровнях проектирования могут ими стать.
- Концептуальная модель может содержать избыточные связи, которые затем могут уйти на следующих уровнях.
Концептуальный уровень помогает понять общую структуру данных в контексте бизнеса или задачи, которую должна решать БД. Обычно, читая концептуальную модель, можно понять предметную область и основные бизнес-процессы, не углубляясь в детали ТЗ.
Для моделирования ER-диаграммы концептуального уровня используют нотации:
- нотация IDEF1X - устаревшая, почти не используется,
- нотация Чена - актуальная и наиболее популярная,
- нотация Мартина - ее элементы чаще используются для логического уровня.
- нотация UML - используют элементы диаграммы классов для создания схемы, наиболее удобная.
К посту прикрепила концептуальную модель БД для G-Food в двух нотациях.
Вопрос опытным коллегам:
Используете ли вы концептуальную модель в процессе проектирования БД?
Делитесь в комментариях, как она вам помогает или почему не используете.
Это первый и самый абстрактный уровень проектирования. Он почти не похож на реальную БД.
На практике я его использую только при работе с заметками по проекту на встречах. В работе всегда стартую с логического или сразу иду на физический.
На этом этапе мы определяем, какие данные будут храниться в БД и как они связаны друг с другом, не углубляясь в технические детали.
Концептуальная модель отражает:
🔸 основные сущности будущей БД (например, продукты, пользователи, прием пищи - запись об употребленных калориях),
🔸 связи между ними (как пользователи связаны с приемами пищи, как продукты связаны с пользователями и т.д.).
Важно понимать, что в контексте концептуальной модели БД:
- Сущности это не таблицы БД, хотя в на следующих уровнях проектирования могут ими стать.
- Концептуальная модель может содержать избыточные связи, которые затем могут уйти на следующих уровнях.
Концептуальный уровень помогает понять общую структуру данных в контексте бизнеса или задачи, которую должна решать БД. Обычно, читая концептуальную модель, можно понять предметную область и основные бизнес-процессы, не углубляясь в детали ТЗ.
Для моделирования ER-диаграммы концептуального уровня используют нотации:
- нотация IDEF1X - устаревшая, почти не используется,
- нотация Чена - актуальная и наиболее популярная,
- нотация Мартина - ее элементы чаще используются для логического уровня.
- нотация UML - используют элементы диаграммы классов для создания схемы, наиболее удобная.
К посту прикрепила концептуальную модель БД для G-Food в двух нотациях.
Вопрос опытным коллегам:
Используете ли вы концептуальную модель в процессе проектирования БД?
Делитесь в комментариях, как она вам помогает или почему не используете.
❤9🔥5👍3👏2👎1🤩1
G-Food Database by GetAnalyst - Logical Level.drawio.png
413.2 KB
🟨 Проектирование БД: пример ER-диаграммы - логический уровень 🟨
Логическая модель показывает структуру реляционной базы данных, состоящей из таблиц, полей и связей между ними.
На этом этапе мы переводим концептуальную модель в более конкретную форму, не привязываясь пока к какой-либо конкретной системе управления базами данных (СУБД).
На логическом уровне мы уже думаем о типах данных, но всё ещё не заботимся о физических аспектах хранения данных и не отражаем их в модели, т.к. после перехода к конкретной СУБД могут возникнуть несовместимости.
Логическая модель отражает структуру таблиц:
- поля (свойства сущностей - столбцы таблиц),
- первичные ключи (PK - Primary Key) - отвечают за уникальность, часто вводятся искусственные значения (например. uuid или порядковый номер),
- внешние ключи (FK - Foreign Key) - для отражения связей между таблицами,
- Кратности связей (один-ко-многим, один-к-одному, многие-ко-многим).
❗️Если на уровне логической модели вы получили связи “многие-ко-многим”, то к завершению работы с этим уровнем их нужно “развязать” за счет введения промежуточной таблицы. Этот процесс называется нормализацией, чтобы создание реляционной базы данных было возможно. Нормализация позволяет представлять в “плоских таблицах” - как-будто у вас файл EXCEL и в нем каждая страница это наша таблица с колонками.
В примере для G-Food вы найдёте подсказки (в комментариях):
- как проставлять кратности,
- где располагать внешние ключи,
- как проектировать справочники, которые будут пополняться (пример: виды физ. активности),
- как отражать перечисления (списки значений),
- другие.
*Допущение для текущей модели: пока авторизацию пользователя сделали упрощенной, в идеале вынести в отдельную таблицу параметры учетной записи и ввести систему хранения активных токенов пользователя.
Изучайте и сохраняйте пример 🙂 А далее мы продолжим с физическим уровнем и перейдем к проектированию под PostgreSQL.
Логическая модель показывает структуру реляционной базы данных, состоящей из таблиц, полей и связей между ними.
На этом этапе мы переводим концептуальную модель в более конкретную форму, не привязываясь пока к какой-либо конкретной системе управления базами данных (СУБД).
На логическом уровне мы уже думаем о типах данных, но всё ещё не заботимся о физических аспектах хранения данных и не отражаем их в модели, т.к. после перехода к конкретной СУБД могут возникнуть несовместимости.
Логическая модель отражает структуру таблиц:
- поля (свойства сущностей - столбцы таблиц),
- первичные ключи (PK - Primary Key) - отвечают за уникальность, часто вводятся искусственные значения (например. uuid или порядковый номер),
- внешние ключи (FK - Foreign Key) - для отражения связей между таблицами,
- Кратности связей (один-ко-многим, один-к-одному, многие-ко-многим).
❗️Если на уровне логической модели вы получили связи “многие-ко-многим”, то к завершению работы с этим уровнем их нужно “развязать” за счет введения промежуточной таблицы. Этот процесс называется нормализацией, чтобы создание реляционной базы данных было возможно. Нормализация позволяет представлять в “плоских таблицах” - как-будто у вас файл EXCEL и в нем каждая страница это наша таблица с колонками.
В примере для G-Food вы найдёте подсказки (в комментариях):
- как проставлять кратности,
- где располагать внешние ключи,
- как проектировать справочники, которые будут пополняться (пример: виды физ. активности),
- как отражать перечисления (списки значений),
- другие.
*Допущение для текущей модели: пока авторизацию пользователя сделали упрощенной, в идеале вынести в отдельную таблицу параметры учетной записи и ввести систему хранения активных токенов пользователя.
Изучайте и сохраняйте пример 🙂 А далее мы продолжим с физическим уровнем и перейдем к проектированию под PostgreSQL.
👍20❤8🔥4👎1
Физическая модель реляционной БД – это финальный чертеж для вашей будущей базы данных. Остаётся только воплотить её в жизнь с помощью SQL-запросов или других полезных инструментов СУБД и готово! 💻 Можно писать логику систему, работать с функциями на получение и хранение данных.
Что показывает физическая модель базы данных:
🔵 таблицы с наименованиями, которые фактически будут БД,
🔵 поля с наименованиями, которые фактически будут БД,
🔵 типы данных и ограничения для полей,
🔵 первичные и внешние ключи,
🔵 обязательность для полей,
🔵 уникальность для полей,
🔵 индексы,
🔵 связи между таблицами и за счет каких полей они реализуются.
Физическая модель дополняет и конкретизирует логическую модель.
Понимание физической модели позволяет видеть, как данные будут храниться и использоваться в реальных системах.
Что показывает физическая модель базы данных:
🔵 таблицы с наименованиями, которые фактически будут БД,
🔵 поля с наименованиями, которые фактически будут БД,
🔵 типы данных и ограничения для полей,
🔵 первичные и внешние ключи,
🔵 обязательность для полей,
🔵 уникальность для полей,
🔵 индексы,
🔵 связи между таблицами и за счет каких полей они реализуются.
Физическая модель дополняет и конкретизирует логическую модель.
Понимание физической модели позволяет видеть, как данные будут храниться и использоваться в реальных системах.
⚡13❤8👍5👎1
G-Food Database by GetAnalyst-PostgreSQL.drawio.png
307.9 KB
🟨 PostgreSQL - пример перехода к физической модели БД 🟨
Переходим от логической к физической модели БД.
Как я это делала поэтапно для нашего проекта G-Food:
1. Т.к. моя модель была создана в draw.io, то для начала я её просто скопировала “как есть” и переименовала в физическую.
2. Далее воспользовалась знаниями английского (или Google Translate / Reverso) и перевела все наименования таблиц и полей на английский.
3. Ознакомилась с типами данных PostgreSQL. Документация PostgreSQL по типам данных доступна по этой ссылке.
4. Для каждого поля в скобках начала указывать:
- тип данных,
- NOT NULL - обязательность,
- UNIQUE - уникальность,
- default - значения по умолчанию.
Пока не занималась оптимизацией и не указала индексы.
5. Проверила, что нигде точно нет связи “Многие-ко-многим”.
6. Структурировано хранение ФИО для администратора, т.к. хранить в одном поле может быть плохо для работы с поиском в будущем.
Скачайте и внимательно сравните две картинки. Так вы поймёте как прошёл переход от логической модели к физической по инструкции выше. Положение таблиц старалась максимально сохранить для вас :)
Переходим от логической к физической модели БД.
Как я это делала поэтапно для нашего проекта G-Food:
1. Т.к. моя модель была создана в draw.io, то для начала я её просто скопировала “как есть” и переименовала в физическую.
2. Далее воспользовалась знаниями английского (или Google Translate / Reverso) и перевела все наименования таблиц и полей на английский.
3. Ознакомилась с типами данных PostgreSQL. Документация PostgreSQL по типам данных доступна по этой ссылке.
4. Для каждого поля в скобках начала указывать:
- тип данных,
- NOT NULL - обязательность,
- UNIQUE - уникальность,
- default - значения по умолчанию.
Пока не занималась оптимизацией и не указала индексы.
5. Проверила, что нигде точно нет связи “Многие-ко-многим”.
6. Структурировано хранение ФИО для администратора, т.к. хранить в одном поле может быть плохо для работы с поиском в будущем.
Скачайте и внимательно сравните две картинки. Так вы поймёте как прошёл переход от логической модели к физической по инструкции выше. Положение таблиц старалась максимально сохранить для вас :)
🔥12❤7👍2👎1
🪲 Типичные ошибки проектирования БД 🪲
При проектировании реляционных БД разработчики и аналитики допускают ошибки, которые могут привести к проблемам в ее использовании.
БД - это как фундамент в строительстве дома. Если вы не построите основание правильно, то в дальнейшем будут возникать проблемы, которые могут стать катастрофическими 🏡
Хочу поделиться с вами подборкой типичных ошибок проектирования БД и рекомендациями, как их избежать 🪲
Неправильное определение первичного ключа
🪲: При проектировании базы данных для онлайн-магазина, первичный ключ для таблицы "Товар" определили как "Имя".
Это может привести к ситуации, когда два товара с одинаковым названием нельзя будет создать, хотя такое может быть необходимо пользователю системы.
💊: Лучше определить первичный ключ как уникальный идентификатор, который не зависит от вводимых пользователем данных и не может быть случайно задублирован. Например, можно использовать автоинкрементирующееся поле "id". Также я рекомендую использовать UUID-ы (f81d4fae-7dec-11d0-a765-00a0c91e6bf6), но они занимают много памяти.
Использование ненужных таблиц
🪲: При проектировании базы данных для онлайн-магазина, разработчик создали отдельные таблицы для каждого типа товаров (продукты, хоз. товары, одежда и т.д).
При этом не обратили внимание, что все эти типы товаров имеют почти одинаковый набор свойств (полей).
💊: Лучше использовать одну таблицу "Товары" с полем "тип товара" и заполнять только нужные данные под каждый тип товара. Это позволит избежать дубли и сложные запросы к БД для работы со списком всех товаров в системе и поиском по ним (как минимум).
Хранение паролей в БД в чистом виде (без шифрования)
🪲: Не храните пароли в явном виде или в форме, которую можно легко прочитать.
💊: Если вы хотите, чтобы данные ваших пользователей были в безопасности, то вместо того, чтобы хранить пароли в явном виде, храните их в зашифрованном виде.
Продолжение скоро 👇
При проектировании реляционных БД разработчики и аналитики допускают ошибки, которые могут привести к проблемам в ее использовании.
БД - это как фундамент в строительстве дома. Если вы не построите основание правильно, то в дальнейшем будут возникать проблемы, которые могут стать катастрофическими 🏡
Хочу поделиться с вами подборкой типичных ошибок проектирования БД и рекомендациями, как их избежать 🪲
Неправильное определение первичного ключа
🪲: При проектировании базы данных для онлайн-магазина, первичный ключ для таблицы "Товар" определили как "Имя".
Это может привести к ситуации, когда два товара с одинаковым названием нельзя будет создать, хотя такое может быть необходимо пользователю системы.
💊: Лучше определить первичный ключ как уникальный идентификатор, который не зависит от вводимых пользователем данных и не может быть случайно задублирован. Например, можно использовать автоинкрементирующееся поле "id". Также я рекомендую использовать UUID-ы (f81d4fae-7dec-11d0-a765-00a0c91e6bf6), но они занимают много памяти.
Использование ненужных таблиц
🪲: При проектировании базы данных для онлайн-магазина, разработчик создали отдельные таблицы для каждого типа товаров (продукты, хоз. товары, одежда и т.д).
При этом не обратили внимание, что все эти типы товаров имеют почти одинаковый набор свойств (полей).
💊: Лучше использовать одну таблицу "Товары" с полем "тип товара" и заполнять только нужные данные под каждый тип товара. Это позволит избежать дубли и сложные запросы к БД для работы со списком всех товаров в системе и поиском по ним (как минимум).
Хранение паролей в БД в чистом виде (без шифрования)
🪲: Не храните пароли в явном виде или в форме, которую можно легко прочитать.
💊: Если вы хотите, чтобы данные ваших пользователей были в безопасности, то вместо того, чтобы хранить пароли в явном виде, храните их в зашифрованном виде.
Продолжение скоро 👇
❤25🔥9👍6😴5
🪲Типичные ошибки проектирования БД - часть 2 🪲
Не описан алгоритм изменения схемы БД в процессе релиза (миграции данных)
🪲: При изменении базы данных было добавлено новое обязательное поле "Внешний идентификатор" в таблицу "Заказ", чтобы поддержать обработку заказов из внешних систем, типа (Amazon, Ozon и тд). Но от аналитика не было требования чем заполнить это поле для старых заказов, которые были созданы ранее. Что туда добавлять?
💊: Не забывайте про миграции.
Миграции БД - это процесс изменения схемы БД со временем, что может быть необходимо для поддержки новых функций или исправления ошибок.
Не забывайте добавлять требования к миграции при каждом изменении структуры базы данных, иначе вы можете создать баги, связанные с недостатком данных или с несовместимостью версий БД.
Поддержка регионов и часовых поясов
🪲: При разработке не учли, что пользователи системы живут в разных часовых поясах. Сведения о часовом поясе отсутствуют для значений времени в БД и им могут отображаться некорректные данные: например о времени отправления поезда в билетной системе.
💊: Не забывайте о часовых поясах и специальных форматах времени и даты.
Неверные типы данных в БД - выход за границы диапазона
🪲: При разработке налоговой системы ИНН решили хранить в целочисленном виде. В процессе работы системы пришла ошибка, что ИНН не сохраняется или почему-то выглядит не так, как ввел пользователь.
💊: Проверяйте ограничения по типам данных в СУБД (PostgreSQL, MySQL. и другие) и сопоставляйте с реальными значениями, которые могут ввести пользователи. Ищите границы и выбирайте соответствующие типы данных. Особенно часто проблемы встречаются с номерами телефонов, документов и подобными. Часто их вообще лучше хранить в виде строки.
Это распространенные ошибки начинающих специалистов, которые погружаются в техническое проектирование систем. Сохраняйте эти примеры. Они помогут избежать ошибки в вашей работе 🙌
Не описан алгоритм изменения схемы БД в процессе релиза (миграции данных)
🪲: При изменении базы данных было добавлено новое обязательное поле "Внешний идентификатор" в таблицу "Заказ", чтобы поддержать обработку заказов из внешних систем, типа (Amazon, Ozon и тд). Но от аналитика не было требования чем заполнить это поле для старых заказов, которые были созданы ранее. Что туда добавлять?
💊: Не забывайте про миграции.
Миграции БД - это процесс изменения схемы БД со временем, что может быть необходимо для поддержки новых функций или исправления ошибок.
Не забывайте добавлять требования к миграции при каждом изменении структуры базы данных, иначе вы можете создать баги, связанные с недостатком данных или с несовместимостью версий БД.
Поддержка регионов и часовых поясов
🪲: При разработке не учли, что пользователи системы живут в разных часовых поясах. Сведения о часовом поясе отсутствуют для значений времени в БД и им могут отображаться некорректные данные: например о времени отправления поезда в билетной системе.
💊: Не забывайте о часовых поясах и специальных форматах времени и даты.
Неверные типы данных в БД - выход за границы диапазона
🪲: При разработке налоговой системы ИНН решили хранить в целочисленном виде. В процессе работы системы пришла ошибка, что ИНН не сохраняется или почему-то выглядит не так, как ввел пользователь.
💊: Проверяйте ограничения по типам данных в СУБД (PostgreSQL, MySQL. и другие) и сопоставляйте с реальными значениями, которые могут ввести пользователи. Ищите границы и выбирайте соответствующие типы данных. Особенно часто проблемы встречаются с номерами телефонов, документов и подобными. Часто их вообще лучше хранить в виде строки.
Это распространенные ошибки начинающих специалистов, которые погружаются в техническое проектирование систем. Сохраняйте эти примеры. Они помогут избежать ошибки в вашей работе 🙌
❤22👍4🔥2
🗓 Актуальные онлайн-встречи по проектированию БД и SQL 🗓
С этого года у нас изменения в работе с темами по проектированию БД и SQL.
Было много запросов на погружение в вопросы распределенных БД, индексов в таблицах и оптимизации, миграций между СУБД и другие. И это действительно те темы, которые нужно и важно разобрать.
Что теперь есть в GetAnalyst по БД и SQL:
🟨 Полная практическая программа “Проектирование БД и основы SQL”
Если вы начинаете разбираться с темой с нуля и вам нужно всё:
+ анализ требований и влияние на БД,
+ практика создания всех трех уровней моделей,
+ перенос их в реальную СУБД,
+ обучение SQL-запросам на реальной, разработанной вами БД,
+ миграция данных и развитие БД,
+ постановка задач на разработчиков,
++ углубленные темы в течение всего доступа к программе.
🟨 Онлайн-практикумы “Проектирование БД и SQL” - углубленное изучение
Если вы уже в теме и вам нужно больше практики, то теперь есть возможность регулярно посещать онлайн встречи для освоения углубленных тем по проектированию БД.
Прийти можно на 1, 2, 3 и сколько угодно встреч 🙂
🗓 Ближайшие онлайн-встречи:
13.02.2024 Проектирование БД с нуля: создание ER-диаграммы
14.03.2024 Разработка требований к миграциям БД
25.04.2024 Проектирование распределенных БД
06.06.2024 Оптимизация БД. Работа с индексами в БД
16.07.2024 Инструмент D-Beaver. Практика SQL-запросов
Полное и подробное расписание доступны здесь.
🎁 До 10 февраля 23:55 Мск активна скидка 20% на углубленные онлайн-практикумы (код: DB2024), а также добавили дополнительный практикум по БД и SQL в подарок!
Если уже выбрали интересные темы - планируйте заранее своё расписание 😉 В канале тоже будем напоминать о предстоящих практикумах.
С этого года у нас изменения в работе с темами по проектированию БД и SQL.
Было много запросов на погружение в вопросы распределенных БД, индексов в таблицах и оптимизации, миграций между СУБД и другие. И это действительно те темы, которые нужно и важно разобрать.
Что теперь есть в GetAnalyst по БД и SQL:
🟨 Полная практическая программа “Проектирование БД и основы SQL”
Если вы начинаете разбираться с темой с нуля и вам нужно всё:
+ анализ требований и влияние на БД,
+ практика создания всех трех уровней моделей,
+ перенос их в реальную СУБД,
+ обучение SQL-запросам на реальной, разработанной вами БД,
+ миграция данных и развитие БД,
+ постановка задач на разработчиков,
++ углубленные темы в течение всего доступа к программе.
🟨 Онлайн-практикумы “Проектирование БД и SQL” - углубленное изучение
Если вы уже в теме и вам нужно больше практики, то теперь есть возможность регулярно посещать онлайн встречи для освоения углубленных тем по проектированию БД.
Прийти можно на 1, 2, 3 и сколько угодно встреч 🙂
🗓 Ближайшие онлайн-встречи:
13.02.2024 Проектирование БД с нуля: создание ER-диаграммы
14.03.2024 Разработка требований к миграциям БД
25.04.2024 Проектирование распределенных БД
06.06.2024 Оптимизация БД. Работа с индексами в БД
16.07.2024 Инструмент D-Beaver. Практика SQL-запросов
Полное и подробное расписание доступны здесь.
🎁 До 10 февраля 23:55 Мск активна скидка 20% на углубленные онлайн-практикумы (код: DB2024), а также добавили дополнительный практикум по БД и SQL в подарок!
Если уже выбрали интересные темы - планируйте заранее своё расписание 😉 В канале тоже будем напоминать о предстоящих практикумах.
👍6❤2👌1
💫 Личный опыт: как стать системным аналитиком 💫
Привет!
Мы долго к этому шли и пришли 😎 Ура! Первый эпизод подкаста GetAnalyst - Released! 🎉
Пол года подготовки, как моральной, так и техническо-организационной, и теперь мы готовы стабильно выпускать эпизоды раз в неделю 💫
В первом эпизоде делюсь своим личным опытом в IT и рассказываю, как пришла в системный анализ и нашла свою первую работу.
Обсуждается профессия системного аналитика: роль, задачи и путь к карьерному росту.
0:50 - Екатерина Ананьева и сообщество GetAnalyst
4:00 - Кто такой системный аналитик
8:10 - Процесс работы с рабочими задачами
19:10 - Как Екатерина выбрала системный анализ. О мечтах и "Я тоже могу"
23:25 - Поиск работы и портфолио аналитика: первое предложение о работе junior-системному аналитику
37:55 - Почему был создан проект GetAnalyst
40:25 - Идея подкаста GetAnalyst, пожелания и рекомендации подписчикам
Эпизод доступен в:
⏯ Apple Podcast
⏯ Spotify
⏯ Amazon Music
⏯ Telegram
⏯ YouTube
🔗 Обратная связь и предложения
*Яндекс.Музыка в процессе. Ссылку добавим.
Подписывайтесь на платформах! Делитесь с коллегами и начинающими системными аналитиками! 🙌
Привет!
Мы долго к этому шли и пришли 😎 Ура! Первый эпизод подкаста GetAnalyst - Released! 🎉
Пол года подготовки, как моральной, так и техническо-организационной, и теперь мы готовы стабильно выпускать эпизоды раз в неделю 💫
В первом эпизоде делюсь своим личным опытом в IT и рассказываю, как пришла в системный анализ и нашла свою первую работу.
Обсуждается профессия системного аналитика: роль, задачи и путь к карьерному росту.
0:50 - Екатерина Ананьева и сообщество GetAnalyst
4:00 - Кто такой системный аналитик
8:10 - Процесс работы с рабочими задачами
19:10 - Как Екатерина выбрала системный анализ. О мечтах и "Я тоже могу"
23:25 - Поиск работы и портфолио аналитика: первое предложение о работе junior-системному аналитику
37:55 - Почему был создан проект GetAnalyst
40:25 - Идея подкаста GetAnalyst, пожелания и рекомендации подписчикам
Эпизод доступен в:
⏯ Apple Podcast
⏯ Spotify
⏯ Amazon Music
⏯ Telegram
⏯ YouTube
*Яндекс.Музыка в процессе. Ссылку добавим.
Подписывайтесь на платформах! Делитесь с коллегами и начинающими системными аналитиками! 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17❤🔥6🔥4❤2🥱2🍾2
Одним из ключевых форматов, используемых для представления и передачи данных, является JSON.
JSON, что расшифровывается как "JavaScript Object Notation", является легковесным форматом данных, который легко читается как человеком, так и системами. Он основан на синтаксисе языка программирования JavaScript, но существует независимо от него.
JSON - наиболее распространенный формат сообщений для REST API.
Когда мы говорим о "зависимости" JSON от базы данных, важно понимать, что сам по себе JSON является независимым форматом. Однако способ, каким БД обрабатывает, хранит и индексирует JSON-данные, может существенно влиять на производительность и возможности вашей системы.
Давайте разберем лайфхаки, которыми я пользуюсь при создании JSON на основе потребностей клиентов и БД 🙌
На приложенной картинке вы видите:
1. Экран смартфона с информацией о профиле в G-Food: базовая информация + информация по текущим калориям за последние 5 дней.
По нажатию на "Показать подробнее" переход на отдельный экран с историей, более подробной информацией по калориям.
2. Скриншот физической модели БД. Таблица users.
То, что хотят отображать на экране, явно расходится с тем, что есть в БД, в таблице users. Как быть?
❓Для начала определимся, как мы будем получать информацию о пользователе для этого экрана: в ОДИН запрос или в ДВА?
Голосуем 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3🔥3
Как получать информацию о пользователе для экрана приложения G-Food? (скрин в предыдущем посте)
Anonymous Poll
57%
За один REST API запрос
35%
За два REST API запроса
9%
За три REST API запроса 😉
❤6👍1
Вау, крутое голосование получилось! 😉На самом деле получать данные можно хоть за 10 запросов, зависит от того, как сильно мы пытаемся всё структурировать или оптимизировать.
Обсудим:
1️⃣ В ОДИН ЗАПРОС
Плюсы:
+ Оптимизация - только один запрос на сервер при загрузке экрана.
Минусы:
- Смешаны две потенциально независимые сущности. И нам ничего не мешает вызвать отдельный запрос на получение истории питания пользователя.
2️⃣ В ДВА ЗАПРОСА
Плюсы:
+ Хорошо структурированы данные. Две независимые сущности разделены.
Минусы:
- Два запроса на сервер, вместо одного.
3️⃣ Про три запроса я пошутила. Тут будет перебор. Но если хотите, то можно 😂
Так что оба варианта работают. Но для того, чтобы в рамках G-Food показать как БД и JSON связаны, я возьму вариант с одним запросом, в котором нужно всегда возвращать 5 последних записей из истории калорий.
Метод REST API:
🔺 Запрос
Получить информацию о пользователе
GET https://g-food.com/api/public/v1/users
*Указание {userId} не нужно, запрос подписан авторизацией пользователя.
Тело запроса:
нет.
🔺 Ответ
Успешный: HTTP-200
Тело ответа (body): скриншот прикреплен.
Для описания JSON я буду делать для разработчиков МАППИНГ ДАННЫХ JSON с БД. Полная модель БД тут.
Для отображения данных о пользователе мне нужна таблица “user”.
Как правило, если объект более сложный и информация о пользователе разнесена в несколько таблиц, то я ищу главную и от неё хожу по связям и собираю дополнительные данные, связанные с пользователем. Так я поступлю для сбора данных по истории калорий.
"id": Поле id из таблицы user. Далее =user.id.
"name": user.name
"email": user.email
"age": Использовать поле user.birthday. Посчитать разницу между текущей датой и датой рождения и вернуть в ответе.
"gender": Преобразовывать user.gender: “F”=”Ж”, “M”=”M”
"currentWeight": user.start_weight. Стартовый вес (P.S. В БД этого поля нет. Так что прежде чем делать метод REST API, придется сделать доп. задачу на добавление поля в таблицу БД)
Продолжение👇
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11❤5👍3