Как для поля добавить ограничение на вводимые данные?

Question

[dangelot]

Для поля gender (столбец) добавить ограничение на вводимые данные, разрешив хранить в этом поле только значение 'м' или 'ж'.

Comments

[N]

На уровне enum типа поля...если прям "в лоб"...

Answer 1

[Сергей П]

Не нужно пизать в БД лишнюю логику и лишние ограничения.
У вас с БД работает какой-то софт, например бэкенд. Там и делайте валидаторы данных. В случае пола раньше можно было 1 и 0 удобно хранить и всё было абсолютно интуитивно и понятно, а русскую букву в качестве индекса держать неудобно и неправильно. Во-первых, она в UTF-8, наверняка, что уже как-то изврат для бинарного поля.
Во-вторых, при локализации проблемы могут быть в логах надо юникодовую экранировку читать, если что... в общем либо международное F\M, либо кодами и 1\0 для мнемонического запоминания очень удобно. Вот угадайте что есть что и почему.=)

Но по нынешним временам за такую бинарность могут и засудить=) Не иначе нужна целая таблица гендеров небинарных с названиями, описаниями и локализацией. Да ещё и меняться она будет со временем, а потом при импортах мапить надо одну таблицу полов на другую=).
Шутки шутками, а 0\1 и тут хорошо лягут. Просто идентификаторы такие будут синтетические.

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

Ответ: на надо валидировать значения такого рода полей на уровне БД. Делайте так, чтобы нельзя было ввести неверно на уровне ввода данных от пользователя, и дополнительно валидируйте в бэкенде.

Comments

[Станислав Макаров]

либо кодами и 1\0 для мнемонического запоминания очень удобно

блин, век живи - век учись

[Дмитрий]

Не нужно пизать в БД лишнюю логику и лишние ограничения.

А что такое лишние ограничения и лишняя логика? И что такое не лишняя логика и не лишние ограничения?

[Сергей П]

Дмитрий, лишняя - это та, без которой можно обойтись. Та, которая создаёт больше проблем, чем решает.
Если валидацию сделать при вводе от пользователя, то внутри системы уже будут априори валидные значения. Одна проверка на входе и больше не проверем введенные данные никогда. Если сделать проверку по апдейту\инсерту записи в БД, то проверка будет делаться при каждом апдейте записи.
В тригере такое проверять - лишнее.
Есть тенженция делать БД как можно тоньше и не хранить в ней логику. Только данные.
Причин много:
- логика должна лежать внутри репозитория с исходным кодом и не должна бэкапиться вместе с данными, а с тригерами это так не работает.
- производительность
- скрытая логика в неочевидном месте - это плохо.
- логика, размазанная по куче мест - это плохо. Всю необходимую валидацию в БД не сделать, а в бэкенде можно.
- лишнияя логика в БД усложняет миграции и версионирование.

[Дмитрий]

Сергей Паньков,

Есть тенженция делать БД как можно тоньше и не хранить в ней логику. Только данные.

Ну такое, я лично встречал тенденцию делать из базы бастион, что бы там никоим образом не появлялись невалидные данные. Дом поросенка должен быть крепостью и всякое такое

Если валидацию сделать при вводе от пользователя, то внутри системы уже будут априори валидные значения. Одна проверка на входе и больше не проверем введенные данные никогда. Если сделать проверку по апдейту\инсерту записи в БД, то проверка будет делаться при каждом апдейте записи.

Простите а как валидация при каком нибудь POST запросе на изменение данных отличается от валидации в INSERT/UPDATE? Более того база не дура - она не будет валидировать данные если они не изменяются.

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

А куда у нас делись миграции которые как раз лежат внутри репозитория? Собственно в те же миграции триггеры записываются на раз два три. Но в этом конкретном случае нам нахрен не нужны триггеры - enum. А а другое в 90 случаях из 100 решается словом CONSTRAINT. И чем вы бэкапы делаете? pg_dump? ну такой себе бэкап - ну юзайте --section или чего там.

- производительность

Ну проверка на бэке как то сильно уступает проверке в базе? Какие нибудь аргументы?

