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

[IKA]

Цитата:

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

Вообще говоря, делать такие проверки (значения поля с константой) в коде - моветон. Я бы рекомендовал следующее:

• создать свой Enum, который будет отвечать за выбор этих двух таблиц. Что-то типа MyVendType::T1 и MyVendType::T2 (с осмысленными названиями, разумеется);
• добавить в таблицу T1 поле с типом MyVendType и единовременно (job-ом) заполнить это поле на основе поля vendAccount в соответствии с Вашей логикой. При этом не забыть модифицировать код, выполняемый при добавлении записей в таблицу (инициализация поля MyVendType);
• добавить к таблице T1 два отношения (relation): одно с самой собой, а второе - с таблицей T2. Эти отношения должны иметь тип связи "поле фиксировано" и строиться на поле MyVendType. (В первом случае связь будет MyVendType == 0, во втором - MyVendType == 1);
• добавить в упомянутые отношения связи по первичным ключам (однозначно идентифицирующие запись);
• на форме создать три источника данных: родительский T1 и два подчиненных: T1 и T2, и привязать их к разным TabPage, как советовал ZVV выше.

Получилось на первый взгляд громоздко, но зато: 1) не навешиваются доп. действия на linkActive (может я не прав, но имхо, нагружать этот метод - это совсем крайний случай), и 2) используется стандартный механизм динамического выбора источника данных (если это можно так назвать).

PS: если мое описание покажется сумбурным, посмотрите для примера отношения на таблице LedgerJournalTrans

Спасибо, но логика скорей там такая, что, если данные в T2 есть, то показывать данные для вендора из нее, если нет, то в тех же полях показывать данные из T1.
То есть не от конкретного знаечния вендора зависит, а от того, есть ли в T2 для него записи.

[ZVV]

Цитата:

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

Спасибо, но логика скорей там такая, что, если данные в T2 есть, то показывать данные для вендора из нее, если нет, то в тех же полях показывать данные из T1.
То есть не от конкретного знаечния вендора зависит, а от того, есть ли в T2 для него записи.

А чем вам тогда мэп поможет - не совсем понятно?

[IKA]

Цитата:

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

А чем вам тогда мэп поможет - не совсем понятно?

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

[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 вариант)