Статья
Pavel Luzanov
Долго пытался себя сдерживать, но силы иссякли.
Одним словом получилась статья:
http://www.geocities.com/luzanovp/calendar.html
Изначально, хотел отправить в oramag/ru
(там ТАКОЕ иногда печатают),
но, думаю, что будет правильно подвергнуть ее
предварительной критике.
-----
Павел Лузанов
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Johnny Smith
Хорошее, остроумное решение.
Есть одно маленькое замечание, касающееся использования пакетных
переменных во вьюшках. Я часто сталкивался с таким приемом и считал его
вполне законным, пока не "влез" в многозвенные архитектуры. Там он
(прием)совершенно неприемлем, когда несколько клиентов используют одну
сессию, которую держит для них сервер приложений.
IgorM
Например Web-сервер всегда держит пулинг соединений
и непонятно какая сессия попадется пользователю
например в Oracle Portal для этого делается принудительный сброс всех
пакетов при очередном реквесте
Regards
IgorM
Pavel Luzanov
> Да да
> Например Web-сервер всегда держит пулинг
> соединений
> и непонятно какая сессия попадется пользователю
> например в Oracle Portal для этого делается
> принудительный сброс всех
> пакетов при очередном реквесте
Johnny Smith и IgorM
Спасибо за отзыв.
Посмотрите, в статье есть абзац, в котором
как раз и говорится, что в Oracle Portal такой подход
использовать нельзя. И приводится ссылка на объектный
тип WWSTO_API_SESSION, который позволяет создавать
переменные, "живущие" в течении порталовской сессии.
Была у меня мысль включить и код для Портала, но это
совсем бы уводило в сторону и скорее является темой
для другой статьи. Именно поэтому я ограничился только
упоминанием о проблеме и "намеке" на workaround.
-----
Павел Лузанов
Nicholay Logazyak
которое содержит календарь всех месяцев на 10 лет вперед начиная с 2001
года. Теперь для получения календаря на 12 месяц 2010 года надо написать :
SELECT * from v_calendar WHERE day = to_date('01.12.10','dd.mm.yy')
Тоесть не надо использовать пакет и глобальную переменную.
Текст представления такой :
SELECT
DAY,
MAX(DECODE (day_of_week, 'MON', dd, NULL)) Mon,
MAX(DECODE (day_of_week, 'TUE', dd, NULL)) Tue,
MAX(DECODE (day_of_week, 'WED', dd, NULL)) Wed,
MAX(DECODE (day_of_week, 'THU', dd, NULL)) Thu,
MAX(DECODE (day_of_week, 'FRI', dd, NULL)) Fri,
MAX(DECODE (day_of_week, 'SAT', dd, NULL)) Sat,
MAX(DECODE (day_of_week, 'SUN', dd, NULL)) Sun
FROM (
SELECT dd.N+1 dd,
DAY,
TO_CHAR (MM_DAYS.DAY + dd.N,
'DY', 'NLS_DATE_LANGUAGE=AMERICAN') AS day_of_week,
DECODE ( TO_CHAR( MM_DAYS.DAY, 'MM'),
'12', DECODE ( TO_CHAR( MM_DAYS.DAY+dd.N,'IW'), '01', '54', TO_CHAR(
MM_DAYS.DAY+dd.N,'IW')),
'01', DECODE ( TO_CHAR( MM_DAYS.DAY+dd.N,'IW'), '52', '00', '53', '00',
TO_CHAR( MM_DAYS.DAY+dd.N,'IW')),
TO_CHAR(MM_DAYS.DAY+dd.N, 'IW')
) AS week_num
FROM
( SELECT rownum-1 n from all_objects WHERE rownum <= 31 ) dd,
( SELECT to_date( '01.'||MM||'.'||YY, 'dd.mm.yy' ) DAY
FROM ( SELECT substr( '0'||rownum,-2 ) MM from all_objects WHERE rownum <=
12 ) m,
( SELECT rownum n, substr( '0'||rownum,-2 ) yy from all_objects WHERE rownum
<= 10 ) y ) MM_DAYS
WHERE dd.N < TO_NUMBER(TO_CHAR(LAST_DAY( MM_DAYS.DAY ), 'DD'))
)
GROUP BY
DAY, week_num;
Vladimir M. Zakharychev
обрабатывает, например, '1.1.2' по маске 'dd.mm.yy' как 01.01.2002,
по крайней мере на 8.1.7 (насчет предыдущих версий не уверен). Плюс
вот здесь:
> ( SELECT rownum n, substr( '0'||rownum,-2 ) yy from all_objects WHERE rownum
> <= 10 ) y ) MM_DAYS
выбирается rownum n, который нигде не используется - можно убрать.
То есть можно еще немножко улучшить читаемость запроса:
( SELECT to_date( '1.'||MM||'.'||YY, 'dd.mm.yy' ) DAY
FROM
( SELECT rownum MM from all_objects WHERE rownum <= 12 ),
( SELECT rownum YY from all_objects WHERE rownum <= 50 ) -- до 2050 - а почему нет? :)
) MM_DAYS
А в остальном очень симпатично получилось. :) SQL rulez. ;)
--
Vladimir Zakharychev (b...@dpsp-yes.com) http://www.dpsp-yes.com
Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications.
All opinions are mine and do not necessarily go in line with those of my employer.
"Nicholay Logazyak" <k...@gpb.ural.ru> wrote in message news:ag40m0$1kv4$1...@news.ural.ru...
Nicholay Logazyak
"Vladimir M. Zakharychev" <b...@dpsp-yes.com> сообщил/сообщила в новостях
следующее: news:ag4674$h4m$1...@babylon.agtel.net...
> substr('0'||rownum, -2), по-моему, необязательны - to_date() корректно
> обрабатывает, например, '1.1.2' по маске 'dd.mm.yy' как 01.01.2002,
> по крайней мере на 8.1.7 (насчет предыдущих версий не уверен). Плюс
> вот здесь:
> > ( SELECT rownum n, substr( '0'||rownum,-2 ) yy from all_objects WHERE
rownum
> > <= 10 ) y ) MM_DAYS
>
> выбирается rownum n, который нигде не используется - можно убрать.
> То есть можно еще немножко улучшить читаемость запроса:
>
> ( SELECT to_date( '1.'||MM||'.'||YY, 'dd.mm.yy' ) DAY
> FROM
> ( SELECT rownum MM from all_objects WHERE rownum <= 12 ),
> ( SELECT rownum YY from all_objects WHERE rownum <= 50 ) -- до 2050 - а
почему нет? :)
> ) MM_DAYS
>
> А в остальном очень симпатично получилось. :) SQL rulez. ;)
С замечаниями согласен :) Не причесывал я запрос. Просто написал на скорую
руку
чтобы отобразить идею. Упрощение с датой делает запрос более приятным, хотя
я никогда
не использовал формат типа 1.1.2 ... А "rownum n" остался от тестирования
:) Конечно надо убрать.
Спасибо за внимательное прочтение :)
Vladimir Begun
Календарь не может быть на 10 лет вперёд или назад. Календарь должен
быть на любой период -- в этом смысл электронных календарей. Зачем
вводить искусственные (неразумные) ограничения там где они не нужны?
Моё имхо говорит что в данном случае нет ни простоты, ни выигрыша от
этого. Я когда-то делал аналог cal(1) на SQL (немного не такой внешний
вид, как предложил Павел, но смысл и реализация была похожей, я бы сказал
почти такой же ;) и считаю что для работы такого календаря нужен только
месяц и год -- этого достаточно чтобы решить задачку.
--
Vladimir Begun | The statements and opinions expressed
http://vbegun.net/ | here are my own and do not necessarily
http://vbegun.net/wap/ | represent those of Oracle Corporation.
m...@vbegun.net |
ICQ#19259480/30% reachability|
Nicholay Logazyak wrote:
>
> Раз пошла такая пьянка, то в духе статьи предлагаю вариант представления,
^^^^^^^^^^^^^^^^^^ !!! :((((
> которое содержит календарь всех месяцев на 10 лет вперед начиная с 2001
> года. Теперь для получения календаря на 12 месяц 2010 года надо написать :
Vladimir Begun
Извините что отвечаю не в thread...
Ещё раз хочу поблагодарить за статью. Написана очень хорошо, как
по мне, программный материал представлен стройно и достаточно
подробно -- так что понял любой начинающий. Если честно мне
никогда не хватает терпения "разложить, разжевать и положить
в рот" ;) -- я увидел пример того как это сделано и честно говоря
поразился терпению.
Я когда что-то подобное делаю стараюсь оставить тень сомнения для
читающего, что-то не дописать, не досказать... не потому что не
хочу этого сделать, а совсем наоборот, хочу чтобы он (читатель)
не просто тупо, как зачастую бывает, следовал тому что написано,
а начинал сомневаться и думать. ;)
Теперь немного о моих возрениях на это дела, я хочу сказу сказать
это именно возрения, но никак не замечания! Как я уже сказал я
когда-то делал нечто подобное.
Я перечитал статью ещё раз.
0. Календари вещь сложная и трудоёмкая.
1. Постановка. Вижу что постановка задачи неполна или не до конца
описана. Прав лия что иллюстрируется только программное решение,
конкретного набора лет скажем наших веков (20-21 н.э.) -- т.е. в
статье определён свой стандарт для вывода календаря? Как на счёт
общепринятых, по крайней мере западных (разумеется CIS включаем)
календарей? -- мне кажется что нельзя показывать календарь в
отрыве NLS установок (c поддержкой номера дня в недели) или
нужно оговорить для каких NLS календарь работает.
2. Реализация.
а) Как я уже говорил в частной переписке, PL/SQL код очень уж
часто вызывается, для месяца в котором 31 день у меня получилось
достаточно много, около 94 (если не ошибаюсь) переключения
контекста.
б) Мне кажется что использование all_objects в данном случае
не очень правильно. Начнём хотя бы с того что это достаточно
сложное view, с зависимостями и проверкой прав пользователя
на объекты, вывод прост -- внутри это работает сложнее, чем
таблица с 31 строчкой, из которой данные просто выбираются
без всяких проверок.
в) Вложенные DECODE для расчёта week_num
DECODE (
TO_CHAR(p_calendar.get_date, 'MM'),
'12', DECODE (
TO_CHAR(TRUNC(p_calendar.get_date,'MM')+ROWNUM-1,'IW'),
'01', '54',
TO_CHAR(TRUNC(p_calendar.get_date,'MM')+ROWNUM-1,'IW')
),
'01', DECODE (
TO_CHAR(TRUNC(p_calendar.get_date,'MM')+ROWNUM-1,'IW'),
'52', '00',
'53', '00',
TO_CHAR(TRUNC(p_calendar.get_date,'MM')+ROWNUM-1,'IW')
),
TO_CHAR(TRUNC(p_calendar.get_date,'MM')+ROWNUM-1, 'IW')
) AS week_num
наверное можно переписать так (я не проверял, но вроде бы всё
правильно)
DECODE(TO_CHAR(p_calendar.get_date, 'MM')
|| TO_CHAR(TRUNC(p_calendar.get_date,'MM')+ROWNUM-1,'IW')
, '1201', '54'
, '0152', '00'
, '0153', '00'
, TO_CHAR(TRUNC(p_calendar.get_date,'MM')+ROWNUM-1, 'IW')
) AS week_num
г) Расчёт месяца года, сложная вещь, это очень сильно сочетается
с пунктами 0 и 1.
Положим я хочу посмотреть календарь за октябрь 1582 года,
года Папа Георгий (как известно из истории календарей) сделал
реформу -- код работать не будет. Он также работать не будет
для ноября, декабря 1582 года, поскольку считает недели года,
а не недели месяца, т.е. с точки зрения реализации это пример
error propagation.
http://www.coins.ru/numizm/glossary/showarticle.phtml?word=cal_grig
http://www.astronet.ru:8100/db/msg/1162236/
http://calends.webzone.ru/3000.html
http://www.ernie.cummings.net/calendar.htm
http://webexhibits.org/calendars/timeline.html
http://astro.nmsu.edu/~lhuber/leaphist.html
http://www.calendarzone.com/
Спасибо.
Ниже позволю себе привести свой собственный код, написанный
когда-то. У него свои "тараканы" ;) Для поддержки изменений
папы Георгия код легко модифицируется введением расчётных
deltas. Скажу сразу, я его не тестировал "от и до" -- прогнал
только для первых 3000 лет нашей эры, вроде как "шуршит" --
буде здорово если кто найдёт ошибку. ;) Таблица может быть
и не IOT и без primary key... это сделано для других целей.
Работает для западных и CIS календарей (номера дней). Да,
поскольку у меня туго с русским в базе ;) там может чё-то
вылезти... для american и german это выглядит так:
SUN MON TUE WED THU FRI SAT
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
MO DI MI DO FR SA SO
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Вообщем и целом думаю это более менее ничего contribution для
статьи.
С Уважением,
--
Vladimir Begun | The statements and opinions expressed
http://vbegun.net/ | here are my own and do not necessarily
http://vbegun.net/wap/ | represent those of Oracle Corporation.
m...@vbegun.net |
ICQ#19259480/30% reachability|
===============================================================
DROP TABLE calendar_day
/
CREATE TABLE calendar_day (
dd NUMBER(2)
, CONSTRAINT pk$calendar_day$dd PRIMARY KEY(dd)
, CONSTRAINT ck$calendar_day$dd CHECK (dd > 0 AND dd < 32)
)
ORGANIZATION INDEX
STORAGE (INITIAL 16K NEXT 16K PCTINCREASE 0 MAXEXTENTS 1)
/
INSERT INTO calendar_day
SELECT ROWNUM
FROM all_objects
WHERE ROWNUM < 32
/
COMMIT
/
CREATE OR REPLACE PACKAGE pkg$cal
AS
FUNCTION get_date
RETURN DATE;
PROCEDURE set_date (
ad_date_i DATE DEFAULT SYSDATE
);
END pkg$cal;
/
CREATE OR REPLACE PACKAGE BODY pkg$cal
AS
gd_date DATE NOT NULL := SYSDATE;
FUNCTION get_date
RETURN DATE
IS
BEGIN
RETURN gd_date;
END get_date;
PROCEDURE set_date (
ad_date_i DATE DEFAULT SYSDATE
)
IS
BEGIN
IF (ad_date_i IS NULL)
THEN
gd_date := SYSDATE;
ELSE
gd_date := ad_date_i;
END IF;
END set_date;
END pkg$cal;
/
CREATE OR REPLACE VIEW viw$cal
AS
SELECT d1
, d2
, d3
, d4
, d5
, d6
, d7
FROM (
SELECT 'DAYS' AS d0
, LPAD(MAX(DECODE(day_of_week, 1, name_of_day)), 3) AS d1
, LPAD(MAX(DECODE(day_of_week, 2, name_of_day)), 3) AS d2
, LPAD(MAX(DECODE(day_of_week, 3, name_of_day)), 3) AS d3
, LPAD(MAX(DECODE(day_of_week, 4, name_of_day)), 3) AS d4
, LPAD(MAX(DECODE(day_of_week, 5, name_of_day)), 3) AS d5
, LPAD(MAX(DECODE(day_of_week, 6, name_of_day)), 3) AS d6
, LPAD(MAX(DECODE(day_of_week, 7, name_of_day)), 3) AS d7
FROM (
SELECT TO_CHAR(dt.dt + ROWNUM, 'DY') name_of_day
, TO_CHAR(dt.dt + ROWNUM, 'D') day_of_week
FROM calendar_day
, (
SELECT pkg$cal.get_date dt
FROM sys.dual
GROUP BY pkg$cal.get_date
) dt
WHERE ROWNUM <= 7
)
UNION ALL
SELECT 'WEEKS' || week_of_month AS d0
, TO_CHAR(MAX(DECODE(day_of_week, '1', day_of_month)), '99') AS d1
, TO_CHAR(MAX(DECODE(day_of_week, '2', day_of_month)), '99') AS d2
, TO_CHAR(MAX(DECODE(day_of_week, '3', day_of_month)), '99') AS d3
, TO_CHAR(MAX(DECODE(day_of_week, '4', day_of_month)), '99') AS d4
, TO_CHAR(MAX(DECODE(day_of_week, '5', day_of_month)), '99') AS d5
, TO_CHAR(MAX(DECODE(day_of_week, '6', day_of_month)), '99') AS d6
, TO_CHAR(MAX(DECODE(day_of_week, '7', day_of_month)), '99') AS d7
FROM (
SELECT ROWNUM AS day_of_month
, SIGN(
SIGN(
DECODE(MOD(ROWNUM, 7)
, 0, 7
, MOD(ROWNUM, 7)
)
- TO_CHAR(dt.mo + ROWNUM - 1, 'D')
)
- 1
)
+ TO_CHAR(dt.mo + ROWNUM - 1, 'W') AS week_of_month
, TO_CHAR(dt.mo + ROWNUM - 1, 'D') AS day_of_week
FROM calendar_day
, (
SELECT pkg$cal.get_date dt
, TRUNC(pkg$cal.get_date, 'MM') mo
FROM sys.dual
GROUP BY
pkg$cal.get_date
) dt
WHERE ROWNUM <= TO_NUMBER(TO_CHAR(LAST_DAY(dt.dt), 'DD'))
)
GROUP BY
week_of_month
)
/
Pavel Luzanov
Большое спасибо за письмо.
Очень полезное дополнение.
Я хочу добавить все пришедшие комментарии в том числе
и Ваше к статье.
Как я понял в результате вашей дискуссии с Владимиром
Захарычевым, текст представления изменился. Не могли
бы Вы прислать мне окончательный вариант.
С уважением
-----
Павел Лузанов
----- Исходное сообщение -----
От: "Nicholay Logazyak" <k...@gpb.ural.ru>
Группы новостей: relcom.comp.dbms.oracle
Кому: "All" <relcom.comp...@talk.ru>
Отправлено: 5 июля 2002 г. 19:12
Тема: Re: Статья - relcom.comp.dbms.oracle
> --
> Адрес этого сообщения в WWW: http://talk.mail.ru/article-21035510.html
> Для отмены подписки отправьте пустое письмо по адресу:
> relcom.comp.dbms....@talk.ru
Nicholay Logazyak
Владимир, все очень просто.
Во-первых календарь может быть на 10 лет вперед, на 1 год итд.
Доказательства - Зайди в любой книжный магазин и попроси календарь.
Календарь должен
> быть на любой период -- в этом смысл электронных календарей.
В случае программного обеспечения примеров как все помнят тоже достаточно.
( проблема 2000 года ). И есть ли у тебя твердая уверенность что через
100-200 лет не произойдет очередная календарная реформа и пользователи
твоего календаря будут безбожно обмануты, хотя ты так старался ? Но это все
философия :)
В смысле полезности - этот календарь не для того чтобы любители истории
узнавали в какой день родился Иван Грозный. А к примеру для реальных бизнес
задач в ближайшие десятилетия может применяться. А 10 лет можно изменить на
100. Через 100 лет этот календарь будет я уверен никому не нужен, так же как
и все программы которые сейчас пишутся. Но это опять философия не к
предмету.
Зачем
> вводить искусственные (неразумные) ограничения там где они не нужны?
А теперь к сути : Павел предложил использование пакета с глобальной
переменной. Прочти его статью и найди слова где Павел говорит об истоках
идеи использования одного простого запроса для получения календаря. Мне
стало интересно использовать только SQL. Эту идею я и хотел показать. Если
ты знаешь как с помощью SQL запроса сделать календарь на любой день, то
очень интересно посмотреть ...
> Моё имхо говорит что в данном случае нет ни простоты, ни выигрыша от
> этого.
Тем более интересно если твой календарь еще и по простоте не уступает.
Я когда-то делал аналог cal(1) на SQL (немного не такой внешний
> вид, как предложил Павел, но смысл и реализация была похожей, я бы сказал
> почти такой же ;) и считаю что для работы такого календаря нужен только
> месяц и год -- этого достаточно чтобы решить задачку.
ИМХО - я бы для глобального календаря тоже написал бы нечто другое и без
использования all_objects.Но в данном случае я писал по теме статьи изменив
авторский вариант для исключения PL/SQL кода. Кому то это возможно покажется
интересным.
Николай.
Vladimir Begun
Я выразил свои возрения достаточно полно в сообщении,
к сожалению, я не попал в этот thread. Думаю, тебе
интересно будет его прочитать.
Спасибо.
Nicholay Logazyak wrote:
> > Календарь не может быть на 10 лет вперёд или назад.
> Владимир, все очень просто.
...
Всё значительно сложнее... ;)
--
Nicholay Logazyak
"Pavel Luzanov" <p...@kuzbe.elektra.ru> сообщил/сообщила в новостях
следующее: news:00d801c22628$34e0f2e0$0e17020a@pal...
> Николай!
>
> Большое спасибо за письмо.
> Очень полезное дополнение.
> Я хочу добавить все пришедшие комментарии в том числе
> и Ваше к статье.
> Как я понял в результате вашей дискуссии с Владимиром
> Захарычевым, текст представления изменился. Не могли
> бы Вы прислать мне окончательный вариант.
>
> С уважением
>
> -----
> Павел Лузанов
Добрый день, Павел,
С учетом замечаний Владимира Захарычева и Владимира Бегуна вариант запроса
представляю ниже.
Изменения коснулись в частности :
1) Вместо задания даты задается месяц MM и год YY нужного календаря.
Специально для Владимира Бегуна :))
Запрос к представлению на январь 2001 года теперь выглядит так :
select * from v_calendar where MM_YY = '01_01' -- MM_YY = 'MM_YY'
2) Для Владимира Захарычева колличество лет увеличил до 50 :)
3) Владимир Бегун справедливо заметил что в вашем исходном запросе DECODE
можно упростить. Я с ним согласен. Упрощаю.
4) Убрал перевод даты из 1.1.2 в 01.01.02. Владимир Захарычев ничего не
утверждает но использует такой формат. У меня тоже работает. Я решил что
у всех работает и для большей простоты убрал перевод.
Получается :
SELECT
TO_CHAR(DAY,'mm_yy') MM_YY,
MAX(DECODE (day_of_week, 'MON', dd, NULL)) Mon,
MAX(DECODE (day_of_week, 'TUE', dd, NULL)) Tue,
MAX(DECODE (day_of_week, 'WED', dd, NULL)) Wed,
MAX(DECODE (day_of_week, 'THU', dd, NULL)) Thu,
MAX(DECODE (day_of_week, 'FRI', dd, NULL)) Fri,
MAX(DECODE (day_of_week, 'SAT', dd, NULL)) Sat,
MAX(DECODE (day_of_week, 'SUN', dd, NULL)) Sun
FROM (
SELECT dd.N+1 dd,
DAY,
TO_CHAR (MM_DAYS.DAY + dd.N,
'DY', 'NLS_DATE_LANGUAGE=AMERICAN') day_of_week,
DECODE ( TO_CHAR( MM_DAYS.DAY, 'MM')||TO_CHAR( MM_DAYS.DAY+dd.N,'IW'),
'1201', '54',
'0152', '00',
'0153', '00',
TO_CHAR(MM_DAYS.DAY+dd.N, 'IW')
) WEEK_NUM
FROM
( SELECT rownum-1 N from all_objects WHERE rownum <= 31 ) dd,
( SELECT to_date( '01.'||MM||'.'||YY, 'dd.mm.yy' ) DAY
FROM ( SELECT rownum MM from all_objects WHERE rownum <= 12 ),
( SELECT rownum YY from all_objects WHERE rownum <= 50 ))
MM_DAYS
WHERE dd.N < TO_NUMBER(TO_CHAR(LAST_DAY( MM_DAYS.DAY ), 'DD'))
)
GROUP BY
TO_CHAR(DAY,'mm_yy'), week_num
Vladimir Begun
> 1) Вместо задания даты задается месяц MM и год YY нужного календаря.
> Специально для Владимира Бегуна :))
> Запрос к представлению на январь 2001 года теперь выглядит так :
>
> select * from v_calendar where MM_YY = '01_01' -- MM_YY = 'MM_YY'
Специально для меня делать ничего не нужно, я сам в состоянии ;)
кроме того опыт показывает что лучше иметь 4 цифры для года
чем 2. См. п.1 моего сообщения, нужно не с годами определятся
с предметной областью.
> 2) Для Владимира Захарычева колличество лет увеличил до 50 :)
Лучше бы ты убрал all_objects, ты на план этого запроса смотрел?
А на view definition? Рекомендую. ;)
> 3) Владимир Бегун справедливо заметил что в вашем исходном запросе DECODE можно упростить. Я с ним согласен. Упрощаю.
;)
--
Vladimir Begun | The statements and opinions expressed
http://vbegun.net/ | here are my own and do not necessarily
http://vbegun.net/wap/ | represent those of Oracle Corporation.
m...@vbegun.net |
ICQ#19259480/30% reachability|
Nicholay Logazyak
Ну вот, зря я старался .... За внимание мог бы и спасибо сказать :)
Из вежливости хотя бы :)
> Лучше бы ты убрал all_objects, ты на план этого запроса смотрел?
> А на view definition? Рекомендую. ;)
Мне, как я понял и Павлу, интересен сам факт получения календаря всего
одним SQL запросом. А ты предлагаешь создать еще таблицу, заполнить 50
записями ...
Напрягаешь :)
А вообще я согласен. Вернее для меня это никогда небыло вопросом даже, что
надо в окончательном варианте для практического применения рекомендовать
использование собственной таблицы. Но это уже пусть Павел решает в каком
ключе он оформит статью. Безусловно надо четко оговорить решаемую задачу и
объяснить почему все сделано именно так как сделано. ИМХО у Павла не плохо
это получается.
Босый Алексей
"Johnny Smith" <ilya...@mail.ru> сообщил/сообщила в новостях следующее:
news:ag0sc2$9qa$1...@host.talk.ru...
Vladimir Begun
Nicholay Logazyak wrote:
> > Специально для меня делать ничего не нужно, я сам в состоянии ;)
>
> Ну вот, зря я старался .... За внимание мог бы и спасибо сказать :)
> Из вежливости хотя бы :)
Спасибо! [про себя, кривясь и злобствуя: за хороший пример того как
не нужно решать такие задачки. ;)))]
> > Лучше бы ты убрал all_objects, ты на план этого запроса смотрел?
> > А на view definition? Рекомендую. ;)
>
> Мне, как я понял и Павлу, интересен сам факт получения календаря всего
> одним SQL запросом. А ты предлагаешь создать еще таблицу, заполнить 50
> записями ...
1 запрос != использованию представления all_objects для того чтобы
просто получить результат. Я не предлагаю создать такую таблицу --
это ты сам придумал, извини.
Я вот что хочу отметить, пусть это немного вычурно звучит, но...
1) Любая задачка может быть решена правильно или нет, правильность
определятся спецификацией работы.
2) Любая задачка может быть решена так чтобы она работала, или работала
быстро.
3) SQL это язык работы с данными, неверно (лучше сказать неоптимально)
организованные данные будут обрабатываться неэффективно.
4) Что значит решить только SQL запросом? Ты когда это говоришь до
конца осознаешь смысл сказанного? ;) Я отвечаю, да, эту задачку
можно решить 1 SQL запросом, для, скажем всех месяцев н.э. Не вижу
в этом проблем.
Я только вот не понимаю, что эффективность решения определятся
"только 1 SQL запросом"? Эффективность решения определяется, имхо,
0) правильностью
1) простотой и расширяемостью реализации
2) удобством для работы, как пользователя так и разработчика
3) "легкостью" работы -- системе менее "больно"
4) простотым способом внесения изменений, если потребуется
5) добавь свои пункты
Ну положим сделаешь ты это злосчастное представления для всех дат
н.э. или даже для 50 лет, ну запустят у тебя 10 пользователей твой
запрос для последнего года последнего месяца имеющегося в твоём
представлении, вопрос, будет ли это эффективно работать? А если мы
возьмём любую дату (н.э)?
5) 1 PL/SQL вызов для задания месяца, 1 для извлечения этой даты из
PL/SQL, дальше SQL процессинг максимум 31 строки -- против, как
минимум:
( SELECT rownum-1 N from all_objects WHERE rownum <= 31 ) dd,
( SELECT to_date( '01.'||MM||'.'||YY, 'dd.mm.yy' ) DAY
FROM ( SELECT rownum MM from all_objects WHERE rownum <= 12 ),
( SELECT rownum YY from all_objects WHERE rownum <= 50 ))
(правда я уверен что если подумать то это можно значительно проще
сделать).
Павел, у тебя прошу прощения за эту дискуссию, я не в коем случае
не хочу сказать что-либо негативное о статье и методах в ней обрисованых,
статья, я повторюсь, **очень хорошая**!.
> Напрягаешь :)
Сам этому способствуешь. ;)
Nicholay Logazyak
> Я вот что хочу отметить, пусть это немного вычурно звучит, но...
>
> 1) Любая задачка может быть решена правильно или нет, правильность
> определятся спецификацией работы.
Ну давай о теории. Правильность решения определяется только постановкой
задачи.
1 - Дано ( Условия задачи )
2 - Найти ( Результат )
Если при данных условиях найденное решение получает результат то задача
решена правильно.
Читай статью Павла где идет постановка задачи :
".... мне кажется, что чистое SQL-решение должно быть наиболее
предпочтительно, ведь оно может быть использовано в любой среде разработки
где поддерживается команда SELECT (покажите мне где она не поддерживается).
Итак, задача сводится к написанию запроса, который выводит, скажем для
текущего (Июнь, 2002г.) месяца такой результат: .... "
В итоге Павел получает представление но с необходимостью использовать PL/SQL
Процедуру для задания даты. Читаем стать дальше :
" .... Сейчас очень модно делать различные веб-приложения, вот и мне
довелось разрабатывать что-то подобное, связанное с календарем. Открывает
пользователь страничку, где сбоку такой маленький месячный календарик и
каждый день в виде ссылочки. Нажимаешь на нужный день месяца, а там тебе
новости за этот день или список мероприятий, разнообразных, выводится. ..."
Начинаем понимать, что в подобном проекте речь идет не о глобальном
календаре, а вполне хватит календаря лет на 50.
Павел предложил решение в виде запроса к созданному представлению но с
предварительным вызовом PL/SQL процедуры. Дополнительно вызвав дискуссию о
правомерности использования глобальной переменной пакета для разных сессий.
Я предложил использование только одного представления для решения данной
задачи.
Надеюсь ход мыслей понятен :)
> 3) SQL это язык работы с данными, неверно (лучше сказать неоптимально)
> организованные данные будут обрабатываться неэффективно.
> 4) Что значит решить только SQL запросом? Ты когда это говоришь до
> конца осознаешь смысл сказанного? ;)
Объясняю :) В СУБД Оракл применяется SQL и его расширение PL/SQL. PL/SQL это
процедурный язык позволяющий писать программы с использованием управляющих
конструкций, переменных, обработкой ошибок и другими средствами процедурных
языков программирования. Сл-но решить задачу с использованием только SQL
запроса означает
1) не использовать при решении PL/SQL программирование.
2) не заставлять пользователя вместо одного SQL запроса типа
select * from table where ....;
использовать еще и вызов процедур.
> Я отвечаю, да, эту задачку
> можно решить 1 SQL запросом, для, скажем всех месяцев н.э. Не вижу
> в этом проблем.
Да можно. Только от all_objects тогда точно надо отказаться. А на
собственной таблице будет работать быстро.
> Я только вот не понимаю, что эффективность решения определятся
> "только 1 SQL запросом"?
Я этого не утверждал, это ты сам придумал :) Извени.
> Эффективность решения определяется, имхо,
> 0) правильностью
> 1) простотой и расширяемостью реализации
> 2) удобством для работы, как пользователя так и разработчика
> 3) "легкостью" работы -- системе менее "больно"
> 4) простотым способом внесения изменений, если потребуется
> 5) добавь свои пункты
На самом деле все это должно оговариваться в постановке задачи. Всегда
хочется всего много и бесплатно. Но реально за все надо платить.
> Ну положим сделаешь ты это злосчастное представления для всех дат
> н.э. или даже для 50 лет, ну запустят у тебя 10 пользователей твой
> запрос для последнего года последнего месяца имеющегося в твоём
> представлении, вопрос, будет ли это эффективно работать? А если мы
> возьмём любую дату (н.э)?
Владимир, вот тут я не понял. А с чего ты решил что запрос отрабатывает для
последнего года последнего месяца медленнее чем для первого ?
Что-то ты напутал. План запроса постоянный и отрабатывает одинаково быстро
для любой даты. И как я уже сказал, вместо all_object я использую свою
таблицу из 1000 записей. Запрос на любую дату отрабатывает за 0.02 сек ! Для
10 человек скорость не изменяется. План запроса очень простой - Три
табличных доступа со стопкеями, два соединения циклами и группировка.
Использование all_object как я писал это не есть суть решения. Я же писал
для чего это сделано. На практике надо использовать простую таблицу.
> 5) 1 PL/SQL вызов для задания месяца, 1 для извлечения этой даты из
> PL/SQL, дальше SQL процессинг максимум 31 строки -- против, как
> минимум:
>
> ( SELECT rownum-1 N from all_objects WHERE rownum <= 31 ) dd,
> ( SELECT to_date( '01.'||MM||'.'||YY, 'dd.mm.yy' ) DAY
> FROM ( SELECT rownum MM from all_objects WHERE rownum <= 12 ),
> ( SELECT rownum YY from all_objects WHERE rownum <= 50 ))
> (правда я уверен что если подумать то это можно значительно проще
> сделать).
Но у тебя же нет ни желания ни времени подтвердить свою уверенность. Так
ведь ? :)
> > Напрягаешь :)
>
> Сам этому способствуешь. ;)
Ладно, видно пора отдохнуть :) Мне кажется мы с тобой не поймем друг друга
никогда.
Vladimir Begun
Vladimir Begun
Nicholay Logazyak wrote:
> Доброе утро, Владимир, если оно доброе :)
У нас с тобой разница во времени как минимум 8-10 часов...
т.е даже тут противоречие ;)
> > Я вот что хочу отметить, пусть это немного вычурно звучит, но...
...
> Читай статью Павла где идет постановка задачи :
>
> ".... мне кажется, что чистое SQL-решение должно быть наиболее
> предпочтительно, ведь оно может быть использовано в любой среде разработки
> где поддерживается команда SELECT (покажите мне где она не поддерживается).
Такие SELECTs много где не поддерживаются, MS Access, MySQL где-то
ещё... там проблемы с inline view, может что-то уже и придумали.
но ещё пару-тройку лет назад там такие вещи нельзя было сделать...
> Итак, задача сводится к написанию запроса, который выводит, скажем для
> текущего (Июнь, 2002г.) месяца такой результат: .... "
> В итоге Павел получает представление но с необходимостью использовать PL/SQL
> Процедуру для задания даты. Читаем стать дальше :
>
> " .... Сейчас очень модно делать различные веб-приложения, вот и мне
> довелось разрабатывать что-то подобное, связанное с календарем. Открывает
> пользователь страничку, где сбоку такой маленький месячный календарик и
> каждый день в виде ссылочки. Нажимаешь на нужный день месяца, а там тебе
> новости за этот день или список мероприятий, разнообразных, выводится. ..."
>
> Начинаем понимать, что в подобном проекте речь идет не о глобальном
> календаре, а вполне хватит календаря лет на 50.
>
> Павел предложил решение в виде запроса к созданному представлению но с
> предварительным вызовом PL/SQL процедуры. Дополнительно вызвав дискуссию о
> правомерности использования глобальной переменной пакета для разных сессий.
>
> Я предложил использование только одного представления для решения данной
> задачи.
>
> Надеюсь ход мыслей понятен :)
>
> > 3) SQL это язык работы с данными, неверно (лучше сказать неоптимально)
> > организованные данные будут обрабатываться неэффективно.
> > 4) Что значит решить только SQL запросом? Ты когда это говоришь до
> > конца осознаешь смысл сказанного? ;)
>
> Объясняю :) В СУБД Оракл применяется SQL и его расширение PL/SQL. PL/SQL это
5 баллов, всю жизнь жил и думал в чём разница ;))))
> процедурный язык позволяющий писать программы с использованием управляющих
> конструкций, переменных, обработкой ошибок и другими средствами процедурных
> языков программирования. Сл-но решить задачу с использованием только SQL
> запроса означает
Это утопия решить что-то на SQL, не имея подготовленных (в любом виде)
данных.
> 1) не использовать при решении PL/SQL программирование.
> 2) не заставлять пользователя вместо одного SQL запроса типа
> select * from table where ....;
> использовать еще и вызов процедур.
>
> > Я отвечаю, да, эту задачку
> > можно решить 1 SQL запросом, для, скажем всех месяцев н.э. Не вижу
> > в этом проблем.
>
> Да можно. Только от all_objects тогда точно надо отказаться. А на
> собственной таблице будет работать быстро.
>
> > Я только вот не понимаю, что эффективность решения определятся
> > "только 1 SQL запросом"?
>
> Я этого не утверждал, это ты сам придумал :) Извени.
Тут не написано что ты это утверждал, так что извИняю. ;)
> > Эффективность решения определяется, имхо,
> > 0) правильностью
> > 1) простотой и расширяемостью реализации
> > 2) удобством для работы, как пользователя так и разработчика
> > 3) "легкостью" работы -- системе менее "больно"
> > 4) простотым способом внесения изменений, если потребуется
> > 5) добавь свои пункты
>
> На самом деле все это должно оговариваться в постановке задачи. Всегда
> хочется всего много и бесплатно. Но реально за все надо платить.
У вас, кстати, лицензия на Oracle куплена? ;))) (это шутка)
> > Ну положим сделаешь ты это злосчастное представления для всех дат
> > н.э. или даже для 50 лет, ну запустят у тебя 10 пользователей твой
> > запрос для последнего года последнего месяца имеющегося в твоём
> > представлении, вопрос, будет ли это эффективно работать? А если мы
> > возьмём любую дату (н.э)?
>
> Владимир, вот тут я не понял. А с чего ты решил что запрос отрабатывает для
> последнего года последнего месяца медленнее чем для первого ?
> Что-то ты напутал. План запроса постоянный и отрабатывает одинаково быстро
Я ничего не напутал.
> для любой даты. И как я уже сказал, вместо all_object я использую свою
> таблицу из 1000 записей. Запрос на любую дату отрабатывает за 0.02 сек ! Для
Это хорошо, потому как это *неправильно* использовать для задач
выборки системные представления.
> 10 человек скорость не изменяется. План запроса очень простой - Три
> табличных доступа со стопкеями, два соединения циклами и группировка.
> Использование all_object как я писал это не есть суть решения. Я же писал
> для чего это сделано. На практике надо использовать простую таблицу.
Спасибо что донёс мысль. ;)
> > 5) 1 PL/SQL вызов для задания месяца, 1 для извлечения этой даты из
> > PL/SQL, дальше SQL процессинг максимум 31 строки -- против, как
> > минимум:
> >
> > ( SELECT rownum-1 N from all_objects WHERE rownum <= 31 ) dd,
> > ( SELECT to_date( '01.'||MM||'.'||YY, 'dd.mm.yy' ) DAY
> > FROM ( SELECT rownum MM from all_objects WHERE rownum <= 12 ),
> > ( SELECT rownum YY from all_objects WHERE rownum <= 50 ))
> > (правда я уверен что если подумать то это можно значительно проще
> > сделать).
>
> Но у тебя же нет ни желания ни времени подтвердить свою уверенность. Так
> ведь ? :)
Разумеется, нет ни желания ни времени, просто есть возможность сделать
проще, если уж ты решился ввести эти придуманные ограничения.
DEFINE malpci = "TO_NUMBER(TO_CHAR(TO_DATE('01111976', 'DDMMYYYY'), 'J'))"
DEFINE table = "please define your table here"
SELECT TRUNC(TO_DATE(CEIL(&malpci + (ROWNUM - 1) * 31.4375), 'J'), 'MM')
FROM &table
WHERE ROWNUM <= 100 * 12
/
Павел, тебе ещё интересна эта дискуссия? ;) Если да, будет ли тебе
интересен вариант такого представления календаря:
SUN MON TUE WED THU FRI SAT
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 [18] 19 20
21 22 23 24 25 26 27
28 29 30
MO DI MI DO FR SA SO
[ 1] 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Я просто "причесал" свою старую идейку, она по-прежнему с "тараканами",
но их значительно меньше... ;)
Vladimir Begun
> DEFINE malpci = "TO_NUMBER(TO_CHAR(TO_DATE('01111976', 'DDMMYYYY'), 'J'))"
> DEFINE table = "please define your table here"
>
> SELECT TRUNC(TO_DATE(CEIL(&malpci + (ROWNUM - 1) * 31.4375), 'J'), 'MM')
> FROM &table
> WHERE ROWNUM <= 100 * 12
> /
Для того чтобы не было лишних вопросов 100 * 12 -- это не 100
лет, это просто искусственное ограничение, но оно не противоречит
"постановке" задачи -- т.е. "ошибки" в данном случае нет [тут я
по-привычке хитрю :)] Ясное дело что это не совсем хорошо, но в
данном случае ограничение введено поскольку мы всё равно ставим
рамки для работы кода, неважно нужно это или нет, мы их просто
ставим...
Я за вариант Павла, он, имхо, самый правильный из этих двух. ;)
Pavel Luzanov
VB> да, будет ли тебе
VB> интересен вариант такого представления календаря:
...
VB> Я просто "причесал" свою старую идейку, она
VB> по-прежнему с "тараканами",
VB> но их значительно меньше... ;)
Конечно интересно.
Присылай причесанный вариант, только просьба описать
"тараканов" :-)
Сегодня уже можно подвести предварительные итоги обсуждения,
ибо поток новых предложений судя по всему иссяк.
Все отзывы я разбил на три группы:
1. Замечания, которые повлияют на окончательный вариант статьи.
Я однозначно "пролетел" с форматной маской fmDAY, использование
all_objects требует уточнений, раздел CASE против DECOD* * удет
сильно изменен (я уверен, что вы даже не подозреваете в какую
сторону :-), вероятно нужно как-то откликнуться на NLS-ное
отображение первого дня недели.
2. Дополнения или альтернативные решения, для которых вероятно
придется сделать отдельную страничку.
Вот сюда, Владимир, я и хотел бы поместить твой вариант полностью
(исходники + все комментарии к моей статье)
3. Просто положительные отзывы о статье.
4. Я счастлив, что эта группа пустая :-)
-----
Павел Лузанов
--
Vladimir Begun
> 3. Просто положительные отзывы о статье.
> 4. Я счастлив, что эта группа пустая :-)
В смысле, пустая? Я говорю ещё раз -- статья классная,
впервые вижу русскоязычную статью где всё разложено
по-полочкам, пусть какие-то там ляпы и чё-то там ещё --
это всё ерунда. Мои ощущения -- общий смысл и описание
подхода -- на высоте!
СПАСИБО!
--
Vladimir Begun | The statements and opinions expressed
http://vbegun.net/ | here are my own and do not necessarily
http://vbegun.net/wap/ | represent those of Oracle Corporation.
m...@vbegun.net |
ICQ#19259480/30% reachability|
Pavel Luzanov
VB> Pavel Luzanov wrote:
VB>> 3. Просто положительные отзывы о статье.
VB>> 4. Я счастлив, что эта группа пустая :-)
VB> В смысле, пустая? Я говорю ещё раз -- статья
В том смысле, что если 3-я группа отзывов - просто положительные,
то 4-я должна быть - просто отрицательные и она пустая :-)
-----
Павел Лузанов
--
Nicholay Logazyak
> У нас с тобой разница во времени как минимум 8-10 часов...
> т.е даже тут противоречие ;)
Так пусть оно будет единственным !
По-моему хороший тост :)))
> Это утопия решить что-то на SQL, не имея подготовленных (в любом виде)
> данных.
Не спорю.
> > Я этого не утверждал, это ты сам придумал :) Извени.
> Тут не написано что ты это утверждал, так что извИняю. ;)
1-0 :)
> У вас, кстати, лицензия на Oracle куплена? ;))) (это шутка)
На всякий случай уточню что куплена. Неужели я бы стал воровать версию 8.06,
когда можно украсть сразу 8i или 9 :))
> > Владимир, вот тут я не понял. А с чего ты решил что запрос отрабатывает
для
> > последнего года последнего месяца медленнее чем для первого ?
> > Что-то ты напутал. План запроса постоянный и отрабатывает одинаково
быстро
>
> Я ничего не напутал.
Интересно если бы ты пояснил, но не смею отнимать время своими интересами.
> > для любой даты. И как я уже сказал, вместо all_object я использую свою
> > таблицу из 1000 записей. Запрос на любую дату отрабатывает за 0.02 сек !
Для
>
> Это хорошо, потому как это *неправильно* использовать для задач
> выборки системные представления.
Так оно.
> Разумеется, нет ни желания ни времени, просто есть возможность сделать
> проще, если уж ты решился ввести эти придуманные ограничения.
>
> DEFINE malpci = "TO_NUMBER(TO_CHAR(TO_DATE('01111976', 'DDMMYYYY'), 'J'))"
> DEFINE table = "please define your table here"
>
> SELECT TRUNC(TO_DATE(CEIL(&malpci + (ROWNUM - 1) * 31.4375), 'J'), 'MM')
> FROM &table
> WHERE ROWNUM <= 100 * 12
Вообще я ожидал увидеть что-то вроде
DEFINE table = "please define your table here"
SELECT add_months( TO_DATE('01111976', 'DDMMYYYY'),ROWNUM - 1 ) FROM &table
Но разумеется твой вариант как всегда лучше :)
На самом деле искреннее спасибо за вариант, ибо то что ты пишешь на SQL мне
нравится больше чем то что ты иногда пишешь на русском, пусть даже и без
ошибок :)) Это разумеется шутка :))
Nicholay Logazyak
"Vladimir Begun" <Vladimi...@oracle.com> сообщил/сообщила в новостях
следующее: news:3D2B82D0...@oracle.com...
> Vladimir Begun wrote:
> > DEFINE malpci = "TO_NUMBER(TO_CHAR(TO_DATE('01111976', 'DDMMYYYY'),
'J'))"
> > DEFINE table = "please define your table here"
> >
> > SELECT TRUNC(TO_DATE(CEIL(&malpci + (ROWNUM - 1) * 31.4375), 'J'), 'MM')
> > FROM &table
> > WHERE ROWNUM <= 100 * 12
> > /
>
> Для того чтобы не было лишних вопросов 100 * 12 -- это не 100
> лет, это просто искусственное ограничение, но оно не противоречит
> "постановке" задачи -- т.е. "ошибки" в данном случае нет [тут я
> по-привычке хитрю :)] Ясное дело что это не совсем хорошо, но в
> данном случае ограничение введено поскольку мы всё равно ставим
> рамки для работы кода, неважно нужно это или нет, мы их просто
> ставим...
Вопросов нет.
Но ограничение все равно существует так как ограничено число записей в
таблице.
> Я за вариант Павла, он, имхо, самый правильный из этих двух. ;)
Ну это мог бы и не писать :) Твое отношение к моему запросу было
недвусмысленно с самого начала :)
Vladimir Begun
> SELECT add_months( TO_DATE('01111976', 'DDMMYYYY'),ROWNUM - 1)...
Мы не ищем лёгких путей ;) но всё равно 1-1 [на самом деле
не хотелось решать просто через add_month -- все читают
документацию]. Я честно говоря удивился тому, как можно
по-разному решить казалось бы такую "одинаково" решаемую
задачку. Смыслом постинга был не ответ тебе (это вторично ;),
а иллюстрация ещё одного варианта решения (looks ugly but
works).
Спасибо.
Keep in peace! ;)
P.S.: побольше бы таких статей... хорошая "чистка мозгов".