Създадох подсхема на база данни за обработка на единици преди един век (добре, леко преувеличавам; все пак беше преди около 20 години). За щастие трябваше да се справи само с обикновени размери на маса, дължина, време - не температура, или електрически ток, или светимост и т.н. Доста по-малко проста беше валутната страна на играта - имаше безброй различни начини за конвертиране между една валута и друг в зависимост от датата, валутата и периода, през който обменният курс е бил валиден. Това беше обработено отделно от физическите единици.
По същество създадох таблица „мерки“ с колона „идентификатор“, име за единицата, съкращение и набор от показатели на размери – по един за маса, дължина, време. Това се попълва с имена като „обем“ (дължина =3, маса =0, време =0), „плътност“ (дължина =3, маса =-1, време =0) – и други подобни.
Имаше втора таблица с единици, която идентифицираше мярка и след това действителните единици, използвани от определено измерване. Например, имаше варели, кубични метри и всякакви други уместни единици.
Имаше трета таблица, която определяше коефициентите на преобразуване между конкретни единици. Това се състоеше от две единици и мултипликативния коефициент на преобразуване, който преобразува единица 1 в единица 2. Най-големият проблем тук беше динамичният диапазон на коефициентите на преобразуване. Ако преобразуването от U1 в U2 е 1,234E+10, тогава обратното е доста малко число (8,103727714749e-11).
Коментарът на S.Lott за температурите е интересен - не трябваше да се занимаваме с тях. Съхранена процедура би се справила с това - въпреки че интегрирането на една запаметена процедура в системата може да е трудно.
Схемата, която описах, позволи повечето преобразувания да бъдат описани веднъж (включително хипотетични единици като стадии за две седмици или по-малко хипотетични, но също толкова неясни - извън САЩ - като акър футове) и преобразуванията можеха да бъдат валидирани (например и двете единиците в таблицата на коефициента на преобразуване трябваше да имат една и съща мярка). Може да се разшири, за да се справи с повечето други единици - въпреки че безразмерните единици като ъгли (или плътни ъгли) представляват някои интересни проблеми. Имаше поддържащ код, който обработваше произволни преобразувания - или генерираше грешка, когато преобразуването не можеше да се поддържа. Една от причините за тази система беше, че различните международни дъщерни компании ще докладват своите данни в техните локални удобни единици, но системата на HQ трябваше да приеме оригиналните данни и въпреки това да представи получените обобщени данни в единици, които отговарят на мениджърите - където различни мениджъри всеки имаха собствена идея (въз основа на техния национален произход и продължителност на службата в щаба) за най-добрите единици за техните доклади.
