¿Cómo se manejan los datos de "casos especiales" cuando se modela una base de datos?

Question

Nuestra organización ofrece una variedad de servicios a nuestros clientes (por ejemplo, alojamiento web, soporte técnico, programación personalizada, etc.). Hay una página en nuestro sitio web que enumera todos los servicios disponibles y sus precios correspondientes. Esto era información estática, pero mi jefe quiere que todo se extraiga de una base de datos.

Hay alrededor de 100 servicios en la lista. Sin embargo, solo dos de ellos tienen un valor no numérico para "precio" (específicamente, las cadenas "ISA" y "costo + 8%" - Realmente no sé a qué se refieren, así que no lo hagas). Pregúnteme).

No me gustaría hacer que la columna "price" varchar solo por estas dos listas. Mi enfoque actual es crear un campo especial "price_display", que está en blanco o contiene el texto para mostrar en lugar del precio. Sin embargo, esta solución se parece demasiado a un truco sucio (complicaría innecesariamente las consultas), entonces ¿hay una mejor solución?

Answer 1

Tenga en cuenta que esta columna es un precio que se muestra al cliente que puede contener cualquier cosa.

Estaría invitando a la pena si intenta convertirla en una columna numérica. Ya está luchando con dos valores no conformes, y mañana su jefe podría querer más ...

• ¡PRECIO EN LA APLICACIÓN!
• LLÁMENOS PARA HOY ESPECIAL !!

Ya entendió la idea.

Si realmente necesita una columna numérica, llámela internalPrice o algo así, y ponga sus restricciones numéricas en esa columna.

Answer 2

Quizás use un indicador de "tipo" en la tabla principal, con una tabla secundaria que permite el precio numérico y otra con los valores de los caracteres. Estos podrían combinarse en una sola tabla, pero generalmente evito eso. También puede usar una tabla de enlace intermedio con una cantidad si alguna vez desea basar el precio en la cantidad comprada.

Answer 3

Un montón de opciones:

1. Todos los precios almacenados como varchars
2. precios de campo price_display adicional almacenados numéricamente y que anula el número si pobladas
3. precios almacenan numberically y el campo price_display adicional para fines de visualización pobladas manualmente o en el gatillo cuando el precio numérico se actualiza (duplicación de datos y podría salir de la sincronización - yuk)
4. Tienda caso especial precios negativos que se asignan a situaciones especiales (¡simplemente yuk!)
5. precio varchar, campo de clave de prefijo a una tabla de prefijos disponibles ('costo +', ...), campo de clave de sufijo a una tabla de sufijos disponibles, escriba clave de campo a una lista de tipos para el valor en precio (' $ ','% ',' descripción '). Es útil si necesita escribir consultas complejas contra precios en el futuro.

Probablemente vaya por 2 como una solución pragmática, y una extensión de 5 si necesito algo muy general para un sistema de fijación de precios genérico.

Answer 4

Pregúntese ...

¿Agregaré estos valores? ¿Ordenaré por precio? ¿Tendré que convertir a otros valores de moneda?

O

Voy a ser simplemente mostrando este valor en una página web?

Si esta es solo una lista de lavandería y no se usa para el cálculo, la solución más simple es almacenar el precio como una cadena (varchar).

Answer 5

Si esta es la extensión de su modelo de datos, entonces un campo varchar está bien. Sus precios normales, decimales como sean, probablemente sean inútiles para los cálculos de todos modos. ¿Cómo se comparan $ 10/GB para "transferencia de datos" y $ 25/mes para "alojamiento de dominios"?

Su modelo de datos para este proyecto en particular no se trata de precios, sino de mostrar los precios. Diseña con eso en mente.

Por supuesto, si está almacenando el precio que un cliente en particular pagó por un proyecto en particular, o tratando de averiguar qué cobrarle a un cliente en particular, entonces tiene un dominio diferente (más complejo). Y necesitarás un modelo diferente para apoyar eso.

Answer 6

En que al menos uno de los precios alternativos tiene un número involucrado, ¿qué pasa con una columna Precio, un tipo de precio? Las entradas normales podrían ser un número para el valor en dólares y el tipo 'dólar', y el otro podría ser 8 y 'PercentOverCost' y nulo e 'ISA' (para la columna Price and PriceType).

Probablemente deberías tener una tabla PriceType para validar y PriceTypeID si vas por esta ruta.

Esto permitiría que otros tipos de fijación de precios que se añadirán en el futuro (precio por unidad, currancy foriegn), le dará un número, y también hacen que sea más fácil saber qué tipo de fijación de precios que se trata de ..

Answer 7

cuando he tenido que hacer este tipo de cosas en el pasado he utilizado:

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

precio sería de tipo de datos decimal (cualquier numérico exacto, no flota o real), la unidad y la pantalla sería algún tipo de tipo de datos de cadena .

Luego usó la declaración de caso para mostrar el precio con el precio por unidad o la pantalla. También coloque una restricción o desencadenador en la columna de visualización para que sea nulo a menos que el precio sea nulo. Una restricción o desencadenante también debería requerir un valor en la unidad si el precio no es nulo.

De esta forma, puede calcular los precios de un pedido siempre que sea posible y dejarlos fuera cuando no se especifique el precio, pero mostrar ambos. También puse una regla de busness para asegurarme de que no se pudiera totalizar el total hasta que se resolviera la solicitud de fijación de precios (que también tendría que haber una forma de insertar el precio especial en los detalles de la orden en lugar de extraerlo del lista de precios).

Answer 8

http://books.google.co.in/books?id=0f9oLxovqIMC&pg=PA352&lpg=PA352&dq=How+do+you+handle+%E2%80%9Cspecial-case%E2%80%9D+data+when+modeling+a+database%3F&source=bl&ots=KxN9eRgO9q&sig=NqWPvxceNJPoyZzVS4AUtE-FF5c&hl=en&ei=V3RlSpDtI4bVkAWkzbHNDg&sa=X&oi=book_result&ct=result&resnum=3