Как правильно разрабатывать приложение, начиная с проектирования схемы базы данных?

Question

Евграф

django , базы-данных

Как правильно разрабатывать приложение, начиная с проектирования схемы базы данных?

Вот мне объяснили, что перед началом разработки приложения обязательно нужно изучить предметную область, составить таблицу сущностей, разработать связи, затем оптимизировать это с помощью различных нормальных форм базы данных. После чего можно наполнять базу данных через приложение и предоставлять доступ пользователям. <br/> Но как обстоят дела на практике? Например, возьмем Django, где уже встроено ORM, и разработчики сразу начинают создавать объекты, игнорируя все эти сложности. Да, мы избавляемся от одного языка, но получаем непонятную семантику взамен. <br/> Однако меня больше всего интересует, зачем разработчики интегрировали редактор схемы, если я всё равно должен заново создавать эту схему с помощью команд? <br/> И что еще более удивительно: когда мне нужно внести изменения в продакшен, например, убрать сущности с городами и областями (которые уже имеют множество связанных виджетов) и вместо них добавить идентификатор региона (по просьбе клиента), я сталкиваюсь с проблемой. Я слышал о Pedantic, но зачем мне схема, которую я не могу отредактировать в версии №2 и создать миграцию из интерфейса на этапе проектирования? Почему выбран такой "страдальческий" путь, где все нужно кодить с нуля, и если что-то не укладывается в голове, то надо рисовать от руки или визуализировать? <br/> Если кто-то дойдет до конца и прочитает этот текст, пожалуйста, поделитесь своими мыслями. Может быть, я чего-то не понимаю? <br/> Конкретный вопрос: существует ли стек технологий, где после создания схемы данных можно работать с данными через автоматически генерируемое API, а в случае изменения схемы строится план миграции, и возможно ли как-то анализировать устаревший код, связанный с потерянными данными?

13 апреля 2025 г. 23:35

Ответы на вопрос 2

Похожие вопросы

Answer 1

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

### 1. Проектирование схемы базы данных

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

### 2. ORM и автоматизация работы с базой данных

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

### 3. Интегрированные редакторы схем 

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

### 4. Изменения в продакшен и миграции

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

### 5. Стек технологий для автоматизации

На данный момент существует несколько технологий и инструментов, которые могут помочь вам с автоматизацией работы с API и миграциями:

- **Hasura** — предоставляет GraphQL API-генерацию поверх PostgreSQL и позволяет следить за изменениями структуры базы. Это может решить часть ваших проблем.
- **Prisma** — ORM для Node.js с интеграцией в графические редакторы, который генерирует SQL миграции на основе изменений в вашей схеме.
- **PostgREST** — позволяет автоматически создавать RESTful API из базы данных PostgreSQL.

### 6. Анализ устаревшего кода

Для анализа устаревшего кода/данных вам могут пригодиться:

- **Статические анализаторы кода** — такие как SonarQube, которые помогут находить зависимые компоненты и mark его как устаревшие.
- **Инструменты для управления миграциями** — такие как Alembic для SQLAlchemy, которые позволяют отслеживать изменения в схеме и обеспечивать плавный переход.

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

Answer 2

Есть 2 вида разработок:
1. Сначала ER модель и сама БД, а потом код пишется под сущности.
2. Сначала код, потом он сгенерирует вам БД.

Что лучше? Берёте что вам удобнее. Если вам нравится не видеть полную картину, постоянно писать, переделывать и перегенерировать БД (в том числе и тесты), выбираете 2 вариант.
Если же вы хотите потратить недели (месяцы?), на качественную проработку ER модели и нормализации её, а потом просто быстро натянуть код на "ядро" вашей ER модели, то выбираете этот вариант.

Ещё 1 вариант подразумевает, что вы очень сильно вкладываетесь в консистентность данных, храните запасную логику в самой БД (check, foregin key, etc но желательно без триггеров), чтобы данные ВСЕГДА и ПРИ ЛЮБОМ случае были согласованными.
Во 2 варианте же, вся бизнес логика ложиться только на приложение (ну или надейтесь, что миграция сгенерирует вам правильные constraint), а БД просто как хранение данных и если где-то у вас приложение допустит ошибку и похерет к чёртям данные БД, ну что ж, это ваша беда.