Здраствуйте. Ув. гуру помогите новичку в ado.net и c#
Есть датасет с несколькими таблицами, запросы к некоторым таблицам БД включают джойны, объяснюсь - мне в некоторых ситуациях нет смысла тянуть на клиента здоровенные таблицы с связывать их между собой отношениями, когда можно просто сджойнить нужную мне только для чтения инфу. Суть проблемы в том как проще и можно ли узнать оригинальное имя таблицы в БД для конкретного столбца?
Например:


Хотелось бы получать для поля ID, NAME, DESCRIPTION в результате строку OFFERING, а для STAFF_CREATED и STAFF_MODIFIED строку STAFF.
Прошу строго не судить, перехожу на C# с Delphi, там это очень просто реализовывалось средствами библиотек доступа к БД. БД использую огнептицу

ок, знаю что C# программисты не любят упоминания о делфи и ни в коем разе не хочу развести холивар, лишь покажу чего хотелось бы иметь. В Delphi я мог вызвать метод что-то вроде этого


и получить заветную строку STAFF
Именно это меня интересует, можно ли средствами языка узнать оригинальное название таблицы для конкретного поля.

up
Народ, за все время так и не понял возможно ли узнать сабж? Сейчас пользуюсь DataColumn.ExtendedProperties, т.е. заполняю вручную по всем полям...но это не по фен шую, да и муторно. Может все же есть волшебный метод который возвращает имя сджойненной таблички?

Приложение построенно по модульной архитектуре т.е. динамически подгружаются dll в которых сожержатся грубо говоря справочники и их редакторы. Заранее какие модули будут стоять у клиента не известно, посему по условию задачи все модули не зависимы друг от друга, ссылок друг на друга в студии быть не должно. Между собой модули взаимодействуют посредством "регистрации" справочников и редакторов. Фактически это выглядит как Dictionary<string, DictionaryFormType> и Dictionary<string, EditorFormType>, в качестве ключа выступает имя таблицы для которой предназначен справочник/редактор.
Исходя из примера из первого поста в идеале при открытии справочника система должна проверить наличие зарегестрированного редактора для каждого из полей сджойненной таблицы, в нашем случае STAFF_CREATED, STAFF_MODIFIED, понять что необходим справочник STAFF, оформить поля в справочники в стиле гиперссылок т.е. при нажатии на любое из значений узнаем какой необходим для редактирования справочник поля редактор, создаем его, передаем ему ID и показываем, если редактор не зарегестрирован то поле "ридонли". Далее та же песня с синхронизацией данных, ведь все поля не связанны отношениями таблиц, они ведь в разных модулях и получены джойном, а таскать ту же таблицу сотрудников в каждый модуль не гут. Зная имя редактируемой таблицы написать процедуру пробегающую по другим таблицам и проверяющую их на необходимость синхронизации не проблема.
Прототип приложения был написан на делфи, но по некоторым корпоративным причинам решено было мигрировать на C#. Там эта схема работала просто как часы, как дети радовались когда все модули были независимы друг от друга, когда на основе информации о "регистрациях" знали что чем редактируется, редакторы подтягивались из других модулей, какие права проверять, какие таблицы синхронизировать и тд...вообщем подход был опробован и я остался доволен, но столкнулся вот с такой проблемой в С#.
Критика приветствуется, но переделывать что либо уже врятли будем, если не получится все же получать автоматом, то посажу джуниора заполнять ExtendedProperties

skyANAThor234, а на картинке собственно что? Модуль - это форма, модуль - это закладка на форме, или нечто меньшее?
Почему модуль не инкапсулирует в себе работу с данными?
Если я захочу написать модуль, что работает не с БД а с сервисом каким-нить, то как его регистрировать?
На данный момент модуль в отношении этого проекта это Dll с набором справочников и редакторов. Справочники двух типов: мастер-деталь создается в системе как вкладка с выбором оного на риббон панели (на рис. 1) и собственно как справочник небольщих сущностей без детальных вкладок таких как например "тип контакта", создаются в виде отдельных окон с вызовом из меню "спровочники" (на рис. 2). Ну и собственно редакторы (на рис. 3), в основном вызываются по клику на ссылку сущности, либо при редактировании текущей записи.
На данный момент в задачах только работа с БД, бюджет маленький, времени нет, людей почти нет, в общем все как всегда буду решать проблемы по мере поступления, сейчас в задачах только БД.
Есть базовый класс справочника и редактора, остальные наследуются от них