- скрытая логика в неочевидном месте - это плохо.

В чем скрытость и неочевидность когда база тупо шлет вас лесом когда вы пытаетесь вставить в нее невалидные данные? то есть когда какой нибудь foreign key или not null шлет лесом - это неочевидность?

- логика, размазанная по куче мест - это плохо. Всю необходимую валидацию в БД не сделать, а в бэкенде можно.

Ну смутно могу представить что бы я не смог сделать в БД предоставленными инструментами. Как бы СУБД живут уже не один 10 лет, и чего только от них не требовалось за их жизнь.

З.Ы. Когда мы говорим о больших проектах и больших командах - растет возможность человеческой ошибки. И возникновение ситуации, когда программер Вася вернувшись из отпуска, забыл где то что провалидировать и принес вам с пляжей Турции при помощи какой нибудь богом забытой интеграции с кем либо в поле sex миллиард разных типов трансгедеров в базу на пару сотен террабайт - моментально из вас сделает поборника самой строгой валидации в БД.

[Сергей П]

Дмитрий, количество логики, которое впихивают в БД может быть разным и где-то стоит провести границу. А вот где - ворос дискуссионный и однозначного ответа не имеет.
Мне приходилось иметь дело с БД ВУЗа на несколько гигов размеров и в ней на полторы тысячи таблиц было более полутора тысяч хранимых процедур с кучей логики. Да, это было давно, но какой же это был ад!

Простите а как валидация при каком нибудь POST запросе на изменение данных отличается от валидации в INSERT/UPDATE? Более того база не дура - она не будет валидировать данные если они не изменяются.

Я имел в виду, что трггеры, особенно триггеры с тяжелыми проверками, влияют на производительность. Триггер срабатывает на изменение всей заиси, а факт изменения отдельных полей нужно детектить внутри триггера. Но мы же можем захотитеть делать более сложные валидации внутри БД, и нам для этого захоется внутри триггера делать SQL-запросы, обращаться к каким-то внешним настройкам, а эти настройки могут вдруг поменяться...
Валидация слишком расплывчатое понятие. Может быть валидация простых вещей вроде гендера ещё норм и куда ни шло, внешние ключи- тоже приемлемо, а вот валидация номера телефона по регекспу или email - это уже ближе к тому, о чем я говорил.
А ещё мы можем захотеть детектить на уровне БД наличие похожих по написанию букв на разных языках. К примеру, русская фамилия с английской буквы "A" будет ломать сортировку, а выглядеть корректно. Место ли для такой валидации на уровне БД? А проверка адекватности даты рождения?
Я лишь хотел сказать, что эту черту приемлемости размещения тех или иных валидаций в БД проводят по-разному.
Если мы говорим о том. что у нас большой проект и много неопытных чижиков без налаженного ревью кода, то косяк в валидации ввода на бэке попортит новые записи, а косяк в изменении правил валидации на уровне БД может обрушить всю базу.

проверка на бэке как то сильно уступает проверке в базе? Какие нибудь аргументы?

Я писал про тяжелые нетривиальные валидации.
Да уступает. Резльтат валидации на уровне бэка обрабатывается ближе к точке, где что-то можно исправить, а валидация глубоко в БД требует нетривиального подъёма ошибки в бэк и обработки её на разных уровнях: бд, бэк, фронт. Больше ступеней.
Я не утверждаю. что нельзя сделать правильнее, но в большинстве случаев валидации на бэке удобнее, понятнее и проще.
Опять же, это сильное утверждение, а реальные проекты обычно достаточно сложны, чтобы такие сильные утверждения не обрастали нюансами.

В чем скрытость и неочевидность когда база тупо шлет вас лесом когда вы пытаетесь вставить в нее невалидные данные? то есть когда какой нибудь foreign key или not null шлет лесом - это неочевидность?

