Förklaringen till problemet är lite vag och jag är inte säker på tillämpningens omfattning, men ur systemarkitektursynpunkt, om du använder ett MVC-ramverk, skulle du förmodligen vilja behålla alla dina databasenheter samma och skapa en UnitConversion Controller. Denna styrenhet skulle ta standardenheten som ingång och mata ut ett värde baserat på önskad enhet. En flagga skulle hållas på din användar-/klientpost i databasen för att låta dig veta vilken enhet de föredrar så att du inte förlorar denna information mellan inloggningar. Skicka in värdet i ett standardenhetsformat (säg, meter) och den önskade enhetens flagga (säg "FEET") till din Controller och låt den göra omvandlingen och returnera ett värde.
Jag skulle inte försöka behålla olika enhetstyper i databasen eftersom du sannolikt kommer att skriva alla typer av kod för att försöka hantera undantagen och underhållet (uppdatera alla värden när klienter ändrar sina enheter, till exempel). Behåll en standardenhet i databasen och gör omvandlingarna via en php-klass som liknar hur Zend Framework som Robert nämner gör. Att googla på "php unit conversion" kommer att få upp några klasser som kan passa dina behov.
PÅ UPPDATERING:
Fortfarande inte säker på att jag ser hela problemet, men jag ska försöka svara så gott jag förstår. Som tidigare är det bäst att behålla 1 enhetssystem i databasen, till exempel metrisk. Measurement_type i user_pref talar om vad klienten vill ha, säg 'IMPERIAL'. Beroende på hur utbredd din databas är kan du välja en av två lösningar för att hålla värden:
-
För artiklar i din DB kan du ha olika egenskaper (kolumner), som vikt, höjd, volym, etc.
-
Du kan ha en artikeltabell som innehåller föremål. Sedan har du en egenskapstabell som innehåller egenskaper. Egenskapstabellen har fyra kolumner:property_id (primärnyckel), egenskap (HEIGHT, WIDTH, LENGTH, WEIGHT), egenskapstyp (SIZE, MASS, VOLUME, AWESOMENESS) och värde. Sedan har du en Property_Lookup-tabell som har 2 kolumner:item_id, property_id och en koppling mellan dessa 3 tabeller ger dig alla värden och enhetstyper för varje egenskap som hör till ett objekt. I det här schemat skulle jag fortfarande behålla alla poster i kolumnen "värde" i ett enda enhetssystem (i det här exemplet mått). Se den här länken för mer om många-till-många-relationer (http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php ).
Dina modeller kommer att hämta data och kapsla in dessa egenskaper i ett Unit { system(METRIC*,IMPERIAL,BOTH); typ(STORLEK, MASSA, VOLYM); värde } minimodell. Skicka det till din handkontroll. Vid rendering kommer din vy att förvänta sig ett enhetsvärde baserat på vad klienten vill ha, så när din Controller sätter ihop data för din vy kommer den att skicka enhetsobjekt genom UnitConversion Library. UnitConversion Library kommer att kontrollera användarmodellen för klientens föredragna system och 'systemet' i enhetsmodellen och göra den nödvändiga konverteringen (eftersom biblioteket kan anta att systemet i enhetsmodellen är metriskt när det kommer från databasen, gör det detta steg lite lättare). Den kommer sedan att mata ut ett nummer i rätt enhet (enheter om BÅDA är vald), som kan skickas vidare till vyn.
Ett snabbt ord om ovanstående är att det alltid när det handlar om systemarkitektur finns det ingen "korrekt" lösning på ett problem. Så här skulle jag organisera saker baserat på informationen som ges, men du kommer förmodligen behöva finjustera den en hel del för att få den att passa perfekt med det du arbetar med. Som sagt, jag skulle justera ovanstående för att fungera i ditt system, och inte justera ditt system för att få ovanstående att fungera! Hoppas detta ger dig några bra idéer.