» InterBase и FireBird: вопросы по работе и их решение

Похоже OXDBA с нами нет.
- Что Вы думаете на счёт
select
50 join
plan Один индекс?

Добавлено:
Ладно, второй вопрос - гдето видел кейс-сенситив не сенситив индексы. Непомню - может IBExpert новый был. Реално не помню в натуре. Если таков есть отпишите.

Цитата:

гдето видел кейс-сенситив не сенситив индексы

Можно сделать индекс по выражению:
CREATE INDEX IDX1 ON T1 COMPUTED BY (UPPER(COL1))

Добавлено:

Цитата:

- Что Вы думаете на счёт  
select
50 join
plan Один индекс?

Не понял мысли.

exteris
На момент написания вопроса я не знал действительности. Возможно знал из предыдущих жизней, но составлять планы я учился сегодня.

Цитата:

Не понял мысли.

Индекс используется в двух случаях - поиск и последовательное чтение - это огромная разница минуя учебники. Могу объяснить скайпом и только матом. ))))) Обязательный вывод - вопрос не по существу.

Кейс - да, интересовало только это. - Зачёт.

Извиняюсь за экспрессию. Я сейчас не могу сказать что подобрал для себя оптимальный способ писать план - значит утверждать ничего не могу, академический подход ещё не сформирован.

Подскажите, как сделать следующий фокус. Есть БД, в ней есть поле типа Timestamp. Необходимо во всех записях этого поля увеличить время (только время, дату надо оставить) на один час.

Maximus777

Код: UPDATE MY_TABLE
SET MY_FIELD_TIMESTAMP = DATEADD(HOUR,1,MY_FIELD_TIMESTAMP)

eddoc
Yes! Работает! Благодарю.

Анекдотичный случай. Хочу озвучить. Обычный примари - триггер сделал эксперт. Пол часа не могли понять почему гад не вставляет. Выяснилось - Рома - ололо. Для поля - примари кей был выбран домен - у него по дефоолту 0. Но мы то пол часа мозг морщили. Вот мы ололо.

Возвратом к датасоурце. эта фигня умеет делать клозеопен и делает это всегда. Потому что морщить лоб вредно. Постэвент в этом случае пможет. В начале, потом открутятпревилегии, переименуют папки и всем расскажут что Вы не козёл а просто не всё учли.

delover
Вы, уважаемый, себе блог что ли какой завел. Ваши словесные исупражнения в этом форуме выглядят не совсем уместно.

Я конечно понимаю, что вам нас:%;ть на мнение окружающих, а модераторы забыли про эту ветку. Но разум же у вас есть...

eddoc Присоединяюсь.

eddoc
Извиняюсь, я иногда перерабатываю, и видимо в тот момент был не разборчив в детальном пояснении мысли. Придётся пост оставить для стыда мне.

Тем не менее, семиотики SQL зря хлебушек свой кушают (IMHO*IMHO). В SQL нет выражения "where id =?? :id". В моей интерпретации - когда два ?? это значит надо вернуть только True. Это происходит каждый раз когда параметр = null. Из математики очевидно, что выполняется это 1 раз для запроса и в том случае если Null, то запрос не выполняет сравнения. Следовательно тратится меньше времени. Это было из контекста той задачи, когда пришлось мучить удалённую программу до десяти вечера.

ЗЫ
Хотел непонятно, а вышло совсем непонятно, в продолжении темы о POST EVENT. - Надо то только единственное поле Modified teble. И тогда if (t1.modified) CloseOpen. Однако за экспрессию большие извинения.

where (:id not null) and (id = :id)

AlexCoRu
Не анд а ор блин.

Добавлено:
написано же труе

Цитата:

в том случае если Null, то запрос не выполняет сравнения

Добавлено:
А мне вот непонятно почему NULL <> NULL?
Приходится делать так:
Код: where (FIELD1 = :PARAM1) or (FIELD1 is null and :PARAM1 is null)

AlexCoRu

Цитата:

