Форум: "Базы";
Текущий архив: 2003.06.19;
Скачать: [xml.tar.bz2];
ВнизПочему не могу явно указать имя индекса? Найти похожие ветки
← →
plans (2003-05-27 13:24) [0]Трабл при использовании IBManager:
select t1.f1
from table t1
where t1.id = :id
plan (t1 index(IDX_id))
ругается, что нет такого индекса:
fmCompile.trCompile:
Invalid token.
invalid request BLR at offset 132.
there is no index IDX_id for table <table>.
Как правильно указать? Диалект 3. Индекс точно есть.
← →
Alexandr (2003-05-27 13:34) [1]да он и сам должен прицепиться.
Зачем тебе план вручную писать для такого простого запроса.
← →
Alexandr (2003-05-27 13:35) [2]диалект 3 говоришь...
А чего там, с регистром символов не напутано?
← →
plans (2003-05-27 13:35) [3]так не прицепляется... natural в плане пишет...
← →
plans (2003-05-27 13:36) [4]не напутано. уже и кавычки ставил и регистр менял - ни фига.
← →
plans (2003-05-27 13:39) [5]
> Alexandr © (27.05.03 13:34)
я просто хочу на простом убедить почему не могу указать имя индекса. а я оптимизирую большой запрос - там у меня почему-то, если есть FK, то не подхватывает индекс.
← →
plans (2003-05-27 13:52) [6]VМастаки, омогите не могу догнать что ему надо. не хочет подключать индекс если его яно указать...
← →
Zz_ (2003-05-27 13:59) [7]IDX_id - это чистый индекс или имя FK?
Если имя FK, то насколько я помню, IB
глубоко ложит на это имя, а использует,
самосозданный индеск RDB$FOREIGNxxx. Его
тогда и надо в плане прописывать. Кажись
аналогично и с PK.
← →
DarkGreen (2003-05-27 13:59) [8]Тебе уже Alexandr © (27.05.03 13:35) говорил, ни чего с регистрами не напутано? Посмотри в RDB$INDICES как твой индекс называется
← →
plans (2003-05-27 14:10) [9]
> IDX_id - это чистый индекс или имя FK?
чистый индекс, но по этому полю еще есть и PK.
← →
Zacho (2003-05-27 14:19) [10]Не лучше ли разобраться, почему оптимизатор не использует индексы ? Может в данном случае natural действительно быстрее, а конкретное указание плана приведет наоборот, к ухудшению производительности ?
← →
plans (2003-05-27 14:23) [11]
> Zacho © (27.05.03 14:19)
> Не лучше ли разобраться, почему оптимизатор не использует
> индексы ?
как?
я хочу понять почему явное указание индекса не катит?
← →
Danilka (2003-05-27 14:26) [12]Zacho © (27.05.03 14:19)
а разве он в этом случае будет ругаться на индекс?
plans
приведи DDL своей таблицы, вместе с реальным запросом.
← →
plans (2003-05-27 14:32) [13]/* Таблица: employee_working */
CREATE TABLE "employee_working" (
"id" INTEGER NOT NULL,
"FirstName" RUS_FIO collate PXW_CYRL,
"MiddleName" RUS_FIO collate PXW_CYRL,
"LastName" RUS_FIO collate PXW_CYRL,
"fio" COMPUTED BY ("MiddleName"||" "||"FirstName"||" "||"LastName"),
"id_proffesion" INTEGER,
"rating" INTEGER);
/* Primary keys definition */
ALTER TABLE "employee_working" ADD CONSTRAINT "PK_employee_working" PRIMARY KEY ("id");
/* Foreign keys definition */
ALTER TABLE "employee_working" ADD CONSTRAINT "FK_employee_working2" FOREIGN KEY ("id_proffesion") REFERENCES "profession" ("id") ON DELETE SET NULL ON UPDATE CASCADE;
/* Indices definition */
CREATE INDEX "IDX_id_e" ON "employee_working" ("id");
SET TERM ^ ;
/* Triggers definition */
/* Trigger: "employee_working_BD" */
CREATE TRIGGER "employee_working_BD" FOR "employee_working" ACTIVE
BEFORE DELETE POSITION 0
AS
BEGIN
delete from "installation_of_ telephones" o
where o."id_owner" = old."id";
END
^
SET TERM ; ^
/* Таблица: profession */
CREATE TABLE "profession" (
"id" INTEGER NOT NULL,
"profession_txt" RUS_TXT_200 collate PXW_CYRL);
/* Primary keys definition */
ALTER TABLE "profession" ADD CONSTRAINT "PK_profession" PRIMARY KEY ("id");
/* Indices definition */
CREATE INDEX "IDX_id_prof" ON "profession" ("id");
SET TERM ^ ;
/* Triggers definition */
/* Trigger: "AI_profession_id" */
CREATE TRIGGER "AI_profession_id" FOR "profession" ACTIVE
BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW."id" IS NULL) THEN
NEW."id" = GEN_ID("profession_id_GEN", 1);
END
^
SET TERM ; ^
запрос такой:
select t1."fio", t2."profession_txt"
from "employee_working" t1
join "profession" t2 on t1."id_proffesion"=t2."id"
where t1."id"=:id_employee
план:
PLAN MERGE (SORT (T1 NATURAL),SORT (T2 NATURAL))
← →
Zacho (2003-05-27 14:33) [14]
> plans (27.05.03 14:23)
> как?
Хорошенько подумать. Конкретную инструкцию для общего случая дать не могу.
> я хочу понять почему явное указание индекса не катит?
Ну синтаксис вроде правильный. Единственно, что приходит в голову - или ошибка в написании имени индекса, или какая-то заморочка с регистрозависимостью и кавычками в диалекте 3. Впрочем, если при создании индекса указывал имя большими буквами и без кавычек - то и в запросе пойдет без кавычек.
Глупое предположение: а индекс активен ?
← →
plans (2003-05-27 14:39) [15]
> Глупое предположение: а индекс активен ?
галочки стоят. у PK и FK - нет.
← →
plans (2003-05-27 14:45) [16]вот попробовал запрос с order by - индексы не использует, если убрать order - то использует, как тут быть?
← →
Zacho (2003-05-27 14:51) [17]
> plans (27.05.03 14:39)
Какие еще галочки ? Где ?
В общем, если индексы не активны - сделай активными. Если активны - собери по ним статистику. Дополнительные индексы по полям, входяшим в PK и FK - удали. После этого оптимизатор и сам должен построить нормальный план.
Еще несколько советов:
1. У тебя "id_proffesion" INTEGER допускает NULL и при этом в запросе join "profession" . Так и надо ? Или все-таки надо left join (или NOT NULL) ?
2. Триггер /* Trigger: "employee_working_BD" */ нафиг не нужен, достаточно для installation_of_ telephones создать FK с ON DELETE CASCADE
3.Так ли тебе нужна регистрочуствительность имен объектов
БД ? При создании метаданных пиши все имена большими буквами и без кавычек - избежишь разнообразных наступаний на грабли.
← →
plans (2003-05-27 14:59) [18]
> Дополнительные индексы по полям, входяшим в PK и FK - удали
у меня их и не было раньше. когда я их сделал - быстрее стало работать.
← →
Zacho (2003-05-27 15:04) [19]
> plans (27.05.03 14:59)
Да не нужны они. Разве только для ручного задания плана. Но для такого запроса план и оптимизатор должен построить оптимальный. Конечно, если индексы активны. Так что если индексы по PK и FK не активны - немедленно сделай активными.
← →
plans (2003-05-27 15:26) [20]
> Какие еще галочки ? Где ?
это в IBManager можно посмотреть индексы - если он активен, то стоит галочка. Так вот на PK и FK - галочки нет и поставить ее не могу.
← →
Zacho (2003-05-27 15:58) [21]
> plans (27.05.03 15:26)
Выкинь IBManager :-)
Ну активируй их запросом, в крайнем случае - убей PK и FK и создай заново.
← →
Danilka (2003-05-27 16:02) [22]а вместо IBManager используй отличную вещь: IBExpert
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.06.19;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.008 c