Каждая запись хранит номер формата (1 байт). Формат записи содержит все необходимые сведения для декодирования записи в том числе типы и смещения. Но когда для таблицы делаешь alter более 255 раз будет больно (либо бекап рестор, либо пересоздание таблицы с полной перезаливкой данных). Впрочем не любой alter меняет формат. Это одна из особенностей фб, которая с одной стороны позволяет делать быстрый alter таблицы без ее блокировки, но с другой ограничивает полет фантазий разработчика.
Во-первых сжимаются не отдельные varchar, а запись целиком. То есть потенциально могут быть сжаты и другие типы данных если там null.
Во-вторых как я уже говорил кодирование в зависимости от типа данных пробовалось и оно оказалось медленней. Возможно где-то что-то упустили. Но факт остается фактом.
И в-третьих, firebird 5.0 не вводит новую мажорную ods. RLE использовался еще со времен interbase, просто сейчас его усовершенствовали. Таким образом 5 ка может работать с базами данных 4 ки.
В будущих версиях сжатие/ кодирование записи может изменится.
Microsoft SQL Server в некоторых случаях далек от SQL стандарта. В прочем ни один он, все так или иначе отклоняются от стандарта, ибо стандарт обычно формируется постфактум, когда коммерческие субд уже реализовали некоторую фичу и пропихивают ее в стандарт.
Из курсора читается обычно не одна запись. Предположим в первой записи один символ, а во второй 200, в третьей 50. Предлагаешь на каждом фетче буфер переаллоцировать? Сейчас переаллокаций не происходит вообще. Выделяется буфер фиксированного размера и в нем просто перезаписываются байтики.
Не знаю где вы этот "классический" вариант нашли. Его в Firebird с роду не было. Направление всегда указывалось для всего индекса, а не отдельного столбца.
А дополнился синтаксис предложением where, которое фильтрует ключи записей по некоторому условию. Те что не соответствуют предикату просто не будут попадать в индекс.
Подход с кодированием байтов в зависимости от типа вместо сжатия данных пробовался разработчиками и оказался более медленным. Проще иметь буфер фиксированной длины, чем постоянные реалокации памяти.
Что касается смены тип с varchar(100) на varchar(200), то это происходит быстро потому что в реальности записи на диске вообще не изменяются. Просто записывается новый формат таблицы, а при извлечении данных записи со старым форматом преобразуются к новому на лету.
Я не знаю что там за PHP драйвер использован, наверное PDO. Но выполняю простейший запрос:
select
current_timestamp
from rdb$database
и видим:
|------------------------------------------|
| select |
| current_timestamp |
| from rdb$database |
|------------------------------------------|
| Incorrect values within SQLDA structure |
Что обозначает, что там либо fbclient не от 4.0, либо что pdo_firebird тупо до сих пор не знает типа TIMESTAMP WITH TIME ZONE. Эхх... опять что ли придётся Pull Request пилить (((
Если уж делать, то не только для insert, а нормальный Table Value Constructor, чтобы можно было и для insert, update, delete, merge, select использовать
MERGE INTO SalesReason AS Target
USING (VALUES ('Recommendation','Other'), ('Review', 'Marketing'), ('Internet', 'Promotion'))
AS Source (NewName, NewReasonType)
ON Target.Name = Source.NewName
WHEN MATCHED THEN
UPDATE SET ReasonType = Source.NewReasonType
WHEN NOT MATCHED BY TARGET THEN
INSERT (Name, ReasonType) VALUES (NewName, NewReasonType)
Материализованные представления вещь безусловно полезная, но их функциональность можно обеспечить существующими средствами (обычная таблица + ХП), пусть и с большими затратами и менее красиво. Поэтому у них не очень большой приоритет. А вот поддержку геоданных, например, нормально без поддержке в ядре не сделать.
Извиняюсь скрипты создания БД я забыл выложить. Что каcается заливки данных, то я это делал через генератор данных IBExpert и импорт каталога товаров с какого-то сайта. Уже сам не помню. Выложил файлы готовых БД.
Насчёт 2 я посмотрю, у меня всё и так запускалось.
Нет смысл статьи не в этом. Про ibase_ и PDO обзор был дан лишь для того, чтобы люди понимали как работать с Firebird на низком уровне. Да и PDO драйвере для FB есть свои баги, которые сейчас правятся.
Спасибо, поправил ошибки, Произвёл трассировку, действительно автокоммита после каждого оператора не происходит. Честно говоря был уверен, что ibase_ функции работают по той же схеме, что и PDO.
Не firebase, а Firebird, это совершенно разные СУБД. В общем я публикую цикл статей о том, как работать с Firebird использую самые различные технологии. Использовать или нет Firebird при разработке вашего сайта решать вам. Никаких призывов побросать свои СУБД и переходить на Firebird здесь нет. Но уж если потребовалось работать с FB, то неплохо бы с чего-то начать.
Каждая запись хранит номер формата (1 байт). Формат записи содержит все необходимые сведения для декодирования записи в том числе типы и смещения. Но когда для таблицы делаешь alter более 255 раз будет больно (либо бекап рестор, либо пересоздание таблицы с полной перезаливкой данных). Впрочем не любой alter меняет формат. Это одна из особенностей фб, которая с одной стороны позволяет делать быстрый alter таблицы без ее блокировки, но с другой ограничивает полет фантазий разработчика.
Во-первых сжимаются не отдельные varchar, а запись целиком. То есть потенциально могут быть сжаты и другие типы данных если там null.
Во-вторых как я уже говорил кодирование в зависимости от типа данных пробовалось и оно оказалось медленней. Возможно где-то что-то упустили. Но факт остается фактом.
И в-третьих, firebird 5.0 не вводит новую мажорную ods. RLE использовался еще со времен interbase, просто сейчас его усовершенствовали. Таким образом 5 ка может работать с базами данных 4 ки.
В будущих версиях сжатие/ кодирование записи может изменится.
Microsoft SQL Server в некоторых случаях далек от SQL стандарта. В прочем ни один он, все так или иначе отклоняются от стандарта, ибо стандарт обычно формируется постфактум, когда коммерческие субд уже реализовали некоторую фичу и пропихивают ее в стандарт.
Из курсора читается обычно не одна запись. Предположим в первой записи один символ, а во второй 200, в третьей 50. Предлагаешь на каждом фетче буфер переаллоцировать? Сейчас переаллокаций не происходит вообще. Выделяется буфер фиксированного размера и в нем просто перезаписываются байтики.
Не знаю где вы этот "классический" вариант нашли. Его в Firebird с роду не было. Направление всегда указывалось для всего индекса, а не отдельного столбца.
А дополнился синтаксис предложением where, которое фильтрует ключи записей по некоторому условию. Те что не соответствуют предикату просто не будут попадать в индекс.
Это нестандартно и не переносимо, поэтому такого точно не будет, а вот поддержка хинтов Аля оракул не помешала бы.
Подход с кодированием байтов в зависимости от типа вместо сжатия данных пробовался разработчиками и оказался более медленным. Проще иметь буфер фиксированной длины, чем постоянные реалокации памяти.
Что касается смены тип с varchar(100) на varchar(200), то это происходит быстро потому что в реальности записи на диске вообще не изменяются. Просто записывается новый формат таблицы, а при извлечении данных записи со старым форматом преобразуются к новому на лету.
Я не знаю что там за PHP драйвер использован, наверное PDO. Но выполняю простейший запрос:
и видим:
Что обозначает, что там либо fbclient не от 4.0, либо что pdo_firebird тупо до сих пор не знает типа
TIMESTAMP WITH TIME ZONE. Эхх... опять что ли придётся Pull Request пилить (((Насчёт 2 я посмотрю, у меня всё и так запускалось.