Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 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.014 c
3-60069
alienka
2003-05-27 11:11
2003.06.19
KeyList в колонке DBGridEh


1-60153
Shluz
2003-06-06 18:39
2003.06.19
Проект без форм....


1-60226
BDRON
2003-06-05 15:10
2003.06.19
Иконка для файла


14-60421
Fredericco
2003-06-03 17:47
2003.06.19
Вопрос про корректность кода.


3-60060
GreySerg
2003-05-28 11:40
2003.06.19
Как восстановить базу данных Interbase 5.5 ?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский