информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
я имел ввиду операций сравнения, то есть 1 итерация поиска =... 13.12.07 03:00  Число просмотров: 5291
Автор: i1 Статус: Незарегистрированный пользователь
Отредактировано 13.12.07 03:09  Количество правок: 1
<"чистая" ссылка>
> Это всего лишь упорядочивание записей в таблице по заданным
> полям.
> Для таблицы с количеством записей ~2500 и "индексом",
> построенным по двум полям, максимальное количествово
> итераций поиска не привысит 12.

я имел ввиду операций сравнения, то есть 1 итерация поиска = 2 операции сравнения
но понял что так считать нельзя :)
в индексах я так понимаю используются двоичные деревья, то есть количество итераций поиска
равно логарифму по основанию 2 от числа записей (забыл как считать логарифм по основанию при
помощи других логарифмов и поэтому посчитал от е, получилось 7 с чемто,
ну я и прикинул что от 2-х будет 10 :))
от 2-х оказалось 11.28.... операций сравнения в предыдущем посте тогда получилось бы 24

но так как в процессе поиска участвуют 2 поля то на начальном этапе поиска достаточно сравнивать
1-е поле и, если нет совпадения, то второе не сравнивать, то есть на вскидку 12 сравнений 1-го поля
и 2-3 сравнения второго и то это много, если 1-е поле в таблице имеет в основном разные значения.
то есть в итоге 15 операций сравнения

хм.. только что понял что при построении индекса из 2-х полей выгоднее пихать первым полем то,
в котором значения будут больше разниться :)

тогда и для простого перебора будет максимум не 2*2500 сравнений а 2500 + 100 (чтоб не жадничать :))
тогда в среднем получается 1300 сравнений
<programming>
(sql CE) Индекс(-ы) 07.12.07 21:04  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
Постановка задачи:
Дано:
- Справочник (~2500 записей) имущества. Меняется в справочнике только одно поле (битовое) -метка, что считано.
- Реинженеринг. Те софт не знает про "тонкости" структуры базы
- Сиквел для СЕ
- "Вход" select в базу данных - штрих-код.
- Индексов нет.
- Есть два поля из которых формируется штрих-код, которые присвоен (приклеен :)) к имуществу.
Требуется:
- Будет ли прирост, если создать индекс(ы)?
- Структура индекса.
- Оценка прироста?

Софт работает. Вопрос больше архитектурный :)
Индексы при 50к записей действительно помогают на select, а как ускорить update - меняется одно поле в одной строке тип bit? Секунд пять идет апдейт. 16.05.08 14:03  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
change transaction Isolation Level? 16.05.08 21:36  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Однозначно будет! 09.12.07 15:50  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> Постановка задачи:
> Требуется:
> - Будет ли прирост, если создать индекс(ы)?

Однозначно будет!

> - Структура индекса.

Кластерный индекс по полям, на основе которых строится штрих-код.
(+) - существенный прирост произв.поиска без увеличения размера БД
(-) - возможно некоторое падение производительности при добавлении записей (некритичный аспект в случае "справочника").

> - Оценка прироста?
>
> Софт работает. Вопрос больше архитектурный :)

З.Ы. Не совсем понятно, зачем использовать SQL CE. Вполне достаточно подобия DBF формата и кластерного индекса.
"З.Ы. Не совсем понятно, зачем использовать SQL CE. Вполне достаточно подобия DBF формата и кластерного индекса." - приложение исполняется на мобильном устройстве со ШК сканером. 10.12.07 00:46  
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 10.12.07 00:48  Количество правок: 1
<"чистая" ссылка>
а и сама реализация сиквел СЕ весьма проста. Установил библиотеку, положил файл в нужное место и работай. Нет необходимости сиквел сервер поднимать :)

Но нет, соотвественно, и многопользовательского режима. Да и зачем на мобильном терминале многопользовательский режим? :) Для этого есть експресс редакция (но для десктопов), также бесплатная.

С индексами попробую по возможности, сенкс.
Только не знаю как на мобильном устройстве бенчмаркинг с БД устроить, тут софт писать надо :)
на 2500 записей имхо индексы будут не заметны в простых... 08.12.07 05:45  
Автор: i1 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Постановка задачи:
> Дано:
> - Справочник (~2500 записей) имущества. Меняется в
> справочнике только одно поле (битовое) -метка, что считано.
> - Реинженеринг. Те софт не знает про "тонкости" структуры
> базы
> - Сиквел для СЕ
> - "Вход" select в базу данных - штрих-код.
> - Индексов нет.
> - Есть два поля из которых формируется штрих-код, которые
> присвоен (приклеен :)) к имуществу.
> Требуется:
> - Будет ли прирост, если создать индекс(ы)?
> - Структура индекса.
> - Оценка прироста?
>
> Софт работает. Вопрос больше архитектурный :)