Я имел в виду, что код, касающийся одной и той же валидации будет размещен и в триггере внутри БД, и в соответствующей миграции (или в сложных случаях в цепочке миграций), и в бэкенде а уровне бизнес-логики, и в бэкенде на уровне хендлеров АПИ, и во фронтенде для пояснения пользователю что не так и для предупреждения возможных ошибок при вводе.
Я конечно сгущаю краски немного, но если некоторые валидации делать не в БД, то эта лестница будет на ступеньку меньше.
Да, речь не о констрейнах, которые уже привнесли непростую концепцию лукап полей. Эта штука у нас трогает и фронт и бэк, а ошибки нужно правильно эскалировать и в нужном месте обрабатывать. И снова вопрос где провести черту.

Мне кажется мы говорим каждый о своей крайности и на конкретных примерах вряд ли бы не согласились друг с другом.
Я считаю, что ограничивать выбор пола на уровне БД при остутствии словарной таблицы - с порно.
"БД как бастион" - это не близкая мне концепция. Я склоняюсь к простоте, всяким NoSQL, и чтоб не упарываться сильно с нормализацией данных без острой на то нужды и необходимости.
Оверинженеринг там, где в нем нет острой необходимости плох.

[Дмитрий]

Сергей Паньков,

количество логики, которое впихивают в БД может быть разным и где-то стоит провести границу. А вот где - ворос дискуссионный и однозначного ответа не имеет.

Ага. Только решается он не обсуждением "нравится/не нравится" - а обсуждением вопроса насколько критично будет появление невалидных данных в БД.

Я имел в виду, что трггеры, особенно триггеры с тяжелыми проверками, влияют на производительность. Триггер срабатывает на изменение всей заиси, а факт изменения отдельных полей нужно детектить внутри триггера. Но мы же можем захотитеть делать более сложные валидации внутри БД, и нам для этого захоется внутри триггера делать SQL-запросы, обращаться к каким-то внешним настройкам, а эти настройки могут вдруг поменяться..

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

А ещё мы можем захотеть детектить на уровне БД наличие похожих по написанию букв на разных языках. К примеру, русская фамилия с английской буквы "A" будет ломать сортировку, а выглядеть корректно. Место ли для такой валидации на уровне БД? А проверка адекватности даты рождения?

И? Указание check решит всю проблему. Пара символов - и вы гарантируете себе факт что в одном поле не появятся русские символы, а во втором херовый день рождения, и все это - без триггеров, регистраций и смс.

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

А неопытные чижики у нас и не правят БД. Это как раз легче отследить, чем то что кто то забыл провалидировать что то.

Я конечно сгущаю краски немного, но если некоторые валидации делать не в БД, то эта лестница будет на ступеньку меньше.

Ага. А возможностей получить секс с руководством напорядок выше. Такая себе цена.

"БД как бастион" - это не близкая мне концепция. Я склоняюсь к простоте, всяким NoSQL, и чтоб не упарываться сильно с нормализацией данных без острой на то нужды и необходимости.

До первой встречи с ситуацией когда у вас огромная бд заполнена каким нибудь трешом, и из-за этого встало поступление бабла в контору.

Я склоняюсь к простоте, всяким NoSQL

Да не вопрос - вот только вопрос с тэгом Postgres а это нихрена не NoSQL. И вряд ли стоит тащить сюда опыт работы с каким нибудь Mongo

[Сергей П]

Я понял. Нам в одной команде не ужиться=)
Вы считаете, что БД - это место, где нужно держать не только данне, но и логику.
Я считаю, что место логике в бэкенде, а БД должна быть по возможности тонкой.
Видимо актуальность наших подходов надо оценивать в применении к каждому конкретному проекту и к каждой конкретной команде.

И? Указание check решит всю проблему. Пара символов - и вы гарантируете себе факт что в одном поле не появятся русские символы, а во втором херовый день рождения, и все это - без триггеров, регистраций и смс.

Кстати, а если вам нужно сделать заполнение таблицы с прошлыми местами раоты пользователя, вы валидировать ынутреннее непересечение дат и соответствие их возрасту пользователя тоже будете check'ами делать? Приведите пример как это делать?
Как валидировать в БД значения, для проверки которых нужны данные контекста, данные других запсей и даже таблиц?