La explicación del problema es un poco vaga y no estoy seguro del alcance de la aplicación, pero desde el punto de vista de la arquitectura del sistema, si está utilizando un marco MVC, probablemente querrá mantener todas las unidades de su base de datos mismo y cree un controlador de conversión de unidades. Este controlador tomaría la unidad estándar como entrada y generaría un valor basado en la unidad deseada. Se mantendría una marca en su registro de usuario/cliente en la base de datos para informarle qué Unidad prefieren para que no pierda esta información entre inicios de sesión. Pase el valor en un formato de unidad estándar (digamos, metros) y la bandera de la unidad deseada (digamos, 'PIES') a su Controlador y deje que haga la conversión y devuelva un valor.
No trataría de mantener diferentes tipos de unidades en la base de datos, ya que probablemente terminará escribiendo todo tipo de código tratando de administrar las excepciones y el mantenimiento (actualizando todos los valores cuando los clientes cambien sus unidades, por ejemplo). Mantenga una unidad estándar en la base de datos y realice las conversiones a través de una clase php similar a como lo hace Zend Framework mencionado por Robert. Buscar en Google "conversión de unidades php" mostrará algunas clases que pueden satisfacer sus necesidades.
AL ACTUALIZAR:
Todavía no estoy seguro de estar viendo todo el problema, pero intentaré responder lo mejor que entiendo. Como antes, es mejor mantener un sistema de 1 unidad en la base de datos, por ejemplo, métrico. El tipo de medida en user_pref dice lo que quiere el cliente, digamos 'IMPERIAL'. Dependiendo de qué tan dispersa esté su base de datos, puede elegir una de dos soluciones para almacenar valores:
-
Para los elementos en su base de datos, puede tener diferentes propiedades (columnas), como peso, altura, volumen, etc.
-
Es posible que tenga una tabla de elementos que contenga elementos. Entonces tienes una tabla de propiedades que contiene propiedades. La tabla de propiedades tiene 4 columnas:property_id (clave principal), property (ALTO, ANCHO, LARGO, PESO), property_type (TAMAÑO, MASA, VOLUMEN, IMPRESIONANTE) y valor. Luego, tiene una tabla Property_Lookup que tiene 2 columnas:item_id, property_id y una unión entre estas 3 tablas le dará todos los valores y tipos de unidades de cada propiedad que pertenece a un artículo. En este esquema, aún mantendría todas las entradas en la columna 'valor' en un sistema de una sola unidad (en esta métrica de ejemplo). Consulte este enlace para obtener más información sobre las relaciones de muchos a muchos (http://www.tomjewett.com/dbdesign/dbdesign.php?page=muchosmuchos.php ).
Sus Modelos recuperarán datos y encapsularán estas propiedades en una Unidad { system(METRIC*,IMPERIAL,BOTH); tipo(TAMAÑO,MASA,VOLUMEN); valor } mini-Modelo. Pase eso a su controlador. Al renderizar, su vista esperará un valor de unidad basado en lo que el cliente quiere, por lo que cuando su controlador esté reuniendo datos para su vista, enviará objetos de unidad a través de la biblioteca UnitConversion. La biblioteca UnitConversion verificará el modelo de usuario para el sistema preferido del cliente y el 'sistema' en el modelo de unidad y realizará la conversión necesaria (dado que la biblioteca puede asumir que el sistema en el modelo de unidad es métrico cuando proviene de la base de datos, hace esto paso un poco más fácil). Luego generará un número en la unidad correcta (unidades si se eligen AMBOS), que se puede pasar a la Vista.
Una palabra rápida sobre lo anterior es que siempre que se trata de la arquitectura del sistema no existe una solución "correcta" para un problema. Así es como organizaría las cosas en función de la información proporcionada, pero es probable que deba modificarlo un poco para que encaje perfectamente con lo que está trabajando. Dicho esto, ¡modificaría lo anterior para que funcione en su sistema, y no modificaría su sistema para que lo anterior funcione! Espero que esto te dé algunas buenas ideas.
