Содержание
- + Методалогии разработки ПО
-
+
Проектирование систем
- + API
- + UML
- + Интеграции
- + Моделирование данных
- + Представление данных
- BPMN
- C4 model
- Domain Driven Design
- EPC
- IDEF0
- Архитектор
- Архитектура
- Интерфейс
- Карта экосистемы
- Когда стоит выбирать микросервисы
- Контекстная диаграмма
- Ролевая модель
- Проектирование систем
- + Развёртывание
-
+
Разработка
- + Git
- + Linux OS
- + Mac OS
- + Подходы организации кода
- + Языки программирования
- Виды программирования
- Интерпритатор
- Компилятор
- Разработка
-
+
Сеть
- + OSI
- + Защита
- CDN
- ngrok
- Сеть
- + Системный анализ
- + Требования
- – Хранение данных
- + Языки разметки
3 нормальная форма Бойса Кодда
Нормализация - избавлкение от избыточности хранения данных
индексы это тоже избыточность, но за их синхронизацию отвечает сама СУБД
Цели
-
избавиться от аномалий операций с данными
-
повысить качество БД
-
Процесс декомпозиции отношения на несколько поекций, так что объединение проекций точно даёт нам исходное отношение
-
Нужна каждая проекция для получения изначального отн.
-
Хотябы 1 из проекций находится в более высокой форме, чем исходное отношение
Требования
-
Сохранять ограничения предметной области
-
Стандарт: Адекватна ПО, удобна в тех обсл, выс производ, защита данных
-
Минимальность PK: ключи точно нужны? В логе не нужно часто. Ключ достаточно мал и велик по типу? Можем мы сократить ключ при том же объёме?
-
Не избыточность данных. Одни данный хранятся в 1 месте. Чтобы не было конфликтов
-
Производительность. Какие операции будут в таблице? Индексы для чтения и тп.
-
Консистентность данных. Создавать связи явным образом. Юзаем триггеры, проверки для ограничений. Если есть кэш, то как его обновлять? Все ограничения должны быть на стороне БД
-
Гибкость. Соглашение по наименованию. Комментарии (сохраняются навсегда). Документация по БД (схемы лучше вручную)
-
Логически оправданный подход. Нужны ли ограничения по кол-ву символов? Зачем?
-
Актуальность. Есть агрегированные поля. Когда кэш обновить?
Нормальных форм куча
есть канонические(жирным)
### Когда остановить нормализацию?
Часто 3НФ является достаточной
Денормализация
-
Для увеличения скорости доступа к данным (join)
-
Запросы будут проще, чем там где куча join
-
Излишне не усложняем схему
Подходы
-
Объединение 2х в 1 отношение
-
Кэширующие отношение (триггер пересчитывает поле из др таблицы и сохраняет в нужную) эт часто
-
Агрегирующие отношение/атрибуты (предобработать информацию)
-
Создание материализованного представления - наименование SQL запроса, сохранение этого запроса