Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Основная таблица + справочники. Болезни роста  [new]
Бедный Йорик
Guest
Разработка на Дельфи 5 + SQL Server 7.0
Люди как мне лучше всё организовать данные и в программе?
Есть одна главная таблица куда добавляются записи.В этой таблице много полей которые как бы только коды, которые проставляются соответственно справочникам. Так вот в различных интерфейсах программы нужно показывать значения из справочников, которые соответствуют различным полям этой основной таблицы. Как добиться того чтобы можно было одновременно просматривать произвольное любое число полей, можно ли это сделать только средствами SQL? И не влияет ли большое количество используемых справочнков на сетевой трафик? Или нужно действовать штатными средствами Дельфи - Lookup поля, отдельные объекты ADOSQL и ADOTable для каждого поля и справочника?
26 мар 03, 07:07    [156437]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Создавай lookup поля - вообще-то их число неограничено и они с курсорами никак не связаны - так, что по одной таблицы на lookup поле создавать необязательно - можно и одну для нескольких полей

Ну а насчет трафика - выборо та все равно не большой
26 мар 03, 08:38    [156468]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
2 funikovyuri

>Создавай lookup поля

Ага, у меня справочник продукции 70 000 наименований, контрагентов - 10 000 позиций. И это все в lookup поля. Ну, ну. Рекомендую памяти сразу прикупить по гигу на каждую рабочую станцию.

lookup поля можно использовать только когда в наборе 10-20 записей. А иначе жуткое пожирание ресурсов и прочие неудобстава, типа невозможности поиска. В таких случаях заполнение реквизитов главной таблицы производят через дополнительные формы, которые так и называют Выбор из справочника...
В котором юзер может задать некоторые критерии поиска, например, часть наименования и типоразмер. и получить ограниченный набор данных. Выбрать нужную запись и нажав кнопку ОК заполнить соответствующие поля.
26 мар 03, 09:09    [156493]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
А я чего-то не совсем понял вопрос - проблема в просматривании значений справочников в записи основной таблицы или в изменении записи?

Если просматривать - зачем тут вообще lookup поля? Я бы вообще посоветовал их не использовать. В селекте, который выдает записи основной таблицы, и прописываешь все ссылки на справочники и добавляешь в resultset их значения. Какие тут проблемы?
26 мар 03, 10:42    [156641]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
А проблемы могут быть с быстродействием. join многих таблиц будет работать достаточно медленно.
Сколько у Вас будет таблиц-справочников? Возможно, следует подумать о денормализации?
26 мар 03, 11:09    [156681]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
...join многих таблиц будет работать достаточно медленно...
...Возможно, следует подумать о денормализации?...


Ой...ё...ёй. Это откуда такие филосовские выводы. Когда это SQL медлено работал со звездой.
26 мар 03, 11:14    [156689]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
ТиБиБи
Member

Откуда: Москва
Сообщений: 906
lookup поля можно использовать только когда в наборе 10-20 записей

IMHO это "перегиб в другую сторону". Даже 100-200 записей выбираются без каких-либо проблем. Вот с тысячами (тем более - с десятками тысяч) - действительно наблюдаются тормоза.

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

Многим пользователям доставляют неудобства именно дополнительные формы. Мне - тоже. Предпочтительнее перемещаться по полям основной формы с помощью обычных кнопок навигации, в случае завершения ввода в одном поле это Enter и/или Tab (или Shift-Tab, если нужно переместиться на предыдущее поле по завершении редактирования текущего). Поиск (в случае LOOKUP-а) - тоже удобен - пользователи вводят первые символы в поле, программа автоматически дополняет до первого найденного образца из справочника, если найдена "не та" строка, тогда пользователь дополняет еще один или несколько символов. Вот если нужен расширенный поиск, тогда уже пользователь выбирает соседнюю кнопочку "[...]" и работает во всплывшей дополнительной форме.
26 мар 03, 13:50    [156822]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
Бедный Йорик
Guest
Спасибо всем кто отвечал.
Болезни роста потому, что данных очень много, добавление просмотр, редактирование идут очень интенсивно в режиме 24Х7, поэтому быстродействие имеет решающее значение.Ну и удобство работы.
Lookup поля сейчас используются...выборка приблизительно 1000 записей....все работает быстро...я вот что думаю, значит придется остальные поля делить и показывать только по запросу...отдельным так сказать окном...
30 мар 03, 00:14    [159989]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Основная таблица + справочники. Болезни роста  [new]
Бедный Йорик я
Guest
а все таки когда лукап используешь при длительной беспрерывной работе трафик меньше чем лефт джойны
6 апр 05, 20:52    [1447043]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
Артем1
Member

Откуда: www.desnogorsk.{ru||net} -> Москва
Сообщений: 2036
Бедный Йорик я
а все таки когда лукап используешь при длительной беспрерывной работе трафик меньше чем лефт джойны


Результат 2-хлетнего наблюдения?
6 апр 05, 21:21    [1447071]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
Flint-San
Member

Откуда: Magnitogorsk
Сообщений: 146
А нельзя создать таблицу фильтров на справочник?

К примеру у нас есть справочник ЖД, в нем более 10тыс возможных отправителей сырья, однако реально сутками и неделями груз приходит
не более чем от 6-7 постоянных поставщиков. Но всегда существует вероятность появления нового поставщика.
Для этого мы сделали

НСИ ЖДТ Фильтр Клиент
Код ------------- 1:1 Код ---------- 1:M--- PK...., и Код из фильтра
все описание

То есть в фильтре только код, связь 1:1.
Справочник вызвается простой связкой фильтра и НСИ.
Если появился новый поставщик, клиент открывает весь перечень и с помощью поиска загоняет его в используемые.
Нас такой вариант устраивает, потому как длительное время не наблюдается
большого роста поставщиков в используемом фильтре.

