InterBase vs MS Access

← →
Tracer (2002-12-10 17:11) [0]

Есть две абсолютно одинаковые таблицы в MS Access97 и IB 5.5 Два абсолютно одинаковых запроса, загоняющие данные из этих таблиц во временную. В Access запрос работает ~3 мин. В IB - от 13 до 20 минут и более. Кол-во записей - 295302. Кто-то может прокомментировать столь плохой результат IB? Повторюсь, что индексы идентичны в обоих случаях, в настройках IB я выставлял параметры максимальной производительности, пробовал выполнять этот запрос как через BDE, так и в WISQL. Вот такая запара получается. Access не устраивает своим ограничением на размер БД 1 Гиг, более навороченные СУБД - своими жуткими ценами (все должно быть лицензионным). Кто-то может что-то посоветовать?

← →
Digitman (2002-12-10 17:20) [1]

приведи структуру таблицы, индексов к ней и текст select-запроса

← →
Prooksius (2002-12-10 17:21) [2]

http://www.ibase.ru
Почитай про планирование запросов.
Да, у IB с оптимизатором проблемы (пока) :(
Можно указывать план запроса вручную.

← →
sniknik (2002-12-10 17:24) [3]

> Access не устраивает своим ограничением на размер БД 1 Гиг

на самом деле 2 гиг. Возьми MSDE (бесплатный MSSQL), то же ограничение 2 гиг. но работать приятнее функций больше, можно без заморочек пересесть на MSSQL.

IB бесплатные тоже есть, вроде.

← →
Tracer (2002-12-10 17:57) [4]

Digitman
/* Extract Table FULL_ARH_AMORT */

/* Table: FULL_ARH_AMORT, Owner: SYSDBA */
CREATE TABLE FULL_ARH_AMORT (TYP_PRVA SMALLINT,
KOD_GRUPPA_NU SMALLINT,
DOP_GRUPP SMALLINT,
SFR_CEHA SMALLINT,
SFR_UCHA SMALLINT,
SFR_BRIG SMALLINT,
NOM_INVK VARCHAR(9) CHARACTER SET WIN1251 NOT NULL,
GOD_AMORT SMALLINT NOT NULL,
MES_AMORT SMALLINT NOT NULL,
SH_ZATRAT VARCHAR(10) CHARACTER SET WIN1251,
BAL_STOIM_NACH_MES_NALOG FLOAT,
NORM_AMORT_NALOG FLOAT,
POPR_KOFF FLOAT,
SUM_AMORT FLOAT,
NACHALN_STOIM_BUH FLOAT,
BAL_STOIM_NACH_MES_BUH FLOAT,
IZN_SUMA FLOAT,
KOD_OTRG FLOAT,
KOD_MEST FLOAT,
SUM_IZNOSA FLOAT,
KOMU_AREND FLOAT,
NORM_AMORT_BUH FLOAT,
KOD_VIDA_OS FLOAT,
NCH_STOIM_NALOG FLOAT,
SUM_IZNOS_NALOG FLOAT,
SCHET FLOAT,
AMORT_STOIM FLOAT,
SUM_AREND FLOAT,
SUM_INDEX FLOAT,
PRVA_BUH SMALLINT,
CONSTRAINT FULL_ARH_AMORTPRIMARYKEY1 PRIMARY KEY (NOM_INVK, GOD_AMORT, MES_AMORT));

Индексы:
SHOW INDEX FULL_ARH_AMORT
FULL_ARH_AMORTINDEX1 INDEX ON FULL_ARH_AMORT(DOP_GRUPP)
FULL_ARH_AMORTINDEX10 INDEX ON FULL_ARH_AMORT(MES_AMORT)
FULL_ARH_AMORTINDEX2 INDEX ON FULL_ARH_AMORT(SFR_CEHA, SFR_UCHA, SFR_BRIG)
FULL_ARH_AMORTINDEX3 INDEX ON FULL_ARH_AMORT(KOD_GRUPPA_NU)
FULL_ARH_AMORTINDEX4 INDEX ON FULL_ARH_AMORT(NOM_INVK)
FULL_ARH_AMORTINDEX5 INDEX ON FULL_ARH_AMORT(TYP_PRVA)
FULL_ARH_AMORTINDEX6 INDEX ON FULL_ARH_AMORT(SFR_CEHA)
FULL_ARH_AMORTINDEX7 INDEX ON FULL_ARH_AMORT(SFR_UCHA)
FULL_ARH_AMORTINDEX8 INDEX ON FULL_ARH_AMORT(SFR_BRIG)
FULL_ARH_AMORTINDEX9 INDEX ON FULL_ARH_AMORT(GOD_AMORT)
RDB$PRIMARY18 UNIQUE INDEX ON FULL_ARH_AMORT(NOM_INVK, GOD_AMORT, MES_AMORT)

Запрос:
INSERT INTO tmpFull_Arh_Amort ( TYP_PRVA, KOD_GRUPPA_NU, DOP_GRUPP, SFR_CEHA, SFR_UCHA, SFR_BRIG, NOM_INVK, GOD_AMORT, MES_AMORT, SH_ZATRAT, BAL_STOIM_NACH_MES_NALOG, NORM_AMORT_NALOG, POPR_KOFF, SUM_AMORT, NACHALN_STOIM_BUH, BAL_STOIM_NACH_MES_BUH, IZN_SUMA, KOD_OTRG, KOD_MEST, SUM_IZNOSA, KOMU_AREND, NORM_AMORT_BUH, KOD_VIDA_OS, NCH_STOIM_NALOG, SUM_IZNOS_NALOG, SCHET, AMORT_STOIM, SUM_AREND, SUM_INDEX, PRVA_BUH, id_user )
SELECT amort.TYP_PRVA, amort.KOD_GRUPPA_NU, amort.DOP_GRUPP, amort.SFR_CEHA, amort.SFR_UCHA, amort.SFR_BRIG, amort.NOM_INVK, amort.GOD_AMORT, amort.MES_AMORT, amort.SH_ZATRAT, amort.BAL_STOIM_NACH_MES_NALOG, amort.NORM_AMORT_NALOG, amort.POPR_KOFF, amort.SUM_AMORT, amort.NACHALN_STOIM_BUH, amort.BAL_STOIM_NACH_MES_BUH, amort.IZN_SUMA, amort.KOD_OTRG, amort.KOD_MEST, amort.SUM_IZNOSA, amort.KOMU_AREND, amort.NORM_AMORT_BUH, amort.KOD_VIDA_OS, amort.NCH_STOIM_NALOG, amort.SUM_IZNOS_NALOG, amort.SCHET, amort.AMORT_STOIM, amort.SUM_AREND, amort.SUM_INDEX, amort.PRVA_BUH, :puser
FROM FULL_ARH_AMORT amort
WHERE AMORT.GOD_AMORT*100+AMORT.MES_AMORT>=:dat1 And AMORT.GOD_AMORT*100+AMORT.MES_AMORT<=:dat2;

Индексы не используются. Здесь два варианта - либо переписать запрос, либо проиндексировать выражение "AMORT.GOD_AMORT*100+AMORT.MES_AMORT", что IB не позволяет:(

← →
Tracer (2002-12-10 18:01) [5]

sniknik ©

>на самом деле 2 гиг. Возьми MSDE (бесплатный MSSQL), то же ограничение 2 гиг. но работать приятнее функций больше, можно без заморочек пересесть на MSSQL.

Можно поподробнее об MSDE? Где о нем можно узнать поподробнее?
Однозначно с Access"a пересаживаться нужно, потому что при интенсивной работе нескольких пользователей (отчетный период, к примеру) даже ограничение на 2 Гига не устроит:(

← →
BlackTiger (2002-12-10 18:04) [6]

Хе-хе! Не такай уж плохая весЧь Аксесс!
А вообще, если у тебя база больше 300-500 мегов, то надо брать бызы по-серьезней: MSSQL, Oracle, DB/2.
Нельзя сказать, что на других не будет работать - будет, но...
Почувствуешь разницу, когда начнешь использовать. И не покупайся на "бесплатность" и "перспективность"!

← →
Romkin (2002-12-10 18:19) [7]

Отрубай все индексы, кроме первичного ключа нафиг :-))
Они же все обновляются при вставке записи... Да и вообще, что за таблица?! Зачем столько индексов???
И для where не поленись смонтировать дополнительные поля данных, в которые в триггерах пиши значения типа AMORT.GOD_AMORT*100+AMORT.MES_AMORT, и по ним индексируй...

