Конструкция прототипа SQL: сталкивается с молчаливым усечением данных с использованием varchar (N) - любые лучшие альтернативы? (Teradata)

Ситуация:

varchar(20) кажется обрезать молча в Teradata и not для расширения или жалобы при столкновении строк длиной более 20 символов... Это немного сюрприз поскольку я ожидал либо автоматического расширения столбца, чтобы он соответствовал более крупным строкам, скажем 30 символов, ИЛИ для ошибки, которую нужно было бы выбросить, если бы столкнулась большая строка. Безмолвное усечение кажется мне самым худшим из всех миров...

Усложнение:

Для моего приложения (прототип аналитического дизайна) я не знаю заранее, насколько большими будут данные, которые я буду глотать в течение нескольких недель. Кажется, это исключает использование varchar (N), за исключением max

Вопросы:

Итак, теперь у меня есть несколько вариантов, и я ищу несколько советов:

Q1. Ошибка пользователя? Не понимаю ли я ключевого понятия о varchar(N)?

Если это фактически то, как Teradata обрабатывает поля varchar, то

Q2. почему бы кто-нибудь указать что-нибудь меньшее, чем varchar(max), особенно если заранее не ясно, сколько символов должно быть сохранено в поле.

Q3. Есть ли другой тип данных, который допускает гибкую калибровку строки - т.е. Строку символов истинной переменной длины?

Если я помню, другие SQL-диалекты реализуют varchar(N) как рекомендуемый начальный размер для строки, но позволяют ей расширяться по мере необходимости, чтобы соответствовать максимальной длине строк данных, которые были добавлены. Есть ли аналогичный тип данных в Teradata?

(Примечание: поскольку я создаю прототипы таблиц, я в настоящее время меньше обеспокоен эффективностью работы, больше обеспокоен быстрыми, но безопасными конструкциями, которые позволяют прототипу прогрессировать.)

Ответ 1

Я не знаком ни с одним диалектом SQL, который реализует varchar (n), который ведет себя так, как вы предлагаете, - рекомендуемый начальный размер, а затем позволяющий ему расти. Это применимо к Oracle, SQL Server, MySQL и Postgres. Во всех этих базах данных varchar (n) ведет себя довольно сильно, как вы видите, что он ведет себя в Teradata в операторах SELECT с явными нажатиями. Я не считаю, что какая-либо причина является ошибкой усечения, когда более длинная строка помещается в более короткую строку.

Как отмечает Бранко в своем комментарии, поведение отличается от шагов модификации данных, когда неявное приведение вызывает ошибку.

Я не знаком со всеми деталями Teradata. В SQL Server существует исторически мир различий между varchar (max) и varchar (8000). Первый будет выделен на отдельной странице данных, причем последний будет размещен на той же странице, что и данные. (Правила были изменены в более поздних версиях, поэтому varchars может вывести страницу данных.)

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

Мое предложение состоит в том, что вы выбираете достаточно большой размер, скажем 1000 или около того, и пусть приложение продолжается оттуда. Если вам нужна реальная гибкость, используйте varchar (max). Вы также должны исследовать через документацию Teradata и/или технические контакты, какие проблемы возникают при объявлении очень больших строк.

Ответ 2

Teradata работает в двух режимах: Teradata (BT;.. ET;) и ANSI (commit;). У них есть список различий и один из них, который вы встречали во время разработки. Режим Teradata позволяет обрезать отображаемые данные. Напротив - ANSI запрещает такое усечение, поэтому вы увидите ошибку. Чтобы получить эту идею, просто используйте простой пример: создать таблицу check_exec_mode (str varchar (5)) ; выберите * from check_exec_mode ; вставить в значения check_exec_mode ('123456') ; Если вы настроите соединения своего клиента Teradata (например, Teradata Studio Express) в TMODE (режим транзакции) = TERA, вы получите в результате одну усеченную строку в таблице ('12345'). Изменение режима транзакции на ANSI и выполнение инструкции insert приведет к ошибке "Прямое усечение строковых данных".