Но если у вас как на "войне" :) можно в фильтре задействовать даты, но для этого нужно вникнуть в вашу задачу.
6 апр 05, 22:40    [1447144]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
GMSUka
Member

Откуда: Ukraine
Сообщений: 113
Мы сталкивались с подобной проблемой.
Решение было найдено следующее:

1) Мы отказались от клиентских курсоров, перешли на сервере
2) Каждое поле которое подтягивается из справочника реализовали подзапросом и обязательно подзапросом (ни каких JOIN’ov)
3) Реализовали эмуляцию изменения наименования при изменении кода путем перекрытия, GetText, SetText у поля


Визуально получили тоже самое. Быстродействие проверялось на таблице данных
1,5 млн. записей справочник 350 тыс. записей.

Открытие полной таблицы данных в серверном курсоре ~ 5 секунд.
С использование 10 подобных подзапросов время открытия ~ 10 секунд.
Если использовать JOIN то, время открытия вырастает до нескольких минут.


P.S. Эти подзапросы нельзя оформлять во View, их надо добавлять в Делфи и естественно ни о каком ADOTable речи уже быть не может.
7 апр 05, 10:49    [1447796]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
GMSUka
Решение было найдено следующее:


Эээ... Ваше "решение" очень похоже на решение следствия, а не причин. Причем, IMHO, Вы обходили ограничения механизма доступа к данным, скорее всего это ADO. Так?

GMSUka
Каждое поле которое подтягивается из справочника реализовали подзапросом и обязательно подзапросом (ни каких JOIN’ov)


Никогда подзапрос не будет работать быстрее, чем джоин!

GMSUka
Визуально получили тоже самое. Быстродействие проверялось на таблице данных
1,5 млн. записей справочник 350 тыс. записей.


нашли на чем поверять!!! И зачем пользователю эти 1,5 лимона записей.


GMSUka
Эти подзапросы нельзя оформлять во View, их надо добавлять в Делфи и естественно ни о каком ADOTable речи уже быть не может.


Это Ваше высказывание еще раз подтверждает, что Ваше решение - это обход ограничение механизма доступа.
7 апр 05, 11:21    [1447938]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
GMSUka
Member

Откуда: Ukraine
Сообщений: 113
>> Эээ... Ваше "решение" очень похоже на решение следствия, а не причин. >> Причем, IMHO, Вы обходили ограничения механизма доступа к данным,
>> скорее всего это ADO. Так?

Так, это ADO.
Есть задача, пользователь должен видеть реестр документов,
видить хотябы за год. 5000 док. в день итого 5000*360=1 800 000
Отсюда кстати и цифра теста 1,5 млн

>> Никогда подзапрос не будет работать быстрее, чем джоин!

Это связанно с особенностью серверных курсоров, я до конца не понял
этот механизм, но происходис примерно следующее. Если я использую
джоин все таблицы входящие в запрос доступны для изменения в результируещем наборе данных (что естественно не надо само по себе)
По всей видимости торможе джойна связанны с этим. Подсзапрос ведет
себя кординально по другому.

>> нашли на чем поверять!!! И зачем пользователю эти 1,5 лимона записей.
см. выше

С объемом можно действительно можно поспорить.
Я этот вопрос поднимаю постоянно.
Но как говорится есть проблема ее надо решить....

>> Это Ваше высказывание еще раз подтверждает, что Ваше решение - это
>> обход ограничение механизма доступа.

Ну ни чего криминального мы не использовали...
7 апр 05, 11:30    [1447995]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
GMSUka
Есть задача, пользователь должен видеть реестр документов,
видить хотябы за год. 5000 док. в день итого 5000*360=1 800 000
Отсюда кстати и цифра теста 1,5 млн


Меня всегда "убивает" такая постановка задачи, как "видеть" 1,5 лимона документов. Вы здравомыслящий человек? Какие решения можно принять просматриая 1,5 лимона документов?

GMSUka
Это связанно с особенностью серверных курсоров, я до конца не понял
этот механизм, но происходис примерно следующее. Если я использую
джоин все таблицы входящие в запрос доступны для изменения в результируещем наборе данных (что естественно не надо само по себе)


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

автор
По всей видимости торможе джойна связанны с этим. Подсзапрос ведет себя кординально по другому.


Тормоза не из-за джоинов, а из-за объемов. попробуйте при тех же объемах выборки (1,5 лимона) заменить джоины на подзапросы и сделайте курсор клиентским. А при серверном, правильно, пока определенная порция данных не запрошена с клиента, сервер нисего не предпринимает.
7 апр 05, 11:44    [1448071]     Ответить | Цитировать Сообщить модератору
 Re: Основная таблица + справочники. Болезни роста  [new]
GMSUka
Member

Откуда: Ukraine
Сообщений: 113
pkarklin
[quot GMSUka]Есть задача, пользователь должен видеть реестр документов,
видить хотябы за год. 5000 док. в день итого 5000*360=1 800 000
Отсюда кстати и цифра теста 1,5 млн


Меня всегда "убивает" такая постановка задачи, как "видеть" 1,5 лимона документов. Вы здравомыслящий человек? Какие решения можно принять просматриая 1,5 лимона документов?

С этим я согласен...
Но мы обсуждаем решение или задачу....
Т.к. я здравомыслящий человек ;-) то понимаю обсурдность такого набора.

Поэтому давайте отнесеммся к этому вопросу как к теоритической задаче.
И в рамках этой задачи я говорю:
-- У меня получилось обеспечить работу, заметьте нормальную, пользователей
для справочника 300 тыс. со списком данных 1.5 млн. Вот таким корявым
способом. У кого какие еще ест идеи?
7 апр 05, 11:49    [1448102]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить