🤔 Что такое Docker?

Docker - это платформа для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Она позволяет разработчикам создавать, тестировать и разворачивать приложения в изолированных средах, называемых контейнерами.

🚩Основные компоненты Docker

🟠Docker Engine
Это серверное ПО, которое запускает и управляет контейнерами. Состоит из двух частей:
Docker Daemon: Служба, которая управляет всеми объектами Docker (контейнерами, образами и т.д.).
Docker CLI: Командная строка, через которую пользователи взаимодействуют с Docker Daemon.

🟠Образы (Images)
Это шаблоны для создания контейнеров. Образ включает в себя все зависимости, библиотеки, конфигурационные файлы, скрипты и код, необходимый для запуска приложения.

🟠Контейнеры (Containers)
Это изолированные среды, в которых выполняются приложения. Контейнеры создаются на основе образов и содержат всё необходимое для работы приложения.

🟠Docker Hub
Это облачный сервис для хранения и распределения Docker-образов. Разработчики могут загружать свои образы в Docker Hub и делиться ими с другими пользователями.

🟠Docker Compose
Это инструмент для определения и управления многоконтейнерными Docker-приложениями. С помощью файла docker-compose.yml можно описать конфигурацию всех контейнеров, сетей и томов, необходимых для работы приложения.

🚩Плюсы

➕Изоляция
Каждый контейнер работает в своей собственной изолированной среде, что предотвращает конфликты между приложениями.
➕Портативность
Образы Docker могут работать на любом сервере с установленным Docker, независимо от операционной системы.
➕Масштабируемость
Контейнеры можно легко масштабировать в зависимости от нагрузки.
➕Быстрое развёртывание
Контейнеры запускаются гораздо быстрее, чем виртуальные машины.
➕Упрощение CI/CD
Docker интегрируется с системами непрерывной интеграции и доставки, упрощая процессы разработки и развёртывания.

🚩Основные команды

docker build: Создание образа из Dockerfile.
docker run: Запуск нового контейнера из образа.
docker ps: Список запущенных контейнеров.
docker stop: Остановка работающего контейнера.
docker rm: Удаление остановленного контейнера.
docker pull: Загрузка образа из Docker Hub.
docker push: Загрузка образа в Docker Hub.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Чем отличается rebase от merge?

В Git команды rebase и merge используются для объединения изменений из разных веток, но делают это по-разному. Основное различие между ними заключается в том, как они сохраняют историю коммитов и как они влияют на структуру репозитория.

🚩Основные отличия

🟠Merge (Слияние)
Объединяет две ветки, создавая новый коммит слияния (merge commit), который имеет две родительских ветки. Сохраняет всю историю коммитов обеих веток без изменений. История ветвления и слияния сохраняется. Если есть конфликты, Git предложит их разрешить перед созданием коммита слияния.
git merge <branch>

git checkout main
git merge feature-branch

🟠Rebase (Перебазирование)
Переносит все коммиты текущей ветки на вершину целевой ветки. Это делает историю линейной, как если бы изменения были сделаны последовательно. Изменяет историю коммитов, создавая новые коммиты для каждого коммита из текущей ветки. История ветвления исчезает. Если есть конфликты, Git предложит их разрешить по мере переноса каждого коммита.
git rebase <branch>

git checkout feature-branch
git rebase main

🚩Плюсы и минусы

🟠Merge
➕Простота
Процесс слияния прост и понятен.
➕Сохранение истории
Вся история коммитов сохраняется, включая информацию о ветвлении и слиянии.
➖Коммиты слияния
Создаются дополнительные коммиты слияния, что может усложнить историю.

🟠Rebase
➕Чистая история
История линейная и более читабельная.
➕Упрощение навигации
Проще следить за последовательностью изменений.
➖Изменение истории
Изменение коммитов может привести к проблемам, если кто-то уже основывается на этих коммитах.
➖Конфликты
Может потребоваться больше усилий для разрешения конфликтов, особенно если коммитов много.

🚩Когда использовать

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

🟠Rebase
Когда важно иметь чистую и линейную историю изменений. Для интеграции изменений из основной ветки в текущую рабочую ветку перед отправкой изменений в основную ветку.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что в твоем понимании значит правильный код?

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

🚩Характеристики

🟠Читаемость
Переменные, функции, классы и другие сущности должны иметь понятные и описательные имена, которые отражают их назначение. Следование стандартам кодирования и стиля, включая правильное форматирование, отступы и использование комментариев. Использование комментариев для объяснения сложных или неочевидных частей кода, но не для очевидных вещей, которые можно понять из названий переменных и функций.

