MAP в качестве datasource формы

[ZVV]

Цитата:

Сообщение от IKA

Смысл - скрыть от пользователя и программиста из какой таблицы берутся поля и в какую таблицу сохраняются и сделать универсальный способ работы с этими данными в системе, чтобы программисту постоянно не писать запросы, проверяющие есть ли данные в одной таблице, и если ли нету, искать в другой таблице, то же с update . Хочу всю логику инкапсулировать в мапе. Можно было бы многое сделать то же с помощью временных таблиц, возможно, но мэп позволит точней работать с полями + универсальность вызовов не зависимо от того с буфером из какой таблицы работаешь.
Какие за/против?

Да я примерно понимаю для чего обычно используют мэпы...
Но это не совсем ваш случай, мне кажется... Обычно в map-е объединяют однотипные таблицы из разных модулей (типа CustVendTrans). Вы же пытаетесь объединить 2 таблицы одной и той же сущности, которые ещё и каким-то крайне странным образом зависимы ("То есть не от конкретного знаечния вендора зависит, а от того, есть ли в T2 для него записи.")
- А если нет и там, и там?
- А если в Т2 нет, но я хочу добавить?
- ...
Мне кажется Вы пытаетесь лечить последствия неправильного дизайна. Просто забыли вовремя в нужном месте добавить поле "типа записи".
И лечить лучше болезнь, если есть возможность, а не симптом...

[IKA]

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

[denny]

Цитата:

Сообщение от IKA

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

Комментарий по дизайну: вот потом по закону подлости обязательно захочется видеть базовые, неизмененные значения ПЛЮС кастомные (например, для сравнения тех и других). И Map придется выбросить.
Такие поля называются подстановкой. Хотите программисту работу облегчить - напишите в базовой таблице edit-методы, работающие с подстановкой (1 вариант), скрывайте/показывайте контролы, проверяя методом isCustom правомерность того или иного действия (2 вариант)