Есть ли законная причина для использования стольких полей varchar? (БД MS SQL)

Question

Я работаю над переносом данных из старой системы на основе IBM Universe в новую систему управления данными и данными на уровне предприятия и изучаю процесс проектирования базы данных.

Я посмотрел навнутреннюю структуру базы данных новой системы (это MS SQL DB, около 100 таблиц), и некоторые вещи выглядят довольно странно.Но я не знаю, является ли моя неопытность причиной, по которой я так думаю, и это просто стандартная практика, или эти странности на самом деле просто плохой дизайн базы данных / приложения.

Например:

• Некоторые поля даты - это varchar (20)
• Поля, в которых хранятся измерения, - это varchar (50), а не что-то вроде десятичного числа и перечисление для хранения единиц измерения
• ISBN 10& 13 числовых полей: varchar (50)
• Некоторые внешние ключи идентификатора поиска - varchar (100), хотя фактический первичный ключ таблицы поиска - int
• Некоторые поляvarchar (0)
• Дополнительные отдельные поля для хранения месяца и года, каждое из которых - varchar (250) - Я не знаю, для какого типа проектного решения потребуется максимум 250 символов длягод, если они действительно не переусердствовали в своем соответствии требованиям 2000 года или решили использовать секунды с начала вселенной для хранения даты и времени

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

Я должен также упомянуть, что все поля varchar в БД на самом деле n -varchar - так что это все Unicode, даже те поля, которыетолько номера магазинов.

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

Answer 1

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

Например, в сфере недвижимости цена дома должна быть числовой. Однако многие агенты хотят отображать такие фразы, как «запрос цены», «в нижних 300-х» и т. Д. (Хотя мы сохраняем отдельное числовое поле цены для поиска).

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

Answer 2

Некоторые поля даты - это varchar (20)

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

Некоторые внешние ключи идентификатора поиска имеют тип varchar (100), хотя фактический первичный ключ таблицы соответствия - int

Это плохо, потому что вы получите конверсии, когда присоединитесь, и это замедлит процесс

Храните десятичные дроби как десятичные дроби ... рано или поздно вы получите там плохие данные, и тогда это будет классический случай GIGO(Garbage In Garbage Out)

Также использование nvarchar для хранения чисел безумно, вы просто удвоили объем памяти, необходимый для хранения этих чисел, тогда будет сохранено меньше строк на страницу, и вам потребуется больше IO для возврататакое же количество строк, если использовались обычные varchars или целые числа

Answer 3

Некоторые из них явно являются проблемами, особенно «даты как текст» и «внешние ключи, которые не соответствуют типу данных их связанного ключа».

«Поля номеров ISBN 10 и 13 как varchar(50) "не так однозначно.Конечно, он будет работать, чтобы сохранить его как BIGINT, но есть несколько хороших аргументов для использования CHAR (10) или CHAR (13) вместо этого: (даже если он использует немного больше памяти. Varchar (50) явно излишним)

1. Вам когда-нибудь понадобится выполнить математические операции с этим числом?(нет)
2. Будете ли вы часто "красиво отформатировать" это?(00-0000-00-0 или что-то в этом роде. Операции форматирования над строками проще выполнять)
3. Вам когда-нибудь придется сравнивать LIKE?ГДЕ convert (varchar (13), ISBN) LIKE '% 123%' довольно уродлив.

Поэтому, в зависимости от того, как именно он будет использоваться, у меня не возникнет проблем с использованием CHAR вместо,На самом деле, вы можете утверждать, что VARCHAR (13) будет иметь смысл, если значительное количество строк не будет иметь ISBN (меньше памяти).

Answer 4

Неа.Я бы изменил это, если бы оно было моим.Вы знаете, кто принимал эти решения?Если они все еще рядом, вы можете спросить их.