Создать вьюхи на стороне БД - единственно правильное решение, т.к. при смене схемы БД без вьюх нужно нехило лопатить BW...

А вьюхи - это интерфейсы к данным, выходной интерфейс при смене схемы БД должен быть неизменным.

Отделяйте мух от котлет. Есть поставщик данных, мы с ним договорились об интерфейсе. Если без вьюх - при изменении схемы БД весь интерфейс летит к чертям.

Сам столкнулся с этим. Если бы без вьюх делали - долго бы еще после смены модели БД тра... транзакциии бы разные запускали и исправляли логику загрузки.

Знакомо. Лихо вы технические вопросы решаете. А с чего вы взяли, что админ имеет к вам какое-либо отношение?
Попробуйте посмотреть на это с другой стороны. Вам любезно предоставили доступ к базе: завели пользователя, дали права на чтение. Импортируйте на здоровье. Не импортируется? Так это недоработка САП системы, а не оракла. В моём понимании проблему нужно решать там, где она возникла. Вы же предлагаете исправлять следствие, а не причину.

Смотрите мой предыдущий пост.

Попробуйте посмотреть на это с точки зрения руководителя проекта. Приходит к нему этакий программист и говорит - медленно работает на компьютере SAP, давайте я перепишу ядро SAP, и он будет быстро работать. Ведь нужно исправлять причину, а не покупать быстрое железо.
Ситуация обычно такова, что при малых ресурсах нужно много сделать. Так что такие предложения идут лесом...

Ваш подход - это подход технаря, который сам себе хозяин. Сказал финансовый директор - надо - а вы его послали по матери, потому как с вашей точки зрения это не верно. А финик или собственник смотрит на вещи по - другому. Стоимость доработки интерфейса со стороны сап составляет не один десяток тысяч долларов. Стоимость создание вьюшки на стороне БД - копейки. Внимание вопрос, что сделает ГРАМОТНЫЙ финансист?

А я могу поставить проблему под другим ракурсом. R/3 приходит на предприятие надолго. Это дорогая система. И тендеция такова, что Р3 становиться основной системой, под которую подстраиваются другие. Вы как админ другой, не саповской, системы просто саботируете внедрение интегрированной системы управления предприятием. Таким образом, вставляя палки в колеса, вы наносите многомиллионный ущерб предприятию. Из за того, что вы упираетесь, на предприятии не может быть внедрена систиема, а из - за этого предприятие не может например выйти на IPO и т.д. Или финансовый директор не увидит всей картины того что твориться на предпрятии.

Таким образом вы подрываете экономическую состовляющую благостостояния собственника. А САП поддтвердит, что стомость доработки будет очень велика. И по времени очень длительна. А сопровождать это - еще дороже. И не надежно все это. А самое дешевое и надежное - это нагнуть админа и сделать вьюху. потму как делов на час работы по сравнению с пару - тройкой недель упорной работы абапера + консультанта + адамина. А сопровождать это - ИТ отделу по сопровождению - дополнительные траты и нагрузка. по всем статьям выходит, что нежелание админа встает компании в пару сот тысяч долларей. И в гарантированной 2 недельной задержке внедрение продукта.

И вот теперь после такого спича на каком нить сборище руководителей проекта долго ли вы будете настаивать на своем в этой компании?

Вы смотрите как технарь, который сам себе хозяин. Вы являетесь хозяином самопальной системы. А хозяин у SAP - продуктов - собственник и владелец бизнес - процесса. Тут парадигма другая.

Предлагаю данную дискуссию прекратить, так как она все равно беспредметна - надо рассматривать каждый конкретный случай по-одельности. Решения бывают разные. И не факт, что ваше решение - единственно верное.

Руководитель проекта испытывает сильное недоумение по поводу того, как работает импорт в BW из Oracle.
А вообще, вы как-то странно истолковали мои слова.

Не имею такой привычки - посылать по матери. Обычно пользуюсь другими аргументами.

