Вверх ↑
Этот топик читают: Гость
Ответов: 1891
Рейтинг: 110
#136: 2007-09-04 01:58:30 ЛС | профиль | цитата
nesco, писал(а):
только концепция не совсем понятна была с одинаковыми значениями


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

Например не следует создавать индексы по столбцу status

FAMSTATUS
Петров Женат
ИвановРазведен
Сидоров Женат
Иволгин Разведен
Сидоренко Холост
Кличко Женат
МитинЖенат
......
Яковлев Холост


Использование индекса, построенного на данных столбца STATUS
для классификации, не является оправданным. Например, следующим запрос
SELECT * FROM tbl WHERE STATUS = 'Женат'
вызывает непрерывный поток обращений от таблицы к индексу и наоборот. Из-за того, что условие WHERE STATUS = 'Женат' возвращает большой объем данных, серверу базы данных придется постоянно читать сначала данные из индекса, затем соответствующую строку из таблицы и т. д. В данном случае гораздо более эффективным было бы простое сканирование всех данных таблицы, поскольку значительная ее часть все равно должна быть прочитана.
карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#137: 2007-09-04 02:05:45 ЛС | профиль | цитата
Alexbootch, понял. У меня что-то тиа того, только номера, но ради чистоты эксперимента попробую почитать, хочу проверить -- будет быстрее или медленнее визуально. Если будет так же или медленнее, то нафиг надо такое счастье
карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#138: 2007-09-04 10:56:42 ЛС | профиль | цитата
nesco писал(а):
хочу проверить -- будет быстрее или медленнее визуально

в нормальной базе медленнее быть не может. Это может быть верно только для совсем безумных структур БД, когда скажем все значения в индексированной колонке одинаковые.
карма: 23
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#139: 2007-09-04 11:31:08 ЛС | профиль | цитата
Проверил, чтение, даже по сети, очень быстрое -- выборка из базы в 45000 событий по одному номеру с индексированным столбцом меньше секунды, но теряет некоторую информацию при записи одного поля из другой таблицы. Таких дыр -- процентов десять по номеру и это -- в пиках нагрузки, в штатном режиме дыр нет. Надо как-то ускорить выборку полей из смежной таблицы. Возможно ее тоже придется индексировать по столбцу поиска.
карма: 19

0
Ответов: 1891
Рейтинг: 110
#140: 2007-09-04 11:38:43 ЛС | профиль | цитата
nesco, писал(а):
...но теряет некоторую информацию при записи одного поля из другой таблицы.


какую именно иформацию?
карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#141: 2007-09-04 13:40:07 ЛС | профиль | цитата
Alexbootch, при получении данных, по определенному коду, выбирается поле одной из смежных таблиц и приклеивается к основному запросу на запись, но вроде, разобрался. При выборе были переставлены точки FormatStrihga, прикол в другом -- как оно умудрялось правильно читать, вот этого я не понял , вообще (чистый нонсенс), но исправил. Дальше буду смотреть соответствие, но смежные таблицы проиндексировал и убрал поиск по rowid, хорошо, что были резервные поля id, по ним и проиндексировал. Все хорошо, но размер в полтора раза увеличился с 40 кб до 57 кб
карма: 19

0
Ответов: 1891
Рейтинг: 110
#142: 2007-09-10 21:48:43 ЛС | профиль | цитата
nesco, писал(а):
Все хорошо, но размер в полтора раза увеличился с 40 кб до 57 кб


nesco, для хранения индекса требуется физическая память и иногда бывает так что индекс разрастается больше самой таблицы, для которой он был построен.
карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#143: 2007-09-10 22:19:45 ЛС | профиль | цитата
Alexbootch, да и фиг с ними, с этими килобайтами. Практически ушел от применения rowid, но есть некоторые места, гле никак не могу от него избавиться. Вот например: как заполнить поле id c автоинкрементом, начиная с 1 не применяя rowid от начала таблицы до конца, после удалении одной из строк -- предположим id было 1,2,3,4,5,6, а после удаления стало -- 1,2,3,5,6. Вот тут надо пересчитать последовательность id и привести ее к виду 1,2,3,4,5 (лучше всего в одной группе запросов), с rowid получилось, а вот без него никак.
карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#144: 2007-09-10 23:15:42 ЛС | профиль | цитата
nesco писал(а):
Практически ушел от применения rowid

по какой причине если не секрет? Некоторое время назад доказывалась истинность обратного...

nesco писал(а):
как заполнить поле id c автоинкрементом, начиная с 1 не применяя rowid от начала таблицы до конца

каждая новая задача оригинальнее предыдущей. nesco, основываясь на предыдущем опыте этого же поста полагаю имеет смысл излагать задачу полностью. Глядишь научимся как все нормальные люди делать сортировку с перемещением записей, идентифицировать эти записи по уникальному идентификатору(а не псевдополю), обходится без пересчета индексов, которые будучи однажды прописанными меняться по идее не должны...
карма: 23
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#145: 2007-09-11 00:36:53 ЛС | профиль | цитата
Dilma, ну что ты издеваешься? Мне предложили, я и подписался.
Dilma писал(а):
обходится без пересчета индексов, которые будучи однажды прописанными меняться по идее не должны...
Вот тут как раз я и столкнулся с тем, что при удалении теряется последовательность уникального индекса (об этом и были ранние посты)... Остальное известно.
А вот перемещение записей вообще не требует, оказывается, изменения однажды присвоенного индекса. Еще раз каюсь за тупой и необдуманный, затеянный мной, спор
карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#146: 2007-09-11 01:12:11 ЛС | профиль | цитата
nesco писал(а):
Вот тут как раз я и столкнулся с тем, что при удалении теряется последовательность уникального индекса

уникальным он потому и называется, что будучи присвоенным один раз не меняется впоследствие. Есть основания считать, что индекс, для которого всегда поддерживается условие I(n) = I(n-1) + 1 (следующий на единицу больше предыдущего) - есть занятие бессмысленное(не оправданное). Точнее можно сказать при наличие примера.
карма: 23
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#147: 2007-09-11 01:42:20 ЛС | профиль | цитата
Dilma писал(а):
есть занятие бессмысленное(не оправданное).

Тут, похоже, мне надо хорошенько подумать. Я уже начинаю понимать, что такая последовательность действительно не нужна. В самом главном месте, там где оформляются динамические каналы, я вообще отошел от каких-либо индексов и использую другой признак (всеже пустой спор помог и заставил изменить алгоритм в лучшую сторону, сократив при этом еще и занимаемую динамическую память).
карма: 19

0
Ответов: 1891
Рейтинг: 110
#148: 2007-09-11 01:44:55 ЛС | профиль | цитата
nesco, писал(а):
Вот тут как раз я и столкнулся с тем, что при удалении теряется последовательность уникального индекса (об этом и были ранние посты)... Остальное известно.


именно об этом уже и писалось не раз
карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#149: 2007-09-11 02:05:58 ЛС | профиль | цитата
Alexbootch, не катит тут Vacuum, совсем не катит. Сегодня в этом еще раз убедился, что Vacuum срабытывает только если переоткрыть базу. Rowid остается неизменным до закрытия базы. Вот об этом было писано мной с примером http://www.dev.hiasm.com/xf/topic.php?t=7798&start=30
карма: 19

0
Гость
Ответов: 17029
Рейтинг: 0
#150: 2007-09-11 03:44:07 правка | ЛС | профиль | цитата


Редактировалось 2 раз(а), последний 2017-06-15 04:20:43
карма: 0

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)