The explanation of the problem is a bit vague and I'm not sure the scope of the application, but from a system architecture point of view, if you are using a MVC framework, you would probably want to keep all of your database units the same and create a UnitConversion Controller. This Controller would take the standard unit as input and output a value based on the unit desired. A flag would be kept on your user/client record in the database to let you know which Unit they prefer so you don't lose this information between logins. Pass in the value in a standard unit format (say, meters) and the desired unit's flag (say, 'FEET') into your Controller and let it do the conversion and return a value.
I would not try to keep different unit types in the database as you will likely end up writing all kinds of code trying to manage the exceptions and maintenance (updating all of the values when clients change their units, for example). Keep a standard unit in the database and do the conversions via a php class similar to how the Zend Framework mentioned by Robert does. Googling "php unit conversion" will bring up some classes that may suite your needs.
ON UPDATE:
Still not sure I'm seeing the entire problem, but I'll try to answer as best as I understand. As before it is best to keep 1 unit system in the database, say, metric. The measurement_type in user_pref tells what the client wants, say 'IMPERIAL'. Depending on how spread out your database is you might choose one of two solutions to hold values:
For items in your DB you might have different properties (columns), like weight, height, volume, etc.
You might have an Item table which holds items. Then you have a Property table which holds properties. The Property table has 4 columns: property_id(primary key), property(HEIGHT, WIDTH, LENGTH, WEIGHT), property_type(SIZE,MASS,VOLUME,AWESOMENESS), and value. Then you have a Property_Lookup table which has 2 columns: item_id, property_id and a join between these 3 tables will give you all of the values and unit types of each property belonging to an Item. In this schema I would still keep all of the entries in the 'value' column in a single unit system (in this example metric). See this link for more on many-to-many relationships (http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php).
Your Models will retrieve data and encapsulate these properties in a Unit { system(METRIC*,IMPERIAL,BOTH); type(SIZE,MASS,VOLUME); value } mini-Model. Pass that to your Controller. On render your View will expect a unit value based on what the client wants, so when your Controller is putting together data for your View it will send Unit objects through the UnitConversion Library. The UnitConversion Library will check the User Model for the client's prefered system and the 'system' in the Unit model and make the necessary conversion (since the Library can assume the system in the Unit model is metric when coming from the database, it makes this step a little easier). It will then output a number in the correct unit (units if BOTH is chosen), which can be passed on to the View.
A quick word on the above is that always when dealing in system architecture there is no 'correct' solution to a problem. This is how I would organize things based on the information given, but you will probably need to tweak it quite a bit to get it to fit in perfectly with what you're working with. That said, I would tweak the above to work in your system, and not tweak your system to get the above to work! Hope this gives you some good ideas.