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