Как вы обрабатываете данные «особого случая» при моделировании базы данных? - PullRequest
Новая
       7

Как вы обрабатываете данные «особого случая» при моделировании базы данных?

5 голосов
/ 05 декабря 2008

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

В списке около 100 услуг. Однако только два из них имеют не числовое значение «цена» (в частности, строки «ISA» и «стоимость + 8%») - я действительно не знаю, что они должны означать, поэтому не надо спросите меня).

Я бы не хотел делать столбец "цена" varchar только из-за этих двух списков. Мой текущий подход заключается в создании специального поля "price_display", которое либо пустое, либо содержит текст, отображаемый вместо цены. Это решение слишком похоже на грязный хак (оно без необходимости усложнит запросы), так есть ли лучшее решение?

Ответы [ 8 ]

4 голосов
/ 05 декабря 2008

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

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

  • ЦЕНА НА ЗАЯВКУ!
  • ПОЗВОНИТЕ НАМ, ЧТОБЫ СЕГОДНЯ СПЕЦИАЛЬНО !!

Вы поняли идею.

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

4 голосов
/ 20 июля 2009

Когда мне приходилось делать подобные вещи в прошлом, я использовал: 

Price   Unit   Display
10.00   item   null
100.00  box    null
null    null   "Call for Pricing"

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

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

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

2 голосов
/ 05 декабря 2008

Задай себе вопрос ...

Буду ли я добавлять эти значения? Буду ли я сортировать по цене? Нужно ли будет конвертировать в другую валюту?

OR

Буду ли я отображать это значение на веб-странице?

Если это просто список прачечной и не используется для вычислений, самое простое решение - сохранить цену в виде строки (varchar).

1 голос
/ 06 декабря 2008

В том, что по крайней мере одна из альтернативных цен включает число, как насчет столбца Цена, типа цены? Обычные записи могут быть числом для значения доллара и типа «доллар», а другими могут быть 8 и «PercentOverCost», а также ноль и «ISA» (для столбца «Цена и цена»).

Вероятно, для проверки вам понадобится таблица PriceType и PriceTypeID.

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

1 голос
/ 05 декабря 2008

Если это экстент вашей модели данных, тогда поле varchar подходит. Ваши обычные цены - как бы десятичные они ни были - вероятно, в любом случае бесполезны для расчетов. Как вы сравниваете $ 10 / ГБ для «передачи данных» и $ 25 / месяц для «доменного хостинга»?

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

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

1 голос
/ 05 декабря 2008

Много вариантов:

  1. Все цены хранятся в виде varchars
  2. Цены сохраняются в цифровом виде и дополнительное поле price_display, которое переопределяет число, если оно заполнено
  3. Цены хранятся в числовом виде и дополнительное поле price_display для целей отображения заполняется вручную или по триггеру при обновлении числовой цены (дублирование данных, которое может выйти из синхронизации - юк)
  4. Храните отрицательные цены в особых случаях, которые соответствуют особым ситуациям (просто юк !!)
  5. цена varchar, поле ключа префикса к таблице доступных префиксов ('cost +', ...), поле ключа суффикса к таблице доступных суффиксов, ключ поля типа для списка типов для значения в цене ( «$», «%», «описание»). Полезно, если вам нужно в будущем написать сложные запросы по ценам.

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

1 голос
/ 05 декабря 2008

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

0 голосов
/ 21 июля 2009
...