есть форма с редактированием одной таблицы Ship
доступ к данным в проекте организован через DataSet
у нее есть две связанные таблицы
Flag
ShipType

как идеалогически правильно организовать dataSource для DataGridView?
сейчас у меня используется 4 BindingSource
1. Ship - основная таблица, где редактируются записи
2. Flag (flag.id = ship.flag_id)
3. ShipType (ShipType.id = ship.ShipType_ID)
4. vg_Ship - view c сервера для отображения в гриде полей с разных таблиц. (vg.id = ship.id)

Для редактирования таблицы используется источник Ship
В датасете таблица Ship связана с vg_Ship (vg.id = ship.id)

Перемещаемся по vg_Ship, идет перемещение по Ship, в текстбоксах отражаются корректные данные.
Пробовал редактировать vg_Ship, стандартно датасет отказывается сохранять данные (источник - view c join)

Вопросы
1. Сейчас после изменения в Ship надо
1a. либо самому прописать vg_Ship.Flag_Name и vg_Ship.ShipType_Name
1b. либо обновить с сервера одну запись в vg_Ship (сейчас я поступаю именно так)
Вопрос. как идеалогически правильно делается источник данных для грида, с учетом того, что в нем должны быть данные из нескольких таблиц?

2. Сейчас таблицы Flag и ShipType скачиваются при загрузке формы целиком (поля id, code, name, obsolete). В конкретном примере это неважно, но на других формах будут ссылки на другие таблицы с десятками тысяч записей. Тащить их целиком, хотя в записях в гриде будут ссылки только на сотню, не хочется. И так же не хочется скачивать в таблицы Flag и ShipType по одной записи, когда при перемещении в гриде будет обращение к отсутствующим связанным записям
Вопрос - как идеалогически правильнее организовать скачивание записей Flag и ShipType (при редактировании и выборе значения для соответствующих полей все равно придется скачивать почти все записи (за исключением архивных))

[attachment 29862 2018-08-1014_31_18-PortRunning-MicrosoftVisualStudio.png]



Исправлено 2 раз(а). Последнее : AlexSSS, 10.08.18 15:05

Отвечу совсем не в жилу)
Просто есть 25 мин)
Я плохо знаю возможности winForm.
Как бы решил на asp.net (веб)
Я бы все решал на EF.
1.
Грид оставил как у тебя есть - от вью.
По каждому перемещению, заполнял из БД верхнюю часть, при этом комбо заполнил бы только 1 раз, и в конкретных записях, ставил бы правильные данные.
ТОгда тебе надо сохранить только объект Ship (верхний на форме)

AlexSSS
либо самому прописать vg_Ship.Flag_Name и vg_Ship.ShipType_Name

Наверное так.
2.
Ну там где 10.000 записей, вряд ли стоит использовать комбо.
Типично, открываешь справочник, выбираешь значение, заполняешь id

Кстати, достаточно типовые задачи для веба.
Опять тебя в сторону толкаю)

Аспид
Ну там где 10.000 записей, вряд ли стоит использовать комбо.

обижаешь ;)
это мой класс (несколько текстбоксов (в зависимости от источника) + кнопка), поиск по коду/наименованию или выбор из списка (грида)
[attachment 29864 2018-08-1016_27_33-frmShip.png]

поиск
[attachment 29865 2018-08-1016_40_01-frmShip.png]



Исправлено 3 раз(а). Последнее : AlexSSS, 10.08.18 16:41

AlexSSS
как идеалогически правильно организовать dataSource для DataGridView?

Отдельно от source редактирования

AlexSSS
сейчас у меня используется 4 BindingSource

А Ship тебе зачем, если визуализируешь vg_Ship? А так то нет проблем разные bs даже с разными ds использовать (но тогда вручную управлять CurrencyManager-ом, т.е. "текущей записью").

AlexSSS
Для редактирования таблицы используется источник Ship

Мне кажется это слегка избыточно - хватит и таблицы vg_Ship

AlexSSS
Пробовал редактировать vg_Ship, стандартно датасет отказывается сохранять данные (источник - view c join)

Ну так настроить надо те самые адаптеры - вручную Ins/Upd/Del команды прописать (на таблицу ship), а то и вызов ХП их оборачивающих (если это мсскл и "идеологи" ратующие за "всё через хп" тебя убеждают).
Оракл, кстати, умеет для некоторых представлений с join автоматом обновлять базовую таблицу (там понятие key-preserved table фигурирует - если во вью гарантировано можно для каждой записи найти "исходную запись" в основной таблице, то поля взятые из этой таблицы можно обновлять). Для "сложных" случаев в оракле применяют instead of триггера - с их помощью практически любое вью можно редактировать как таблицу. Не знаю можно ли это в твоей СУБД реализовать...

AlexSSS
1. Сейчас после изменения в Ship надо
1a. либо самому прописать vg_Ship.Flag_Name и vg_Ship.ShipType_Name
1b. либо обновить с сервера одну запись в vg_Ship (сейчас я поступаю именно так)

И так и этак можно делать.
Минусы первого (ну кроме того что надо ручками пару строк кода написать) - изменения в других полях (те что не изменялись) не будут видны (если это НАДО - судя по желанию рефрешить запись перед началом редактирования, то и после оного явно захочешь "свежачок" подтянуть).
Минус второго - "лишний" запрос.

AlexSSS
Вопрос. как идеалогически правильно делается источник данных для грида, с учетом того, что в нем должны быть данные из нескольких таблиц?

Так и делается - View данных (не обязательно вью в СУБД - в том же адаптере для таблицы датасета можно запрос прописать) вынимающее все нужные элементы в удобный для отображения вид.

AlexSSS
2. Сейчас таблицы Flag и ShipType скачиваются при загрузке формы целиком (поля id, code, name, obsolete). В конкретном примере это неважно, но на других формах будут ссылки на другие таблицы с десятками тысяч записей. Тащить их целиком, хотя в записях в гриде будут ссылки только на сотню, не хочется. И так же не хочется скачивать в таблицы Flag и ShipType по одной записи, когда при перемещении в гриде будет обращение к отсутствующим связанным записям

А не надо показывать данные из этих таблиц (хватит данных во вью - там то уже "названия" подтянуты). Они нужны лишь для редактирования, и там то вполне можно делать микро-запросы, по введенной части наименования, или шифру, если юзера могут им манипулировать.

AlexSSS
при редактировании и выборе значения для соответствующих полей все равно придется скачивать почти все записи

Не обязательно. Можно только подходящие куски после ввода скажем минимально 3 символов брать, или как в фоксе - таймер и если остановились при вводе более чем на 5 секунд - тянуть по введенному шаблону. Ладно там какие страны/типы по 10-200 записей, но там где 10к крайне нехорошо все эти 10к вынимать... Ну разве что они (справочники) реально супер-статичные, и их можно спокойно закэшировать хоть на месяц в программе (ну и юзеру не жалко сожранной под это дело памяти).