Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

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

Автор: delover
Дата сообщения: 02.08.2012 20:01
Похоже OXDBA с нами нет.
- Что Вы думаете на счёт
select
50 join
plan Один индекс?

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

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

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

Добавлено:

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

Не понял мысли.
Автор: delover
Дата сообщения: 03.08.2012 21:01
exteris
На момент написания вопроса я не знал действительности. Возможно знал из предыдущих жизней, но составлять планы я учился сегодня.

Цитата:
Не понял мысли.

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

Кейс - да, интересовало только это. - Зачёт.
Автор: delover
Дата сообщения: 06.08.2012 20:15
Извиняюсь за экспрессию. Я сейчас не могу сказать что подобрал для себя оптимальный способ писать план - значит утверждать ничего не могу, академический подход ещё не сформирован.
Автор: Maximus777
Дата сообщения: 08.08.2012 15:13
Подскажите, как сделать следующий фокус. Есть БД, в ней есть поле типа Timestamp. Необходимо во всех записях этого поля увеличить время (только время, дату надо оставить) на один час.
Автор: SevereK20
Дата сообщения: 08.08.2012 15:33

Цитата:
To add days, increment by 1.
To add minutes, increment by 1/1440...and so on.
Автор: eddoc
Дата сообщения: 08.08.2012 16:35
Maximus777

Код: UPDATE MY_TABLE
SET MY_FIELD_TIMESTAMP = DATEADD(HOUR,1,MY_FIELD_TIMESTAMP)
Автор: Maximus777
Дата сообщения: 08.08.2012 17:03
eddoc
Yes! Работает! Благодарю.
Автор: delover
Дата сообщения: 13.08.2012 18:12
Анекдотичный случай. Хочу озвучить. Обычный примари - триггер сделал эксперт. Пол часа не могли понять почему гад не вставляет. Выяснилось - Рома - ололо. Для поля - примари кей был выбран домен - у него по дефоолту 0. Но мы то пол часа мозг морщили. Вот мы ололо.
Автор: delover
Дата сообщения: 16.08.2012 21:37
Возвратом к датасоурце. эта фигня умеет делать клозеопен и делает это всегда. Потому что морщить лоб вредно. Постэвент в этом случае пможет. В начале, потом открутятпревилегии, переименуют папки и всем расскажут что Вы не козёл а просто не всё учли.
Автор: eddoc
Дата сообщения: 17.08.2012 17:07
delover
Вы, уважаемый, себе блог что ли какой завел. Ваши словесные исупражнения в этом форуме выглядят не совсем уместно.

Я конечно понимаю, что вам нас:%;ть на мнение окружающих, а модераторы забыли про эту ветку. Но разум же у вас есть...
Автор: YuriyRR
Дата сообщения: 18.08.2012 08:23
eddoc Присоединяюсь.
Автор: delover
Дата сообщения: 23.08.2012 17:58
eddoc
Извиняюсь, я иногда перерабатываю, и видимо в тот момент был не разборчив в детальном пояснении мысли. Придётся пост оставить для стыда мне.

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

ЗЫ
Хотел непонятно, а вышло совсем непонятно, в продолжении темы о POST EVENT. - Надо то только единственное поле Modified teble. И тогда if (t1.modified) CloseOpen. Однако за экспрессию большие извинения.
Автор: AlexCoRu
Дата сообщения: 23.08.2012 20:59
where (:id not null) and (id = :id)
Автор: delover
Дата сообщения: 23.08.2012 21:04
AlexCoRu
Не анд а ор блин.

Добавлено:
написано же труе
Автор: AlexCoRu
Дата сообщения: 23.08.2012 21:33

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

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

Цитата:
А мне вот непонятно почему NULL <> NULL?

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

Код:
(NULL=NULL) = NULL (а не true)
(NULL<>NULL) = NULL (а не false)
Автор: eddoc
Дата сообщения: 24.08.2012 14:38
AlexCoRu

Цитата:
А мне вот непонятно почему NULL <> NULL?

потому что NULL можно интерпретировать как "ничего"
Автор: Varenik
Дата сообщения: 24.08.2012 17:31
AlexCoRu
Всё очень просто. Пример:
У Иванова и Рабиновича изъяли из паспорта графу «национальность». Теперь в базе данных у обоих стоит Null. Но это же не означает, что Иванов и Рабинович одной национальности…
Автор: AlexCoRu
Дата сообщения: 24.08.2012 18:36
Varenik, э-э-э, вот тут-то и подвох. Они оба неопределённой национальности, следовательно равноправны, следовательно попадают в категорию лиц без национальности, а значит одинаковы (равны до выяснения обстоятельств).
Автор: Varenik
Дата сообщения: 24.08.2012 19:02
AlexCoRu
равноправие никакого отношения к национальности не имееет, лиц без национальности не бывает (бывают без гражданства)
Автор: eddoc
Дата сообщения: 24.08.2012 19:38
AlexCoRu, Varenik
Девочки, не надо ссориться! (с) Даже Вика об этом знает
Автор: AlexCoRu
Дата сообщения: 24.08.2012 20:17
Да, ладно, понятно, что null не может быть категоретизирован. Почему тогда GROUP BY FIELD группирует FIELD которые is null?

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

Добавлено:

Цитата:
лиц без национальности не бывает
А-а-а! Шикарно! Толерантно!

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

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

это уже философия пошла
с точки зрения того, что (NULL=NULL) даёт null их группировать таки нельзя, они не равны между собой, а вот с точки зрения field=2, field=3, .... field is null - можна
Автор: delover
Дата сообщения: 25.08.2012 00:28
Ребят а нелзя ли без заумства? Обычная процедура, если я задал ID то хочу этот ID а если не задал - хочу все. И кто скажет что это редкий случай? Семиотики собирают общее в языке и ищут способы всё упростить. На языке SQL семиотики явно отдохнули.
Автор: AlexCoRu
Дата сообщения: 25.08.2012 10:53

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

На мой взгляд - две процедуры лучше. Например, SELECT_SALES_ALL и SELECT_SALES_DEPARTMENT (DEPARTMENT_ID).
Автор: delover
Дата сообщения: 27.08.2012 00:03
Это именно 2 процедуры - одна с параметром другая с суфиксом _null. Только удваивать придётся все процедуры в базе. - Весёлый путь к прогрессу.
Автор: ant0ni02004
Дата сообщения: 27.08.2012 15:20
delover

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

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

Код:
......
if (param is null) then
begin
........ что-то делаем
select ...... /*select all*/
end
else
begin
........ всё то же самое делаем
select ...... where (id=:param) /*select by param*/
end
Автор: AlexPetrovich
Дата сообщения: 27.08.2012 16:33
delover

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

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

http://tracker.firebirdsql.org/browse/CORE-2298
Автор: delover
Дата сообщения: 27.08.2012 17:32
AlexPetrovich
Эх спасибо, но боюсь я был опять не до конца понятен в выражении мысли. Ещё раз делаю упор - семиотики ищут общее. Находят. Это две функции мозга - поиск информации и анализ. Семиотики их выполняют на 100%. Третья функция - синтез. Всё таки, я не предлагал игнорировать особенности сервера. Если null <> null, то будет справедливо, что t1.id =?? null вернёт False. Это уже контекст сервера и его математической архитектуры. Я предложил, только, уйти немного от этого. Для PrimaryKey полей не произойдёт ничего существенного, но в других случаях будет дополнительная фильтрация или дополнительная выборка. Однако аксиоматический базис будет не тронут.

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

Страницы: 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465

Предыдущая тема: Сравнение двух строк


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.