Кот МатроскинХБЯ делаю (увы) преобразование многих "горизонтальных" таблиц где каждое такое поле - это отдельная колонка в одну вертикальную, тот самый 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. Тогда на первом скрине будет размещен один элемент со своими значениями в поп-листе, на другом скрине - другой элемент со своими значениями.
Менеджер говорит - название элемента одно, свалить все значения в кучу, показывать все их на обоих поп-листах и пусть пользователь сам разбирается, на каком экране какие значения присваивать. Вот это я называют "му**к", но объяснить не удаётся, потому что он индус и заботится только о прикрытии своей ж.

решение менеджера не такое плохое, оно сводит риски именно переноса (т.е. того, за что Вы с ним отвечаете) к минимуму. Ну создает проблемы пользователям, ну что делать :)

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

Ennor TiegaelХБпропущено...
Вот за это я и ненавижу таких недоумков-менеджеров.
Ему насрать что получиться приложение, с которым невозможно работать.
Он не понимает, что мы работаем - для пользователей, а не для того чтобы отчитаться перед начальством. И вы, кстати, с ним тоже.
Escalate? Должен же где-то быть представитель пользователя, который поймет, что такие семь шапок из овцы ему не нужны.
Блин,как у вас все просто, как по писаному.
Представьте, позиция пользователя - "мне вполне нравится то уёбище приложение с которым я работаю 20 лет и делайте что хотите но так чтобы мне не пришлось тратить время на переучивание".
Вот и получается, что единственный в этой цепочке кому не пох - это азм несчастный, потому что я ненавижу когда мне стыдно за приложения, которые я сделал.

Mr.FontaineХБПредставьте, позиция пользователя - "мне вполне нравится то уёбище приложение с которым я работаю 20 лет и делайте что хотите но так чтобы мне не пришлось тратить время на переучивание".
И именно по этой причине на первом скрине должны быть свои названия, на втором - свои. Ибо если поставить все семь названий в один список, то пользователю придётся переучиваться - уметь мысленно отсекать не используемые для данного скрина пункты.
Это не является аргументом в споре с менеджером?
Наконец-то, спасибо за понимание. Нет, не является, он заявляет: не надо переусложнять, у нас мало времени.

Но в общем, никакого спора нет. Единственное его положительное качество - он в принципе понимает что он ничего не понимает, и если разраб упёрся - значит, поспорить для выпендрёжа а потом пусть разраб делает как знает. А не сделает вовремя (а "вовремя" берётся с потолка) - вот тогда все свалить на разраба.

Mr.FontaineХБпропущено...

"котлеты с рисом, тефтели с картошкой. Менять нельзя!"
Структуру таблиц менять нельзя.
Честно говоря не понял какую струтуру таблиц менять нельзя. Ты же сам писал, что эначения из AUX_COMPRESSOR_COND в переделываемой версии хранились в коде программы безо всяких таблицы element_values. Ты же сам добавляешь эту таблицу. Почему ты изменить её не можешь? Не понимаю.

Я не добавляю эту таблицу. Она есть в БД, куда я мигрирую MS ACCESS. Я же писал - в Access все данные хранятся в большом количестве горизонтальных таблиц, одна колонка - один элемент. Т.е. AUX_COMPRESSOR_COND это колонка в одной из таблиц.
В target database используется EAV, т.е. таблиц только 3 - ELEMENTS (element_id, element_name), ELEMENT_VALUES(element_id, value_id, value) и сводная UNIT_INFO(unit_id, element_id, value_id) где unit_id - идентификатор устройства (скажем, паровоза) которому принадлежит данный набор элементов.
Вот структуру этих трех таблиц менять нельзя.

MasterZivХБ,
кроме того у тебя не различается книга и её экземпляр.

жанр - атрибут книги.
состояние - экземпляра.
кроме того, прочитай для разнообразия посты. С книгами - упрощенный пример из головы.