Vysvětlení problému je trochu vágní a nejsem si jistý rozsahem aplikace, ale z hlediska systémové architektury, pokud používáte framework MVC, pravděpodobně budete chtít zachovat všechny své databázové jednotky stejné a vytvořte UnitConversion Controller. Tento regulátor bude mít standardní jednotku jako vstupní a výstupní hodnotu založenou na požadované jednotce. Ve vašem záznamu uživatele/klienta v databázi by byl zachován příznak, abyste věděli, kterou jednotku preferují, abyste o tyto informace mezi přihlášeními nepřišli. Předejte hodnotu ve standardním formátu jednotek (řekněme metry) a příznak požadované jednotky (řekněme 'FEET') do ovladače a nechte jej provést převod a vrátit hodnotu.
Nesnažil bych se uchovávat různé typy jednotek v databázi, protože pravděpodobně skončíte psaním všech druhů kódu, který se bude snažit spravovat výjimky a údržbu (například aktualizace všech hodnot, když klienti změní své jednotky). Udržujte standardní jednotku v databázi a provádějte převody pomocí třídy php podobně, jako to dělá Zend Framework zmíněný Robertem. Google "php unit conversion" vyvolá některé třídy, které mohou vyhovovat vašim potřebám.
PŘI AKTUALIZACI:
Stále si nejsem jistý, zda vidím celý problém, ale pokusím se odpovědět, jak nejlépe rozumím. Stejně jako dříve je nejlepší ponechat v databázi 1 jednotkový systém, řekněme metrický. Metriční typ v user_pref říká, co klient chce, řekněme 'IMPERIAL'. V závislosti na tom, jak je vaše databáze rozložená, můžete zvolit jedno ze dvou řešení pro uchování hodnot:
-
U položek ve vaší databázi můžete mít různé vlastnosti (sloupce), jako je hmotnost, výška, objem atd.
-
Můžete mít tabulku položek, která obsahuje položky. Pak máte tabulku vlastností, která obsahuje vlastnosti. Tabulka vlastností má 4 sloupce:property_id (primární klíč), property (HEIGHT, WIDTH, LENGTH, WEIGHT), property_type (SIZE, Mass, VOLUME, WESOMENESS) a value. Pak máte tabulku Property_Lookup, která má 2 sloupce:item_id, property_id a spojení mezi těmito 3 tabulkami vám dá všechny hodnoty a typy jednotek každé vlastnosti patřící k Item. V tomto schématu bych stále ponechal všechny položky ve sloupci „hodnota“ v systému jedné jednotky (v tomto příkladu metriky). Další informace o vztazích many-to-many naleznete na tomto odkazu (http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php ).
Vaše modely načtou data a zapouzdří tyto vlastnosti do jednotky { system(METRIC*,IMPERIAL,BOTH); typ (VELIKOST, HMOTNOST, OBJEM); hodnota } mini-Model. Předejte to svému ovladači. Při vykreslování bude váš pohled očekávat hodnotu jednotky založenou na tom, co chce klient, takže když váš řadič shromažďuje data pro váš pohled, odešle objekty Unit prostřednictvím knihovny UnitConversion Library. Knihovna UnitConversion Library zkontroluje uživatelský model pro preferovaný systém klienta a „systém“ v modelu jednotek a provede potřebnou konverzi (protože knihovna může předpokládat, že systém v modelu jednotek je při příchodu z databáze metrický, provede to krok trochu jednodušší). Poté vypíše číslo ve správných jednotkách (jednotky, pokud je vybráno OBA), které lze předat do zobrazení.
Rychlé slovo k výše uvedenému je, že vždy, když se zabýváte architekturou systému, neexistuje žádné „správné“ řešení problému. Takto bych uspořádal věci na základě uvedených informací, ale pravděpodobně to budete muset trochu vyladit, aby to dokonale zapadalo do toho, s čím pracujete. To znamená, že bych vyladil výše uvedené, aby fungovalo ve vašem systému, a ne upravoval váš systém, aby výše uvedené fungovalo! Doufám, že vám to dá nějaké dobré nápady.