Спасибо, я в курсе, что SAP - дорогостоящая система. Тем более удивительно, что такая очевидно необходимая функциональность, как импорт из другой БД сделана через одно место.

Грамотный финансист должен знать, что информация, хранящаяся в БД, может стоить на порядки больше, если её вообще как-то можно оценить. Поэтому подход к организации системы её хранения должен быть максимально строгим. Есть мнение, что в БД не должно быть ничего лишнего.

Непросто у вас админам живётся.

Речь не о саботаже или нежелании админа. Речь об организации системы хранения данных. Которая была внедрена, разрабатывается и поддерживается задолго до начала внедрения SAP. В общем случае её главные цели - несколько отличные от организации максимально комфортной выгрузки данных в SAP.

ОК

Я на вселенскую истину не претендую. Вы спросили - я пояснил свою точку зрения.

Ну, кто еще тут не понял что бивишники - это самые крутые перцы, после прихода которых на проекте все начинают плясать под их дудку и лихорадочно трудиться в поте лица
По секрету скажу, все из-за того, что основными потребителями отчетности является финансовая служба, которая бошку за копейку оторвет и руководство (умолчу про то, что они могут сделать )

p.s.: просто с утра хорошее настроение.

Приведите пример как создание вьюхи может нарушить целостность/производительность/да мало ли что в Оракле?
По-моему целью создания любой системы является все же предоставление требуемых данных владельцу бизнеса, а не внутренняя стройность и правильность (это само-сабой).

то плясун: я просто повернул проблему под другим углом. все надо смотреть в комплексе. целостность вьюха ненарушит. финансисту вообще по барабану на организацию хранения. для этого он содержит штат ИТ.

то Blizzard: вьюху тоже можно построить так, что постой селект из нее запросто "положит" систему...

ну при желании конечно ломать не строить.
я по опыту сужу...все прекрасно работает...и оракл пашет и данные идут и все договорились в короткие сроки:)

Хмм...ну ладно...доступ к базе предоставили, пользователя завели, права на чтение есть...вьюху делать не дают по причинам:


что делать??!!

Варианты :
1.Ставим рядом точно такой-же оракл "Оракл Б"
1.1 настраиваем переодическую репликацию из оракла А в Б
1.2 делаем в оракле Б необходимуюже Вьюху/ХП
1.2 грузим все в SAP
плюсы - оракл A не усложняется, дополнительных Сущностей в нем не создается
минусы - долго и геморно, да искорей всего прав только на чтение не хватит

2.Ставим рядом точно такой-же оракл,
2.1 делаем дблинк в оракле Б на оракл A
2.2 делаем в оракле Б необходимуюже Вьюху/ХП
2.3 грузим все в SAP
плюсы - см вариант 1, побыстрее и чуть меньше геморроя
минусы - второй оракл все равно ставить в лом

3. делаем дблинк(или аналог дблинка, если SAP стоит не на оракле) в саповской базе на оракл A
3.1 делаем в в саповской базе необходимую Вьюху/ХП
3.2 грузим все из саповской базы в SAP
плюсы - быстрее и менее геморно чем вариант 1 и 2
минусы - скорей всего SAP не одобрит усложнение своей базы и создания в ней дополнительных Сущностей

Осталось только найти добровольца (если админ откажется) который будет писать Вьюху/ХП и поддерживать ее в актуальном состоянии

Гуру вы наши, поясните, пожалуйста, если нетрудно - что такое "вьюха"? и тем более на стороне оракла

Сначала покажите, где я это утверждал.

Не только.
Также для получения требуемых данных в удобной форме существует возможность использовать SQL на стороне клиента БД.

Без этого никуда.

Предложенные вами варианты, конечно, тоже имеют право на существование.
Я думаю, что правильнее всего посылать native sql-запросы из САП системы. Только для этого придётся дополнительно программировать на ABAP-е. Так как в DB Connect такой возможности, к сожалению, не имеется. Почему этого не предусмотрели разработчики САП - лично мне непонятно.