Urri1 лс = 1 кг * 1 м / 1 с
ЧЕГО-ЧЕГО? Вы с размерностями явно ошиблись.
Вт = Дж/с = кг * (м/с)^2 / с = кг * м^2 / с^3. (здесь ^ - степень).
А лс - вообще не метрическая ЕИ, но той же размерности, что и Вт (ЕИ измерения мощности).

Если по существу темы - метод предложили рабочий, только он будет давать погрешности при отношении неметрических ЕИ между собой через метрические. Да и не всегда удобно бывает выбрать одну основную ЕИ, например, что взять за основную ЕИ длины, пс, км, м или нм? По идее, зависит от задачи, но по Вашей схеме, в БД может быть только одна основная ЕИ длины.

softwarerНе очень понял сути Вашей мысли
Urri предложил "В каждом классе 1 ЕИ выбирается за основную", поэтому, так как "длина" - класс ЕИ (в терминах Urri), то основная ЕИ длины у него может быть только одна. Предположим, это метр. Соответственно, если в одной БД есть данные по астрономии и атомной физике, то коэффициенты перевода различаются на 20-30 порядков. Именно поэтому проще не фиксировать одну основную ЕИ для класса ЕИ, а разрешить формирование "дополнительных" ЕИ для любой ЕИ (как у меня, собственно, и сделано). Таким образом, я не про то, что "как предлагает Urri, так в принципе нельзя", а про то, что "можно по-другому, чтобы было проще пользоваться". То что "можно выбрать учетную единицу свою для каждого товара" безусловно верно, но непосредственно к обсуждению построения справочника ЕИ не относится.

softwarerв данных это никак не отражается
Не соглашусь. Безусловно, можно взять очень широкие флоатовые или нумериковые поля (чтобы не терять точность при больших по модулю порядках) или хранить коэффициенты в логарифмическом виде, но в любом случае это требует 1) больше места и 2) принятия решения о порядке вычисления операций. Например, если есть 2 ЕИ масштаба аттометра или фемтометра и между ними надо перевести значение, то придется сначала взаимно приводить их коэффициенты, а уж потом умножать или делить значение на полученный коэффициент. Так как у меня - я обхожусь сермяжным флоатовым полем и для коэффициентов перевода, и для самих значений количеств. При этом флоат делает именно то, что от него требуется - хранение с максимальной точностью в рамках ограничения по размеру поля, независимо от того, ввел я 10^-15 или 10^18. А моя схема позволяет все то, что схема Urri (то есть, любые две ЕИ одного класса можно связать через 2 коэффициента), но и даже больше, а именно, если очень потребуется, то между любыми двумя ЕИ одного класса можно установить один коэффициент пересчета, минуя основную ЕИ (фактически, любая ЕИ может играть роль основной). Кроме того, одна основная ЕИ дает погрешность при переводе между неметрическими ЕИ (переводе, замечу, изначально точном), ибо исходные коэффициенты пересчета от неметрических ЕИ к основной метрической ЕИ вводятся с погрешностью.

softwarer
Сложнее делать пересчет. Потребуется делать денормализацию, держать предрассчитанную таблицу коэффициентов

Я все же думаю, я не смог толком объяснить, как у меня сделано. Ну да и ладно. Разве что замечу, что никакой предрассчитанной таблицы коэффициентов нет.

softwarer
Придется постоянно проверять "деревянность" данных - отсутствие циклов и связность графа

Продуманный интерфейс решает эту задачу даже без дополнительной логики в триггерах.

softwarerПридется постоянно проверять согласованность данных - скажем, для пива заданные и хранящиеся коэффициенты преобразования "из литров в килограммы" и "из кубометров в килограммы" должны соответствовать коэффициенту между литрами и кубометрами.

Скажем так, принципиальную возможность их несоответствия я рассматриваю скорее как фичу, а не как багу. В любом случае, все, что Вы имеете в виду под "придется постоянно", реализуется ровно один раз в триггерах и потом работает как часы.

softwarerИтого - не вижу смысла так поступать. Лучше хранить с основной единицей, а интерфейс - как удобнее в конкретном случае.
1. Именно это и называется "зависит от задачи". 2. Про интерфейс я вообще не писал в своем исходном сообщении.

UrriДж, если я физику не окончательно забыл, строится от Н, а не от кг. А Н переводятся в кг как раз умножением на ускорение (м/с2).
И получается что Н * м2/с3 (Дж) [ = Н * м/с2 * м/с ] = С * кг * м/с (лс, здесь С - коэффициент)
Я ж написал цепочку.
Вт=Дж/с.
Дж=кг*(м/с)^2 (вспоминайте E=mv^2/2).

softwarerПоявляется желание внедрить еще понятие "семейства", что ли, и иметь основную ЕИ для каждого семейства.
Почти в точку. Это решает как раз проблему точного расчета коэффициента отношения, незавиcимо от природы возникновения погрешности. Только что я не называю это "семейством", ибо у меня нет "одной основной ЕИ для класса".

softwarerХм. Имхо в Вашей схеме расчет коэффициента на лету окажется неприятной штукой.
Ничего на лету не считается. Просто через coalesce кроме "стандартного" отношения коэффициентов пытается использоваться еще более приоритетный прямой коэффициент.

