Для тех, кто не смог подключиться вчера в онлайн!
Практический вебинар:
От проектирования БД до SQL-запросов
🔍 Анализ требований и выявление ключевых сущностей.
📐 Проектирование БД с нуля на концептуальном, логическом и физическом уровнях.
💻 Реализация созданной модели базы данных в SQLite.
⌨️ Выполнение на ней SQL-запросов.
🤖 Лайфхаки от Кати: применение ChatGPT для проектирования БД и SQL-запросов.
Повторы:
📅 28 СЕНТЯБРЯ, 15:00 МСК - ЧТ
📅 1 ОКТЯБРЯ, 10:00 МСК - ВСК
📅 1 ОКТЯБРЯ, 15:00 МСК - ВСК
📅 2 ОКТЯБРЯ, 10:00 МСК - ПН
📅 2 ОКТЯБРЯ, 18:00 МСК - ПН
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
Регистрируйтесь 1 раз и приходите в один из указанных дней по ссылке в ответном письме 🙂
Практический вебинар:
От проектирования БД до SQL-запросов
🔍 Анализ требований и выявление ключевых сущностей.
📐 Проектирование БД с нуля на концептуальном, логическом и физическом уровнях.
💻 Реализация созданной модели базы данных в SQLite.
⌨️ Выполнение на ней SQL-запросов.
🤖 Лайфхаки от Кати: применение ChatGPT для проектирования БД и SQL-запросов.
Повторы:
📅 28 СЕНТЯБРЯ, 15:00 МСК - ЧТ
📅 1 ОКТЯБРЯ, 10:00 МСК - ВСК
📅 1 ОКТЯБРЯ, 15:00 МСК - ВСК
📅 2 ОКТЯБРЯ, 10:00 МСК - ПН
📅 2 ОКТЯБРЯ, 18:00 МСК - ПН
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
Регистрируйтесь 1 раз и приходите в один из указанных дней по ссылке в ответном письме 🙂
❤15👍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 полностью соответствующая идентификатору клиента. Это позволяет нам понять, какой клиент сделал каждый заказ.
Один из ключевых моментов в любом проекте, связанном с базами данных, - это внешние ключи.
Внешний ключ – это столбец (отдельное поле в таблице БД), значения которого соответствуют Первичному ключу в другой таблице. Они созданы для установки связей между таблицами.
Помните, в прошлом посте я писала про 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 полностью соответствующая идентификатору клиента. Это позволяет нам понять, какой клиент сделал каждый заказ.
❤5
🔑 Внешний ключ в БД: теория и практика. Часть 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 и т.д. Согласна, что есть разные подходы к именованию, и каждый проект может иметь свои стандарты. Главное делать все единообразно для внешних ключей по всей БД. А то потом можно будет запутаться. Рекомендуется создавать гайд по дизайну БД.
На уровне СУБД (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 и т.д. Согласна, что есть разные подходы к именованию, и каждый проект может иметь свои стандарты. Главное делать все единообразно для внешних ключей по всей БД. А то потом можно будет запутаться. Рекомендуется создавать гайд по дизайну БД.
🔥8
🇬🇧 English Quiz: ER-Diagram Knowledge 📊
Готовы проверить свои знания английского языка в контексте баз данных? Я обещала! Погнали!
--- Что обозначает аббревиатура "ER" в ER-диаграмме?
Готовы проверить свои знания английского языка в контексте баз данных? Я обещала! Погнали!
--- Что обозначает аббревиатура "ER" в ER-диаграмме?
Anonymous Quiz
1%
Electric Resonance
96%
Entity-Relationship
1%
Error-Report
2%
Executable-Runnable
Как переводится слово "Entity" и слово "Relation" на русский язык в контексте ER-диаграммы? 🔄 Пишите свой выбор в комментариях!
Anonymous Quiz
19%
Entity - Существо, Relation - Связь
80%
Entity - Сущность, Relation - Отношение
0%
Entity - Часть, Relation - Разделение
2%
Entity - Единица, Relation - Взаимодействие
Кто из вас слышал это в своей голове? 👻
😓«Таких аналитиков с такими же скилами как у меня - полный рынок. Конкуренция. Я вряд ли сменю работу.»
😓«Пока я здесь без движения, другие идут вперёд. Смотрю на коллег, и кажется, что я мне никогда не догнать их. Я тупой.»
😓«А если я допущу ошибку, и всё рухнет? Это будет конец моей карьере! Лучше я помолчу, пусть они как-то сами решат, мое слово ничего не решит.»
Наши внутренние критики часто усердствуют, намекая на то, что наши достижения - пустяк, а успехи других - величие. Эти критики без устали анализируют каждый наш шаг, сравнивая нас с окружающими и, как правило, выводят, что другие лучше.
Помните ли вы моменты, когда родители, учителя или друзья ставили вам в пример кого-то другого? "Смотри на Васю, у него всё идеально!" или "Ты и это не можешь?". Это было так обидно! Ведь и ты тоже старался со всей душой.
А что если бы в такие моменты кто-то приговаривал: "Ты потрясающий! Посмотри, сколько ты уже достиг! Я тобой горжусь, это твои лучшие результаты и я вижу, ты способен на большее!!" 💖
Оценил свои небольшие достижения? — устрой праздник и своди себя в ресторан 🎉
Сложная задача на работе не поддалась сразу? — угости себя чем-нибудь вкусным, прогуляйся и вернись к решению чуть позже, на свежую голову 🍦
Всё, что ты делаешь, имеет значение. На ошибки не стоит смотреть как на провал, это шаг к целям. Это опыт. Пробуй. Всё получится. Я в тебя верю.
😓«Таких аналитиков с такими же скилами как у меня - полный рынок. Конкуренция. Я вряд ли сменю работу.»
😓«Пока я здесь без движения, другие идут вперёд. Смотрю на коллег, и кажется, что я мне никогда не догнать их. Я тупой.»
😓«А если я допущу ошибку, и всё рухнет? Это будет конец моей карьере! Лучше я помолчу, пусть они как-то сами решат, мое слово ничего не решит.»
Наши внутренние критики часто усердствуют, намекая на то, что наши достижения - пустяк, а успехи других - величие. Эти критики без устали анализируют каждый наш шаг, сравнивая нас с окружающими и, как правило, выводят, что другие лучше.
Помните ли вы моменты, когда родители, учителя или друзья ставили вам в пример кого-то другого? "Смотри на Васю, у него всё идеально!" или "Ты и это не можешь?". Это было так обидно! Ведь и ты тоже старался со всей душой.
А что если бы в такие моменты кто-то приговаривал: "Ты потрясающий! Посмотри, сколько ты уже достиг! Я тобой горжусь, это твои лучшие результаты и я вижу, ты способен на большее!!" 💖
Оценил свои небольшие достижения? — устрой праздник и своди себя в ресторан 🎉
Сложная задача на работе не поддалась сразу? — угости себя чем-нибудь вкусным, прогуляйся и вернись к решению чуть позже, на свежую голову 🍦
Всё, что ты делаешь, имеет значение. На ошибки не стоит смотреть как на провал, это шаг к целям. Это опыт. Пробуй. Всё получится. Я в тебя верю.
❤32🔥12👍5
Многие из нас слышали термины "БД" и "СУБД", но иногда они путают их, особенно в волнительные моменты собеседований. 🤔
😅«Что такое БД? Это то, что хранит все мои данные, верно?»
😅«СУБД... это как БД, только сложнее? Или это одно и то же?»
😅«Я слышал про MySQL, но это БД или СУБД? Ой, запутался!»
Разберемся! 🧐
БД, или база данных, – это место структурированного хранения информации. Это конкретные данные и структура их хранения в виде таблиц или в виде файлов определенного формата.
БД - огромный шкаф с файлами. Представьте себе шкаф в библиотеке, где каждый ящик – это таблица, а каждая папка в ящике – это запись. Например, в БД "Библиотека" может быть таблица "Книги", где каждая запись – это конкретная книга. 📚
Теперь СУБД! Это система управления базами данных. Если БД – это шкаф, то СУБД – это библиотекарь, который знает, какие папки где лежат, как их добавлять, удалять или изменять.
MySQL, PostgreSQL, Oracle – это примеры СУБД. Они помогают нам работать с нашими "шкафами" (БД).
Так что, когда ты слышишь о MySQL, это СУБД, которая управляет БД! 💡
😅«Что такое БД? Это то, что хранит все мои данные, верно?»
😅«СУБД... это как БД, только сложнее? Или это одно и то же?»
😅«Я слышал про MySQL, но это БД или СУБД? Ой, запутался!»
Разберемся! 🧐
БД, или база данных, – это место структурированного хранения информации. Это конкретные данные и структура их хранения в виде таблиц или в виде файлов определенного формата.
БД - огромный шкаф с файлами. Представьте себе шкаф в библиотеке, где каждый ящик – это таблица, а каждая папка в ящике – это запись. Например, в БД "Библиотека" может быть таблица "Книги", где каждая запись – это конкретная книга. 📚
Теперь СУБД! Это система управления базами данных. Если БД – это шкаф, то СУБД – это библиотекарь, который знает, какие папки где лежат, как их добавлять, удалять или изменять.
MySQL, PostgreSQL, Oracle – это примеры СУБД. Они помогают нам работать с нашими "шкафами" (БД).
Так что, когда ты слышишь о MySQL, это СУБД, которая управляет БД! 💡
👍35
Физическая модель реляционной БД – это финальный чертеж для вашей будущей базы данных. Остаётся только воплотить её в жизнь с помощью SQL-запросов или других полезных инструментов СУБД и готово! 💻 Можно писать логику систему, работать с функциями на получение и хранение данных.
Что показывает физическая модель базы данных:
🔵 таблицы с наименованиями, которые фактически будут БД,
🔵 поля с наименованиями, которые фактически будут БД,
🔵 типы данных и ограничения для полей,
🔵 первичные и внешние ключи,
🔵 обязательность для полей,
🔵 уникальность для полей,
🔵 связи между таблицами и за счет каких полей они реализуются.
Физическая модель дополняет и конкретизирует логическую модель.
Этот навык критически важен для системных аналитиков: понимание физической модели позволяет видеть, как данные будут храниться и использоваться в реальных системах.
Что показывает физическая модель базы данных:
🔵 таблицы с наименованиями, которые фактически будут БД,
🔵 поля с наименованиями, которые фактически будут БД,
🔵 типы данных и ограничения для полей,
🔵 первичные и внешние ключи,
🔵 обязательность для полей,
🔵 уникальность для полей,
🔵 связи между таблицами и за счет каких полей они реализуются.
Физическая модель дополняет и конкретизирует логическую модель.
Этот навык критически важен для системных аналитиков: понимание физической модели позволяет видеть, как данные будут храниться и использоваться в реальных системах.
👍6🔥6❤2
Продолжаем разбираться с физической моделью БД. Переходим к нашему примеру:
🐶 Мы рассматриваем онлайн-зоомагазин "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". Мы хотим хранить информацию о товарах для животных.
В логической модели у нас могла бы быть таблица:
▫️Товар
- 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, так как ее типы данных я использую для перехода к физической модели.
Понимание как переходить логической к физической модели – это путь к пониманию того, как именно данные будут храниться и обрабатываться в реальной БД.
Работая над физической моделью, аналитики и разработчики объединяют свои усилия. Часто в работе переход от логической к физической модели это задача разработчиков. Особенно договоренности по выбору именования полей и типов данных - их зона ответственности. Бывают крутые дебаты)) И круто, когда можешь твердо аргументировать свою точку зрения!
Знание и понимание физической модели БД помогает аналитику оптимизировать хранение данных, улучшать производительность и экономить серверные ресурсы.
❤10👍4
Всем привет! 👋
В этот прекрасный воскресный день очень хотим поделиться мемами, которые непредумышленно создают в IT-продуктах 🤯😳
Именно поэтому очень важно, чтобы в команде был аналитик, который учитывает в проектируемом решении не только систему, но и дизайн, и возможные Use cases, и вообще всё! Вот такие мы с вами крутые ребята 🥷💥
В этот прекрасный воскресный день очень хотим поделиться мемами, которые непредумышленно создают в IT-продуктах 🤯😳
Именно поэтому очень важно, чтобы в команде был аналитик, который учитывает в проектируемом решении не только систему, но и дизайн, и возможные Use cases, и вообще всё! Вот такие мы с вами крутые ребята 🥷💥
😁21🔥5👍1
Когда мы говорим о больших объемах данных, производительность запросов становится ключевым моментом. Чтобы ускорить выборку данных из таблицы, мы используем индексы 🌟
Представьте их как оглавление в книге. Вместо того чтобы перебирать каждую страницу, вы можете быстро перейти к нужной вам, зная ее номер.
Для нашего магазина "PetCo" наиболее часто задаваемые запросы могут касаться поиска товара по названию, типу животного или штрихкоду. Создадим для этого индексы:
Теперь, когда запрос будет искать товар по названию или другому индексированному полю, СУБД (например, 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) будет использовать индекс для быстрого нахождения записи.
Однако индексы не всегда "бесплатные". Их создание и поддержка требуют дополнительных ресурсов, в том числе по памяти. Поэтому важно уметь балансировать между количеством индексов и необходимостью их использования. Чрезмерное индексирование может замедлить операции создания и обновления записей в БД.
Индексы - мощный инструмент для оптимизации работы с БД. Но как и все мощные инструменты, их следует использовать с осторожностью и пониманием. Для системного аналитика важно знать, когда и как их применять, чтобы обеспечить гармоничное взаимодействие аналитики и разработчиков, а также максимальную производительность системы 🚀
👍14
Индекс, как и другие функции, зависит от СУБД, и вот почему:
1. Типы индексов:
У разных СУБД могут быть свои уникальные типы индексов. Например, PostgreSQL предлагает B-tree, Hash, GiST, SP-GiST, GIN и BRIN, в то время как другая СУБД может предлагать другой набор типов индексов или даже свои эксклюзивные типы.
2. Оптимизация:
Каждая СУБД имеет свой собственный оптимизатор запросов. Оптимизатор принимает решение о том, когда и как использовать индекс. В разных СУБД этот процесс может отличаться.
3. Создание и обслуживание:
Процесс создания, обновления и удаления индексов может немного отличаться в зависимости от СУБД. Некоторые системы могут автоматически реорганизовать индексы, чтобы поддерживать их эффективность, в то время как другие могут требовать ручного вмешательства.
4. Ресурсные требования:
Индексы могут иметь разное влияние на производительность и потребление ресурсов в разных СУБД. В одной системе индекс может быстро создаваться и требовать небольшого дискового пространства, а в другой — создание индекса может быть более ресурсозатратным.
5. Ограничения и возможности:
В зависимости от СУБД могут быть определенные ограничения на количество индексов, их размер или другие характеристики. Также некоторые СУБД могут предлагать дополнительные возможности, связанные с индексами, например, индексы на выражениях или частичные индексы.
1. Типы индексов:
У разных СУБД могут быть свои уникальные типы индексов. Например, PostgreSQL предлагает B-tree, Hash, GiST, SP-GiST, GIN и BRIN, в то время как другая СУБД может предлагать другой набор типов индексов или даже свои эксклюзивные типы.
2. Оптимизация:
Каждая СУБД имеет свой собственный оптимизатор запросов. Оптимизатор принимает решение о том, когда и как использовать индекс. В разных СУБД этот процесс может отличаться.
3. Создание и обслуживание:
Процесс создания, обновления и удаления индексов может немного отличаться в зависимости от СУБД. Некоторые системы могут автоматически реорганизовать индексы, чтобы поддерживать их эффективность, в то время как другие могут требовать ручного вмешательства.
4. Ресурсные требования:
Индексы могут иметь разное влияние на производительность и потребление ресурсов в разных СУБД. В одной системе индекс может быстро создаваться и требовать небольшого дискового пространства, а в другой — создание индекса может быть более ресурсозатратным.
5. Ограничения и возможности:
В зависимости от СУБД могут быть определенные ограничения на количество индексов, их размер или другие характеристики. Также некоторые СУБД могут предлагать дополнительные возможности, связанные с индексами, например, индексы на выражениях или частичные индексы.
👍7❤2👎1
Последний десяток лет тема инвестиций особенно популярна🏅
Сейчас можно вложиться в:
💸 акции и облигации множество крупных и не очень компаний,
💸 драгоценные металлы,
💸 недвижимость,
💸 стартапы / готовые бизнесы,
и прочее, прочее.
Это всё здорово и очень интересно, это даже работает. Кроме этого, я считаю, что самая важная и необходимая инвестиция — образование 🙌
Наверняка вы смотрели множество американских фильмов. В них часто упоминается тема колледжа и про то, как родители мечтают, чтобы их ребёнок учился в этом заведении. Как они чуть ли не с рождения открывают счёт, чтобы начать копить на учёбу. И я вижу почему. Я наглядно вижу разницу между людьми с образованием и без, абсолютно разный уровень жизни.
На личном опыте я убедилась, что самая надёжная инвестиция — это инвестиции в саморазвитие!
Вложение средства и времени в обучение и развитие навыков — залог моего будущего. Где бы я ни оказалась, в какую страну или город бы не переехала, со мной всегда буду я и мои знания.
Чем больше мы знаем и умеем, тем больше возможностей открывается перед нами.
Конечно, это не означает, что нужно забывать о финансовой стороне вопроса и других сферах жизни. Но если передо мной стоит выбор куда вложить деньги, и на одной из стороне весов обучение, то я делаю выбор в пользу обучения.
Получение качественной информации останется трендом и лучшим стартапом для инвестирования. И стартап тут - наша жизнь, которую мы улучшаем.
Сейчас можно вложиться в:
💸 акции и облигации множество крупных и не очень компаний,
💸 драгоценные металлы,
💸 недвижимость,
💸 стартапы / готовые бизнесы,
и прочее, прочее.
Это всё здорово и очень интересно, это даже работает. Кроме этого, я считаю, что самая важная и необходимая инвестиция — образование 🙌
Наверняка вы смотрели множество американских фильмов. В них часто упоминается тема колледжа и про то, как родители мечтают, чтобы их ребёнок учился в этом заведении. Как они чуть ли не с рождения открывают счёт, чтобы начать копить на учёбу. И я вижу почему. Я наглядно вижу разницу между людьми с образованием и без, абсолютно разный уровень жизни.
На личном опыте я убедилась, что самая надёжная инвестиция — это инвестиции в саморазвитие!
Вложение средства и времени в обучение и развитие навыков — залог моего будущего. Где бы я ни оказалась, в какую страну или город бы не переехала, со мной всегда буду я и мои знания.
Чем больше мы знаем и умеем, тем больше возможностей открывается перед нами.
Конечно, это не означает, что нужно забывать о финансовой стороне вопроса и других сферах жизни. Но если передо мной стоит выбор куда вложить деньги, и на одной из стороне весов обучение, то я делаю выбор в пользу обучения.
Получение качественной информации останется трендом и лучшим стартапом для инвестирования. И стартап тут - наша жизнь, которую мы улучшаем.
🔥8
Иногда системный анализ кажется сложным лабиринтом, где каждый поворот приносит новый вызов.
Но момент, когда все технические детали начинают складываться в единое целое. Тот момент, когда ты вдруг осознаешь, что понимаешь, как работает система, что стоит за каждым нажитием на кнопку, какие запросы в базу данных идут, как работают строки кода... Это вау ❤️🙏 Ты видишь не какие-то отрывки и комбинации непонятных слов. Ты видишь и понимаешь всё.
Сегодня с командой по проектированию БД и SQL, на практической программе GetAnalyst, мы начинаем этот путь с предобучения по небольшим проектам. А дальше в шаг за шагом, задача за задачей будем подробно разбирать особенности проектирования БД, после которых вы осознаете, что технические детали стали друзьями, а не таинственными загадками.
Буквально вчера на созвоне с командой обсуждали, что часть наших текущих учеников сменили работу на пол пути прохождения практических программ. У меня шок. Приятный. Особенно от отзывов, что в работе нужно ровно то, что разбираем сейчас. Это то, что вдохновляет меня!!! И это то, почему мы постоянно стараемся актуализировать всю информацию под текущие запросы компаний.
Благодарю за то, что проходите путь роста и новые проекты вместе со мной и нашей командой ❤️
Но момент, когда все технические детали начинают складываться в единое целое. Тот момент, когда ты вдруг осознаешь, что понимаешь, как работает система, что стоит за каждым нажитием на кнопку, какие запросы в базу данных идут, как работают строки кода... Это вау ❤️🙏 Ты видишь не какие-то отрывки и комбинации непонятных слов. Ты видишь и понимаешь всё.
Сегодня с командой по проектированию БД и SQL, на практической программе GetAnalyst, мы начинаем этот путь с предобучения по небольшим проектам. А дальше в шаг за шагом, задача за задачей будем подробно разбирать особенности проектирования БД, после которых вы осознаете, что технические детали стали друзьями, а не таинственными загадками.
Буквально вчера на созвоне с командой обсуждали, что часть наших текущих учеников сменили работу на пол пути прохождения практических программ. У меня шок. Приятный. Особенно от отзывов, что в работе нужно ровно то, что разбираем сейчас. Это то, что вдохновляет меня!!! И это то, почему мы постоянно стараемся актуализировать всю информацию под текущие запросы компаний.
Благодарю за то, что проходите путь роста и новые проекты вместе со мной и нашей командой ❤️
👍10❤4🔥2🥰2
Привет! Продолжаем разбираться с индексами в БД.
И самый главный вопрос:
ЗАЧЕМ СИСТЕМНОМУ АНАЛИТИКУ ЗНАТЬ ПРО ИНДЕКСЫ В БД И ПОНИМАТЬ ИХ? 🤔
Абсолютно аналогичный вопрос у меня был про SQL. И он до сих пор иногда всплывает в моей голове, но я быстро вспоминаю ответ.
На первый взгляд, может показаться, что такие вопросы более актуальны для разработчиков или администраторов БД. Однако, даже если системный аналитик не занимается написанием запросов или оптимизацией индексов и это выходит за его зону ответственности, знание этих концепций дает прорыв понимании технических особенностей разработки.
Вопросы про индексы в БД и SQL стали актуальными на собеседованиях для системных аналитиков на позиции мидл и выше.
Особенно в таких сферах как банковский сектор. Это становится проверкой компетенции и широты знаний. И это не просто ради галочки.
Понимание индексов позволяет системному аналитику участвовать в дискуссиях с разработчиками на равных, выявлять потенциальные узкие места в проектах и предлагать решения для оптимизации.
По аналогии, умение читать и писать SQL-запросы открывает возможность более глубокого понимания логики работы с базов данных и понимать влияние каждой новой функциональности в системе на общую архитектуру решения.
Также эти навыки не просто делают аналитика "умнее", они делают его более ценным специалистом в команде, способным эффективно сотрудничать на всех этапах разработки: от описания Use Cases до сотрудничества с архитекторами. На собеседованиях это демонстрирует готовность кандидата к комплексному и многогранному подходу в проектировании систем.
Я придерживаюсь подхода "лучше знать, чем возмущаться". Широкий кругозор и умение быстро осваивать новую информацию одни из ключевых компетенций аналитиков.
Сохраняем материал про индексы и добавляем в свой чеклист подготовки к собеседованиям✔️
И самый главный вопрос:
ЗАЧЕМ СИСТЕМНОМУ АНАЛИТИКУ ЗНАТЬ ПРО ИНДЕКСЫ В БД И ПОНИМАТЬ ИХ? 🤔
Абсолютно аналогичный вопрос у меня был про SQL. И он до сих пор иногда всплывает в моей голове, но я быстро вспоминаю ответ.
На первый взгляд, может показаться, что такие вопросы более актуальны для разработчиков или администраторов БД. Однако, даже если системный аналитик не занимается написанием запросов или оптимизацией индексов и это выходит за его зону ответственности, знание этих концепций дает прорыв понимании технических особенностей разработки.
Вопросы про индексы в БД и SQL стали актуальными на собеседованиях для системных аналитиков на позиции мидл и выше.
Особенно в таких сферах как банковский сектор. Это становится проверкой компетенции и широты знаний. И это не просто ради галочки.
Понимание индексов позволяет системному аналитику участвовать в дискуссиях с разработчиками на равных, выявлять потенциальные узкие места в проектах и предлагать решения для оптимизации.
По аналогии, умение читать и писать SQL-запросы открывает возможность более глубокого понимания логики работы с базов данных и понимать влияние каждой новой функциональности в системе на общую архитектуру решения.
Также эти навыки не просто делают аналитика "умнее", они делают его более ценным специалистом в команде, способным эффективно сотрудничать на всех этапах разработки: от описания Use Cases до сотрудничества с архитекторами. На собеседованиях это демонстрирует готовность кандидата к комплексному и многогранному подходу в проектировании систем.
Я придерживаюсь подхода "лучше знать, чем возмущаться". Широкий кругозор и умение быстро осваивать новую информацию одни из ключевых компетенций аналитиков.
Сохраняем материал про индексы и добавляем в свой чеклист подготовки к собеседованиям
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤5🔥1
Давайте подробно разберем, как работают индексы, на примере самого распространенного типа индекса в PostgreSQL – B-tree (сбалансированное дерево).
B-tree индекс – это, в некотором роде, иерархическая структура, напоминающая дерево. В начале у нас есть корневой узел, который в свою очередь ведет к нескольким дочерним узлам, и так далее до "листьев" этого дерева.
Есть прекрасный пример по игре "угадай число": Когда вы ищете число, например, 37, вместо того чтобы начать с первого числа и двигаться далее, как в переборе, вы бы задали вопрос: "Оно больше 25?". Если ответ "да", то вы переходите к дочернему узлу с большими числами. Далее: "Оно меньше 40?". Снова ответ "да", и вы двигаетесь ещё глубже в дерево.
Когда новые элементы добавляются или удаляются из базы данных, дерево значений "перебалансируется". Это значит, что структура дерева меняется таким образом, чтобы сохранить свою эффективность. Представьте, что у вас есть доска для игры в боулинг, и вы хотите, чтобы все кегли стояли в сбалансированном порядке. Если одна из кегель упала, вы быстро переставите остальные, чтобы сохранить равновесие.
Такой подход к поиску позволяет значительно сократить количество "шагов" или "вопросов", необходимых для нахождения нужной информации. Это как раз и является преимуществом B-tree: быстрый поиск, вставка и удаление данных.
Продолжение 👇
B-tree индекс – это, в некотором роде, иерархическая структура, напоминающая дерево. В начале у нас есть корневой узел, который в свою очередь ведет к нескольким дочерним узлам, и так далее до "листьев" этого дерева.
Есть прекрасный пример по игре "угадай число": Когда вы ищете число, например, 37, вместо того чтобы начать с первого числа и двигаться далее, как в переборе, вы бы задали вопрос: "Оно больше 25?". Если ответ "да", то вы переходите к дочернему узлу с большими числами. Далее: "Оно меньше 40?". Снова ответ "да", и вы двигаетесь ещё глубже в дерево.
Когда новые элементы добавляются или удаляются из базы данных, дерево значений "перебалансируется". Это значит, что структура дерева меняется таким образом, чтобы сохранить свою эффективность. Представьте, что у вас есть доска для игры в боулинг, и вы хотите, чтобы все кегли стояли в сбалансированном порядке. Если одна из кегель упала, вы быстро переставите остальные, чтобы сохранить равновесие.
Такой подход к поиску позволяет значительно сократить количество "шагов" или "вопросов", необходимых для нахождения нужной информации. Это как раз и является преимуществом B-tree: быстрый поиск, вставка и удаление данных.
Продолжение 👇
👍12❤2🔥2
Пример поиска по штрихкоду
Предположим, у нас есть индекс по полю barcode.
Как это работает без индекса:
Для каждого запроса поиска по штрихкоду, СУБД должна будет перебирать каждую строку в таблице (`full table scan`), что займет много времени при больших объемах данных - сотни тысяч записей записей в БД о товарах, для каждого зоомагазина.
Как это работает с индексом B-tree:
- Индекс B-tree можно представить как дерево, где каждый узел содержит значение и указатели на дочерние узлы.
- При запросе по штрихкоду, PostgreSQL начинает поиск с корневого узла дерева.
- Он сравнивает искомое значение штрихкода с значениями в узле.
- Если искомое значение меньше, PostgreSQL идет к левому дочернему узлу; если больше – к правому.
- Этот процесс повторяется, пока не будет найдена нужная запись или узел, который указывает на нее.
Пример поиска по названию товара
Как это работает с индексом B-tree:
- Когда клиент ищет определенный товар по названию, PostgreSQL будет использовать индекс по полю name.
- Алгоритм поиска аналогичен примеру с штрихкодом: СУБД начинает поиск с корневого узла дерева и двигается влево или вправо, сравнивая искомое значение с значениями в узле, пока не найдет нужную запись.
Ключевой момент в работе B-tree индекса – это способность быстро находить записи, даже на огромных объемах данных, путем систематического разделения данных на меньшие части (дерево). Вместо просмотра миллионов строк, СУБД может определить местоположение нужной строки, проверив всего лишь десяток или сотню узлов индекса. Это делает операции поиска намного быстрее 🤝🔑
Предположим, у нас есть индекс по полю barcode.
Как это работает без индекса:
Для каждого запроса поиска по штрихкоду, СУБД должна будет перебирать каждую строку в таблице (`full table scan`), что займет много времени при больших объемах данных - сотни тысяч записей записей в БД о товарах, для каждого зоомагазина.
Как это работает с индексом B-tree:
- Индекс B-tree можно представить как дерево, где каждый узел содержит значение и указатели на дочерние узлы.
- При запросе по штрихкоду, PostgreSQL начинает поиск с корневого узла дерева.
- Он сравнивает искомое значение штрихкода с значениями в узле.
- Если искомое значение меньше, PostgreSQL идет к левому дочернему узлу; если больше – к правому.
- Этот процесс повторяется, пока не будет найдена нужная запись или узел, который указывает на нее.
Пример поиска по названию товара
Как это работает с индексом B-tree:
- Когда клиент ищет определенный товар по названию, PostgreSQL будет использовать индекс по полю name.
- Алгоритм поиска аналогичен примеру с штрихкодом: СУБД начинает поиск с корневого узла дерева и двигается влево или вправо, сравнивая искомое значение с значениями в узле, пока не найдет нужную запись.
Ключевой момент в работе B-tree индекса – это способность быстро находить записи, даже на огромных объемах данных, путем систематического разделения данных на меньшие части (дерево). Вместо просмотра миллионов строк, СУБД может определить местоположение нужной строки, проверив всего лишь десяток или сотню узлов индекса. Это делает операции поиска намного быстрее 🤝🔑
👍18
Что использовать для проектирования БД - диаграмму классов UML или ER-диаграмму?
Вопрос с подвохом, хорош для собеседований.
Давайте разберем различия диаграммы классов UML или ER-диаграммы, и определим, для каких целей используется каждая из них.
Диаграмма классов UML
Это графическое представление структуры программного кода системы, создаваемой согласно принципам объектно-ориентированного программирования (далее - ООП), которое показывает классы, их атрибуты, методы и взаимосвязи между ними.
Элементы:
🔶 Классы программного кода (представлены прямоугольниками).
🔶 Атрибуты (свойства / переменные) программного кода (находятся внутри прямоугольника класса, сверху).
🔶 Методы программного кода (находятся внутри прямоугольника класса, снизу).
🔶 Взаимосвязи (стрелки между классами: ассоциация, наследование и др.).
Назначение:
Показывает как организовать структуру программного кода в системе.
Пример:
У нас есть класс "Пользователь" с атрибутами "имя", "электронная почта" и методом "заказать". Он связан с классом "Заказ", который содержит информацию о покупках.
ER-диаграмма (Entity-Relationship Diagram)
Это графическое представление структуры базы данных. Показывает сущности, их атрибуты и связи между сущностями.
Элементы:
🔶 Сущности (представлены прямоугольниками).
🔶 Атрибуты (находятся внутри прямоугольника сущности).
🔶 Связи (стрелки между сущностями).
Назначение:
Помогает разработчикам и аналитикам создавать и описывать структуру БД.
Пример:
У нас есть сущность "Пользователь" с атрибутами "имя" и "электронная почта". Эта сущность связана с сущностью "Заказ", который включает в себя номер, дату оформления, а также связан с различными товарами. Методов нет.
⬇️⬇️⬇️⬇️⬇️
Вопрос с подвохом, хорош для собеседований.
Давайте разберем различия диаграммы классов UML или ER-диаграммы, и определим, для каких целей используется каждая из них.
Диаграмма классов UML
Это графическое представление структуры программного кода системы, создаваемой согласно принципам объектно-ориентированного программирования (далее - ООП), которое показывает классы, их атрибуты, методы и взаимосвязи между ними.
Элементы:
🔶 Классы программного кода (представлены прямоугольниками).
🔶 Атрибуты (свойства / переменные) программного кода (находятся внутри прямоугольника класса, сверху).
🔶 Методы программного кода (находятся внутри прямоугольника класса, снизу).
🔶 Взаимосвязи (стрелки между классами: ассоциация, наследование и др.).
Назначение:
Показывает как организовать структуру программного кода в системе.
Пример:
У нас есть класс "Пользователь" с атрибутами "имя", "электронная почта" и методом "заказать". Он связан с классом "Заказ", который содержит информацию о покупках.
ER-диаграмма (Entity-Relationship Diagram)
Это графическое представление структуры базы данных. Показывает сущности, их атрибуты и связи между сущностями.
Элементы:
🔶 Сущности (представлены прямоугольниками).
🔶 Атрибуты (находятся внутри прямоугольника сущности).
🔶 Связи (стрелки между сущностями).
Назначение:
Помогает разработчикам и аналитикам создавать и описывать структуру БД.
Пример:
У нас есть сущность "Пользователь" с атрибутами "имя" и "электронная почта". Эта сущность связана с сущностью "Заказ", который включает в себя номер, дату оформления, а также связан с различными товарами. Методов нет.
⬇️⬇️⬇️⬇️⬇️
❤9🔥8👍3🤩3