Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > СУБД, общие вопросы > Организация данных которые имеют разные единицы из

Автор: dimqw31 29.10.2010, 13:16

Уважаемые форумчане, встал новый вопрос по схеме данных.. У меня есть данные которые имеют разные единицы измерения. Допустим в штуках, граммах, мешках и т.д. В таблице есть колонка с именем параметра и колонка с его количеством. В колонке с количеством как раз и будут разные ед. измерения. Это усложнит алгоритм поиска информации в БД. Может есть какие-то стандартные методы для более эффективной реализации схемы данных. Или предается уже пользоваться логикой приложения, чтобы переводить все данные для формирования запроса..(делать конвертер), или сделать дополнительную колонку в табл. ЕД. ИЗМЕРЕНИЯ (тогда как тогда запрос составить?).... Допустим мне в запросе надо найти гвозди и шурупы в определенном количестве.. Я задаю значение 2 (но в одном случаи полается два мешка, а в другом два ящика). Как лучше реализовать схему данных и запросы..? гвозди - в шт, в килограммах, в мешках, в коробках шурупы - в шт, в килограммах, в мешках, в коробках

Автор: Akina 29.10.2010, 13:30

Таблица-словарь единиц измерения и таблица коэффициентов перевода для совместимых единиц измерения.

Автор: Frees 29.10.2010, 13:31

Цитата(dimqw31 @  29.10.2010,  16:16 ) В таблице есть колонка с именем параметра и колонка с его количеством добавь ссылку на ед. измерения. Цитата(dimqw31 @  29.10.2010,  16:16 ) Допустим мне в запросе надо найти гвозди и шурупы в определенном количестве.. указывать пири поиске кол-во и ед. измерения. или нужен се*с с конвертацией коробок в мешки? Добавлено через 53 секунды Цитата(Akina @  29.10.2010,  16:30 )  коэффициентов перевода для совместимых единиц измерения. только для каждой позиции свои соотношения

Автор: Deniz 29.10.2010, 14:38

Вообще-то есть общепринятые единицы измерения. Цитата(Frees @  29.10.2010,  15:31 ) только для каждой позиции свои соотношения дополню: и судя по всему отношения эти будут в извращенной форме, камасутра отдыхает. Особенно интересно будет посмотреть изменения в поставках, в зависимости от времени (сегодня в ящике 10кг а завтра 15кг)

Автор: Akina 29.10.2010, 14:46

Цитата(Deniz @  29.10.2010,  15:38 )  интересно будет посмотреть изменения в поставках, в зависимости от времени (сегодня в ящике 10кг а завтра 15кг)  Ничего сложного.  Id 1 КороткоеИмя ящик ПолноеИмя ящик 15 кг Id 2 КороткоеИмя ящик ПолноеИмя ящик 10 кг Id 3 КороткоеИмя кг ПолноеИмя килограмм ---------------- Id 1 Id1 1 Id2 3 K 15 Id 2 Id1 2 Id2 3 K 10 Id 3 Id1 3 Id2 1 K 0,066666666666666666666666666666667 Id 4 Id1 3 Id2 2 K 0,1

Автор: _Y_ 1.11.2010, 00:07

Что-то стойкое у меня подозрение, что данные должны быть приведены к одним и тем же единицам измерения до занесения в БД. Это правило было еще до существования БД  и отностилость к таблицам на бумаге. Иначе путаница гарантирована. Я бы приводил к весу, как к наиболее универсальному из перечисленных (например, к углеродным единицам ). Другая же таблица может содержать единицы хранения и их соотношение с весом. Ну а интерфейс должен предлагать юзеру возможность задавать вопросы и получать ответы хоть в 15-килограммовых рюмках, хоть в 26-каратных ящиках. Лишь бы такие величины во второй таблице были.

Автор: Deniz 1.11.2010, 08:20

Цитата(Akina @  29.10.2010,  16:46 ) Ничего сложного. Сложного может и не много, пока, но сразу видны грабли: Цитата(Akina @  29.10.2010,  16:46 ) Id 3 Id1 3 Id2 1 K 0,066666666666666666666666666666667 это точно где-нибудь выстрелит (имеется ввиду значение К). Все нужно приводить к единым системам исчисления. Про ящики: можно сделать дополнительное поле/поля в приходе Тара/Упаковка/ и т.д.

Автор: Akina 1.11.2010, 08:45

Цитата(_Y_ @  1.11.2010,  01:07 ) Что-то стойкое у меня подозрение, что данные должны быть приведены к одним и тем же единицам измерения до занесения в БД. Это правило было еще до существования БД  и отностилость к таблицам на бумаге. Иначе путаница гарантирована. У меня есть иное стойкое убеждение - в базе данных данные хранятся строго в той форме, в какой они присутствуют в первичном документе. Пожалуйста, при вводе выполняй приведение и клади приведённые данные в эту же или другую таблицу, и используй их, и не исходные - но исходник изволь сохранить.

Автор: _Y_ 2.11.2010, 12:17

Цитата(Akina @  1.11.2010,  08:45 ) но исходник изволь сохранить.   А я согласная. Но только в папочке в виде исходной бумажки или ее ксерокопии.   Данные, введенные руками (а именно это, как понимаю, и предполагается в данной задаче), никак не являются исходным документом.  Потому как именно стадия ручного ввода и есть основной источник ошибок (слаб человек  )

Автор: Akina 2.11.2010, 12:25

Цитата(_Y_ @  2.11.2010,  13:17 ) в папочке в виде исходной бумажки или ее ксерокопии. Тебя надо пару раз послать в архив на поиск подшитой в папочку бумажки десятилетней давности. Для корректировки мировоззрения. Цитата(_Y_ @  2.11.2010,  13:17 ) Данные, введенные руками (а именно это, как понимаю, и предполагается в данной задаче), никак не являются исходным документом. Эти данные должны быть точной копией исходного документа. В оптимуме - даже с сохранением внешнего вида. Цитата(_Y_ @  2.11.2010,  13:17 ) именно стадия ручного ввода и есть основной источник ошибок  Именно блок входного контроля данных и есть основной головняк любого программиста подобных систем. PS. Сколько времени я убил на то, чтобы заставить разработчика сделать входной контроль кадровой программы и исключить возможность приёма на работу трёхмесячных младенцев и 130-летних стариков...

Автор: Zloxa 2.11.2010, 13:24

Цитата(Akina @  2.11.2010,  12:25 ) даже с сохранением внешнего вида.    И даже с сохранением ошибок ввода оператора контрагента, ну и всяких там погрешностей, вызванными различиями алгоритмов округления.

Автор: Akina 2.11.2010, 13:42

Цитата(Zloxa @  2.11.2010,  14:24 ) И даже с сохранением ошибок ввода оператора контрагента Всенепременно! Исходный документ в бумаге - это догма. И "что написано пером"... оператор НЕ ИМЕЕТ ПРАВА вносить изменения в исходные данные - даже если неверность этих данных очевидна и ежу. Он имеет право отклонить документ или обратить внимание ответственного на ошибку - но не более.

Автор: _Y_ 2.11.2010, 20:53

Цитата(Akina @  2.11.2010,  12:25 ) ...данные должны быть точной копией исходного документа. В оптимуме - даже с сохранением внешнего вида.  Здесь я тоже согласная. И лучше в виде скана. В целом же спорить не буду - если важна именно архивация данных - будь по-творему   Цитата(Akina @  2.11.2010,  12:25 ) Цитата(_Y_ @  2.11.2010,  13:17 ) Тебя надо пару раз послать в архив на поиск подшитой в папочку бумажки десятилетней давности. Для корректировки мировоззрения. ОФФ №1. Архивариус сказал бы так: Тебя надо пару раз к компьютерщикам послать на поиск информации десятилетней давности. Для корректировки мировоззрения.   ОФФ №2. Решил я недавно раздобыть свою трудовую книжку. Лежала она там, куда лет 15 не ступала нога этого конкретного человека. Кадровики послали в архив. Захожу. Комната - пенал 10х5х2 метров (причем 5 это высота). Стелажи обвалившиеся. Старушенция в очках +25. Излагаю кратко проблему. Минуту пыхтя лезет вверх по лестнице. Еще пол-минуты спускается уже с трудовой. Еще секунд 20 на расписаться в откуда-то извлеченном формуляре. И не поверишь - книжку получил именно свою, а не чужую.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)