Comments 11
полезные конечно короткие примеры(но далеко не все), но есть замечания (я видел что это перевод):
"Архитектуру баз данных можно разделить на следующие категории:"? (посмотрел оригинал "The design of databases can be separated into these categories:", суть в том что база данных соответствует одной из нормальных форм(это не перевод), кстати список нормальных форм не полный)
по поводу коде стайла для именования https://www.sqlstyle.guide/ru/ хороший пример с объяснениями.
Используйте как минимум третью нормальную форму
А потом мы просыпаемся, грустим и идём писать код, который должен работать с реальными данными на реальных серверах.
Про нормализацию и денормализацию выше уже сказали.
Прошёл по ссылке — удивился потоку елея. Что с интернетом, с нами происходит?! Надо писать (и переводить) отдельные статьи про нормальные формы? В 2020 году, серьёзно?!
Констрайнты, серьёзно? А как их потом обрабатывать в слое бизнес-логики? INSERT INTO… — облом.
Команды разработки меняются, не всегда разработчик знает об ограничениях, которые действуют на уровне бизнес логики, особенно, если речь идет о легаси проектах. Констрейнты помогают избежать нарушение консистентности данных.
Многократно приходилось сталкиваться с некорректными данными в БД из-за отсутствия ограничений на уровне базы данных — то пару лямов записей в таблице бесхозных валяются, ибо изначально внешний ключ не повесили, то значения рандомные, ломающие всю логику своей неоднородностью.
А что делать с этим обломом? У нас упала база, у нас кончились UUID-ы, или просто новый пользователь ввёл возраст меньше 13 лет?
Проверить ошибку, возвращаемую СУБД?
Все зависит от конкретной ситуации, но чаще лучше вообще не вставить данные и вернуть конечному пользователю ошибку, чем тихо записать некорректные данные.
Меня другое мучает. Например у заказа есть варианты доставки: самовывоз, доставка до клиента своими силами, доставка транспортной компанией (ограничим для простоты тремя).
- В интерфейсе мы должны сделать недоступным/невидимым поле адрес, если самовывоз. Аналогично с полем Транспортная компания — если она не используется. Тоже ограничение мы прописываем при проверке логики: на сервере приложения или в триггере БД. Не кажется это дублированием кода? Но не проверять нельзя — возможно данные будут получены из сторонних источников.
- Что делать в логике когда заполнены поля, когда они должны быть пустыми? Например заполнен адрес и/или транспортная компания при варианте самовывоз? Бросать исключения, откатывать транзакцию, проглатывать как есть или обнулять поле?
- Если ничего не делаем, то это переходит в ответственность следующего звена. Например отчёт по графику отгрузки/сборки. Где нужно ничего не выводить в полях адреса и перевозчика.
Есть четкие методики или как всегда нет правильного и неправильного решения?
Смешались в кучу кони, люди…
Проблемы интерфейса — это проблемы только и исключительно интерфейса, и касаются они исключительно юзабилити, а не корректности. Конкретнее: интерфейс может скрывать или не скрывать "лишние" поля визуально, позволять или не позволять юзеру вводить изначально некорректные данные (дублируя тем самым проверки бэка, вполне возможно некорректно) — всё это не принципиально до тех пор, пока он в состоянии показать юзеру полученную от бэка ошибку при отправке данных. Иными словами источник истины о корректности данных — всегда только бэк и возвращаемые им ошибки.
Насколько я понял, вопрос про логику бэка. Если некорректные данные (включая "лишние поля") получены от юзера — вернуть юзеру ошибку, в которой ясно описана проблема. Если некорректные данные получены из БД — тут сложнее, и вариантов корректного поведения больше одного, потому что многое зависит от доступных бэку инструментов уведомления разработчиков о проблемах (отправка писем, метрики, логирование, …), доступных инструментов для откладывания обработки (пометка проблемных записей в БД, откладывание события по обработке текущей записи, dead letter queue, …), но, главное, критичности и рискам для бизнеса в случаях игнорирования, откладывания или некорректной обработки этих данных.
Если на предыдущем этапе принято бизнес-решение обработать данные любой ценой, даже если это потенциально некорректно, то как минимум к результату обработки стоит приложить дополнительное поле с текстовым комментарием, в котором описать возникшие при обработке ошибки (лишние поля с их содержимым, например). Возможно эту информацию никто никогда не увидит, но по возможности стоит её стараться всегда показывать хоть как-нибудь.
P.S. Разумеется, в идеале не стоит в принципе создавать возможность получения некорректных данных из БД — на то нам SQL даёт множество разных инструментов для поддержания внутренней целостности данных. Но если БД уже спроектирована криво, и нет возможности её мигрировать в более строгий формат одновременно исправляя некорректные данные, тогда и возникают описанные в 2. сложности. Хотя я бы рекомендовал всё-таки очень постараться мигрировать БД, это однократная операция и она обычно обойдётся намного-намного дешевле.
Никогда не храните в одном поле имя и фамилию
Аналогично ситуации с адресами: количество вариаций имени и фамилии слишком велико, чтобы их четко различать.
А зачем их различать? Чтобы по имени обратиться? Практика показывает, что деление на first_name и last_name проблем больше приносит, чем удобств от обращения по имени. Например, когда вы приходите на азиатский рынок, а абстрактный пользователь сам не знает как поделить свое имя Trần Thị Mai Loan на ваши два (или что еще хуже — три) поля (или просто не хочет об этом думать). И в итоге вы получаете одно из двух:
1. Либо в first_name все равно оказывается не first name и вы не достигли цели.
2. Либо в first_name и last_name вы имеете абсолютно две одинаковых строки Trần Thị Mai Loan.
Так что, имхо, нужно писать:
Никогда не храните в разных полях части полного имени
А уж если захотелось, можно добавить дополнительное поле, где пользователь сам укажет как к нему обращаться и вы даже сможете увидеть, что кто-то захотел иметь в ваших email обращение «Доблестный Дон Кихот» — вам все равно, а пользователю приятно.
Скромное руководство по схемам баз данных