Владимир Саныч, ну Вы бы как знаток Accces (судя по профилю) и сами бы ответили, чтоли...

2 Smile

1. Правда ли, что чем больше индексов, тем больше загружается сеть (потому что они все гоняются по ней)?

Товарищи клиент-серверщики, ну вы пАрите просто. Куда ни плюнь - везде одно и то же идиотское заблуждение. Не тянется ничего ПОЛНОСТЬЮ - ни таблицы, ни индексы!!! Почему это тянутся индексы ВСЕ? Откуда такой вывод? Перечитайте выступление Л.П. Тянутся нужные для оптимизации запроса. Л.П. вам же объяснил как происходит выборка по индексам. Зачем для этого ВСЕ индексы тянуть? В Access и Фоксе есть оптимизатор (в первый перекочевал из второго). Rushmore зовётся. Он и решает, получая SQL-инструкцию, какие индексы тянуть и с каких таблиц. Далее - по вытянутым индексам, в соответствии с запрошенным в SQL-инструкции выражением, определяются нужные записи, и вытягивабтся на клиента ТОЛЬКО ОНИ.


2. Как с той же точки зрения выглядит алгоритм обновления? И тот же вопрос про удаление.
Никаких страшных заморочек и тут нет. Я не знаю как в Access на низком уровне (на 99% уверен, что абсолютно так же), а в фоксе источник выборки (та часть (я подчёркиваю - имеено _часть_) источника, которая была вытянута из сети на клиента) сидит в памяти, она же и изменяется при обновлении/удалении. Синхронизацией её с сетью занимается сам движок Фокспро, с определенным интервалом опрашивая сетевой источник и синхронизируясь с ним.

2 c127

Ваша фраза:
c127Т.е. тянет индек с на клиетна именно ПОЛНОСТЬЮ и там шерстит
моя фраза:
AijikНе тянется ничего ПОЛНОСТЬЮ - ни таблицы, ни индек сы !!!
фраза Владимир Саныча:
Владимир Санычпотому что они все гоняются по ней
Вы разве не усмотрели разницу между озвученными понятиями "индекс" и "(все) индексы"? Что такое "тег" составного индекса кто помнит? В Access, насколько мне известно, понятия "тег" не существует. Просто "индекс" и "индексы" таблицы. Ну пусть так - сути это не меняет.
Кто все равно не понял - пример:
Допустим, есть таблица Cities
Допустим есть поля:
Name, Country, Population, Location, TimeZone, Budget
Для простоты примера допустим, что по ним всем есть индексы

Выборка на клиенте:
SELECT * FROM Cities WHERE Cities.Country="France"
Из сети тянется индекс Country. Не все 5 индексов, а ТОЛЬКО индекс Country (!!!). Тянется полностью (никто о частичном вытягивании индекса не говорил, упаси боже). В индексе находятся адреса записей с Country="France". Тянутся на клиента только они. Всё.. трафик минимально возможный для Файл-сервера и его алгоритма оптимизации

c127А индексы бывают большие, это ИМХО и имел в виду Smile: больше индексов - больше трафик,
Я бы перестроил это заявление. Сложнее выборка - больше индексов затрагивается - больше трафик. "Большие" индексы затрагиваются тогда, когда именно они нужны. ВСЕГДА ли они нужны? Нет! Не раздувайте проблему из ничего. Не надо искать черную кошку в темной комнате ;)

c127заранее неизвестно нужен ли индекс, может дешевле было бы проскинировать таблицу целиком.
Вообще-то сканирование в Файл-сервере тоже оптимизируется (по крайней мере в Фоксе). По тем же самым законам, ибо работает тот же самый Rushmore (который можно отключать при желании).
Насчет "может дешевле было бы...". Упомянутая Вами ситуация возможна. Индекс тормозит работу выборки (ибо увеличивает трафик), если под под критерий выборки попадает очень большой процент записей, сопоставимый с общим количеством записей в таблице. Итого, в такой ситуации мы получаем:
1. Выкачку индекса на клиента
2. Выкачку почти всех записей на клиента.
Это конечно же "дороже", чем "безындексное":
1. Выкачка всех записей на клиента
2. Отсечение малого количества ненужных на клиенте
Во втором варианте и трафик ниже и скорость выше (по причине трафика опять же).

У любой медали 2 стороны и идеального ничего не бывает. Но обход таких ситуаций - это уже дело прогера

2 x, gardenman
x Вытаскивается страница с вершиной, сравнивается с заданным значением, вытаскивается следующая нужная станица. В результате из индекса читается всего несколько страниц, а не весь индекс.

Это мне известно

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

c127
Я усмотрел только что Лох Позорный, на .... поэтому по-видимому Smile не имел в виду что .... А так я согласен.
Ну и ладненько. Будем считать, что вопрос о вытягивании индекса на клиента на этом закрыт ;)