skyANAThor234, мне кажется, что если Вы инкапсулируете работу с данными модуля внутри самого модуля, то Вы решите и текущую проблему и ряд будущих :)
так, работа с данными и происходит внутри модуля. "ядро" по сути только лишь создает классы, кнопочки, менюшки. Самой системе вообще пофиг где и как модуль получает данные

skyANAThor234, такс... Тогда вернёмся к вопросу: зачем надо знать оригинальное имя таблицы?
Грубо говоря разработчик модуля внутри него ручками прописал запрос на выборку данных, добавление, изменение и удаление и всё. Какие таблицы участвуют в этих операциях интересны только внутри модуля. Снаружи это должно быть прозрачно.
Во-первых спасибо, что пытаетесь помочь разобраться.
Во-вторых - да, все верно, но если справочник модуля наследует базовый класс работы с БД, то будь добр пользоваться правилами системы.
Давайте взглянем на скрин: на нем видно как открыт справочник "Контакты", в нем присутствует поле "Контрагент" к которому привязан контакт (все связи осуществлены на уровне БД как пологается), если же мы кликнем на ссылку контрагента, то откроется редактор конкретного контрагента, класс редактора естественно находится в совершенно другом модуле. Насчет остального повторюсь: при создании справочника система пробегает по полям узнавая есть ли редактор для этой сущности, в нашем случае для сущности "Контрагент", если есть делает "гиперссылковое поле" если нет - обычное как например поле ФИО. Далее при клике на гиперссылку опять же получаем по оригинальному названию таблицы CONTRAGENT тип редактора ContragentEditor из общего реестра редакторов. Таблица контактов имеет только ключ контрагента:

авторхреновый стиль, завтра вам нужно будет выводить 2 поля для контрагента, побежите менять запросы? не проще ли работать на уровне сущностей, а не на уровне Sql запросов
Не пойму в чем проблема? Да практически в каждой таблице есть два поля из одной и той же таблицы - STAFF, а именно ID_STAFF_CREATED и ID_STAFF_MODIFIED, узнаем имя таблицы по полю, в обоих случаях это STAFF и подсовываем ID из нужного поля, открываем редактор с нужным сотрудником. А вот из какого поля брать ID т.е. у STAFF_CREATED это ID_STAFF_CREATED, у STAFF_MODIFIED это ID_STAFF_MODIFIED уже указываю в ExtendedProperties и это удобно

Согласен, убедительный довод.
Тогда может посоветуете какую схему работы с данными лучше применить в данной ситуации? Учитывая несколько пунктов:
1. Не хочу ORM
2. Не должно быть "избыточных" таблиц, т.е. например таблицы сотрудников в каждом модуле лишь для отображения кто создал/редактировал запись (я про связи таблиц)
3. Независимость модулей друг от друга
4. В идеале хотелось бы иметь хоть некоторую синхронизацию данных между модулями. Изменили имя сотруднику - обновить таблицы (возможно в оффлайне) где присутствуют поля из данной таблицы.
Пока придумал только такой костыль, буду благодарен за варианты

_nautilus_Thor234Приложение построенно по модульной архитектуре т.е. динамически подгружаются dll в которых сожержатся грубо говоря справочники и их редакторы.
Тут имеется в виду, что например есть комплекс ПО "Больница", на одном клиентском ПК установлен модуль "Регистратура", на другом - "Лаборатория" и при этом каждый из модулей имеет собственный набор справочников и прочих форм? Если так, то почему не поставлять 1 единый модуль на все клиентские ПК, а набор элементов, которые пользователь может увидеть/отредактировать и т.д. формировать на основе предварительно раздаваемых прав доступа по ролям?
Немного не так. Модуль обычно содержит одну основную сущность и несколько вспомогательных для нее, например модуль "Контакты" содержит собственно справочник/редактор/отчеты контактов, "типы контактов", "роли в принятии решений", "источники контактов" и т.д. Далее готовое решение собирается уже из этих модулей под нужды клиента. Тащить весь разнообразный парк модулей смысла нет ибо автодиллеру нафиг не упал справочник лекарственных средств, да и поддерживать такого монстра нет желания