🟠Сопровождаемость
Код должен быть разбит на модули, функции или классы с чётко определёнными задачами. Это упрощает его понимание, тестирование и изменение. Избегание дублирования кода через применение принципа DRY (Don't Repeat Yourself). Код должен быть легко тестируемым. Написание автоматических тестов для проверки корректности работы помогает предотвратить ошибки.

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

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

🟠Документированность
Написание документации, описывающей основные компоненты системы, их взаимодействие и использование. Хорошо документированный код облегчает его понимание для других разработчиков.

🟠Применение принципов и паттернов проектирования
Применение принципов SOLID для создания устойчивого, гибкого и масштабируемого кода. Использование проверенных решений для общих задач проектирования.

🚩Примеры

Читаемость и сопровождаемость

def calculate_area(radius):
    """Calculate the area of a circle given its radius."""
    import math
    if radius < 0:
        raise ValueError("Radius cannot be negative")
    return math.pi * radius ** 2

Тестируемость

def add(a, b):
    """Add two numbers and return the result."""
    return a + b

# Unit test for the add function
def test_add():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0
    assert add(0, 0) == 0

test_add()

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие есть уровни изоляции транзакций ?

Уровни изоляции транзакций определяют степень видимости изменений, сделанных одной транзакцией, для других параллельно выполняющихся транзакций. Они помогают контролировать влияние транзакций друг на друга и управляют различными типами аномалий, такими как "грязное" чтение, неповторяющееся чтение и фантомные чтения. В стандарте SQL-92 определены четыре уровня изоляции транзакций:

🚩Read Uncommitted (Чтение неподтвержденных данных)

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

🟠Грязное чтение (Dirty Read)
Транзакция может прочитать данные, которые были изменены другой транзакцией, но не были зафиксированы.

🟠Неповторяющееся чтение (Non-repeatable Read)
Транзакция может видеть разные значения данных при повторном чтении, если другая транзакция изменила эти данные и зафиксировала изменения.

🟠Фантомные чтения (Phantom Read)
Транзакция может видеть новые строки, добавленные другой транзакцией, при повторном выполнении запроса.

🚩Read Committed (Чтение подтвержденных данных)

Транзакция может видеть только изменения, которые были зафиксированы другими транзакциями. Неподтвержденные изменения не видны.

🟠Неповторяющееся чтение (Non-repeatable Read)
Транзакция может видеть разные значения данных при повторном чтении, если другая транзакция изменила и зафиксировала эти данные.
🟠Фантомные чтения (Phantom Read)
Транзакция может видеть новые строки, добавленные другой транзакцией, при повторном выполнении запроса.

🚩Repeatable Read (Повторяемое чтение)

Транзакция гарантирует, что если она прочитала данные в начале транзакции, эти данные останутся неизменными до конца транзакции. Транзакция не видит изменения данных, сделанные другими транзакциями после начала текущей транзакции.
Фантомные чтения (Phantom Read): Транзакция может видеть новые строки, добавленные другой транзакцией, при повторном выполнении запроса.

🚩Serializable (Сериализуемость)

Транзакция выполняется так, как если бы она была единственной, работающей в системе. Другие транзакции не могут добавлять, изменять или удалять данные, пока текущая транзакция не завершится. Это самый строгий уровень изоляции. Все аномалии (грязное чтение, неповторяющееся чтение, фантомные чтения) предотвращаются.

-- Установка уровня изоляции
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Пример на Java (использование JDBC)

connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
connection.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
connection.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чем разница между MVC и MVVM?

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

🚩MVC (Model-View-Controller)

🟠Model (Модель)
Представляет данные и бизнес-логику. Модель отвечает за получение данных из базы данных, выполнение операций над ними и отправку обновлений обратно в представление через контроллер.

🟠View (Представление)
Отображает данные пользователю. Представление отвечает за визуальное представление данных, полученных от модели, и обновление интерфейса в ответ на изменения данных.

🟠Controller (Контроллер)
Обрабатывает пользовательские вводы и взаимодействует с моделью и представлением. Контроллер получает ввод от пользователя, обрабатывает его (например, валидирует данные), обновляет модель и выбирает соответствующее представление для отображения.

Пользователь взаимодействует с представлением (например, нажимает кнопку).
Контроллер обрабатывает это событие, изменяет данные в модели.
Модель уведомляет представление об изменениях.
Представление обновляет отображение данных для пользователя.

🚩MVVM (Model-View-ViewModel)

🟠Model (Модель)
Так же, как и в MVC, модель представляет данные и бизнес-логику. Модель не изменяется.

🟠View (Представление)
Отвечает за визуальное представление данных. В отличие от MVC, представление связывается с ViewModel, а не с контроллером.

🟠ViewModel (Модель представления)
Посредник между моделью и представлением. ViewModel содержит логику отображения и команду для представления. Он отвечает за преобразование данных из модели в форму, удобную для представления, и наоборот. ViewModel часто использует механизмы связывания данных (data binding) для автоматического обновления представления при изменении данных.

Представление связывается с ViewModel через механизмы привязки данных.
Пользователь взаимодействует с представлением (например, вводит текст).
ViewModel обновляет данные в модели.
Модель уведомляет ViewModel об изменениях.
ViewModel автоматически обновляет представление через привязку данных.

🚩Основные различия

🟠Связывание данных
В MVVM используется двустороннее связывание данных между представлением и ViewModel, что упрощает автоматическое обновление UI. В MVC такого механизма нет, и обновление представления осуществляется через контроллер.

🟠Посредник
В MVC контроллер действует как посредник между моделью и представлением. В MVVM эту роль выполняет ViewModel, который теснее интегрирован с представлением через привязку данных.

🟠Упрощение UI-логики
MVVM лучше подходит для сложных UI, так как позволяет выносить логику отображения в ViewModel, что делает код представления (UI) более чистым и простым. В MVC логика может оставаться в представлении или контроллере, что иногда усложняет структуру.

🟠Технологическая направленность
MVVM часто используется в приложениях, где активно применяется привязка данных, например, в WPF, Xamarin, Angular. MVC более универсален и часто используется в веб-приложениях (например, ASP.NET MVC).

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чем разница между Scrum и Kanban ?

Это два популярных метода управления проектами и процессами, используемых в Agile-разработке. Оба они помогают командам улучшать производительность и управление работой, но имеют различные подходы и принципы. Вот основные различия между Scrum и Kanban:

🚩Scrum

🟠Структура
Фиксированные спринты: Работа делится на временные интервалы, называемые спринтами, обычно длительностью 2-4 недели.
Роли: В Scrum определены конкретные роли, такие как Scrum-мастер, Product Owner и команда разработки.

🟠Процессы и церемонии
Планирование спринта: Каждому спринту предшествует планирование, где команда определяет, какие задачи будут выполнены.
Ежедневные Scrum-встречи: Короткие ежедневные встречи (Stand-ups) для обсуждения прогресса, препятствий и планов на день.
Ретроспектива спринта: В конце каждого спринта команда анализирует, что прошло хорошо, что можно улучшить, и как это сделать.

🟠Артефакты
Product Backlog: Список всех задач и требований для продукта.
Sprint Backlog: Список задач, выбранных для выполнения в текущем спринте.
Burn-down Chart: График, показывающий оставшееся количество работы в спринте.

🟠Изменения в ходе спринта
Изменения в задачах не допускаются после начала спринта. Все задачи должны быть зафиксированы до начала спринта.

🚩Kanban

🟠Структура
Непрерывный поток работы: Kanban не имеет фиксированных временных интервалов или спринтов. Работа выполняется непрерывно.
Роли: В Kanban нет строгих определений ролей. Команда может включать любые роли по мере необходимости.

🟠Процессы и церемонии
Визуализация работы: Kanban использует доску с колонками для визуализации рабочего процесса (например, "To Do", "In Progress", "Done").
Лимиты на количество задач в работе (WIP): Ограничивает количество задач, которые могут находиться в определенных колонках одновременно, чтобы предотвратить перегрузку и улучшить поток работы.

🟠Артефакты
Kanban-доска: Основной инструмент для визуализации работы и контроля за её состоянием.
Карточки задач: Представляют отдельные задачи на Kanban-доске.

🟠Изменения в ходе работы
Изменения допускаются в любой момент времени. Задачи могут добавляться, изменяться и удаляться по мере необходимости.

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чем разница между SQL lite и Express SQL?

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

🟠Архитектура
SQLite
Встраиваемая СУБД: SQLite - это библиотека, которая встраивается непосредственно в приложение. Она не требует отдельного сервера для работы.
Без сервера: Работает без необходимости запуска серверного процесса, что упрощает установку и настройку.
Файловая система: Все данные хранятся в одном файле базы данных на диске.
SQL Server Express
Серверная СУБД: SQL Server Express - это урезанная версия Microsoft SQL Server, требующая установки и запуска серверного процесса.
Клиент-серверная архитектура: Клиенты подключаются к серверу базы данных через сеть.
Разделенные файлы данных и логов: Данные и логи хранятся в отдельных файлах.

🟠Производительность и масштабируемость
SQLite
Легковесная и быстрая: Подходит для приложений с небольшими или средними объемами данных и низкими требованиями к многопользовательскому доступу.
Ограниченная многопользовательская поддержка: Поддерживает ограниченное количество одновременных пользователей, так как блокировки осуществляются на уровне файла.
SQL Server Express
Масштабируемость: Подходит для приложений с высокими требованиями к производительности и поддерживает значительное количество одновременных пользователей.
Многопользовательская поддержка: Обеспечивает управление многопользовательским доступом и параллельностью транзакций.

🟠Функциональные возможности
SQLite:
Основные возможности SQL: Поддерживает основные команды SQL, такие как SELECT, INSERT, UPDATE, DELETE.
Ограниченные возможности: Отсутствие многих расширенных функций, таких как триггеры, хранимые процедуры, сложные типы данных и транзакции с несколькими заявлениями.
SQL Server Express:
Расширенные возможности: Поддержка триггеров, хранимых процедур, полнотекстового поиска, транзакций и других продвинутых функций.
Ограничения по сравнению с полной версией: SQL Server Express имеет ограничения по объему базы данных (до 10 ГБ на одну базу данных) и по использованию ресурсов (до 1 ГБ ОЗУ и 1 процессор).

🟠Установка и развертывание
SQLite:
Простота установки: Не требует установки, просто включается как библиотека в приложение.
Легкость развертывания: Так как данные хранятся в одном файле, перемещение базы данных сводится к копированию этого файла.
SQL Server Express:
Требует установки: Необходимо установить серверную часть, что может включать несколько шагов настройки.
Администрирование: Требует определенного уровня администрирования для настройки безопасности, резервного копирования и восстановления данных.

🟠Случаи использования
SQLite:
Мобильные приложения: Часто используется в мобильных приложениях (например, Android и iOS) для локального хранения данных.
Встроенные системы: Подходит для встроенных систем и IoT устройств.
Прототипирование и тестирование: Удобен для быстрого создания прототипов и тестирования.
SQL Server Express:
Веб-приложения: Хорошо подходит для небольших веб-приложений и сервисов, особенно на платформе Windows.
Настольные приложения: Используется в настольных приложениях, требующих мощной базы данных.
Учебные цели: Часто используется в образовательных целях для обучения работе с SQL Server.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Почему возрастает интерес к функциональному программированию (FP)?

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

🚩Основные причины роста интереса к FP

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

🟠Масштабируемость и управление состоянием
Современные распределённые системы требуют минимизации работы с изменяемым состоянием. FP, с его подходом к неизменяемым данным, позволяет избегать проблем, связанных с изменяемостью, таких как гонки данных или сложные состояния.

🟠Обработка больших данных
Фреймворки, такие как Apache Spark и Apache Flink, используют концепции функционального программирования (например, операции над коллекциями, как map, filter, reduce) для работы с большими данными. Это делает FP особенно полезным для обработки потоков данных и анализа больших объёмов информации.

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

🟠Популяризация функциональных возможностей в императивных языках
Основные императивные языки программирования (Java, Python, JavaScript, C#) добавляют функциональные возможности, такие как лямбды, стримы и функции высшего порядка. Это делает функциональный стиль более доступным для широкой аудитории разработчиков.

🟠Повышение надёжности кода
Исключение побочных эффектов уменьшает количество ошибок. Код становится проще для тестирования, так как функции можно протестировать в изоляции. Система типов в функциональных языках, таких как Haskell, гарантирует большую безопасность, что снижает вероятность ошибок в рантайме.

🟠Тенденции к модульности и повторному использованию кода
FP способствует созданию более модульного кода. Композиция функций позволяет легко строить новые функциональности из существующих компонентов.

🟠Популярность в веб-разработке и мобильных приложениях
Языки, такие как Elm, ReasonML, и фреймворки, например React (с концепцией функциональных компонентов), активно используют принципы функционального программирования. Это позволяет создавать приложения с минимальным количеством багов и высокой предсказуемостью поведения.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что тебе известно про нереляционные базы данных?

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

🚩Основные типы нереляционных баз данных:

🟠Документные базы данных
Хранят данные в формате документов (например, JSON, BSON, XML). Например, MongoDB, CouchDB. Подходит для приложений, работающих с данными, которые могут иметь гибкую и изменяющуюся структуру.

🟠Колонковые базы данных
Хранят данные в виде столбцов, а не строк. Это позволяет эффективно обрабатывать большие объемы данных и выполнять аналитические запросы. Например Apache Cassandra, HBase. Аналитика, обработка больших данных, телекоммуникации.

🟠Ключ-значение базы данных
Хранят данные в виде пар "ключ-значение". Очень проста по своей природе и обеспечивает быструю работу. Например Redis, Riak, DynamoDB. Кеширование, сессии пользователей, реализация простых хранилищ данных.

🟠Графовые базы данных
Хранят данные в виде графов с узлами, ребрами и свойствами. Отлично подходят для моделирования связей и взаимосвязей между данными. Например Neo4j, OrientDB. Социальные сети, рекомендательные системы, управление сетями.

🚩Плюсы

➕Гибкость модели данных: Легко справляются с изменяющимися и разнообразными данными.
➕Масштабируемость: Хорошо масштабируются как горизонтально (добавление новых серверов), так и вертикально (увеличение мощности серверов).
➕Производительность: Обеспечивают высокую производительность для специфичных типов операций и больших объемов данных.
➕Обработка больших данных: Способны эффективно обрабатывать большие объемы данных и быстро реагировать на запросы.

🚩Минусы

➖Отсутствие стандартов: Разные системы могут использовать разные модели и API, что может усложнять переход между ними.
➖Ограниченная поддержка сложных запросов: Могут не поддерживать сложные SQL-запросы и транзакции, привычные для реляционных баз данных.
➖Консистентность данных: Некоторые NoSQL базы данных жертвуют строгой консистентностью ради доступности и масштабируемости (в соответствии с теоремой CAP).

🚩Примеры использования:

🟠Социальные сети
Графовые базы данных для моделирования взаимоотношений между пользователями.
🟠Интернет-магазины
Документные базы данных для хранения информации о продуктах с различной структурой данных.
🟠Аналитические платформы
Колонковые базы данных для выполнения сложных аналитических запросов на больших объемах данных.
🟠Кеширование
Ключ-значение базы данных для быстрого доступа к часто используемым данным.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что делает код хорошим?

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

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

🟠Поддерживаемость
Код должен легко поддаваться изменениям, чтобы можно было адаптировать его под новые требования или исправлять ошибки. Это достигается за счёт модульности, изолирования логики и избегания «жёсткого» связывания частей кода. Хорошая структура и стандартизация, такие как следование принципам SOLID или архитектурным шаблонам (например, MVC), делают код более устойчивым.

🟠 Простота
Хороший код решает задачи самым простым и прямым способом. Простой код легче читать, тестировать и отлаживать. Он избегает ненужных усложнений и излишних абстракций, но при этом остаётся гибким. Следование принципу KISS (Keep It Simple, Stupid) и принципу YAGNI (You Aren't Gonna Need It) помогает держать код простым.

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

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

🟠 Гибкость и расширяемость
Хороший код легко адаптируется к изменяющимся требованиям. Новые функции можно добавлять без значительных изменений существующей логики. Это достигается благодаря слабому сцеплению и высокой связанности, применению шаблонов проектирования и принципов SOLID.

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

🟠Соответствие стилю и стандартам
Код должен соответствовать общим стандартам стиля, принятым в проекте или языке. Это делает его единообразным и легко читаемым для других участников команды. Использование линтеров, форматтеров и следование общеотраслевым стандартам (например, PEP8 для Python) помогает поддерживать единый стиль.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое git-flow?

Git-flow — это модель ветвления в Git, предложенная Винсентом Дриссеном, которая структурирует разработку, упрощает выпуск версий и поддерживает стабильность проекта.

🚩Основные компоненты git-flow

🟠Основные
master: Эта ветка содержит стабильные и готовые к выпуску версии продукта. Каждый коммит в master должен представлять собой релизную версию.
develop: Эта ветка используется для интеграции всех новых разработок. Она содержит последний готовый к выпуску код, но ещё может быть нестабильной.

🟠Поддерживающие
feature: Эти ветки создаются для разработки новых функций. Они ответвляются от develop и сливаются обратно в develop после завершения работы. Например, feature/новая-функция.
release: Эти ветки создаются для подготовки нового релиза. Они ответвляются от develop, и после завершения всех необходимых исправлений и тестирования сливаются в master и develop. Например release/1.0.0
hotfix: Эти ветки используются для срочных исправлений в стабильной версии продукта. Они ответвляются от master и после завершения работы сливаются в master и develop. Например, hotfix/исправление-ошибки.

🚩Как это используется:

🟠Создание новой функции:
Создайте ветку feature от develop.
Разработайте новую функцию.
Слейте feature ветку обратно в develop.

🟠Подготовка к новому релизу:
Создайте ветку release от develop.
Проведите финальное тестирование и внесите мелкие исправления.
Слейте release ветку в master и develop.
Создайте тег для новой версии на master.

🟠Срочные исправления:
Создайте ветку hotfix от master.
Исправьте проблему.
Слейте hotfix ветку в master и develop.
Создайте тег для новой версии на master.

🚩Плюсы

🟠Организация: Четкое разграничение между стабильной версией и текущей разработкой упрощает управление проектом.
🟠Параллельная разработка: Легкость создания и слияния веток способствует одновременной работе над несколькими функциями.
🟠Поддержка релизов: Обособленные ветки для подготовки релизов и срочных исправлений упрощают управление версионностью.

🚩Минусы:

🟠Сложность: Может быть избыточным для небольших проектов с небольшими командами.
🟠Требования к дисциплине: Требует строгого соблюдения правил для обеспечения стабильности и непрерывности разработки.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Каким образом можно найти "медленный запрос" и проанализировать его в PostgreSQL?

🚩Методы и инструменты.

🟠Включение журналирования медленных запросов
Настройка параметров конфигурации PostgreSQL для журналирования медленных запросов позволяет отслеживать запросы, выполнение которых занимает много времени.
1⃣Откройте файл конфигурации PostgreSQL (postgresql.conf).
2⃣Настройте следующие параметры:

# Включить логирование всех запросов
log_statement = 'all'

# Либо логирование только медленных запросов
log_min_duration_statement = 1000  # Логировать запросы, выполнение которых заняло более 1000 мс (1 секунда)

3⃣Перезапустите сервер PostgreSQL для применения изменений:

sudo systemctl restart postgresql

🟠Использование инструмента `pg_stat_statements`
Расширение pg_stat_statements позволяет собирать статистику по выполненным запросам и предоставляет информацию о частоте, времени выполнения и других характеристиках запросов.
1⃣Включите расширение в postgresql.conf:

shared_preload_libraries = 'pg_stat_statements'

2⃣Перезапустите сервер PostgreSQL:

sudo systemctl restart postgresql

3⃣Создайте расширение в нужной базе данных:

CREATE EXTENSION pg_stat_statements;

4⃣Используйте запрос для получения информации о медленных запросах:

SELECT
  query,
  calls,
  total_time,
  mean_time,
  stddev_time,
  rows,
  min_time,
  max_time
FROM
  pg_stat_statements
ORDER BY
  total_time DESC
LIMIT 10;

🟠Анализ запросов с помощью `EXPLAIN` и `EXPLAIN ANALYZE`
Команды EXPLAIN и EXPLAIN ANALYZE позволяют понять, как PostgreSQL планирует и выполняет запросы, предоставляя детальную информацию о плане выполнения.
1⃣Выполните команду EXPLAIN для запроса:

EXPLAIN SELECT * FROM my_table WHERE id = 1;

2⃣Выполните команду EXPLAIN ANALYZE для запроса:

EXPLAIN ANALYZE SELECT * FROM my_table WHERE id = 1;

3⃣Анализируйте выходные данные, чтобы понять, какие операции занимают больше всего времени (например, полное сканирование таблицы, узкие места при соединении таблиц и т.д.).

🟠Использование системных представлений и утилит
pg_stat_activity: Показывает текущую активность базы данных, включая выполняемые запросы и их состояние.

SELECT
  pid,
  usename,
  state,
  query,
  now() - query_start AS duration
FROM
  pg_stat_activity
WHERE
  state != 'idle'
ORDER BY
  duration DESC;

pg_locks: Отображает информацию о текущих блокировках в базе данных.

SELECT * FROM pg_locks;

1⃣Индексы:
Убедитесь, что для часто используемых условий WHERE и JOIN существуют соответствующие индексы.
2⃣Переписывание запросов:
Попробуйте переписать запросы для улучшения их производительности.
3⃣Материализованные представления:
Используйте материализованные представления для часто выполняемых сложных запросов.
4⃣Конфигурация сервера:
Настройте параметры конфигурации PostgreSQL для оптимизации производительности (например, work_mem, shared_buffers, maintenance_work_mem).

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое идемпотентность?

Идемпотентность — это свойство операции, при котором повторное выполнение этой операции приводит к тому же результату, что и однократное выполнение. Это понятие часто используется в контексте HTTP методов, API запросов и транзакций в системах с распределенной архитектурой.

🚩Основные аспекты идемпотентности

🟠Идемпотентные операции
GET: Получение ресурса. Повторный запрос не изменяет состояние ресурса.
PUT: Обновление или создание ресурса. Повторный запрос с одинаковыми данными приводит к одному и тому же состоянию ресурса.
DELETE: Удаление ресурса. Повторный запрос удаляет ресурс, если он существует, или не изменяет состояние, если ресурс уже удален.

🟠Неидемпотентные операции
POST: Создание нового ресурса. Повторный запрос приводит к созданию нового ресурса с новым идентификатором, что изменяет состояние системы.

🚩Примеры идемпотентности

GET запрос

  GET /user/123

PUT запрос

  PUT /user/123
  {
      "name": "John Doe",
      "age": 30
  }

Идемпотентная операция

  UPDATE users SET name = 'John Doe' WHERE id = 123;

Неидемпотентная операция

  INSERT INTO users (name, age) VALUES ('John Doe', 30);

🚩Зачем нужна идемпотентность

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

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

🟠Удобство разработки
Идемпотентность упрощает разработку и тестирование, так как позволяет предсказуемо управлять состоянием системы при повторных запросах.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Обеспечение отказоустойчивости веб-приложения

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

🚩Методы

🟠Использование балансировщиков нагрузки
Балансировщики нагрузки распределяют входящий трафик между несколькими серверами, чтобы снизить нагрузку на отдельные серверы и избежать перегрузок. В случае сбоя одного сервера запросы автоматически перенаправляются на работающие экземпляры. Использование балансировщика повышает масштабируемость системы, поскольку позволяет легко добавлять или убирать серверы по мере необходимости.

🟠Горизонтальное масштабирование и кластеризация
Развертывание приложения на нескольких серверах (в кластере) позволяет избежать единой точки отказа (SPOF — Single Point of Failure). Горизонтальное масштабирование даёт возможность добавлять дополнительные серверы при увеличении нагрузки, что повышает отказоустойчивость и общую производительность системы. Сервисы, такие как Kubernetes и Docker Swarm, упрощают управление и оркестрацию контейнеров в кластере, автоматизируя процесс развертывания, обновлений и балансировки нагрузки.

🟠Механизмы резервного копирования и репликации данных
Важные данные должны регулярно сохраняться в резервных копиях и реплицироваться на несколько узлов или в несколько дата-центров. Репликация базы данных (например, master-slave или master-master репликация) обеспечивает доступность данных, даже если один из узлов выходит из строя. Для обеспечения целостности данных реплики могут быть синхронными (обеспечивают актуальность данных на всех узлах, но добавляют задержку) или асинхронными (с меньшей задержкой, но возможностью устаревания данных).

🟠Кеширование и использование CDN
Использование кешей (Redis, Memcached) снижает нагрузку на базу данных и позволяет быстрее обрабатывать запросы, снижая риски сбоев из-за высокой нагрузки. Content Delivery Network (CDN) распределяет контент по серверам, находящимся близко к пользователю. Это снижает нагрузку на основной сервер и обеспечивает доступность контента в случае перегрузки или отказа в одном из центров обработки данных.

🟠Автоматическое восстановление и мониторинг системы
Настройка систем мониторинга (например, Prometheus, Grafana, New Relic) позволяет оперативно выявлять сбои и реагировать на проблемы. Системы автоматического восстановления могут перезапускать упавшие серверы или контейнеры. Например, инструменты оркестрации, такие как Kubernetes, могут автоматически восстанавливать неработающие контейнеры. Настройка системы оповещений для обнаружения потенциальных проблем (например, медленного ответа сервера) позволяет вовремя реагировать на них и предотвращать крупные сбои.

🟠Использование очередей сообщений
Для работы с критически важными задачами, которые могут быть временно отложены, целесообразно использовать системы очередей сообщений (например, RabbitMQ, Kafka). Очереди позволяют обрабатывать запросы асинхронно, обеспечивая бесперебойную работу системы при перегрузках. Если один компонент выходит из строя, другой может продолжить обработку сообщений из очереди после восстановления.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое транзакция в БД ?

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

🚩Основные свойства транзакций (ACID)

🟠Atomicity (Атомарность)
Транзакция должна быть либо выполнена полностью, либо не выполнена вовсе. Если какая-то часть транзакции не удается, вся транзакция откатывается (roll back) к исходному состоянию.

🟠Consistency (Согласованность)
Транзакция переводит базу данных из одного согласованного состояния в другое. Это означает, что после завершения транзакции все правила целостности данных должны быть соблюдены.

🟠Isolation (Изоляция)
Результаты выполнения транзакции не должны быть видны другим параллельно выполняющимся транзакциям до тех пор, пока данная транзакция не завершится. Это предотвращает влияние одной транзакции на другую.

🟠Durability (Устойчивость)
После успешного завершения транзакции (коммита) ее результаты должны быть зафиксированы в базе данных и сохранены, даже если произойдет сбой системы.

🚩Пример работы с транзакциями

На SQL

BEGIN TRANSACTION;

-- Пример операций внутри транзакции
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;

-- Если все операции прошли успешно
COMMIT;

-- Если произошла ошибка
ROLLBACK;

Пример на Java (использование JDBC)

Connection connection = null;
try {
    connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/mydatabase", "user", "password");
    connection.setAutoCommit(false);  // Начало транзакции

    // Пример операций внутри транзакции
    PreparedStatement pstmt1 = connection.prepareStatement("UPDATE accounts SET balance = balance - 100 WHERE account_id = ?");
    pstmt1.setInt(1, 1);
    pstmt1.executeUpdate();

    PreparedStatement pstmt2 = connection.prepareStatement("UPDATE accounts SET balance = balance + 100 WHERE account_id = ?");
    pstmt2.setInt(1, 2);
    pstmt2.executeUpdate();

    connection.commit();  // Коммит транзакции
} catch (SQLException e) {
    if (connection != null) {
        try {
            connection.rollback();  // Откат транзакции при ошибке
        } catch (SQLException ex) {
            ex.printStackTrace();
        }
    }
    e.printStackTrace();
} finally {
    if (connection != null) {
        try {
            connection.close();
        } catch (SQLException ex) {
            ex.printStackTrace();
        }
    }
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Примеры систем CP, AP и CA?

В контексте CAP-теоремы(Consistency, Availability, Partition Tolerance) системы обычно делят на три группы: CP (Consistency + Partition Tolerance), AP (Availability + Partition Tolerance) и CA (Consistency + Availability).

🚩CP-системы (Consistency + Partition Tolerance)

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

🟠HBase и MongoDB в режиме CP
Оба эти хранилища данных поддерживают согласованность при сетевых сбоях, но могут ограничивать доступность данных, блокируя операции до восстановления связи.

🟠Zookeeper
Система координации распределённых приложений, обеспечивающая согласованность, но жертвующая доступностью в случае сетевых проблем. Она часто используется для управления конфигурацией и синхронизацией данных.

🚩AP-системы (Availability + Partition Tolerance)

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

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

🟠DynamoDB (режим AP)
Поддерживает доступность и устойчивость к разделению сети, за счёт возможного отклонения в согласованности. DynamoDB был разработан Amazon для обеспечения высокой доступности даже в условиях сбоя сети.

🟠Riak
Распределённое хранилище, оптимизированное для доступности и устойчивости к разделениям сети. Оно допускает временные рассогласования данных, которые разрешаются позже.

🚩CA-системы (Consistency + Availability)

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

🟠Реляционные базы данных на одном сервере
Например, PostgreSQL или MySQL в традиционной конфигурации, работающей на одном сервере без распределения данных. Они поддерживают согласованность и доступность, так как нет сетевого разделения.
🟠Системы кэширования в локальной сети
Такие системы, как Redis, при отсутствии распределённой конфигурации и работе в пределах одного узла, могут обеспечить согласованность и доступность.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как выбрать данные из двух таблиц без метода join()?

Для выбора данных из двух таблиц без использования метода JOIN можно использовать подзапросы. Подзапросы позволяют выполнять вложенные запросы, где результат одного запроса используется в другом запросе.

🟠Использование подзапросов в `SELECT`
Вы можете использовать подзапрос в операторе SELECT, чтобы извлечь данные из одной таблицы, используя значения из другой таблицы.

SELECT 
  o.order_id, 
  o.order_date, 
  (SELECT c.customer_name FROM customers c WHERE c.customer_id = o.customer_id) AS customer_name
FROM 
  orders o;

🟠Использование подзапросов в `WHERE`
Вы можете использовать подзапрос в операторе WHERE, чтобы фильтровать данные на основе условий из другой таблицы.

SELECT 
  o.order_id, 
  o.order_date 
FROM 
  orders o
WHERE 
  o.customer_id IN (SELECT c.customer_id FROM customers c WHERE c.city = 'New York');

🟠Использование подзапросов в `FROM`
Вы можете использовать подзапрос в операторе FROM, чтобы создать временную таблицу и затем выбрать данные из нее.

SELECT 
  c.customer_name, 
  latest_orders.order_id, 
  latest_orders.order_date
FROM 
  customers c,
  (SELECT 
     o.customer_id, 
     o.order_id, 
     o.order_date 
   FROM 
     orders o 
   WHERE 
     o.order_date = (SELECT MAX(order_date) FROM orders o2 WHERE o2.customer_id = o.customer_id)
  ) AS latest_orders
WHERE 
  c.customer_id = latest_orders.customer_id;

🟠Использование подзапросов с агрегатными функциями
Подзапросы могут быть полезны при использовании агрегатных функций для получения обобщенной информации из одной таблицы, связанной с другой таблицей.

SELECT 
  c.customer_name, 
  (SELECT COUNT(*) FROM orders o WHERE o.customer_id = c.customer_id) AS total_orders
FROM 
  customers c;

🟠Использование подзапросов с операторами EXISTS
Оператор EXISTS проверяет наличие строк в подзапросе и возвращает TRUE, если подзапрос возвращает хотя бы одну строку.

SELECT 
  c.customer_name
FROM 
  customers c
WHERE 
  EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id);

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое нормализация баз данных?

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

🚩Зачем нужна нормализация

🟠Устранение избыточности данных
Нормализация позволяет минимизировать дублирование данных, что экономит пространство и упрощает управление базой данных.
🟠Обеспечение целостности данных
Нормализация помогает поддерживать целостность данных, обеспечивая правильное и единообразное хранение данных.
🟠Упрощение структуры базы данных
Разделение данных на логические таблицы делает структуру базы данных более понятной и удобной для использования.
🟠Избежание аномалий данных
Нормализация предотвращает возникновение аномалий при обновлении, вставке и удалении данных.

🚩Основные формы нормализации

🟠Первая нормальная форма (1NF)
Удаление повторяющихся групп в таблице. Каждый столбец должен содержать только атомарные (неделимые) значения. Все записи в таблице должны быть уникальными.

🟠Вторая нормальная форма (2NF)
Таблица должна быть в 1NF. Удаление частичной функциональной зависимости: каждый неключевой атрибут должен быть полностью зависим от первичного ключа.

🟠Третья нормальная форма (3NF)
Таблица должна быть в 2NF. Удаление транзитивной зависимости: все неключевые атрибуты должны быть напрямую зависимы от первичного ключа, а не от других неключевых атрибутов.

🟠Бойс-Кодд нормальная форма (BCNF)
Усиление 3NF: каждая детерминанта должна быть кандидатом на ключ, что означает, что в любой нетривиальной функциональной зависимости X -> Y, X должно быть суперключом.

🟠Четвертая нормальная форма (4NF)
Таблица должна быть в BCNF. Устранение многозначных зависимостей: таблица не должна содержать многозначных зависимостей, когда один атрибут зависит от нескольких значений другого атрибута.

🟠Пятая нормальная форма (5NF)
Таблица должна быть в 4NF. Устранение соединительных зависимостей: данные должны быть разбиты так, чтобы каждая зависимость сохранялась.

🚩Примеры применения нормализации

🟠Первая нормальная форма
Если у вас есть таблица с повторяющимися группами, такими как несколько телефонных номеров для одного клиента, вы создаете отдельную таблицу для телефонов и связываете ее с таблицей клиентов.

🟠Вторая нормальная форма
Если у вас есть таблица заказов с колонками "номер заказа", "название товара" и "цена товара", вы можете создать отдельные таблицы для заказов и товаров, чтобы цена товара зависела только от товара, а не от комбинации заказа и товара.

🟠Третья нормальная форма
Если у вас есть таблица сотрудников с колонками "идентификатор сотрудника", "название отдела" и "имя начальника отдела", вы можете создать отдельные таблицы для сотрудников и отделов, чтобы имя начальника отдела зависело только от отдела, а не от сотрудника.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Основные подводные камни удалённых вызовов?

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

🟠Скрытие распределённости
Удалённые вызовы маскируют тот факт, что операция выполняется через сеть. Это может создать ложное чувство локальности у разработчиков, которые не учитывают:
Сетевую задержку: вызовы занимают больше времени, чем локальные операции, особенно при медленных сетях. Сетевые сбои: соединение может быть потеряно, что приведёт к ошибкам выполнения или длительным тайм-аутам. Изменение задержки: время выполнения одного и того же вызова может существенно варьироваться в зависимости от сетевых условий.

🟠Обработка ошибок
Обработка ошибок в распределённых системах сложнее, чем при локальных вызовах:
Необходимо обрабатывать такие ошибки, как потеря соединения, тайм-ауты, отказ сервера. В некоторых случаях может возникнуть "проблема повторного вызова" (например, запрос был выполнен, но подтверждение потерялось), что приводит к возможной идемпотентности операций.

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

🟠Распределённая согласованность
Взаимодействие между распределёнными компонентами приводит к необходимости поддерживать согласованность данных: Проблема согласованности особенно актуальна при частичных отказах системы. Может потребоваться использование распределённых транзакций, что усложняет архитектуру.

🟠Проблемы безопасности
Удалённые вызовы подвержены угрозам: Необходимо обеспечивать шифрование данных, чтобы избежать утечек. Аутентификация и авторизация играют ключевую роль в защите системы. Возможны атаки на уровень сети или использование слабостей в протоколах передачи данных.

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

🟠Выбор протокола и технологий
Различные протоколы (например, HTTP, gRPC, Thrift) обладают своими особенностями: Протокол может накладывать ограничения на производительность и возможности. Ошибки конфигурации или несоответствие версий могут вызвать проблемы.

🚩Как это используется

🟠Для создания распределённых систем
Микросервисные архитектуры. Взаимодействие клиент-сервер (например, мобильное приложение и API). Системы с тяжёлой серверной логикой.
🟠Чтобы избежать подводных камней
Чётко проектировать архитектуру, учитывая особенности сети. Использовать идемпотентные операции. Обеспечивать надёжные стратегии обработки ошибок. Применять мониторинг и трассировку (например, OpenTelemetry) для отслеживания поведения системы.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие связи с моделями в БД знаешь?

🚩"Один к одному" (One-to-One)

Каждая запись в одной таблице связана с одной и только одной записью в другой таблице.

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

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100)
);

CREATE TABLE passports (
  id SERIAL PRIMARY KEY,
  user_id INTEGER UNIQUE,
  passport_number VARCHAR(50),
  FOREIGN KEY (user_id) REFERENCES users(id)
);

🚩"Один ко многим" (One-to-Many)

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

Пользователь (User) и Заказы (Orders)
Один пользователь может сделать много заказов, но каждый заказ связан с одним пользователем. Эта связь обычно реализуется с помощью внешнего ключа.

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100)
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INTEGER,
  order_date DATE,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