А мне вот непонятно почему NULL <> NULL?

всё гораздо "хуже"

Код:
(NULL=NULL) = NULL (а не true)
(NULL<>NULL) = NULL (а не false)

AlexCoRu

Цитата:

А мне вот непонятно почему NULL <> NULL?

потому что NULL можно интерпретировать как "ничего"

AlexCoRu
Всё очень просто. Пример:
У Иванова и Рабиновича изъяли из паспорта графу «национальность». Теперь в базе данных у обоих стоит Null. Но это же не означает, что Иванов и Рабинович одной национальности…

Varenik, э-э-э, вот тут-то и подвох. Они оба неопределённой национальности, следовательно равноправны, следовательно попадают в категорию лиц без национальности, а значит одинаковы (равны до выяснения обстоятельств).

AlexCoRu
равноправие никакого отношения к национальности не имееет, лиц без национальности не бывает (бывают без гражданства)

AlexCoRu, Varenik
Девочки, не надо ссориться! (с) Даже Вика об этом знает

Да, ладно, понятно, что null не может быть категоретизирован. Почему тогда GROUP BY FIELD группирует FIELD которые is null?

Добавлено:
Т.е. поля со значениями NULL группируются. А должны бы вообще не участвовать в группировке?

Добавлено:

Цитата:

лиц без национальности не бывает

А-а-а! Шикарно! Толерантно!

Добавлено:
Ёще чють поясню:
FIELD = 0 (true или false)
FIELD = 1 (true или false)
FIELD = NULL (всегда NULL)
По какому признаку (true, false, null) они группируются?

AlexCoRu

Цитата:

Т.е. поля со значениями NULL группируются. А должны бы вообще не участвовать в группировке?

это уже философия пошла
с точки зрения того, что (NULL=NULL) даёт null их группировать таки нельзя, они не равны между собой, а вот с точки зрения field=2, field=3, .... field is null - можна

Ребят а нелзя ли без заумства? Обычная процедура, если я задал ID то хочу этот ID а если не задал - хочу все. И кто скажет что это редкий случай? Семиотики собирают общее в языке и ищут способы всё упростить. На языке SQL семиотики явно отдохнули.

Цитата:

Обычная процедура, если я задал ID то хочу этот ID а если не задал - хочу все

На мой взгляд - две процедуры лучше. Например, SELECT_SALES_ALL и SELECT_SALES_DEPARTMENT (DEPARTMENT_ID).

Это именно 2 процедуры - одна с параметром другая с суфиксом _null. Только удваивать придётся все процедуры в базе. - Весёлый путь к прогрессу.

delover

Цитата:

Это именно 2 процедуры

ну а в одной такой процедуре обычно что бывает?
что-то типа такого

Код:
......
if (param is null) then
begin
........ что-то делаем
select ...... /*select all*/
end
else
begin
........ всё то же самое делаем
select ...... where (id=:param) /*select by param*/
end

delover

Цитата:

Обычная процедура, если я задал ID то хочу этот ID а если не задал - хочу все. И кто скажет что это редкий случай?

Дык уже:
Add support for "some_col = ? or ? IS NULL" conditions

http://tracker.firebirdsql.org/browse/CORE-2298

AlexPetrovich
Эх спасибо, но боюсь я был опять не до конца понятен в выражении мысли. Ещё раз делаю упор - семиотики ищут общее. Находят. Это две функции мозга - поиск информации и анализ. Семиотики их выполняют на 100%. Третья функция - синтез. Всё таки, я не предлагал игнорировать особенности сервера. Если null <> null, то будет справедливо, что t1.id =?? null вернёт False. Это уже контекст сервера и его математической архитектуры. Я предложил, только, уйти немного от этого. Для PrimaryKey полей не произойдёт ничего существенного, но в других случаях будет дополнительная фильтрация или дополнительная выборка. Однако аксиоматический базис будет не тронут.

Символ одного вопроса мне не по душе. - Я тогда ?mas_ могу перепутать.