Группы единиц измерений (меры длины, веса итп). Справочник. Удобно выделить особую группу "контейнеры" - в ней будут "упаковка", "ящик" итп.

Единицы измерения. Относятся к группам, в каждой группе отмечена единственная базовая единица, для прочих вводятся коэффициенты пересчета в базовую.

Межгрупповые коэффициенты пересчета. Вводит коэффициент пересчета между двумя ЕИ, атрибуты задают дополнительные условия. Смысл: для товара "ПЕПСИ 2Л" "1 штука" = "2 л", а "1 упаковка" = "6 штук". Для товара "ПИВО 0.5Л" другие записи с другими коэффициентами.

iscrafmНадо бы начать с изучения русского.
Согласен. Без этого вряд ли удастся понять и применить ответ: тугугл!

LSVА что Вас испугало ?
Не то чтобы испугало, просто... сомнительная мысль, назовем так. Сейчас прикинул, когда это может быть удобно, придумал единственный вариант - какой-нибудь онлайновый сервис вида "перевод из любых единиц в любые".

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

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

UrriПереназначение основной ЕИ после первого назначения в своем классе не допускается.
Можно и допустить. Принципиальных проблем нет.

Сергей Васкецов
Понял, и оказался прав :)

C моей точки зрения, то, о чем Вы говорите - вопрос интерфейса ввода, а не структуры данных. Когда я ввожу новую единицу, можно сделать интерфейс со вводом коэффициента к основной ЕИ, можно - со вводом коэффициента к выбираемой ЕИ и так далее, в данных это никак не отражается.

Роль основной ЕИ - в удобстве пересчета. Раз любая ЕИ имеет коэффициент к основной, а межклассовые коэффициенты также связывают основные ЕИ, значит задача "сложить два литра пива с шестью банками и выдать результат в пьяных сотрудниках" выполняется легко, просто, быстро, и что самое главное - надежно. И эта роль достаточно значима для того, чтобы "иметь ЕИ и только одну", имхо.

Конечно, можно усложнить эту структуру, и хранить как основные данные "коэффициенты пересчета в неосновные ЕИ". В результате по сути получится дерево, в котором ОЕИ - корень, но путь до корня может занять несколько шагов. Однако, при этом:

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

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

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

Итого - не вижу смысла так поступать. Лучше хранить с основной единицей, а интерфейс - как удобнее в конкретном случае.

Сергей Васкецов softwarerв данных это никак не отражается
Не соглашусь.
Согласен, стоило сказать "принципиально не отражается". Я сначала написал некий абзац, потом потер его, и потерял упоминание о технических аспектах.

Сергей Васкецовно в любом случае это требует 1) больше места
Да не сказал бы, различия малозначительны. Правда, это наверное зависит от формата хранения в конкретной СУБД. В моем случае -


Сергей ВаскецовНапример, если есть 2 ЕИ масштаба аттометра или фемтометра и между ними надо перевести значение, то придется сначала взаимно приводить их коэффициенты, а уж потом умножать или делить значение на полученный коэффициент.
И в чем проблема в этом случае?

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

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

Сергей ВаскецовКроме того, одна основная ЕИ дает погрешность при переводе между неметрическими ЕИ
Cогласен, в этом есть определенная проблема. Появляется желание внедрить еще понятие "семейства", что ли, и иметь основную ЕИ для каждого семейства.

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

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

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

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

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

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