Форум: "Базы";
Текущий архив: 2002.12.30;
Скачать: [xml.tar.bz2];
Вниз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.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.12.30;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.01 c