c127Вообще рано или поздно выборка произойдет по любому индексированному полю или полям в базе
Вывод Вы какой из этого делаете, я не совсем понял? Заметьте, Вы говорите "рано или поздно". То, что части таблицы подтягиваются на клиента постепенно, по мере надобности, что в этом плохого? Чем не принципы всеми обожаемого клиент-сервера? ;)) Суть данного обсуждения (по крайней мере как я это понимаю) - это "пиковый" трафик при файл-серверной архитектуре. Именно это ставится обычно в упрек. Я утверждаю, что эта проблема непомерно раздута. Я не говорю, что трафик в Файл-сервере ниже, это не так, конечно же, ниже чем в клиент-сервере трафик сделать просто нельзя, ибо в последнем трафик при грамотном проектировании самый минимальный из вообще возможных, т.к. возвращается "чистый" результат, созданный сервером. В Файл-сервере же результат еще надо добыть (добыть на клиенте... для чего и перетягиваются на него индексы)... Однако при всем при этом проблема в Файл-сервере не имеет таких масштабов, которые ей обычно приписывают те, кто с принципами его оптимизации не знаком вообще. Самое расхожее: "Файл-сервер вытягивает по сети таблицы полностью". Расшифровываю подтекст этого заявления. "Файл-сервер тянет на клиента те данные, которые нахрен для работы не нужны". Глупость - еще раз повторяю... Не вытягивает он то, что для работы не нужно. Но... при условии грамотного применения возможностей оптимизации. При неграмотном - извините, и клиент-сервер положить можно...

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

c127Напоминаю, мы говорим о клиент-сервере
Напоминаю, мы говорим о файл-сервере ;)
c127и с точностью до утверждения Лоха Позорного.

Тогда я напомню с чего всё началось:
Smile укорочение за счет нормализации базы, созданием таблиц-справочников?
ну, да, конечно, но в запросе будет учавствовать уже совсем другое кол-во таблиц, и все это будет обрабатываться на клиенте, так что тут еще палка о двух концах - иногда в акцессе лучше оставить данные денормализованными, именно с точки зрения скорости обработки (вернее закачки на клиент и дальнейшей обработки), опять же все зависит от задачи
Со Smile совершенно справедливо заспорил Лох Позорный, где и объяснил основной принцип оптимизации выборок в Файл-сервере и что глупо отказываться от нормализации по причинам непонимания потрохов ФС.
Лох Позорный Для Улыбки еще раз на пальцах.
Для того, чтобы сделать выборку (разумеется на клиенте) совсем необязательно копировать по сети всю базу (весь файл .mdb), и даже совсем не обязательно тянуть по сети отдельно взятые таблицы.
Если можно использовать индексы - аксес их использует. Тянет индексы на клиента, там (на клиенте) их (индексы) шерстит, после чего грузит с файл-сервера на клиент только нужные страницы с данными. Аксес - это, конечно, настольная БД, но все-таки чуть-чуть поумнее экселя будет :)
Ответ Smile говорит о том, что он этого не знал:
Smileтогда где он делает эту выборку???
на сервере што ли??
....
т.е. получается прямая зависимость кол-ва передаваемой информации от индексов???
хмм, а как происходит тогда обновление и удаление??? мне че-то сложно увязать его с приведенной вами схемой
объясните, тогда и это на пальцах, если не трудно, конечно


Собственно, в качестве продолжения этой части дискуссии и появился мой первый пост

2 c127

c127join в данном случае ни при чем... Я хотел сказать, что внешний ключ еще не позволяет добавлять в дочернюю таблицу записи, у которых нет ссылки на родительские... к оптимизации это прямого отношения не имеет
Имеет прямое. В Visual FoxPro точно. За Accces пусть авторитетно скажут те, кто с ним работает. Уверен, что скажут они то же самое. Поддержание ссылочной целостности реализовано за счет активного использования соответствующих индексных ключей. Т.е. _оптимизировано_.
Вот кусок стандартного триггера на каскадное удаление, который генерит Visual FoxPro на основе штатного генератора RIBuilder, отвечающего за поддержку ссылочной целостности в Базе данных



c127Не знаю индексирует ли такие поля акцес, но это не важно.
Очень даже важно, иначе на больших таблицах будет тормоз.

c127join в данном случае ни при чем
Я имел в виду то, что поскольку SELECT использует индексы, и поскольку JOIN - операция производящаяся по ключам, то эти индексы используются оптимизатором в первую очередь, т.е. тянутся по сети

Что с файл сервером ни делай - страдает сетка. Клиент-серверу в данном случае легче, ему вообще не нужно оптимизировать сетевой трафик.
Это да. Так и есть

Потом если вытащил индекс на клиент d (полностью или частично, не важно) - блокируй таблицу, иначе положение записи может измениться другим клиентом g и индекс находящийся у клиента d перестанет соответсвовать таблице.
Что значит "положение записи может измениться"? Значение индекса изменится всмысле? Ну и нехай изменяется. Синхронизация с сетевым источником в Файл-сервере происходит автоматом по определенному интервалу - я уже писал об этом. Зачем что-то блокировать? Тем более ТАБЛИЦУ. Для просмотра вообще ничего блокировать не надо. Для редактирования - надо, но только не таблицу, а нужную запись/записи. Как раз для того, чтобы разрулить юзеров, желающих править одно и то же.

Я вообще не понимаю, зачем сейчас использовать ФС, если есть очень неплохие, бесплатные и к тому же легкие (работают даже на палмах и не требуют инсталляции) SQL сервера.
Если Вы не против, я уклонюсь от ввязывания во флейм по поводу ФС vs. КС. Раз первый еще не подох, а активно развивается (Visual FoxPro 9 обещают в конце года и с Access в MS никто не собирается завязывать), то значит рынку это надо... Как только рынку это будет не надо - КС вытеснит ФС окончательно. Уж кто-кто, а MS точно за $ мать родную продаст, если почуствует, что его Файл-серверные направления приносят только убытки. И вообще "неплохие, бесплатные" - это довольно подозрительно :) Всё оно обычно бесплатно до первой же банальности, которую система делать будет не уметь, а тебе оно будет ОЧЕНЬ надо...