Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Сортировка ADODataSet [MSSQL]

Страницы: < 1 2 3 4 5 >
Ega23 © (2007-03-13 16:35:00)
Есть ADODataSet с открытым набором данных.
Как его сортировать по разным столбцам на клиенте, не переоткрывая? IndexDefs добавлять?

Megabyte (2007-04-17 14:37:00) [41]

> Jan1 (17.04.07 13:55) [38]

Я тебя понял.
Но и

> sniknik © (17.04.07 14:21) [40]

тоже. Вот с ним согласен.

Jan1 (2007-04-17 14:34:00) [42]

> p.s. не надо легковушку в плуг запрягать вместо трактора
> и все будет в порядке. а уж если запрягаете, то воздерживайтесь
> от комментариев типа "Лукап-поля которые реализованы в Делфе
> - большая пакость.".

Скажите есть у Вас таблицы которые между собой завязаны и записей там по 100 тыс? Как пример, я приводил Контакт-Контрагент. Показываете ли Вы такую связку пользователю, если да то как? Через лукап или нет?

Jan1 (2007-04-17 14:27:00) [43]

> ну например для того, чтобы не закачивать с сервера лишних
> данных, экономить трафик в условиях его ограниченности.

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

> к примеру работаешь с таблицей на 100 тыс или более у которой
> одно/несколько поле длинное и часто повторяющееся (вынесены
> в справочник)... ну например 20 вариантов на все записи
> первой.
> как думаешь, что выгоднее 1 раз скачать все 20 дополнительных
> записей, а в таблице оригинале только индекс-ссылка(число)
> на эти записи, или тянуть с сервера 100тыс записей * длинна
> записи из справочника при запросе объединении. ???

чего-то не допонял... можно подробнее?

Jan1 (2007-04-17 14:24:00) [44]

> Так вот корректно было бы получать в Наборе данных все поля,

Очень плохое заблуждение. Очень. Нужно создавать поля по требованию и делать перезапрос если юзвер добавил новые поля, если убрал, то делать перезапрос не надо.

sniknik (2007-04-17 14:21:00) [45]
> Зачем мне держать 10 справочников открытыми, по которым все время идет локейт, только для того, чтобы вывести их значения?
ну например для того, чтобы не закачивать с сервера лишних данных, экономить трафик в условиях его ограниченности.

к примеру работаешь с таблицей на 100 тыс или более у которой одно/несколько поле длинное и часто повторяющееся (вынесены в справочник)... ну например 20 вариантов на все записи первой.
как думаешь, что выгоднее 1 раз скачать все 20 дополнительных записей, а в таблице оригинале только индекс-ссылка(число) на эти записи, или тянуть с сервера 100тыс записей * длинна записи из справочника при запросе объединении. ???

p.s. не надо легковушку в плуг запрягать вместо трактора и все будет в порядке. а уж если запрягаете, то воздерживайтесь от комментариев типа "Лукап-поля которые реализованы в Делфе - большая пакость.".

Kostafey (2007-04-17 14:18:00) [46]
А вот еще такая ситуация.
Я заранее не знаю какие именно поля будут отображены в пользовательком датасете.
(пользователь имеет возможность редактировать список отображаемых полей).
Необходимо настроить свойства DisplayLabel и DisplayWidth полей.
Редактировать в Гриде нельзя т.к. неизвестно сколько будет полей и какие.
Так вот корректно было бы получать в Наборе данных все поля,
создавать для каждого поля TField (в Наборе данных) и редактировать только
свойство Visible этих полей ?

Jan1 (2007-04-17 13:55:00) [47]

> 1) Ну хз, я не замечал, хотя скажу, что и не так много делал,
> чтоб заметить.

там локейты, а это сам должен понимать какая-скорость.

> 2)Ну теоретически разве что на больших объемах справочных
> таблиц. Но справочников больших объемов пока что не видел
> ни в одном проекте(в том числе и в чужом).

та какая разница сколько там записей(хотя тоже важно :))? Зачем мне держать 10 справочников открытыми, по которым все время идет локейт, только для того, чтобы вывести их значения? Я могу и запросом это получить. Да есть справочники простые, а есть взаимные ссылки, допустим контакт-контрагент. и в каждой таблице по 1 мл. записей.

Megabyte (2007-04-17 13:45:00) [48]

> Jan1 (17.04.07 11:40) [32]
1)А в том как это все релизовано и как это все работает.
2)Особенно это заметно на больших обьемах.

1) Ну хз, я не замечал, хотя скажу, что и не так много делал, чтоб заметить.
2)Ну теоретически разве что на больших объемах справочных таблиц. Но справочников больших объемов пока что не видел ни в одном проекте(в том числе и в чужом).

Kostafey (2007-04-17 12:34:00) [49]
> [34] Jan1 (17.04.07 12:26)

Спасибо, читаю.

