|
skyANAХБпропущено...
И опять я плохо объясняю...значит, вопрос действительно не простой.
давайте попробую в последний раз по-другому.
Речь идет о группировке допустимых значений поля по признаку однородности. Т.е. само название поля должно быть всего лишь названием группы допустимых значений. А эти самые значения должны группироваться по признаку...по какому?..по как бы "однородности". Типа, цвет, вес, цена, размер и т.д. Т.е. есть группа значений описывающих жанр. Тогда и поле должно называться "жанр книги".
Другая группа описывает состояние изношенности. Тогда нужно другое поле, названное "состояние". А когда одно название "характеристика книги" использует две независимых группы значений, то это плохо. Плохо, хотя и вроде бы не вызывает data inconsistency. Я чувствую что крайним проявлением такого подхода является печально известная структура EAV. Когда одно поле под названием скажем "товар" имеет неограниченное количество неструктурированых допустимых значений. Структура правильная с точки зрения реляционности, но...плохая.
Это вопрос о том, как, имея произвольный набор аттрибутов объекта, выделить из них "сущности", т.е. группы значений которые должны храниться _в отдельных_ таблицах. Т.е. описывая человека аттрибутами "Иванов", "слесарь", "алкоголик" мы должны использовать 3 таблицы - "Фамилия", "профессия", "хобби", а не одну - "аттрибуты человека". Это пример явных различий, а по какому принципу выявлять различия более тонкие?
А зачем? Отсутствие этих более тонких различий как-то мешает работе?
чтобы ответить, придется раскрывать специфику.
мигрирую приложение MS ACCESS в Oracle.
На одном скрине под названием General Description поле AUX_COMPRESSOR_COND со значениями из поп-листа Basic,Rewind,Qualified. Поле берут из таблицы General_Description
На другом скрине под названием Left Side Equipment поле AUX_COMPRESSOR_COND со значениями из поп-листа Good,Fair,Poor,Damaged. Поле берут из таблицы Left_Side_Equipment
Физически это один и тот же агрегат, какой-то вспомогательный компрессор.
Я делаю (увы) преобразование многих "горизонтальных" таблиц где каждое такое поле - это отдельная колонка в одну вертикальную, тот самый EAV, c колонками element_name и element_value_id. Почему - не обсуждается, потому что эта структура используется уже 20 лет в большом приложении.
Если я создам один элемент под названием AUX_COMPRESSOR_COND и для него в таблице element_values создам 7 допустимых значений - Basic,Rewind,Qualified,Good,Fair,Poor,Damaged, то как я смогу различить, какие из этих 7 значений должны появляться в поп-листе на первом скрине, а какие - на втором? Скрины мне тоже надо воспроизводить. В исходном MS ACCESS не мудрствуя лукаво поп-листы просто hardcoded. Т.е. нет вообще таблицы element_values.
Т.е. очевидно, что нужно создавать 2 разных элемента - напр, AUX_COMPRESSOR_COND со значениями Good,Fair,Poor,Damaged и AUX_COMPRESSOR_STATUS со значениями Basic,Rewind,Qualified. Тогда на первом скрине будет размещен один элемент со своими значениями в поп-листе, на другом скрине - другой элемент со своими значениями.
Менеджер говорит - название элемента одно, свалить все значения в кучу, показывать все их на обоих поп-листах и пусть пользователь сам разбирается, на каком экране какие значения присваивать. Вот это я называют "му**к", но объяснить не удаётся, потому что он индус и заботится только о прикрытии своей ж.
|
