Да, делаются они так же как и в коде. Через проверки, эксепшены. Через pl замешивается (к примеру так). В итоге да, то на то и выходит, но 1) работает на уровне СУБД, значит что бы в коде на намудили данные в базе консистентные; 2) переносимо между проектами при этом совершенно не важно, на каком языке проект написан, забыли там валидаторы или нет.
Кстати, валидация email по регулярке плохая практика. Лучший валидатор email - письмо со ссылкой на подтверждение.
Я вижу, что по RFC. Очень хорошо, что есть люди думающие и подобных вещах. Но многие ли проекты которые могут похвалится, что учли все возможные варианты? К примеру, валидатор сайта одного банка не допускал наличия + в имени ящика. Зачем было делать валидацию такой регуляркой и делать проблему потенциальному клиента, когда валидация через письмо со ссылкой решило бы проблему? Кроме того, регулярка решит вопрос валидации с точки зрения синтаксиса, но на наличие ящика как такового. А если в имя закралась ошибка? Можно конечно устраниться и сказать, что юзер сам ССЗБ, только зачем если эта проблема решаема?
? И если я тебе укажу через запятую штук 100 e-mail'ов то ты их будешь рассылать куда я сказал мда...
А я где-то писал, что не нужны шаги по предотвращению sql инекций и прочие виды атак? Это грязный поклеп и досужие домыслы. Я лишь предложил взглянуть на тему валидации немного с другого угла. Бизнес-логика этого процесса может быть вынесена на уровень СУБД. Причем я даже не веду речь о конкретных вариантах реализации. Хочется/нужны регулярки, ну не вопрос, pl-ем вопрос вполне решаем. В общем вариант имплементации в руках разработчика. А о профите я уже сказал - при сапорте кода забыть добавить такой валидатор в новый код просто невозможно, потому что он и так уже существует на уровне СУБД и его не обойти даже при прямых запросах.alekciy
т.е. в БД сохраняешь не проверив на допустимые символы да, sql-иньекция какбы, но видимо тебя это не смущает, как и кучи всяких XSS, и прочего что будет, т.к. ты тупо сохраняешь в БД введенное мной мыло и все