на 2500 записей имхо индексы будут не заметны в простых запросах,
нужно знать запросы на которых хочется прироста производительности
и исходя их них строить индексы
и вообще проще посмотреть на скорость с индексами и без на нужных запросах :)
имхо индексы будут заметны. Кстати SQL2005 вроде позволяет... 09.12.07 07:04  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> на 2500 записей имхо индексы будут не заметны в простых
> запросах,
имхо индексы будут заметны. Кстати SQL2005 вроде позволяет агрегировать простой ключ непосредствено в индексе. Тогда ещё более заметно будет. Нет?
почитал про предмет разговора, понял что не учел объемы и... 10.12.07 04:30  
Автор: i1 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > на 2500 записей имхо индексы будут не заметны в
> простых
> > запросах,
> имхо индексы будут заметны. Кстати SQL2005 вроде позволяет
> агрегировать простой ключ непосредствено в индексе. Тогда
> ещё более заметно будет. Нет?

почитал про предмет разговора, понял что не учел объемы и скорости памяти :)
я так себе это представляю:
включаем терминал, запускаем приложение,
считываем первый штрих код, sql подгружает таблицу в RAM, ищет по полю,
выдает результат. На следующем считывании если таблица все еще в памяти надо
сделать в среднем 2500 сравнений без индекса, или 20 с индексом
(т.к. штрих код состоит из 2х полей). т.к. штрих код постоянной не очень большой длины
то операция сравнения займет не много времени на 300-400 мегагерцовом проце
и отличить на глаз 2500 и 20 сравнений не получится :) хотя конечно это надо смотреть

если же таблица в оперативке по каким то причинам не хранится то
при поиске в память загружается только индекс, который конечно меньше самой
таблицы, допустим индекс весит 100К (по 40 байт на штрих код) когда таблица
допустим 2.5 метра (по 1К на запись). Скорости чтения с флэш памяти: 2 - 133 Мб/с
то есть на этом этапе разница будет максимум в секунду минимум примерно 0.02 секунды

получается, что если для таблицы хватает памяти в RAM, или флеш-память в терминале быстрая, то разница будет особо не заметна.

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

ПС: индексы конечно это круто :)
Кластерный индекс не является индексом в привычном понимании. 12.12.07 13:53  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Это всего лишь упорядочивание записей в таблице по заданным полям.
Для таблицы с количеством записей ~2500 и "индексом", построенным по двум полям, максимальное количествово итераций поиска не привысит 12.
я имел ввиду операций сравнения, то есть 1 итерация поиска =... 13.12.07 03:00  
Автор: i1 Статус: Незарегистрированный пользователь
Отредактировано 13.12.07 03:09  Количество правок: 1
<"чистая" ссылка>
> Это всего лишь упорядочивание записей в таблице по заданным
> полям.
> Для таблицы с количеством записей ~2500 и "индексом",
> построенным по двум полям, максимальное количествово
> итераций поиска не привысит 12.

я имел ввиду операций сравнения, то есть 1 итерация поиска = 2 операции сравнения
но понял что так считать нельзя :)
в индексах я так понимаю используются двоичные деревья, то есть количество итераций поиска
равно логарифму по основанию 2 от числа записей (забыл как считать логарифм по основанию при
помощи других логарифмов и поэтому посчитал от е, получилось 7 с чемто,
ну я и прикинул что от 2-х будет 10 :))
от 2-х оказалось 11.28.... операций сравнения в предыдущем посте тогда получилось бы 24

но так как в процессе поиска участвуют 2 поля то на начальном этапе поиска достаточно сравнивать
1-е поле и, если нет совпадения, то второе не сравнивать, то есть на вскидку 12 сравнений 1-го поля
и 2-3 сравнения второго и то это много, если 1-е поле в таблице имеет в основном разные значения.
то есть в итоге 15 операций сравнения

хм.. только что понял что при построении индекса из 2-х полей выгоднее пихать первым полем то,
в котором значения будут больше разниться :)

тогда и для простого перебора будет максимум не 2*2500 сравнений а 2500 + 100 (чтоб не жадничать :))
тогда в среднем получается 1300 сравнений
А если будет 35к записей? :) При тех же условиях. 12.12.07 17:02  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
16 итераций поиска :) 13.12.07 03:01  
Автор: i1 Статус: Незарегистрированный пользователь
Отредактировано 13.12.07 03:01  Количество правок: 1
<"чистая" ссылка>
+1 не больше 16-ти 14.12.07 17:29  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach