Forklaringen på problemet er lidt vag, og jeg er ikke sikker på omfanget af applikationen, men fra et systemarkitektursynspunkt, hvis du bruger en MVC-ramme, vil du sandsynligvis beholde alle dine databaseenheder samme og opret en UnitConversion Controller. Denne controller ville tage standardenheden som input og udlæse en værdi baseret på den ønskede enhed. Et flag vil blive holdt på din bruger-/klientpost i databasen for at fortælle dig, hvilken enhed de foretrækker, så du ikke mister disse oplysninger mellem logins. Indsæt værdien i et standardenhedsformat (f.eks. meter) og den ønskede enheds flag (f.eks. 'FEET') i din controller, og lad den foretage konverteringen og returnere en værdi.
Jeg ville ikke forsøge at beholde forskellige enhedstyper i databasen, da du sandsynligvis vil ende med at skrive alle slags kode, der forsøger at styre undtagelserne og vedligeholdelsen (for eksempel opdatere alle værdierne, når klienter ændrer deres enheder). Behold en standardenhed i databasen og lav konverteringerne via en php-klasse, der ligner hvordan Zend Framework nævnt af Robert gør. Googling af "php-enhedskonvertering" vil bringe nogle klasser frem, der kan passe til dine behov.
PÅ OPDATERING:
Jeg er stadig ikke sikker på, at jeg kan se hele problemet, men jeg vil prøve at svare så godt jeg forstår. Som før er det bedst at beholde 1 enhedssystem i databasen, f.eks. metrisk. Measurement_type i user_pref fortæller, hvad klienten ønsker, sig 'IMPERIAL'. Afhængigt af hvor spredt din database er, kan du vælge en af to løsninger til at holde værdier:
-
For varer i din DB kan du have forskellige egenskaber (kolonner), såsom vægt, højde, volumen osv.
-
Du har muligvis en varetabel, som indeholder varer. Så har du en egenskabstabel, som indeholder egenskaber. Egenskabstabellen har 4 kolonner:property_id (primær nøgle), property (HEIGHT, WIDTH, LENGTH, WEIGHT), property_type(SIZE, MASS, VOLUME, AWESOMENESS) og værdi. Så har du en Property_Lookup-tabel, som har 2 kolonner:item_id, property_id og en joinforbindelse mellem disse 3 tabeller vil give dig alle værdier og enhedstyper for hver egenskab, der hører til et element. I dette skema ville jeg stadig beholde alle indtastningerne i 'værdi'-kolonnen i et enkelt enhedssystem (i dette eksempelmetrik). Se dette link for mere om mange-til-mange-forhold (http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php ).
Dine modeller vil hente data og indkapsle disse egenskaber i et Unit { system(METRIC*,IMPERIAL,BOTH); type (STØRRELSE, MASSE, VOLUME); værdi } mini-model. Giv det til din controller. Ved gengivelse vil din visning forvente en enhedsværdi baseret på, hvad klienten ønsker, så når din controller sammensætter data til din visning, vil den sende enhedsobjekter gennem UnitConversion Library. UnitConversion Library vil tjekke brugermodellen for klientens foretrukne system og 'systemet' i enhedsmodellen og foretage den nødvendige konvertering (da biblioteket kan antage, at systemet i enhedsmodellen er metrisk, når det kommer fra databasen, gør det dette skridt lidt lettere). Det vil derefter udsende et tal i den korrekte enhed (enheder, hvis BEGGE er valgt), som kan sendes videre til visningen.
Et hurtigt ord om ovenstående er, at der altid, når man beskæftiger sig med systemarkitektur, ikke er nogen 'korrekt' løsning på et problem. Sådan vil jeg organisere tingene ud fra de oplysninger, der er givet, men du bliver nok nødt til at justere det en del for at få det til at passe perfekt ind i det, du arbejder med. Når det er sagt, ville jeg justere ovenstående for at virke i dit system, og ikke justere dit system for at få ovenstående til at virke! Håber dette giver dig nogle gode ideer.