Уточнения по работе с полями Delphi-FB

[DeveloPerchik]

Здравствуйте!
(создал одну тему, чтобы не создавать мусор.)
1. При обращении к полям как лучше писать Dataset.FieldByName().Value или точно указывать типа данных Dataset.FieldByName().AsInteger/AsString/итд? Что это даёт? Какая разница? Как быстрее?
2. FB2.5 как можно сразу переименовать название индекса? IBexpert не позволяет этого сделать (нужно снимать все PK/FK). Можно как-то переименовать индекс без снятия PK/FK?
3. FB2.5 если поле BLOB =null много ли места в БД оно занимает? Что хуже (менее экономно) хранить поле типа varchar или blob? Varchar поле всегда даже если пустое занимает указанное пространство? (например 100символов)

[Аватар]

1. Value типа Variant - неизбежные потери по скорости
3. Varchar занимает по факту + память для хранения длины этого факта. По blob-у поиска не сделаешь, да и выборка-запись помедленнее varchar. Смотреть нужно что предполагается хранить

[Stilet]

Что это даёт? Какая разница? Как быстрее?

Думаю что на это могут ответить только исходники сего компонента. Посмтори как устроен TField, и какие функции вызываются при вызове Value и AsString

если поле BLOB =null много ли места в БД оно занимает?

По-моему у всех BLOB есть определенный минимальный размер. Я точно не знаю но кажись 80 байт сегмент. Хотя должно конфигурироваться в файле настроек огнептички.

Что хуже (менее экономно) хранить поле типа varchar или blob?

http://www.firebirdsql.su/doku.php?id=tipy_dannyx
Тут все скажут.

По blob-у поиска не сделаешь

Чего так?

[Аватар]

Сообщение от Stilet

Чего так?

Ну не совсем нельзя, udf использовать прийдется и только символьный поиск. Но медленно - индекс не построишь

[Stilet]

А в Огнептичке нет полнотекстового поиска? В Оракле и Информиксе и даже Сиквеле такие индекса построить можно.

[Аватар]

Sphinx есть, но это наружка. Возможно и другие примочки

[DeveloPerchik]

1. Уточнение - то самый быстрый способ это [Dataset1.FieldByName().AsInteger:=D ataset2.FieldByName().AsInteger] ? Интересовало если например поле Integer, то быстрее будет если использовать .Value или .AsInteger ??? Иными словами если тип данных известен, то как быстрее передавать данные - универсальным Value или точным указанием типа данных ? При передаче с указанием типа данных не будет ли происходить каждый раз лишнее преобразование [.AsInteger - > ValueToInteger] ??
2.
3. То есть поле Varchar 1000 при кол-ве текста в 10 будет занимать всего 10 ?? Неужели стали сжимать текстовые строки ? Или всё же в самой БД под поле так и выделяется 100, просто вместо пробелов пусто ?
Нужно хранить некий текст который может быть от 0 до 1000 символом - как это более экономично делать? Тестовым полем varchar или текстовым blob ?

[Прик]

3.
При названных условиях Varchar, конечно. По текстовым полям, длина значений которых не превышает (насколько помниться) 4 Кб, можно создавать индексы.
Доступ ускоряется в разы. Важно для больших объемов. Если записей немного (5-10 тыс.) - это не так и актуально - лишние индексы не уменьшают энтропии.

К слову о хранении данных в FB (кому то это еще важно). Страничная организация файлов в FB делает достаточно быстрым доступ к любому типу данных.
Тип varchar не хранит все установленный для поля байты, только переданную строку и сжатие здесь ни причем. Разумеется, лишние символы обрезаются, если их больше чем зарезервировано для этого поля.

ИМХО. Для современных процессоров с их памятью ловить микросекунды на одиночных операциях сравнения или присвоения (Dataset1.FieldByName().AsInteger:= Dataset2.FieldByName().AsInteger), по крайней мере, не ценить свое время.

[_SERGEYX_]

Dataset1.FieldByName().AsInteger:= Dataset2.FieldByName().AsInteger

Если не ошибаюсь, обращение к полю по его индексу всегда быстрее, чем обращение по имени, т.е.

Dataset1.Fields[0].AsInteger:= x;

сработает быстрее, чем

Dataset1.FieldByName('summa').AsInteger:= x;

А создавать blob-поля без особой необходимости, имхо, вообще нет смысла. Разве что для хранения файлов, картинок или больших текстов.