| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Master-Detail многие ко многим? [D6, IB6.x]
Felan © (2004-04-21 11:58:00)Есть база на InterBase 6.0 и программа-клиент пишущаяся на D6 c FIB+ 5.2.
На форме есть два pFIBDataSet'a у каждого из которых есть свой DataSource. Первый pFIBDataSet выбирает из таблицы коды значений, второй по этим кодам выбирает занчения из других таблиц и показывает их в DBGrid.
SQL запросы выполняются путем установки свойства Active у pFIBDataSet (которые и содержат эти запросы, естественно)
Запрос второго pFIBDataSet'a содержит параметры, которые берутся из первого DataSource. Т.е. у втрого pFIBDataSet'a в свойстве DataSource прописан первый DataSource.
Все это работает, но DBGrid (второй DataSource) содержит только одну строку значений, котороая соответствует первой (в общем случае активной) строке параметров из первого DataSource (типичное отношение Master-Detail).
Вопрос, как сделать так, что бы DBGrid отображались значения, соответствующии всем строкам кодов из первого DataSet.
Нутром чую, что таким способом это не получтися, но как? Понятно, что для этого надо делать объединение таблиц в запросе во втором pFIBDataSet, но, дело в том, что это противоречит принципиальному моменту: коды занчений должны поставляться независимо от значений (разными pFIBDataSet'ами), т.е. надо в одном запросе получать коды значений (строки из одной таблицы), а во втором отображать значения, в соответствии с этими кодами (т.е. это теже строки, только вместо цифр нормальные названия).
Какие есть пути решения проблемы? Желательно на примерах... ссылки на толковые статьи приветствуются.
Зарание спасибо!
Felan (2004-04-26 13:27:00) [1]stud, у тя аська есть? Стукнись 145621848, вдруг когда еще сгодимся друг другу :)
stud (2004-04-26 11:56:00) [2]хозяин - барин)))
Felan (2004-04-26 11:44:00) [3]
> в системных таблицах прописаны все связи между объектами
> базы данных, поэтому простой заменой база просто убивается.
> к тому же никто не запрещает играться с сист. таблицами.
> просто предостерегаю.
А! Я понял :) Давай не будем мешать в одно системные таблици, которые являются частью БД и для каждой свои, и служебную базу (которая isc4.gdb) :)
В системных таблицах не храняться пользователи, в них раниться только права, роли и прочее, что имеет отношение только к конкретной базе. А isc4.gdb хранит инфу по пользователям всего сервера... Строго говоря это и есть пользователи, а остально это разрешения :)
> а создание собственной таблицы пользователей имеет несколько
> плюсов. отпадает необходимость кромсать системные и хранить
> можно все что душе угодно и понятно для самого себя
Ну не знаю... зачем в таблице пользователей хранить "что угодно"? Она нато и таблица пользователей, что бы в ней пользователей хранить ;) Там вроде и так все понятно...
stud (2004-04-26 11:33:00) [4]
> К тому же, служебная база не имеет никакого отношения к
> базе. Она только сервак обслуживает, ты всегда можешь ее
> заменить на родную (немодифицированную).
в системных таблицах прописаны все связи между объектами базы данных, поэтому простой заменой база просто убивается. к тому же никто не запрещает играться с сист. таблицами. просто предостерегаю.
а создание собственной таблицы пользователей имеет несколько плюсов. отпадает необходимость кромсать системные и хранить можно все что душе угодно и понятно для самого себя
Felan (2004-04-26 11:15:00) [5]
> > Надо добавить генератор и триггер
> все это замечательно, только экспериментируя с системными
> таблицами грохнуть базу намертво труда не составит)))
> лучше создать свою таблицу с пользователями и использовать
> ее.
Ну не знаю, я сюда написал потому, что занаю, "как должен быть забит гвоздь, но не знаю какие для этого есть ГОТОВЫЕ инструменты и чем (чем лучше) это сделать". Зачем делать свою таблицу, когда она уже есть? Зачем тогда использовать вообще IB, можно свою СУБД написть? Не знаю, если все делать самому, то я бы и сделал... через n лет. Дело в том, что не хочу опять изобретать колесо! Меня, например, сильно разочаровало, что UID надо самому обслуживать (уж казалось бы, насколько элементарная и нужная рюшечка)... ибо это число, а его можно привезать к репозиторию, с которым могут работать FIB+. Если вести такую таблицу самому, то зачем тогда системная??? Их же синхронизировать надо будет... Разници нет никакой. К тому же, служебная база не имеет никакого отношения к базе. Она только сервак обслуживает, ты всегда можешь ее заменить на родную (немодифицированную).
> > Если честно, я не совсем понял, что ты имел ввиду. Что
> > значит, как фигурирует???
> например выдать все данные. относящиеся к конкретному пользователю:
> select * from table where table.userid=:id или что-то в
> этом роде
Эээ, ну это то понятно, что он в условиях занят... чет помоему мы не поняли тут друг друга...
stud (2004-04-26 10:56:00) [6]
> Надо добавить генератор и триггер
все это замечательно, только экспериментируя с системными таблицами грохнуть базу намертво труда не составит)))
лучше создать свою таблицу с пользователями и использовать ее.
> Если честно, я не совсем понял, что ты имел ввиду. Что значит,
> как фигурирует???
например выдать все данные. относящиеся к конкретному пользователю:
select * from table where table.userid=:id или что-то в этом роде
Felan (2004-04-26 10:40:00) [7]
> модифицировать системные таблицы можно, но вот нужно ли?)))
А как же? В 6.х поля UID и GID в служебной базе не используются :(
Надо добавить генератор и триггер... да плют седлать его notnull и уникальное ограничение добавить... Так что надо :(
Иначе как ID придется имя использовать.
> под идентификацией пользователя я имел ввиду каким образом
> его идентификатор фигурирует в твоих запросах. это понятно,
> что он в системных таблицах прописывается.
Ну, до того как разнесли мою идею с "каждому свою хп" он в запросах вообще не фигурировал :)
Теперь даже не знаю... видимо в зависимости от него будет происходить обращение к соответствующим просмотрам... хотя... может быть стоит и от просмотров отказаться?
Если честно, я не совсем понял, что ты имел ввиду. Что значит, как фигурирует???
stud (2004-04-23 16:43:00) [8]модифицировать системные таблицы можно, но вот нужно ли?)))
> Ну а какая разница? Ну будет айди параметром передаваться,
> фактически то же самое, каждому свой код.
а разница в том, что такая процедура будет универсальной, и будет работать с любым пользователем, и не нужно создавать ненужных процедур.
под идентификацией пользователя я имел ввиду каким образом его идентификатор фигурирует в твоих запросах. это понятно, что он в системных таблицах прописывается.
Felan (2004-04-23 16:34:00) [9]И еще, есть ли какой нибудь способ обращаться к таблицам служебной базе данных через рабочую, если в свойствах соединения указа служебная (когда в IBExpert регистришь базу, там есть пункт такой), или ей обязательно отдельное соединение надо?
Felan (2004-04-23 16:28:00) [10]
> Крайне нежелательный подход. Т.к. связан с постоянным изменением метаданных.
А что такого плохого в изменении ХП?
> У каждого п-ля, если надо, д.б. своя запись или набор записей
> в общей таблице...
Не совсем понял, что ты тут имел ввиду? Хочешь сказать ,что надо добавить каждой записе еще и ид пользователя???
> а каким образом пользователь идентифицирутся? где его идентификатор фигурирует?
Ну как каким? Вроде это на уровне СУБД происходит :) Есть же системные таблицы, где права прописаны, и служебная база данных, в которой пользователи сервера лежат... вот ее чуток модифицировать и айди там есть, только в 6.0 не используется и его руками вести надо... (возможно лучше будет в базе аналог таблици сделать, а при обращении в триггере обновлять?..)
Кстати, то Олл: А стоит ли вообще связываться с системными таблицами? Я имею ввиду их модификацию, понятно, что просто прочитать оттуда что-нибудь всегда полезно :)
> зачем писать каждому пользователю отдельнуб процедуру???
Ну а какая разница? Ну будет айди параметром передаваться, фактически то же самое, каждому свой код.
stud (2004-04-23 15:43:00) [11]а каким образом пользователь идентифицирутся? где его идентификатор фигурирует?
зачем писать каждому пользователю отдельнуб процедуру???
> Johnmen © (23.04.04 15:17) [21]
достаточно в таком случае одной, где в качестве параметра передавать ид пользователя
Johnmen (2004-04-23 15:17:00) [12]>только вот tabel_select_dep1 это ХП, и она как раз зависит от
>пользователя (у каждого совоя),
и
>Т.е. если какому-т опользователю надо что-то изменить в доступе
>и прочее, меняется только его ХП,
Крайне нежелательный подход. Т.к. связан с постоянным изменением метаданных.
У каждого п-ля, если надо, д.б. своя запись или набор записей в общей таблице...
Felan (2004-04-23 15:10:00) [13]То kaif: Блин, да ЗНАЮ Я, ЧТО ЭТО НЕ МАСТЕЙ-ДЕТАЙЛ!!! Прежде чем отвечать, хоть бы внимательно прочитал про что речь. А вот перефразировал ты мой вопрос верно :) Дело в том, что если второй делает все сам, то нафиг тогда первый?
То Johnmen: В принципе твой вариант работает, только вот tabel_select_dep1 это ХП, и она как раз зависит от пользователя (у каждого совоя), поэтму неподходит...
Я хотел построить такуюю структуру:
Есть сводная таблица staff, как почти правильно подметил kaif, в ней коды отделов, сотрудников и прочее, короче кто-где-когда. Есть таблици, в котрые есть "расшифровки" этих кодов (например employee - сотрудники, department - отделы и т.д.)
У каждого отдела есть свое представление staff_n, где n-номер отдела. Так же есть хранимые процедуры для каждого представления, просто для того, что бы все это редактировалось на сервере, и, если что, звращать выборку как угодно.
Далее, на клиенте, как я уже говорил, должно быть два запроса, один исполняя процедуру (также есть таблица, какому юзеру, какая процедура нужна) получает сводную таблицу кодов из нужного предстваления staff_n. А второй запрос по этим кодав отображает информацию. Т.о. получаем независимость оработки результатов, от их выборки. Т.е. если какому-т опользователю надо что-то изменить в доступе и прочее, меняется только его ХП, а клиент как работал, так и работает.
Вот, собственно то, что я хотел...
Теперь я думаю, почитав все что вы писали, что может и не стоит так извращаться... можно ведь отдельно запрос хранить для каждого пользователя... тем более, что у FIB есть репозиторий запросов... или все реилизовать в одной ХП...
Эх, блин, нелегко определиться в первый раз :)
Felan (2004-04-23 15:09:00) [14]То kaif: Блин, да ЗНАЮ Я, ЧТО ЭТО НЕ МАСТЕЙ-ДЕТАЙЛ!!! Прежде чем отвечать, хоть бы внимательно прочитал про что речь. А вот перефразировал ты мой вопрос верно :) Дело в том, что если второй делает все сам, то нафиг тогда первый?
То Johnmen: В принципе твой вариант работает, только вот tabel_select_dep1 это ХП, и она как раз зависит от пользователя (у каждого совоя), поэтму неподходит...
Я хотел построить такуюю структуру:
Есть сводная таблица staff, как почти правильно подметил kaif, в ней коды отделов, сотрудников и прочее, короче кто-где-когда. Есть таблици, в котрые есть "расшифровки" этих кодов (например employee - сотрудники, department - отделы и т.д.)
У каждого отдела есть свое представление staff_n, где n-номер отдела. Так же есть хранимые процедуры для каждого представления, просто для того, что бы все это редактировалось на сервере, и, если что, звращать выборку как угодно.
Далее, на клиенте, как я уже говорил, должно быть два запроса, один исполняя процедуру (также есть таблица, какому юзеру, какая процедура нужна) получает сводную таблицу кодов из нужного предстваления staff_n. А второй запрос по этим кодав отображает информацию. Т.о. получаем независимость оработки результатов, от их выборки. Т.е. если какому-т опользователю надо что-то изменить в доступе и прочее, меняется только его ХП, а клиент как работал, так и работает.
Вот, собственно то, что я хотел...
Теперь я думаю, почитав все что вы писали, что может и не стоит так извращаться... можно ведь отдельно запрос хранить для каждого пользователя... тем более, что у FIB есть репозиторий запросов... или все реилизовать в одной ХП...
Эх, блин, нелегко определиться в первый раз :)
kaif (2004-04-23 04:08:00) [15]Master-Detail связь датасетов бывает нужна, когда ты хочешь при скроллинге в первой сетке чтобы что-либо менялось во второй. Если же у тебя во второй сетке должно что-то отображаться, опираясь на все значенияв первой сетке, как в данном случае, то делать мастер-детейл датасетов неразумно ни в каком смысле.
Я так понял, что в левой сетке - список каких-то контрактов, а во второй - список работников, которые их выполняют или что-то в этом духе. Здесь нужны два изолированных запроса к серверу. Второй запрос должен сам все сделать (вроде того, что предложили Stud и Johnmen). Возможно, что во втором запросе distinct может понадобиться, если один работник сразу по двум контрактам работает, а нужно его один раз высвечивать.
В любом случае мастер-детейл здесь не нужен и вреден.
Felan (2004-04-22 17:05:00) [16]...и, кажется он с именами таблиц напутал... блин, уже башка вообще не соображает. Потом осмыслю его запрос.
stud (2004-04-22 16:58:00) [17]так ты все что тебе нужно получаеш во втором запросе. вопрос первый зачем нужен? все необходимые объединения таблиц сделаны во втором запросе. первый в данном случае для того чтобы было?
Felan (2004-04-22 16:50:00) [18]То stud:
Не знаю... книнануло меня почему-то на двух запросах! Вот теперь думаю... вариант Johnmen'а вполне подходит... хотя идеология конечно не та...
stud (2004-04-22 15:39:00) [19]так а два запроса всетаки зачем??
Felan (2004-04-22 15:24:00) [20]То stud:
Нет, это я для примера привел полный вывод, что б понятно было.
Во первых, во втором наборе должно выводиться только
название
.....
название
Во вторых, зачем не это надо? Затем, что бы вынести управление выводом на сервер, а не на клиенте запросы формировать... (кстати, мне тут одна мысль счас пришла, может действительно одним обойтись...), т.к. нехочется по каждому пустику переписывать приложение.
Например, надо одному пользователю еще что-то подкинуть в этот вывод, берешь, и... (хм... все настойчивее лезет мысля про один запрос...) и на сервере в спец таблице прописываешь, что ему еще и это надо показать... а клинт (прога) сама все цепляет...
Т.е. второй запрос одинаковый для всех по определению, а первы может меняться в зависимости от пользователя...
| |
Страницы: 