softwarerНет такой БД, в которой время от времени не выполняли бы патчи и прочие sql-скрипты.
У меня это решено просто. Справочник ЕИ поддерживается полностью силами клиентов. Патчей, обновляющих данные в справочнике ЕИ, не припомню.

softwarerМало. Хотелось бы увидеть таблицу
Давайте без подробных таблиц и примеров. Я просто попытаюсь написать, как это устроено, без уточнения по номенклатуре и прочих побочных фенечек. Есть 2 рабочих варианта, один более "нормализованный", другой менее. Буду описывать менее "нормализованный", он проще в реализации.

Итак, есть основная таблица справочника ЕИ. Зовется ed. В ней есть поля id_ed (PK), ed_code (varchar, not null), ed_koeff и id_ed_main (необязательная ссылка на основную ЕИ для дополнительных ЕИ). Уникальность по паре полей (ed_code,id_ed_main) . Соответственно,если в ed у записи id_ed_main is null - она основная ЕИ, у нее всегда ed_koeff=1. Все записи, кто на нее ссылается по id_ed_main - это дополнительные ЕИ для нее. Все сущности в системе, имеющие связь со справочником ЕИ, имеют обязательно связь с основной ЕИ и опциональную связь с одной из ее дополнительных ЕИ, если это надо (например, справочник номенклатуры, составы документов, рецепты). Соответственно, никто не мешает завести в качестве основных ЕИ и метр, и км, и пк, и нм. К ним можно наделать дополнительных ЕИ. Соответственно, записей с ed_code='мкм' может быть в таблице ed много, но у них обязательно разные id_ed_main (одно может быть NULL-ом; на самом деле в таблице ed реализован более строгий контроль признака основной ЕИ, так что обсуждать различия реализации уникальности индексов по необязательным полям в разных СУБД я здесь не намерен). По идее, если захочется изменить, например, микрон на мкм, то придется править кучу строк, что, строго говоря, не приветствуется (абстрагируясь от того, насколько часто это потребуется делать в интерфейсе конечному пользователю). Поэтому-то и имеется 2 основных варианта, в обоих уникальность по паре полей для дочерних ЕИ оставлена, но во втором варианте код заменен на еще одну ссылку. В первом все оставлено как есть, ибо еще вопрос, является ли метр одной и той же сущностью, если он является дочерней ЕИ для километра и для микрометра. Это не настолько очевидно, как кажется, достаточно вспомнить, что определения ЕИ в системе СИ (а есть и другие системы) менялись несколько раз, и в последней редакции скорость света в вакууме известна точно, потому что метр определяется по ней, а не наоборот. В любом случае, требуется дополнительный серверный код и определенный гуй, чтобы, грубо говоря, совсем уж откровенно "не налажаться" при заполнении справочника и чтобы была возможность подставить правильный коэффициент из связки мкм->см в связку см->мкм. Неметрические ЕИ реализуются очень просто. Заводится новая ЕИ, например, 'пуд'. К ней дополнительная 'золотник'. Для 'кг' заводится в качестве дополнительной 'пуд'. А для 'пуд' заводится дополнительная ЕИ 'кг' (замечу, что из-за округления произведение коэффициентов может не дать точно 1, но это-то и правильно, потому что преобразования из пуда в килограммы и наоборот, вообще говоря, при наличии округления не взаимно обратны). Конвертация из одной ЕИ в другую запрещено, если они не связаны прямым отношением (то есть, одна должна быть основной, вторая - дополнительной для нее). Конвертация между двумя дополнительными ЕИ (одной основной ЕИ) есть просто умножение на отношение коэффициентов (есть еще модификация схемы с дополнительной прямой связкой двух дополнительных ЕИ, но принципиально она ничего не меняет). Замечу, что, например, кубометр может быть легко дополнительной ЕИ для тонны с уточнением по номенклатуре. Итого, имеем отказ от классов ЕИ (роль класса ЕИ играет сама основная ЕИ), возможность произвольной конвертации с максимальной точностью, но есть и недостатки (я их все и так знаю, так как схема работает много лет, они все "на поверхности", некоторые я привел, еще, например, такая практическая "беда", что напрямую ОКЕИ к такой "денормализованной" схеме "в лоб" не прикрутить, придется, правда несильно, поизвращаться с кодом ЕИ, потому что в такой схеме неясно, чьим атрибутом является номер ЕИ по ОКЕИ). Предложенная схема не ставит задачу запретить указание более одной кратной или дольной приставки, поэтому если юзер захочет ввести кибикилограмм - он это сделает.

guest_20040621Последний вопрос: почему Вы назвали это справочником?
Если честно, не очень понял этот вопрос. Есть какой-то критерий, что является справочником, а что нет, и то, что я написал, не удовлетворяет ему? Или это вопрос по поводу пользовательского интерфейса всей этой байды?

guest_20040621Вы сами описали Ваши ошибки, так что подробно на них останавливаться, видимо, не нужно. Замечу только, что попытки увязать ЕИ с ОКЕИ бессмысленны.
Скорее, это не ошибки, это намеренные упущения для достижения других, более важных в моем случае, целей. А то, что попытки увязать ЕИ с ОКЕИ бессмысленны - соглашусь, благо, пока мне удается отбиться от этого желания многих юзеров.