«Наказать» разработчиков или исправить это автоматически? Триггер против ограничения

Question

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

Вот несколько идей:

1) Создать ограничение столбца: col = UPPER(col)

2) Создать триггер строки перед вставкой / обновлением, который устанавливает: col = UPPER(col)

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

Какой подход вы бы использовали и почему?

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

Answer 1

Это зависит от того, почему столбец должен быть в верхнем регистре, но в целом я бы пошел на ограничение.

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

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

Answer 2

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

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

Добавление индекса без учета регистра может быть лучшим решением (см. Индекс без учета регистра базы данных )

Answer 3

В большинстве ситуаций я бы сказал (1), потому что, как вы указали, триггеры часто могут быть плохими / странными (хотя и не всегда). Но когда я имею дело с чувствительностью к регистру строк, я склонен рассматривать это как особый случай и всегда исправлять его на каждом этапе пути. Я не уверен, что у меня есть какие-то конкретные причины для этого, это просто "чувствует" правильно. Возможно, потому что в большинстве сред, в которых я работал, по крайней мере, с точки зрения бизнес-логики FoO всегда равно foo всегда равно FOO.

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

Answer 4

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

Answer 5

Я бы также рассмотрел другой подход - предоставление «API таблицы», который позволяет разработчикам просто передавать значения в хранимую процедуру (или что-либо еще), что затем гарантирует, что значения вставляются в верхний регистр при вставке (в соответствии с вашим примером). Я бы также подкрепил это ограничением (это может помочь в оптимизации запросов с одной стороны) и снял бы права на прямые изменения в таблице - если вы не доверяете разработчикам вводить все вставки в верхний регистр, вам не следует доверять им всегда используйте TAPI либо.

Answer 6

Или увеличьте охват автоматических тестов и избегайте дополнительной нагрузки на рабочий сервер.