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

Question

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

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

Answer 1

Я думаю, это зависит от того, где находится функция и насколько она доступна.

Если это частная функция, которая просто составляет вашу собственную библиотеку SQL, то вы, вероятно, можете обрезать ее в функции.

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

Если это общедоступный API, то не стоит ничего молча усекать - вместо этого выведите значимое исключение.

Answer 2

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

Answer 3

В соответствии с Widor, но я могу также добавить:

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

В системах с высоким трафиком вы в идеале захотите ограничить объем данных, передаваемых назад и вперед между базой данных и вашим кодом, поэтому проверка данных должна выполняться вашим слоем данных ПЕРЕД передачей их в вашу базу данных. Именно здесь вы можете вызвать значимое исключение для вашей бизнес-логики.

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

Сам уровень данных может быть структурирован таким образом, что он может обрабатывать различные реализации базы данных.

В прошлом я использовал фабричный шаблон, который позволял мне переключаться между SQL, базами данных MySQL, хранилищем файлов XML и скомпилированными тестовыми данными в соответствии с требованиями во время выполнения без необходимости перекомпиляции.

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

Бизнес-логика вызовет уровень данных для обновления базы данных вашей строкой.

В вашем примере слой данных содержит вашу функцию обновления.

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

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

Также вы можете проверить / усечь строку и уведомить об этом пользователя / вызывающий код без записи данных в базу данных.

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