Wyjaśnienie problemu jest nieco niejasne i nie jestem pewien zakresu aplikacji, ale z punktu widzenia architektury systemu, jeśli używasz frameworka MVC, prawdopodobnie chciałbyś zachować wszystkie jednostki bazy danych to samo i utwórz kontroler UnitConversion. Ten kontroler przyjmie standardową jednostkę jako wejście i wyprowadzi wartość opartą na żądanej jednostce. Na Twoim rekordzie użytkownika/klienta w bazie danych zostanie zachowana flaga, aby poinformować Cię, którą jednostkę preferują, aby nie utracić tych informacji między logowaniami. Przekaż wartość w standardowym formacie jednostki (powiedzmy metry) i flagę żądanej jednostki (powiedzmy 'STOPY') do kontrolera i pozwól mu wykonać konwersję i zwrócić wartość.
Nie próbowałbym przechowywać różnych typów jednostek w bazie danych, ponieważ prawdopodobnie skończysz na pisaniu wszelkiego rodzaju kodu, próbując zarządzać wyjątkami i konserwacją (na przykład aktualizując wszystkie wartości, gdy klienci zmieniają swoje jednostki). Zachowaj standardową jednostkę w bazie danych i wykonuj konwersje za pomocą klasy php, podobnie jak robi to Zend Framework wspomniany przez Roberta. Wygooglowanie „konwersji jednostek php” spowoduje wyświetlenie niektórych klas, które mogą odpowiadać Twoim potrzebom.
AKTUALIZACJA:
Nadal nie jestem pewien, czy widzę cały problem, ale postaram się odpowiedzieć najlepiej, jak rozumiem. Tak jak poprzednio, najlepiej jest zachować w bazie danych 1 jednostkę systemu, powiedzmy, metrykę. Typ_pomiaru w user_pref mówi, czego chce klient, powiedz 'IMPERIAL'. W zależności od tego, jak rozłożona jest Twoja baza danych, możesz wybrać jedno z dwóch rozwiązań do przechowywania wartości:
-
W przypadku elementów w Twojej bazie danych możesz mieć różne właściwości (kolumny), takie jak waga, wzrost, objętość itp.
-
Możesz mieć tabelę przedmiotów, która zawiera przedmioty. Następnie masz tabelę właściwości, która zawiera właściwości. Tabela Właściwości ma 4 kolumny:property_id(klucz podstawowy), property(HEIGHT,WIDTH,LENGTH,WEIGHT), property_type(SIZE,MASS,VOLUME,AWESOMENESS) i value. Następnie masz tabelę Property_Lookup, która ma 2 kolumny:item_id, property_id, a połączenie między tymi 3 tabelami da ci wszystkie wartości i typy jednostek każdej właściwości należącej do elementu. W tym schemacie nadal zachowałbym wszystkie wpisy w kolumnie „wartość” w systemie pojedynczej jednostki (w tym przykładzie metryki). Zobacz ten link, aby uzyskać więcej informacji na temat relacji wiele-do-wielu (http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php ).
Twoje modele będą pobierać dane i zamykać te właściwości w jednostce { system(METRIC*,IMPERIAL,BOTH); typ (ROZMIAR,MASA,OBJĘTOŚĆ); wartość } minimodel. Przekaż to swojemu kontrolerowi. Podczas renderowania Twój widok będzie oczekiwał wartości jednostki w oparciu o to, czego chce klient, więc gdy Twój kontroler gromadzi dane dla Twojego widoku, wyśle obiekty Unit za pośrednictwem biblioteki UnitConversion. Biblioteka UnitConversion sprawdzi model użytkownika dla preferowanego systemu klienta i „systemu” w modelu jednostki i dokona niezbędnej konwersji (ponieważ Biblioteka może założyć, że system w modelu jednostki jest metryką, gdy pochodzi z bazy danych, sprawia to, że krok trochę łatwiej). Następnie wypisze liczbę we właściwej jednostce (jednostki, jeśli wybrano OBA), która może zostać przekazana do Widoku.
Szybkie słowo na temat powyższego jest takie, że zawsze, gdy mamy do czynienia z architekturą systemu, nie ma „poprawnego” rozwiązania problemu. W ten sposób zorganizowałbym rzeczy w oparciu o podane informacje, ale prawdopodobnie będziesz musiał je trochę poprawić, aby idealnie pasowały do tego, z czym pracujesz. To powiedziawszy, poprawiłbym powyższe, aby działało w twoim systemie, a nie poprawiałem twojego systemu, aby powyższe działało! Mam nadzieję, że to da Ci kilka dobrych pomysłów.
