1. SQL / Говнокод #10376

    −131

    1. 1
    2. 2
    alter table EqualityCodes add constraint chk_EqualityCodes_Code
  check (Code not in ('', ' ', '  ', '   ', '    ', '     ', '      ', '       '));

    Запостил: glprizes, 28 Мая 2012

    Комментарии (16) RSS

    • ava krypt 28.05.2012 10:26 # 0

      А если 8 пробелов?
      Ответить

      • ava glprizes 28.05.2012 10:38 # +2

        Длина поля в клиенте - 7 символов, так что 8 пробелов не пройдут! :-)
        Ответить

        • ava krypt 28.05.2012 10:40 # +1

          Как я понимаю, 'qwe' и ' qwe' считаются разными вещами?
          Ответить

          • ava glprizes 28.05.2012 10:45 # 0

            trim() делается на сервере
            Ответить

            • ava krypt 28.05.2012 10:47 # 0

              Ага, то есть чудеса вида " ' ', ' ', ' ' " до базы таки не доходят?..
              Ответить

              • ava glprizes 28.05.2012 12:03 # 0

                Да. Потому и неясно, зачем этот constraint вообще нужен.
                Ответить

    • ava vistefan 28.05.2012 13:16 # 0

      Пусть автор напишет поле для телефонного номера с валидацией. Вот уж вариантов-то подбирать... есть разгуляться где на воле.
      Ответить

    • ava DBdev 28.05.2012 16:21 # 0

      Не БД это дело, за качеством входных данных следить.
      Лучше устроить жесткую валидацию на клиентском ПО.
      А на БД можно делать проверки, которые без БД ну никак не сделать (проверка наличия натурального ключа по справочнику и т.п.)
      Ответить

      • ava bormand 28.05.2012 16:26 # +4

        Ой-ли.. может все-таки на серверном ПО. Я бы клиентскому ПО доверять не стал.
        Ответить

        • ava vistefan 28.05.2012 16:31 # +1

          Может всё-таки и там и там?
          Была недавно и клиентская валидация http://govnokod.ru/10362 и серверная http://govnokod.ru/10363
          Ответить

          • ava roman-kashitsyn 28.05.2012 16:39 # +1

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

          • ava bormand 28.05.2012 16:51 # 0

            Все от ситуации зависит :)

            Мое мнение по поводу валидаций:
            Валидация на клиенте - чисто для удобства - быстрее реакция на ошибки, меньше напрягает сервер. Ни о какой безопасности тут речи нет.
            Валидация на сервере - основа безопасности системы.
            Валидация в СУБД - целостность связей и не-null поля - т.е. не допускаем явного нарушения структуры БД при каких-либо багах в ПО.

            P.S. Простых систем с локальными базами это, конечно же, не касается.
            Ответить

        • ava DBdev 28.05.2012 16:51 # 0

          Вы не поверите, но иногда бывают толстые клиенты и серверную прослойку просто не предусмотрено архитектурой.
          Ответить

          • ava bormand 28.05.2012 16:57 # 0

            Ну почему не поверю. Такие системы тоже имеют полное право на существование.
            Ответить

      • ava eth0 28.05.2012 20:32 # +1

        Весь вопрос в уровнях доверия. Особо параноидальные системы не доверяют не только пользовательским данным, но и данным пришедшим из другого модуля, например, из БД. Лично сталкивался с ситуацией, когда БД была "голая", вся обработка ложилась на толстенького клиента. Поскольку частенько проверки работали не так, данные лезли какие Ктулху на душу положит. Хитрые задвоения, которые потом вычищали с матюгами - плёвое дело.
        Ответить

    Добавить комментарий