К имеющим опыт и практический и теоретический:

Есть таблица, в ней два поля, в одном повторяющиеся числовые коды от 101 до 128, во втором один символ (длина поля 1 символ) на кириллице от "а" до "я" (без "ч", "ы", "ь", "ъ", "ё", "й"). Зависимость внесенных цифр и символов закономерна- 101="а", 102="б" и т.д.

Какая выборка из таблицы в пару миллионов записей произойдет быстрее по символьному полю или по числовому с учетом того, что отбирать и сортировать необходимо от 1 до 3 уникальных значений, например: отобрать только 101 или "а", отобрать 101,102,103 или "а","б","в"?

P.S. Структура придумана не мной, уже существует много лет, в таблице на самом деле около 6 лямов записей, прежняя прога писана на FoxPro 2.0, в ней и работают. Просят дополнительный блок, в котором для обработки и необходимо такую сортировку будет делать. Писать буду в VFP9.





Исправлено 2 раз(а). Последнее : Chemberzhy, 28.09.18 10:05

А провести эксперимент? Простая проба показывает, что разницы в скорости на 10 млн записей не наблюдается.

Тестировал, конечно. Тем более, что и "считалка" даже есть давно заготовленная (в Решениях ее когда то выкладывал). Но спросить никогда у коллег более опытных не помешает.

Спасибо!

Индекс по инту будет расти быстрее, чем по C(1). Не исключено, что он деградирует раньше.

pasha_usue
Индекс по инту будет расти быстрее, чем по C(1). Не исключено, что он деградирует раньше.

С теорией и математикой у меня туго, поэтому просто интересно: для данного конкретного случая, когда в записях используется всего 28 фиксированных значений, есть какая-то разница? ИМХО, на скорость вообще влияют конкретные данные в таблице, а не множество возможных значений поля. А так, размышляя логически, для односимвольного поля доступно намного меньше вариантов значений, чем для целочисленного, поэтому соответствующий индекс по символьному полю, по идее, должен в пределе работать быстрее. Вопрос еще в том, будет ли разница заметна на глаз?



Исправлено 2 раз(а). Последнее : ry, 28.09.18 16:35

Поясню...
Вопрос возник не спроста.
Старая прога работает на старом, очень старом оборудовании.
База данных на не менее гремучем сервере, да еще и удаленном, да еще с него нет возможности таблицы напрямую для обработки скопировать на локальную машину.
Есть один единственный у клиента средне качающий бук, на котором моя приблуда и будет крутиться, select-ом вынимая с сервера данные для выборки и уже потом по его результату на этом буке сопоставлением результата выборки с локальными справочниками и будет выдана соответствующая расширенная информация, которая будет в древнем формате передаваться для анализа в старенькую прогу на рабочей станции.

Вот такой триллер





Исправлено 2 раз(а). Последнее : Chemberzhy, 28.09.18 16:47

Если индекса у таблицы нет, то без разницы
Если есть, то не прозевать, чтобы индекс сработал (CPDBF и COLLATE чтобы позволяли)
Индекс можно и пристроить на время выборки
С таблицей в 866 кодировке при использовании индексации из VFP (1251) что-то было нехорошо, что - не помню, надо конкретный файл для пробы пробовать

ry
С теорией и математикой у меня туго, поэтому просто интересно: для данного конкретного случая, когда в записях используется всего 28 фиксированных значений, есть какая-то разница? ИМХО, на скорость вообще влияют конкретные данные в таблице, а не множество возможных значений поля. А так, размышляя логически, для односимвольного поля доступно намного меньше вариантов значений, чем для целочисленного, поэтому соответствующий индекс по символьному полю, по идее, должен в пределе работать быстрее. Вопрос еще в том, будет ли разница заметна на глаз?

При больших объёмах и очень слабом железе - да, наверное будет заметно.
Индекс по int полю будет на ~20% больше по размеру чем для c(1). Правда, размер индекса сильно зависит от версии фокса и того как был создан индекс и заполнена таблица (разница может достигать 3-5 раз). Переиндексация в VFP9SP2 даёт достаточно компактный индекс - но в некоторых других версиях даже "свежесозданный" индекс был весьма и весьма "разряжённым" - т.е. содержал много "пустого места" для более эффективного последующего заполнения (чтобы реже тербовалось создавать новые блоки и соответстенно "разделять" существующие).

Индекс по N полю (с таким набором возможных значений) будет чуть больше чем аналогичный индекс для Int поля. Хотя физически ключ для N поля (или любого другого "числового" выражения) имеет размер в 8 байт - но для целочисленных значений в узком диапазоне малых чисел он неплохо "упаковывается", и занимает в узлах-листьях индекса всего по 3 байта. Правда в узлах-ветках упаковка не применяется, и для структуры не-Compact индекса в один блок поместится всего 500/16=31 ключей - по сравнению с 500/12=41 для Int поля и 500/9=55 для c(1) поля.

По кодировке тоже вопрос очень важный - FPD прога наверняка работает с таблицами в CP=866, а для таких таблиц 9-й фокс не будет вообще использовать при оптимизации индексы по символьным полям. Надо понижать уровень "совместимости движка", и следить чтобы не влететь на возможные ошибки (если реальные данные таки не русские буквы, а произвольные коды, в т.ч. всякие там chr(2) и т.п.).

Спасибо, Игорь, за развернутый ответ!
Спасибо всем за участие!

Первые тесты показали, что по С полю выборка происходит незначительно, но быстрее.

Но все это я пока экспериментирую на локальной машине с подставной таблицей, созданной по подобию, так сказать. Во вторник буду тестить на месте.





Исправлено 1 раз(а). Последнее : Chemberzhy, 29.09.18 19:58

Отчет:
1. Вариант № 1: выборка непосредственно на сервере: однозначно с индексом по символьному полю работает быстрее, меньше нагрузка на процессор.

2. Вариант № 2: копирование данных с сервера в курсор на рабочую машину, выборка уже на рабочей машине, возврат результата в виде таблицы на сервер.
Копирование и выбрка вместе происходят выстрее, чем в варианте 1, при этом сервер практически не нагружается, однако при отправке результата с конвертацией опять на сервер все радости тают мгновенно. Третья процедура напрочь съедает весь выигрыш от первой и второй. Есть, конечно, плюшка- большая уверенность есть в том, что второй вариант безопаснее в смысле возможного сбоя и не мешает работать остальным пользователям.

Всё таки остановился на варианте 1.

Как думаете, верный выбор, или ради безопасности стоит пренебречь скоростью?

Канал связи надёжный?

Связь, к счастью, качественная, здесь все в ногу со временем.

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





Исправлено 1 раз(а). Последнее : Chemberzhy, 03.10.18 11:47

Ну если связь нормальная, то можно тянуть выборки по "сети", главное посмотри на оптимизацию sys(3054).

PaulWist
Ну если связь нормальная, то можно тянуть выборки по "сети", главное посмотри на оптимизацию sys(3054).

Да-да, разница может быть ОЧЕНЬ существенной.