Должен каждое поле в базе данных Oracle иметь проверочное ограничение если возможный?

Тезисы Квассной верны, но стоит помнить, что не все Ограничения CHECK равны. В следующих тестах я сравнил проверку REGEXP_LIKE () с еще двумя «старомодными» проверками; первый преобразует значение в строку нулей, а затем выполняет проверку на равенство, а второй выполняет проверку диапазона с помощью BETWEEN () .

Тесты «Настенные часы» чувствительны к окружающим условиям (например, как стрельба на КПП), поэтому нам нужно запустить их несколько раз. Еще нужно помнить, что производительность может варьироваться от версии к версии. Например, я m работает на 11g, а проверка регулярного выражения выполнялась постоянно на 9-10 секундах , что говорит о том, что Oracle значительно оптимизировала его с 10g. С другой стороны, непроверенные вставки выполнялись на 1,7 - 2 секунды , поэтому регулярное выражение все еще относительно дорого. Другие проверки занимали примерно 2,5–3,0 секунды , что примерно на 50% меньше для целостности.

Стоит ли платить эту пошлину, действительно зависит от того, как вы относитесь к своим данным. Опыт показывает, что полагаться на клиента в обеспечении соблюдения правил данных неизбежно означает, что в какой-то момент правила будут нарушены . Либо потому, что разработчик не применяет их, либо удаляет их из приложения. Или потому, что кто-то прикрепляет к базе данных новое клиентское приложение (например, пакетную загрузку, веб-сервис), которое не включает эти правила.

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

SQL> CREATE TABLE t_check (value VARCHAR2(50))
  2  /

Table created.

Elapsed: 00:00:00.01
SQL>
SQL> INSERT
  2  INTO    t_check
  3  SELECT  level
  4  FROM    dual
  5  CONNECT BY
  6          level <= 1000000
  7  /

1000000 rows created.

Elapsed: 00:00:01.68
SQL>
SQL> prompt Regex check
Regex check
SQL>
SQL> drop table t_check
  2  /

Table dropped.

Elapsed: 00:00:00.37
SQL> CREATE TABLE t_check (value VARCHAR2(50) NOT NULL
  2        , CHECK(REGEXP_LIKE(value, '^[0-9]{1,10}$')))
  3  /

Table created.

Elapsed: 00:00:00.07
SQL>
SQL> INSERT
  2  INTO    t_check
  3  SELECT  level
  4  FROM    dual
  5  CONNECT BY
  6          level <= 1000000
  7  /

1000000 rows created.

Elapsed: 00:00:09.53
SQL>
SQL> prompt old fashioned "mask" check
old fashioned "mask" check
SQL>
SQL> drop table t_check
  2  /

Table dropped.

Elapsed: 00:00:00.59
SQL> CREATE TABLE t_check
  2      (value VARCHAR2(50) NOT NULL
  3          , CHECK(translate(lpad(value, 20, '0')
  4              , '1234567890', '0000000000') = '00000000000000000000' ))
  5  /

Table created.

Elapsed: 00:00:00.01
SQL>
SQL> INSERT
  2  INTO    t_check
  3  SELECT  level
  4  FROM    dual
  5  CONNECT BY
  6          level <= 1000000
  7  /

1000000 rows created.

Elapsed: 00:00:02.82
SQL>
SQL> prompt old fashioned "range" check
old fashioned "range" check
SQL>
SQL> drop table t_check
  2  /

Table dropped.

Elapsed: 00:00:00.39
SQL> CREATE TABLE t_check
  2      (value VARCHAR2(50) NOT NULL
  3          , CHECK( value between 1 and 1000000))
  4  /

Table created.

Elapsed: 00:00:00.01
SQL>
SQL> INSERT
  2  INTO    t_check
  3  SELECT  level
  4  FROM    dual
  5  CONNECT BY
  6          level <= 1000000
  7  /

1000000 rows created.

Elapsed: 00:00:02.23
SQL>  

Это зависит от вашего уровня паранойи.

Конечно, двойные проверки лучше одиночных, но проверка на стороне клиента имеет преимущество или распараллеливание.

Сторона клиента проверки выполняются многими, возможно, тысячами компьютеров, которые используют ваши клиенты, в то время как проверки на стороне сервера выполняются одним сервером.

Я просто провожу тест на моем Oracle 10g :

CREATE TABLE t_check (value VARCHAR2(50) NOT NULL, CHECK(REGEXP_LIKE(value, '^[0-9]{1,10}$')))

INSERT
INTO    t_check
SELECT  level
FROM    dual
CONNECT BY
        level <= 1000000

With a CHECK , это длится 27 секунд, без одного, это займет всего 2 секунд.

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

«Это зависит от вашего уровня паранойи.

Конечно, перепроверьте. лучше, чем одиночные проверки, но проверка на стороне клиента имеет преимущество или распараллеливание.

Проверки на стороне клиента выполняются многими, возможно, тысячами компьютеров, которые используют ваши клиенты, в то время как проверки на стороне сервера выполняются одним server. »

Хотя все это само по себе не является ложным, этот ответ, кажется, непропорционально подчеркивает важность этих 25 секунд, и, таким образом, кажется довольно предвзятым в сторону« полагаться на клиентов ». Это неразумно, и точка. Особенно если затраты на миллион вставок пренебрежимо малы - 25 секунд. Вы никогда не знаете наверняка, ВСЕ ли клиенты будут правильно выполнять все необходимые проверки, и даже если вы ДЕЙСТВИТЕЛЬНО знаете, что для клиентов, которые СУЩЕСТВУЮТ В НАСТОЯЩЕЕ ВРЕМЯ, даже тогда вы не знаете о каких-либо других клиентах в будущем. затраты на ремонт, которые вы понесете, когда ваши данные будут «повреждены» в результате некоторого ограничения, которое не было наложено системой базы данных. Например, подумайте, если бы «бедняга», который должен был решить следующую задачу ( Найти GUID в базе данных ), мог бы сделать это за 25 секунд.

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

Trust is good, control is better.

Often you don't need reg exps at all. See here for an example: Regular Expressions _# at end of string . Substr, translate, instr...are powerful and fast.

Это действительно зависит от вашей общей архитектуры. Если ваша база данных используется строго как хранилище данных, то в базе данных не должно быть никаких проверок.

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

Мой настоящий вопрос к вам: могут ли данные поступать в вашу базу данных из источника, отличного от приложения? Будут ли выполняться большие операции импорта или запросы из других приложений или из окна запроса. Если бы у вас появился новый клиент, который хотел импортировать записи от своего предыдущего поставщика, как бы это было обработано? Если вы можете представить себе какую-либо причину, по которой данные могут быть изменены извне приложения и правила должны применяться для всех данных, тогда вам нужны проверочные ограничения или триггеры, чтобы обеспечить это. Насколько важен формат для работы остальной части приложения? Например, если вы сохраните все телефонные номера только как числа и добавите форматирование на страницу, отображающую данные, каков будет эффект, если кто-то добавит номер телефона (111) 111-1111 к отображаемой информации. Целостность данных является важной частью баз данных. Если вы не можете полагаться на данные в правильном формате или следовать правильным правилам (например, только три правильных значения для поля), ваши dqata становятся менее ценными. В зависимости от серьезности это может быть критический сбой.

Еще одна вещь, которую следует учитывать, - есть ли у вас люди, которые не являются администраторами, которые могут напрямую обращаться к таблицам? Если да, то правила, применяемые на уровне базы данных, могут помочь снизить вероятность мошенничества. (Разработчик часто забывает защитить данные от авторизованных пользователей. Правила, о которых я здесь говорю, скорее всего, применяются с помощью триггеров, чем простых проверочных ограничений, за исключением, возможно, верхних пределов сборов, но это необходимо учитывать при разработке базы данных)

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

Еще одна вещь, которую следует учитывать, - есть ли у вас люди, которые не являются администраторами, которые могут напрямую обращаться к таблицам? Если да, то правила, применяемые на уровне базы данных, могут помочь снизить вероятность мошенничества. (Разработчик часто забывает защитить данные от авторизованных пользователей. Правила, о которых я здесь говорю, скорее всего, применяются с помощью триггеров, чем простых проверочных ограничений, за исключением, возможно, верхних пределов сборов, но это необходимо учитывать при проектировании базы данных)

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

Еще одна вещь, которую следует учитывать, - есть ли у вас люди, которые не являются администраторами, которые могут напрямую обращаться к таблицам? Если да, то правила, применяемые на уровне базы данных, могут помочь снизить вероятность мошенничества. (Разработчик часто забывает защитить данные от авторизованных пользователей. Правила, о которых я здесь говорю, скорее всего, применяются с помощью триггеров, чем простых проверочных ограничений, за исключением, возможно, верхних пределов сборов, но это необходимо учитывать при проектировании базы данных)

Еще одна вещь, о которой следует подумать, - есть ли у вас люди, не являющиеся администраторами, которые могут напрямую обращаться к таблицам? В таком случае правила, применяемые на уровне базы данных, могут помочь снизить вероятность мошенничества. (Разработчик часто забывает защитить данные от авторизованных пользователей. Правила, о которых я здесь говорю, скорее всего, применяются с помощью триггеров, чем простых проверочных ограничений, за исключением, возможно, верхних пределов сборов, но это необходимо учитывать при разработке базы данных)

Еще одна вещь, которую следует учитывать, - есть ли у вас люди, которые не являются администраторами, которые могут напрямую обращаться к таблицам? В таком случае правила, применяемые на уровне базы данных, могут помочь снизить вероятность мошенничества. (Разработчик часто забывает защитить данные от авторизованных пользователей. Правила, о которых я здесь говорю, скорее всего, применяются с помощью триггеров, чем простых проверочных ограничений, за исключением, возможно, верхних пределов сборов, но это необходимо учитывать при разработке базы данных)