ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Есть ли у CTE преимущества перед подзапросом?
3 сообщений из 28, страница 2 из 2
  2  все
Есть ли у CTE преимущества перед подзапросом?
    #39894164
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Alibek B.
них можно построить непрерывную цепочку версий, когда DATE_BEG следующей записи будет равно DATE_END предыдущей.

Не вижу ни одного вменяемого применения этого "преимущества".
Помимо того, разница в секунду не мешает строить "цепочку", если оно вдруг зачем-то понадобится.

Alibek B.

А если диапазон будет закрытым, то как понять, между двумя соседними записями есть разрыв в одну секунду или это непрерывная запись?

Разрыв между версиями одного объекта в версионных таблицах недопустим во всех известных мне системах, использующий подобный подход.
Дзен подобного запрета познаете в join-ах версионных объектов, особенно если 3+.

Несколько постулатов:
- в современных информационных системах время дискретно.
- ни одна версия объекта не может существовать нулевой интервал времени, минимальное время существования - одна дискрета, для типа date это одна секунда.
- интервал времени в одну дискрету от даты окончания жизни версии принадлежит упомянутой версии.
- базовые структуры данных достаточно статичны, чтобы не рассматривать смену типа данных для хранения точек времени за время жизни ИС. Собственно, за 20 лет я только один раз слышал подобное предложение, и то в качестве "безумной идеи" во время классического мозгового штурма.

Тогда для типа date:
Код: plaintext
1.
2.
3.
4.
5.
          dt_from           dt_till comment
01.01.19 00:00:00 01.01.19 00:00:00 версия длиной в 1 с
01.01.19 00:00:01 01.01.19 23:59:59 версия длиной в 86399 с, живет до конца суток
02.01.19 00:00:01 31.12.99 23:59:59 актуальная версия, значение "31.12.99 23:59:59" задается общесистемной константой

Основное преимущество - возможность использования between

Впрочем, Ваш вариант тоже имеет будущее, если, конечно, вендор не забьёт и допилит недофичу из синтаксического сахара во что-то толковое:
 
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
select * from dropme_time_validity;

        ID VAL                                                                              DT_FROM     DT_TILL
---------- -------------------------------------------------------------------------------- ----------- -----------
         1 1-Версия1                                                                        24.11.2019  24.11.2019
         1 1-Версия2                                                                        25.11.2019  31.12.2099
         2 2-Версия1                                                                        24.11.2019  25.11.2019
         2 2-Версия2                                                                        25.11.2019  31.12.2099

select * from dropme_time_validity AS OF PERIOD FOR MyPeriod SYSDATE;

        ID VAL                                                                              DT_FROM     DT_TILL
---------- -------------------------------------------------------------------------------- ----------- -----------
         1 1-Версия2                                                                        25.11.2019  31.12.2099
         2 2-Версия2                                                                        25.11.2019  31.12.2099

SQL>



Alibek B.

andrey_anonymous
Попробуйте создать range-partitioned интервальную таблицу с интервалом 1 день - поймете.

Это для больших таблиц и там в любом случае есть свои особенности, которые нужно учитывать в ущерб другим особенностям.

Вы же не собираетесь делать отдельные системы версий "для больших таблиц" и "для маленьких таблиц"?!
Кроме того, partitioning применяется далеко не только "для больших", есть у него вполне приземленные применения и для таблиц "среднего размера".

Alibek B.

А разве для partition-таблиц нет специальных значений "все что больше значения X складывать в секцию OTHER"?

Для интервальных - нет.
А если делать не интервальные, то возникает лишний головняк для администраторов - своевременно нарезать новые секции.
С чем те регулярно не справляются, и потом с матами и простоем делят maxvalue на вменяемые куски.
...
Рейтинг: 0 / 0
25.11.2019, 20:26
| Ответить | Цитировать | Написать  
Есть ли у CTE преимущества перед подзапросом?
    #39894230
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alibek B
Участник
Stax
так d видит

Этот запрос у меня выполняется, но не получается переделать синтаксис на обычный join (точнее left join).
В 10g это не получится?

andrey_anonymous
Несколько постулатов:

Понятно.
Ну в общем это вполне разумно и существенно упростит/сократит написание запросов.
Я уже привык к шаблону <=moment and (is null or >moment). Но не буду спорить, что between намного короче и понятнее.
Но у меня таблицы уже есть, буду работать с ними.
...
Рейтинг: 0 / 0
26.11.2019, 02:13
| Ответить | Цитировать | Написать  
Есть ли у CTE преимущества перед подзапросом?
    #39894251
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
Alibek B.
а у меня Oracle 10g.
Ту уже достал колебать всех этим засохшим гуаном мамонтов.
Да и твоё мышление не современней.
...
Рейтинг: 0 / 0
26.11.2019, 07:43
| Ответить | Цитировать | Написать  
3 сообщений из 28, страница 2 из 2
  2  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Есть ли у CTE преимущества перед подзапросом?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39894164&tid=1881819]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 80ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 43ms
get tp. blocked users:
 1ms
others: 291ms
total:  458ms
созд. / загр.: 458ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]