← →
Tracer (2002-12-10 18:28) [8]

BlackTiger

>А вообще, если у тебя база больше 300-500 мегов, то надо брать бызы по-серьезней: MSSQL, Oracle, DB/2.

Вобщем-то это все уже работает на Foxpro с вполне приемлимой производительностью - бесплатно, но совсем неперспективно:)

← →
sniknik (2002-12-10 18:35) [9]

Tracer (10.12.02 18:01)
MSDE случайно ссылка завалялась :о) может не совсем то
http://www.osp.ru/win2000/sql/2000/01/001.htm
а взять к примеру с диска с MSOffice XP, папка MSDE2000 (если конечно диск не "резан" пиратами)
переход на MSSQL выполняется "переключением" баз.

← →
Tracer (2002-12-10 18:36) [10]

Romkin © (10.12.02 18:19)
>Отрубай все индексы, кроме первичного ключа нафиг :-))
Они же все обновляются при вставке записи... Да и вообще, что за таблица?! Зачем столько индексов???

Это архив амортизации для задачи по учету основных фондов.
Они реально там нужны все. Часть - для ссылочной целостности, часть - для выборок, без них все еще хуже:))

>И для where не поленись смонтировать дополнительные поля данных, в которые в триггерах пиши значения типа AMORT.GOD_AMORT*100+AMORT.MES_AMORT, и по ним индексируй...

А реально ли это в Calculated поле загонять и по ним индексировать? Calculated в IB индексируется?

← →
Tracer (2002-12-10 18:41) [11]

sniknik ©
Спасибо. Об MSDE уже читаю. Лицензионных дисков с Офисом у нас завались:)) Вполне возможно, что MSDE подойдет если есть возможность БД резать на несколько файлов... Или там ограничение на общий объем БД?.. Вобщем, буду ковырять.

← →
sniknik (2002-12-10 18:51) [12]

> Или там ограничение на общий объем БД?
еще не дочитал? да на общий. запросто обходится простым планированием и делением данных по разным базам (естественно должны быть несвязанные). а доступ из одной базы к данным другой элементарен.

но вы всетаки должны понимать, что это, замануха и цель ее заставить вас купить MSSQL. если сможете постарайтесь избежать, но немногим это удается если начинают ... :-))

← →
ЮЮ (2002-12-11 03:33) [13]

>Они реально там нужны все. Часть - для ссылочной целостности, часть - для выборок, без них все еще хуже:))

Создать их после перекачки данных

← →
Reindeer Moss Eater (2002-12-11 09:17) [14]

>Tracer
Попробуй повторить свой эксперимент, но данные вставляй с рабочей станции, а не с машины где установлены Interbase Server и лежит файл данных Access.

InterBase vs MS Access Найти похожие ветки