De uitleg van het probleem is een beetje vaag en ik weet niet zeker wat de reikwijdte van de toepassing is, maar vanuit het oogpunt van systeemarchitectuur, als u een MVC-framework gebruikt, wilt u waarschijnlijk al uw database-eenheden behouden hetzelfde en maak een UnitConversion-controller. Deze controller zou de standaardeenheid als invoer nemen en een waarde uitvoeren op basis van de gewenste eenheid. Er wordt een vlag bijgehouden op uw gebruikers-/klantrecord in de database om u te laten weten aan welke eenheid zij de voorkeur geven, zodat u deze informatie niet verliest tussen aanmeldingen. Geef de waarde in een standaardeenheidsformaat (bijvoorbeeld meters) en de vlag van de gewenste eenheid (bijvoorbeeld 'FEET') in uw Controller en laat deze de conversie uitvoeren en een waarde retourneren.
Ik zou niet proberen verschillende typen eenheden in de database te houden, omdat je waarschijnlijk allerlei soorten code gaat schrijven om de uitzonderingen en het onderhoud te beheren (bijvoorbeeld alle waarden bijwerken wanneer klanten hun eenheden wijzigen). Houd een standaardeenheid in de database en doe de conversies via een php-klasse vergelijkbaar met hoe het door Robert genoemde Zend Framework doet. Googlen op "php unit conversie" zal enkele klassen opleveren die aan uw behoeften kunnen voldoen.
BIJ UPDATE:
Ik weet nog steeds niet zeker of ik het hele probleem begrijp, maar ik zal proberen zo goed mogelijk te antwoorden. Zoals eerder is het het beste om 1 eenheidssysteem in de database te houden, bijvoorbeeld metrisch. Het type meting in user_pref vertelt wat de klant wil, zeg 'IMPERIAL'. Afhankelijk van hoe verspreid uw database is, kunt u een van de twee oplossingen kiezen om waarden vast te houden:
-
Voor items in uw DB heeft u mogelijk verschillende eigenschappen (kolommen), zoals gewicht, lengte, volume, enz.
-
Mogelijk hebt u een itemtabel met items. Dan heb je een eigenschappentabel die eigenschappen bevat. De eigenschappentabel heeft 4 kolommen:property_id(primaire sleutel), property(HEIGHT, WIDTH, LENGTH, WEIGHT), property_type(SIZE,MASS,VOLUME,AWESOMESS) en value. Dan heb je een Property_Lookup-tabel met 2 kolommen:item_id, property_id en een join tussen deze 3 tabellen geeft je alle waarden en eenheidstypen van elke eigenschap die bij een item hoort. In dit schema zou ik nog steeds alle vermeldingen in de kolom 'waarde' in een systeem met één eenheid bewaren (in dit voorbeeldstatistiek). Zie deze link voor meer informatie over veel-op-veel relaties (http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php ).
Uw modellen zullen gegevens ophalen en deze eigenschappen inkapselen in een Unit { system(METRIC*,IMPERIAL,BOTH); type (GROOTTE, MASSA, VOLUME); waarde } mini-model. Geef dat door aan je controller. Bij het renderen verwacht uw weergave een eenheidswaarde op basis van wat de klant wil, dus wanneer uw controller gegevens voor uw weergave samenstelt, verzendt hij eenheidsobjecten via de UnitConversion-bibliotheek. De UnitConversion-bibliotheek controleert het gebruikersmodel voor het voorkeurssysteem van de klant en het 'systeem' in het Unit-model en voert de noodzakelijke conversie uit (aangezien de bibliotheek ervan uit kan gaan dat het systeem in het Unit-model metrisch is wanneer het uit de database komt, maakt dit dit stap een beetje makkelijker). Het zal dan een getal in de juiste eenheid weergeven (eenheden als BEIDE is gekozen), dat kan worden doorgegeven aan de weergave.
Een kort woord over het bovenstaande is dat er altijd als het gaat om systeemarchitectuur, er geen 'juiste' oplossing voor een probleem is. Dit is hoe ik dingen zou organiseren op basis van de gegeven informatie, maar je zult het waarschijnlijk behoorlijk moeten aanpassen om het perfect te laten passen bij waar je mee werkt. Dat gezegd hebbende, zou ik het bovenstaande aanpassen om in uw systeem te werken, en niet uw systeem aanpassen om het bovenstaande te laten werken! Ik hoop dat dit je goede ideeën geeft.