❔ Вопрос с собеседования

Чем MariaDB отличается от MySQL?

Ответ: MariaDB — это форк (ответвление) MySQL, созданный после того, как MySQL купила компания Oracle.

MariaDB полностью совместима с MySQL на уровне запросов, но развивается отдельно: она добавляет больше новых функций быстрее (например, альтернативные движки хранения), а также остаётся полностью открытой.

Ещё MariaDB часто включает улучшения в производительности и масштабировании, которые в MySQL появляются позже или не появляются вообще.

tags: #собеседование

➡ SQL Community | Чат

💻 Чем отличается пессимистическая и оптимистическая блокировка в MySQL?

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

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

⛓ Читать статью

tags: #статья

➡ SQL Community | Чат

➡ SQL Community | #memes

❔ Вопрос с собеседования

Каковы плюсы и минусы реляционных баз данных?

Плюсы:

▶️ Чёткая и строгая структура данных (таблицы, типы, связи);

▶️ Поддержка мощного языка запросов SQL для сложных выборок и обработки данных;

▶️ Надёжность за счёт транзакций (ACID-свойства), ограничений целостности (FOREIGN KEY, UNIQUE, CHECK) и строгих правил.

Минусы:

▶️ Менее гибкие при изменениях схемы: добавление новых колонок, связей или нормализация требуют осторожных изменений структуры;

▶️ Горизонтальное масштабирование (шардинг) сложнее, чем у NoSQL-баз;

▶️ При сложных связях и большом объёме таблиц возможны накладные расходы на JOIN-операции и поддержку индексов.

tags: #собеседование

➡ SQL Community | Чат

💻 JDBC: как Java научилась дружить с базами данных?

В статье объясняется, как работает JDBC — стандартный способ подключения Java-приложений к базам данных.

Разбираются типы драйверов, методы выполнения запросов и управление транзакциями, что поможет понять, как Java взаимодействует с различными СУБД.

⛓ Читать статью

tags: #статья

➡ SQL Community | Чат

➡ SQL Community | #memes

❔ Вопрос с собеседования

Почему отношение «многие-ко-многим» реализуется через промежуточную таблицу?

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

Без промежуточной таблицы связь автоматически превращается в «один-ко-многим», где одна запись может ссылаться на множество записей, но обратная связь не поддерживается.

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

tags: #собеседование

➡ SQL Community | Чат

💻 PostgreSQL Antipatterns: «вращаем» JSON

В статье рассматриваются антипаттерны использования JSON, особенно при преобразовании JSON-данных в таблицы.

Автор рассматривает распространенные ошибки, их решения и разбирает как правильно работать с JSON в SQL.

⛓ Читать статью

tags: #статья

➡ SQL Community | Чат

➡ SQL Community | #memes

❔ Вопрос с собеседования

Почему в реляционных базах данных не принято хранить несколько значений в одной ячейке?

Ответ: Технически это возможно (например, хранить список через запятую), но противоречит первой нормальной форме (1NF), которая требует, чтобы каждое поле содержало атомарное, неделимое значение.

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

Поэтому в реляционном проектировании такой подход считается антипаттерном.

tags: #собеседование

➡ SQL Community | Чат

💻 Шардировать или не шардировать?

В статье рассказывается, как с помощью шардирования разделить пользователей по нагрузке и сэкономить ресурсы.

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

⛓ Читать статью

tags: #статья

➡ SQL Community | Чат

➡ SQL Community | #memes

❔ Вопрос с собеседования

Почему денормализуют базу, если нормализация считается хорошей практикой?

Ответ: Нормализация делает данные логически чистыми и избавляет от избыточности, но часто требует объединения многих таблиц через JOIN’ы. Это может замедлять чтение, особенно при сложных запросах.

Денормализация — это осознанное нарушение нормализации ради производительности: данные дублируются или объединяются в одну таблицу, чтобы ускорить доступ к ним. Это компромисс: улучшается скорость чтения, но усложняется обновление и контроль целостности.

tags: #собеседование

➡ SQL Community | Чат

💻 Блокировки в PostgreSQL: Часть 1. Блокировки отношений

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

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

⛓ Читать статью

tags: #статья

➡ SQL Community | Чат

GitHub головного мозга

➡ SQL Community | #memes

❔ Вопрос с собеседования

Зачем в таблице нужен искусственный первичный ключ, если уже есть уникальные поля?

Ответ: Искусственный ключ (например, id) делает структуру базы более надёжной и устойчивой к изменениям.
В отличие от естественных ключей (например, email или паспорт), он не зависит от бизнес-логики, не меняется со временем и удобен для связей — так как компактен и не содержит лишней информации. Это упрощает поддержку и повышает гибкость схемы.

tags: #собеседование

➡ SQL Community | Чат

💻 Блокировки в PostgreSQL: Часть 2. Блокировки строк

В статье объясняется, как работают блокировки строк в PostgreSQL и зачем нужны разные режимы вроде FOR UPDATE и FOR SHARE.

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

⛓ Читать статью

tags: #статья

➡ SQL Community | Чат

— Как можно писать одну фичу ГОДАМИ?
— У меня почасовая оплата 🙂

➡ SQL Community | #memes

❔ Вопрос с собеседования

Почему нельзя создать индекс на представление (VIEW)?

Ответ: Потому что обычное представление — это не таблица, а просто сохранённый SQL-запрос. Оно не содержит собственных данных, а строится на лету при каждом обращении.

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

tags: #собеседование

➡ SQL Community | Чат

💻 Краеугольные камни ClickHouse

В статье подробно объясняются архитектурные принципы ClickHouse: от хранения данных и механики слияний до точечных чтений и join-ов.

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

⛓ Читать статью

tags: #статья

➡ SQL Community | Чат

Фатальная ошибка

➡ SQL Community | #memes