Что-то я не совсем понял: почему в первом случае благодаря спаму из 500 покупателей вернутся 100 (20%), а во втором, благодаря бехавиоральному анализу, из 8000 человек вернется 6000 (75%)?
Ах данные не заносятся… А в ERP-системе данные откуда возьмутся? С неба упадут по мановению волшебной палочки? Или придется сотрудников своих напрягать? В таком случае что мешает в уже существующей, своей родной, привычной, и, самое главное, индивидуальной, заточенной именно под этот бизнес системе, добавить функционал?
Сегодня отказался от покупки в интернет-магазине именно потому, что нужно было регистрироваться. Зачем мне регистрироваться, заполняя тридцать полей анкеты, если достаточно указать адрес доставки и телефон для связи?
А в чем проблема допилить существующий продукт? Может в том, что сами руководители не знают, что именно нужно? Я не могу поверить, что куча программистов на уже существующей системе не сможет реализовать отчет, который сейчас «делается в Экселе руками». Очень часть ERP-системы воспринимаются как некая панацея от всех проблем. Мол, стоит только внедрить — а дальше все само собой наладится. Нет. Начинать нужно не с внедрения системы, а с понимания цели. Поймут цели, смогут их внятно сформулировать — дальше дело техники на уже существующей системе доделать нужный функционал.
Мда, таки я не прав. Единственное, что меня оправдывает, это «A condition that evaluates to UNKNOWN acts almost like FALSE». Ну а то, что «a condition evaluating to UNKNOWN differs from FALSE in that further operations on an UNKNOWN condition evaluation will evaluate to UNKNOWN» держать в голове стоит, но в настоящем на это можно не обращать внимания.
Есть система, написанная бог знает кем и когда. Отчеты в ней — CLOB-записи SQL-ей в таблице. Исходников клиентов/серверов нет. Неизвестно даже, на чем оно написано. А новый отчет хотят. Вы предлагаете мне сказать заказчику, что сделать это невозможно, потому что не по науке раз в год нагрузить сервер 365 пустыми строками?
Нет, не смеюсь. Разные подходы могут отличаться по быстродействию? Почитайте вот здесь, www.sql.ru/forum/actualthread.aspx?tid=752505&pg=1&mid=8656527#8656527, в одном из топиков — сравнение быстродействия пайплайнед и коллекций. Если читать лень, то я подскажу, что там написано: на 18% быстрее оказались коллекции. Там же и дискуссия по поводу целесообразности использования NO_DATA_NEEDED.
Повторюсь, все зависит от идеологии и конкретной ситуации. Конечно, можно и на клиенте прописать логику для стапиццот отчетов. И при каждом чихе заказчика всем рассылать новую версию клиента. Или ковыряться в php/asp скриптах в случае web-интерфейса. И это при условии, что к этому самому клиенту есть доступ… А можно один раз научить клиент отображать полученное, и всю логику отчета держать только на сервере. Лично я всегда был и остаюсь сторонником «тонких» клиентов и «умных» серверов.
Ну, это зависит от идеологии приложения наверное. Есть задачи, где клиент выполняет чисто презентативную работу, логики никакой не несет в себе, что сервер прислал — то и показал.
Это уже из OLAPa фишки? У меня на 10g даже не запустилось, мотивируя отсутствием табличного пространства express…
Интервальный тип по крайней мере для дат не слишком удобен, можно, конечно, получать каждый третий день, но вот получить только первые числа месяца уже не получится. Да тут много разных вариантов может быть, смотря какую задачу решать. Но принцип все равно останется тот же: вначале сформировать последовательность, потом с ней соединить имеющиеся данные. Для разовых задач наверное проще использовать голый SQL типа иерархического, для часто повторяющихся лучше создать функцию.
Да, PIPELINED-функции удобней, но они появились начиная с 9-ки, а это и в 8i работает. Потому и привел именно этот вариант функции, как более совместимый.
Можно и через иерархический запрос, вроде вот такого:
SELECT start_data + LEVEL-1 data
FROM (SELECT TRUNC(SYSDATE-7) start_data, TRUNC(SYSDATE) end_Data FROM DUAL) t
CONNECT BY start_data + LEVEL-1 <= end_Data;
Это имелось ввиду? А вот что ты имел ввиду под «моделями»? Не доводилось сталкиваться с таким или же для меня оно называется как-то по другому.
Так де понял, зачем интервальный тип для шага?
а результат получает тогда, когда он уже не нужен?
Любое сравнение с нуллом всегда ложно:
Интервальный тип по крайней мере для дат не слишком удобен, можно, конечно, получать каждый третий день, но вот получить только первые числа месяца уже не получится. Да тут много разных вариантов может быть, смотря какую задачу решать. Но принцип все равно останется тот же: вначале сформировать последовательность, потом с ней соединить имеющиеся данные. Для разовых задач наверное проще использовать голый SQL типа иерархического, для часто повторяющихся лучше создать функцию.
Можно и через иерархический запрос, вроде вот такого:
SELECT start_data + LEVEL-1 data
FROM (SELECT TRUNC(SYSDATE-7) start_data, TRUNC(SYSDATE) end_Data FROM DUAL) t
CONNECT BY start_data + LEVEL-1 <= end_Data;
Это имелось ввиду? А вот что ты имел ввиду под «моделями»? Не доводилось сталкиваться с таким или же для меня оно называется как-то по другому.
Так де понял, зачем интервальный тип для шага?