🚩"Многие ко многим" (Many-to-Many)

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

Студенты (Students) и Курсы (Courses)
Один студент может записаться на множество курсов, и каждый курс может быть записан многими студентами. Эта связь обычно реализуется с помощью промежуточной таблицы (таблицы связи), которая содержит внешние ключи обеих связанных таблиц.

CREATE TABLE students (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100)
);

CREATE TABLE courses (
  id SERIAL PRIMARY KEY,
  course_name VARCHAR(100)
);

CREATE TABLE student_courses (
  student_id INTEGER,
  course_id INTEGER,
  PRIMARY KEY (student_id, course_id),
  FOREIGN KEY (student_id) REFERENCES students(id),
  FOREIGN KEY (course_id) REFERENCES courses(id)
);

🚩Варианты связей в нереляционных базах данных (NoSQL)

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

Вложенные документы
Например, в MongoDB документы могут включать вложенные документы или массивы, что позволяет моделировать отношения "один ко многим" и "многие ко многим" внутри одного документа.

{
  "_id": 1,
  "name": "John",
  "orders": [
    { "order_id": 1, "order_date": "2023-08-01" },
    { "order_id": 2, "order_date": "2023-08-05" }
  ]
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие http методы могут быть?

HTTP (HyperText Transfer Protocol) методы представляют собой набор стандартных операций, которые используются для взаимодействия между клиентом и сервером в сети. Каждый метод определяет конкретное действие, которое должен выполнить сервер. Вот основные HTTP методы и их предназначение:

🟠GET
Метод GET используется для получения данных с сервера. Он запрашивает представление ресурса, не изменяя его состояния. GET запросы часто используются для запросов веб-страниц и получения данных из API.

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

🟠PUT
Метод PUT используется для обновления существующего ресурса или создания нового ресурса на сервере. Если ресурс уже существует, он будет обновлен, если нет — будет создан.

🟠DELETE
Метод DELETE используется для удаления ресурса с сервера. Запросы DELETE могут быть небезопасными, так как они изменяют состояние сервера, удаляя данные.

🟠PATCH
Метод PATCH используется для частичного обновления ресурса. В отличие от PUT, который заменяет весь ресурс, PATCH изменяет только указанные части ресурса.

🟠HEAD
Метод HEAD аналогичен GET, но без тела ответа. Используется для получения метаданных о ресурсе, таких как заголовки, без загрузки самого ресурса.

🟠OPTIONS
Метод OPTIONS используется для запроса информации о поддерживаемых методах на сервере или на конкретном ресурсе. Это может быть полезно для определения доступных операций перед отправкой основного запроса.

🟠CONNECT
Метод CONNECT используется для установления туннеля к серверу через прокси. Обычно используется для HTTPS через прокси.

🟠TRACE
Метод TRACE выполняет тестовый запрос по маршруту до ресурса. Он возвращает запрос, полученный сервером, что может помочь в диагностике сетевых проблем или выявлении изменений в маршруте запроса.

Ставь 👍 и забирай 📚 Базу знаний