Объяснение проблемы немного расплывчато, и я не уверен в объеме приложения, но с точки зрения архитектуры системы, если вы используете инфраструктуру MVC, вы, вероятно, захотите сохранить все своиблоки базы данных одинаковы и создают контроллер UnitConversion.Этот контроллер будет принимать стандартную единицу в качестве входного и выходного значения на основе требуемой единицы.Для вашей пользовательской / клиентской записи в базе данных будет сохранен флажок, чтобы вы знали, какой модуль они предпочитают, чтобы вы не потеряли эту информацию между логинами.Передайте значение в стандартном формате единиц (скажем, в метрах) и флаг требуемой единицы (скажем, «НОГИ») в свой контроллер, и пусть он выполнит преобразование и вернет значение.
Я бы не стал пытатьсяхранить в базе данных разные типы модулей, поскольку вы, вероятно, в конечном итоге будете писать все виды кода, пытаясь управлять исключениями и обслуживанием (например, обновляя все значения, когда клиенты меняют свои модули).Держите стандартный блок в базе данных и выполняйте преобразования через класс php, аналогично тому, как это делает Zend Framework, упомянутый Робертом.При поиске в Google «преобразования единиц php» появятся некоторые классы, которые могут удовлетворить ваши потребности.
ОБНОВЛЕНИЕ:
Все еще не уверен, что вижу всю проблему, но я постараюсь ответитьтак хорошо, как я понимаю.Как и прежде, лучше всего хранить в системе 1 единицу системы, скажем, метрическую.Тип измерения в user_pref говорит, что хочет клиент, скажем «IMPERIAL».В зависимости от степени распространения вашей базы данных вы можете выбрать одно из двух решений для хранения значений:
Для элементов в вашей БД у вас могут быть разные свойства (столбцы), такие как вес, рост,объем и т. д.
Возможно, у вас есть таблица предметов, в которой хранятся предметы.Затем у вас есть таблица свойств, которая содержит свойства.Таблица свойств имеет 4 столбца: property_id (первичный ключ), property (HEIGHT, WIDTH, LENGTH, WEIGHT), property_type (SIZE, MASS, VOLUME, AWESOMENESS) и значение.Затем у вас есть таблица Property_Lookup, которая имеет 2 столбца: item_id, property_id, и объединение между этими 3 таблицами предоставит вам все значения и типы единиц каждого свойства, принадлежащего Item.В этой схеме я по-прежнему сохраню все записи в столбце «значение» в одной системе единиц (в этом примере метрики).См. Эту ссылку для получения дополнительной информации об отношениях «многие ко многим» (http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php).
Ваши модели будут извлекать данные и инкапсулировать эти свойства в типе Unit {system (METRIC *, IMPERIAL, BOTH); тип (SIZE, MASS, VOLUME); value} mini-Model. Передайте это вашему контроллеру. При рендеринге ваш View будет ожидать значение единицы на основе того, что хочет клиент, поэтому, когда ваш контроллер собирает данные для вашего View, он отправит Unit.объекты через библиотеку UnitConversion. Библиотека UnitConversion проверит пользовательскую модель на предмет предпочтительной клиентской системы и «системы» в модели модуля и произведет необходимое преобразование (поскольку библиотека может предположить, что система в модели модуля является метрической при поступлении избазы данных, это делает этот шаг немного проще. Затем он выведет число в правильных единицах (единицах, если выбрана ОБА), которое может быть передано в представление.
Быстрое слово наВыше указано, что всегда, когда речь идет о системной архитектуре, не существует «правильного» решения проблемы.Вот как я бы организовал вещи, основываясь на предоставленной информации, но вам, вероятно, придется немного ее настроить, чтобы она идеально вписывалась в то, с чем вы работаете.Тем не менее, я бы настроил вышеперечисленное для работы в вашей системе, а не настраивал вашу систему, чтобы заставить работать вышеперечисленное!Надеюсь, это даст вам хорошие идеи.