информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetПортрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Модель надежности отказоустойчивой... 
 ЛК нашла бэкдор в ASUS Live Update 
 Facebook хранил часть пользовательских... 
 NSA выпустило Гидру 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
А если будет 35к записей? :) При тех же условиях. 12.12.07 17:02  Число просмотров: 5014
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
<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-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach