Согласна, дизайн извращенный, смысл в том, что есть несколько компаний, и все они должны видеть одни и те же данные про вердора, пока не захотят их изменить в своей конкретной компании. то есть все остальные компании так и будут видеть общие данные, а эта конкретная компания будет видеть свои в соответствующих полях. Поэтому есть запись в shared таблице и есть таблица, которая держит записи переопределенные в конкретной компании, поля могут переопределяться не все, а только около 2 десятков.Записей shared около 300 000, переопределяться будут изредка, поэтому дублировать записи по всем компаниям не вариант. Было несколько дизайнов, по разным причинам остановились на этом, тк позволяет скрыть то, что за мэпом скрыто и можно будет менять нижележащую архитектуру, не меняя каждое место, где используется эта функциональность.
Буду рада, если получу ответ на изначальный вопрос относительно того, как лучше использовать мэп на форме - через link active и заполнение по нему значений или как-ниудь по-другому.
Ну и комментарии предложений по дизайну тоже, может, кто-то делал подобное и знает про достоинства/недостатки разных вариантов. Мэп хорош, как говорилось, тем, что инкапсулирует логику, поэтому девелопить проще, и количсество ошибок меньше и можно нижележащую архитектуру менять, не меняя код по всей системе, но с другой стороны, я думаю, что может оказать влияние на производительность, тк вместо запросов придется в части случаев комбинировать запрос и операции с мэпом(как , например. на форме в изначальном моем вопросе).
|