Jan1 (2007-04-17 12:28:00) [50]
> Это же, например, insert произойдет и в Master и в Detail
> ?
обшибся.
http://delphikingdom.ru/asp/viewitem.asp?catalogid=420

Jan1 (2007-04-17 12:26:00) [51]

> Это же, например, insert произойдет и в Master и в Detail
> ?

читал?
http://delphikingdom.ru/asp/viewitem.asp?catalogid=413
И тут все будет полезно:
http://delphikingdom.ru/asp/itemq.asp?mode=1&itemid=128

Kostafey (2007-04-17 12:23:00) [52]
Что-то я не понял, а к чему приведет редактирование (Edit/Insert) набора данных,
построенного на нескольких таблицах ? Например как:

> select m.id, m.name, m.detail_id, d.name as detail_name
> from Master m
> left join Detail d on d.id = m.detail_id

Это же, например, insert произойдет и в Master и в Detail ?

Jan1 (2007-04-17 11:40:00) [53]
1. Можно подменить контрол, который в зависимости от кол-ва записей в справочнике, будет или кнопку показывать, по нажатию на которую форма с выбором значений - это когда записей больше скажем > 20, или комбобоксик рисовать, если записей <= 20. Да но создавать нужный набор нужно будет только тогда, когда пользователь захочет, а не всегда - как это с лукап-полем.
2. А в том как это все релизовано и как это все работает. Особенно это заметно на больших обьемах.

Megabyte (2007-04-17 11:14:00) [54]
1)А каким образом ты сделаешь, чтобы в гриде, кот. выдает данные с джойном, можно было редактировать данные, чтобы не вводить всякие там ключи, а выбирать значения из выпадающего списка справочных таблиц(как в лукап-комбобокс-полях)?
Все равно придется отдельные НД делать для справочников...

2) В чем выражается "тормознутость и неправильный подход к проектированию клиентских приложений" пакостных лукап-полей?

Я не придираюсь, просто интересно!

Jan1 (2007-04-17 10:18:00) [55]
Те Лукап-поля которые реализованы в Делфе - большая пакость. Это источник тормозов и неправильного подхода к проектированию клиентских приложений. Лукап можно спокойно, а главное оптимально реализовать самому. Например, есть две таблицы одна главная другая справочная. Запрос:
select m.id, m.name, m.detail_id, d.name as detail_name from Master m left join Detail d on d.id = m.detail_id
Выведет ту же информацию, что и с лукап-поля из Делфи, но(!) быстрее на порядок, с возможность сортировки и фильтрации. Осталось только контролы прикрутить.

Kostafey (2007-04-17 03:35:00) [56]
У меня появилась аналогичная проблема. Нужно сделать сортировку по LookUp-полям.
И сразу несколько вопросов по ветке:

> procedure TFrSpr.DBGridEh4TitleBtnClick(Sender: TObject;
> ACol: Integer;
> Column: TColumnEh);

И когда такое событие происходит ?

> > не сортирует по lookup-полям датасета.
>
> Что за бред ?

ADODataSet1.Sort:=ADODataSet1LookTipMeropr.FieldName;
Где ADODataSet1LookTipMeropr - lookup- поле не работает.

> лукап - это пережиток. давно уже все делают через join +
>
> самописные контролы или EhLib.

А это что такое. Я имел в виду самописные контролы?

Если попытаться из всей ветки сделать вывод, то можно ли судить о том, что сортировка
по LookUp - полям невозможна (в том числе и в EhGrid), а уж тем более задание фильтра
вывода записей на основе LookUp - полей ?
В этом случае (для целей сортировки и фильтрации) лучше иметь независимый набор данных который
будет исключительно средствами SQL работать с базой данных с последующим выводом например в EhGrid, а
для ввода и модификации данных отдельно использовать уже стабильно работающие наборы данных с LookUp-полями.
Кроме того, для модификации данных в любом случае потребуется набор данных, содержащий все записи таблицы.

Основной недостаток - необходимость для каждой сетки (EhGrid) настраивать DiplayLabel и проч. в зависимости
от выводимого списка полей. В случае с заданными заранее пролями это удобнее.

Jan (2007-03-28 11:13:00) [57]
это понятно, но вообще-то тема ушла в сторону. на лукап поля и т.п.

sniknik (2007-03-28 11:10:00) [58]
а прочитать собственно вопрос обсуждения в [0]? прежде чем давать советы, даже не зная применительно к чему.

Jan (2007-03-28 10:48:00) [59]
а что будет если я выбрал первые 100 записей? смысл их сортировать на клиенте?

sniknik (2007-03-28 10:39:00) [60]
> через сколько минут у тебя база tempdb загнется.
tempdb про эту сортировку даже не "догадается", т.к. sort это клиентский метод. и неважно по чему обьеденен начальный запрос, все одно действие над результирующем рекордсетом.

т.что предложенная проба из [24] бессмыслена.

Страницы: < 1 2 3 4 5 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »