Итоги и практика
Ключевые выводы
- Большинству приложений нужна лишь одна из трёх форм хранения — реляционная, документная или ключ-значение, — и реляционная это безопасный выбор по умолчанию.
- Начинайте с управляемой базы данных: данные и решения о схеме остаются за вами, а работу серверов берёт на себя платформа.
- Хороший дизайн схемы — это честные типы, внешние ключи и ограничения, разумные индексы и отсутствие дублирования данных.
- Относитесь к каждой миграции как к двери в одну сторону: делайте бэкап перед всем, что удаляет (drop) или переименовывает, и внимательно проверяйте миграции, написанные AI.
- Всегда требуйте параметризованные запросы, чтобы пользовательский ввод никогда не конкатенировался в .
Попробуйте сами
Выберите крошечную идею приложения и сначала выпишите её сущности и связи обычным языком. Затем передайте это описание AI и попросите схему вместе с прямой миграцией — и проверьте результат по чек-листу этой главы, прежде чем что-либо запускать.
Design a relational schema for a personal bookmarks app.
Entities and relationships:
- A user has many bookmarks.
- A bookmark belongs to one user, has a URL, a title, and many tags.
- A tag can apply to many bookmarks.
Requirements:
- Use UUID primary keys and created_at timestamps.
- Enforce relationships with foreign keys.
- Add indexes for the columns we'll filter on.
- Give me the schema as SQL plus a forward migration file.
- Flag any migration step that drops or renames so I can back up first.