Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > СУБД, общие вопросы > relationships или field lookup, что продуктивней?

Автор: aleksh 11.8.2008, 14:06

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

Автор: while 12.8.2008, 01:11

Если "клиент-сервер", то конечно "связывание" вида xxxx join, где xxxx - left, right, inner будет эффективнее (при условии, что отсительное быстродействие "сервера" > клиентского). Тем более, что "связывание" бывает разным... А для сравнения нужен пример с типом СУБД, примером задачи и т.п....

Автор: aleksh 15.8.2008, 10:08

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

Автор: solenko 15.8.2008, 10:29

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

Автор: Akella 15.8.2008, 12:22

Если нужно редактировать данные прямо в гриде, то лукап-поля лучше, т.к. некоторые гриды сразу вставляют для таких полей выпадающие списки.

Автор: solenko 15.8.2008, 12:34

Akella, каким образом связаны ЛОГИЧЕСКОЕ объединение на уровне СУБД и интерфейс?!!

Автор: Akella 15.8.2008, 12:48

да вот как раз я и имел ввиду, что НЕ на уровне СУБД, а на уровне компонентов доступа или же сразу грида.

Автор: aleksh 15.8.2008, 12:55

toAkella: а можно пример, какие именно гриды так делают? хорошо, с целью избежания кривотолков попробую переформулировать вопрос: сталкивался ли кто либо с показательными случаями когда хранить "бизнес-логику" было целесообразнее (или продуктивнее) в субд, чем в "клиенте" (и наоборот), или возникали ли в таких ситуациях неожиданные сложности при реализации "клиентов". еще раз уточню: конкретный пример не приведу, ибо все возникавшие затрудния решались, топик  Цитата(aleksh @  11.8.2008,  14:06 )  спрашиваю "для себя", "на будущее" так сказать хочется "експиренса" набрать не только путем "проб и ошибок"

Автор: solenko 15.8.2008, 13:17

aleksh, хранить бизнес логику в СУБД очень выгодно при наличии большого количества разнообразных клиентов, также, при борьбе за тонкого клиента. Например, с нашей базой работают из десктопного приложения, из веба, с мобильных клиентов и еще бог знает чего. relationships -- это не хранение бизнес логики. это обеспечение целостности данных. ее можно контролировать на клиенте и надеятся, что ни один програмер не забудет поставить проверку, например, на существование связанных записей перед удалением. А можно при проектировании базы прописать зависимости и нерадивый програмер получит exception вместо подвисших в невесомости данных. То, о чем говорит Akella, не имеет никакого отношения к relationships. Есть они или нет -- для отображения вам все равно прийдется делать lookup. Возможно, некоторые среды разроботки сделают это за вас автомаотом, но сути это не меняет.

Автор: aleksh 15.8.2008, 13:53

ладно, видимо я сам не до конца понял что хотел узнать (но ведь честно об это сразу предупредил :) ), с таким же успехом, наверное, можно было спросить об преимуществах толщины клиентов... итог прост: надо контролировать программистов можно писать инструкции, сделать так, чтобы они постоянно между собой общались, чтоб был человек который мог бы уточнить "неточности", и тогда, если будут хорошие тестеры -- все будет хорошо, несмотря ни на что... а все остальное -- тонкости конкретной реализации спасибо за ответы p.s. пойду искать гриды, о которых Akella говорил... Добавлено через 9 минут и 54 секунды забыл галочку...

Автор: Akella 18.8.2008, 00:32

Цитата(aleksh @  15.8.2008,  12:55 ) toAkella: а можно пример, какие именно гриды так делают? про стандартный не знаю, а вот DBGridEh делает, cxGrid делает, думаю, что все более менее продвинутые гриды умеют определять лукап поля и выводить комбобокс. Добавлено через 9 минут и 25 секунд да и не только комбобокс, если поле типа дата, то вываливается календарь

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)