Есть ли преимущества использования varchar по сравнению с десятичным для цены и стоимости

Question

Я спорил с моим другом против его предложения хранить цену, стоимость и другую подобную информацию в varchar.

Моя точка зрения основана на

1. Расчеты станут сложными, так как нам нужно приводить туда-сюда.
2. Целостность данных будет потеряна.
3. Низкая производительность индексов
4. Для сортировки и агрегирования функций также потребуется приведение

и т.д.. и т.д.

Но он говорил, что в своем предыдущем занятии все хранили такие значения в varchar, потому что связь между DB и APP будет очень эффективной при таком подходе. (Я до сих пор не могу принять это)

Действительно ли есть некоторые преимущества в хранении таких значений в varchar?

Примечание: Я не говорю о таких столбцах, как PhoneNo, идентификаторы, почтовый индекс, SSN и т. Д. Я знаю, что varchar лучше всего подходит для них. Столбцы основаны на значениях и наверняка так или иначе будут участвовать в вычислениях.

Answer 1

Нет вообще.

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

DECLARE @foo TABLE (bar varchar(30))
INSERT @foo VALUES (11.2222222222)
INSERT @foo VALUES (22.3333333333)
INSERT @foo VALUES (33.1111111111)
SELECT CAST(CAST(bar AS float) AS varchar(30)) FROM @foo

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

Answer 2

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

Answer 3

Я не вижу никаких преимуществ и целую кучу очень серьезных недостатков - самым неотложным из которых является производительность (особенно при сортировке).

Подумайте, хотите ли вы получить список из N самых дорогихпродукты, и вы храните свою цену как VARCHAR.Вот некоторые примеры значений (отсортированные в порядке убывания)

SELECT Price FROM Table ORDER BY Price DESC

Price
-----

90
600
50
1000

Упс!Порядок сортировки, ну, неправильно!(Буквенно-цифровая сортировка, а не сортировка значений).

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

Answer 4

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

Сравнения тоже не обязательно будут работать. Если поле определено, скажем, как десятичное (8,2), и я задаю ему значение «37,20», а позже я напишу «выбрать ..., где цена = 37,2», результат будет истинным. Но если я храню varchar 37.20 и сравниваю его с 37.2, он не будет равным. Точно так же, если один или другой имеет начальные нули.

Вы можете решить эти проблемы, убедившись, что приложение всегда хранит числа с фиксированным числом десятичных разрядов и дополняется начальными нулями. О, и убедитесь, что у вас есть последовательное соглашение о хранении знаков минус. Но тогда каждое место в приложении, которое пишет в это поле, должно быть уверено, что оно следует точно таким же правилам. Конечно, мы могли бы сделать это, но почему? Движок базы данных сделает это за нас, если мы просто объявим поле числовым. Мол, да, я МОГУ косить газон ножницами, но зачем мне это делать?

Я не понимаю, что говорит твой друг, преимущество должно быть. Более простая связь между приложением и базой данных? Как? Возможно, он использовал какой-то нетрадиционный язык или интерфейс базы данных, который не мог прочитать числовые значения из БД. У меня никогда не было проблем с этим. На самом деле, просто сказав это, я задаюсь вопросом: не случилось ли это: что в его предыдущей компании они использовали какой-то язык или инструмент, который не мог прочитать десятичные числа из базы данных из-за проблемы с реализацией, единственный способ, которым они могли это получить? чтобы работать было объявить все числа как varchar, и теперь он уходит, думая, что это в целом хорошая идея.

Answer 5

Хорошо.Одним словом ответ.Не

Вы правы относительно правильных типов данных, влияющих на производительность (SQL Optimizer работает по-разному для INT VS VARCHAR), согласованности и целостности данных и т. Д.

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

Не проблема источника в том, что потребителю нужны все строки в качестве входных данных.пользователь должен проверять тип и использовать данные.У БД всегда должны быть правильные типы.

(Забудьте о выборе между INT и VARCHAR, я бы сказал, что вы также должны подумать, должны ли вы иметь INT или TINYINT), эти соображения имеют большое значение

Answer 6

Единственное преимущество, которое я вижу при использовании любого вида строкового формата переменного размера, состоит в том, что поле должно содержать неизвестное количество дополнительной информации. Например, «49,95 @ 1 / 39,95 @ 5 / 29,95 @ 20 / 14,95 @ 100, match = true / 24,95 @ 100», чтобы указать, что данный конкретный продукт имеет ценовые точки в 1, 5, 20 и 100 единиц, а также Лучшая цена за 100 штук доступна только тогда, когда все предметы идентичны. Использовать строки для хранения таких вещей нехорошо, но если количество ценовых точек не ограничено, использование поля переменного размера может быть лучше, чем создание другой таблицы с одной строкой на комбинацию продукта / ценовой точки. Если вы пойдете по этому пути, может быть полезно использовать сериализацию XML для данных, а не специальную вещь, как показано выше. Специальный подход может позволить в некоторых случаях быстрее выполнять синтаксический анализ, но если вещи действительно являются открытыми, это может стать реальной проблемой для поддержки.

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

Answer 7

Типы данных лучше всего хранить в полях, которые соответствуют типу между двумя разными системами. В этом случае вы обращаетесь от своих объектов .Net к серверу MS SQL. Вы правы в отношении потери целостности данных и необходимости преобразовывать / преобразовывать типы данных в удобные формы. Что касается других типов, таких как номер телефона, почтовый индекс, SSN и т. Д .; они тоже выиграют от выделенных типов данных. Основная причина, по которой они хранятся в VARCHAR / NVARCHAR, заключается в количестве различных возможностей, которые не нужны в каждой системе. Но если у вас есть тип, который обычно используется, и вы хотите ограничить его, вы можете создать пользовательские типы данных, называемые Определяемые пользователем типы , для хранения этих данных на сервере SQL. (Еще интереснее CLR-типы, см. Пример code project .)