Насчет портала не скажу - не знаю, а в отчетах надо использовать лексические параметры подстановки в запросах. То есть запрос будет выглядеть примерно так

select &col1 col1, &col2 col2, &col3 col3
from &tab t
(по желанию where и т.д.)

При этом обязательно надо использовать псевдонимы для колонок и таблиц. Остальное надо смотреть в документации...

В остальном я согласен с предыдущим ответом.

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

И как бы не ругались администраторы базы, если это необходимо для дела - их мнение надо игнорировать.

2 Vladimir_

Когда администратор просит "почаще делать коммит", из-за чего усложняется логика из-за снятия блокировок и отчеты все время падают по snapshot too old что вы делаете? Я посылаю такого админа подальше.

Vladimir_, Al, по-моему, неквалифицированных девелоперов больше и вреда от них больше, чем от неквалифицированных админов.

У неквалифицированного девелопера все равно что-то будет криво, медленно, но работать, делать то, что надо пользователям. Ради этого, собственно, и ставится система. У неквалифицированного админа перестанет работать все. В этом вся разница. Иногда дешевле купить более мощную железку, чем переделывать "как надо" - тратить деньги и, главное, время.

Ведь что такое таблица? - это физическая реализация сущности.
Что такое сущность - это всё что нас окружает - обьекты реального мира.

Взять например сущность "Сотрудник". Эта сущность используется во многих задачах. У сотрудника есть определённый конечные набор свойств(атрибутов) - имя, должность,оклад итд. Этот набор определяется изначально раз и на всегда. Он конечно может меняться, но не каждый же день и на лету.

Когда экземпляр сущности исчезает, то исчезает строка из таблицы, а не сама таблица.

Золотые слова. С одним дополнением - по определению, сущность - это объекты бизнеса. Из-за недопонимания этого возникает следующее ошибочное предложение:

То-же самое можно сказать про любую таблицу.

А вот это неверно. Можно также сущности разбивать в разные таблицы или сливать в одну несколько сущностей. Все зависит уже от прихоти разработчиков (тюнинг, реализация подтипов, моделирование дуг и т.д.). И можно запросто создавать таблицы, не имеющие сущностей в виде прообразов. Все администрирование приложений, денормализация внутри таблиц или создание специальных денормализационных таблиц относится к таблицам, не имеющим сущностного прообраза.

Забывают еще и о реализациях ключей, которые можно делать по-разному, хотя в сущностной картине все элементарно.

Последнее, что хотел бы сказать о разработчиках оракла и необходимости "мудрого совета от администратора". Беда разработчиков в том, что они часто просто не понимают, как работает оракл и не читают документацию хотя бы в объеме концепций и application developers guide. Поэтому администраторы и чувствуют себя так вольготно и ведут себя так нагло, как я описал в предыдущем письме. Попробуйте любому администратору сказать, что вот здесь надо на таблицу вместо внешнего ключа повесить проверку ссылочной целостности на триггерах, и вы услышите о себе много интересного. А потом тот же администратор будет всем говорить, что внешний ключ включается слишком долго, поэтому пользователи должны ждать.

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

Al, разработчиков из категории "нормальные" (в твоём понимании) можно пересчитать по пальцам одной руки...

Мне наверное повезло, что я всегда работал именно с "нормальными". Очень жаль. Особенно потому, что мало кто стремится к этому. В результате и ходят легенды о потрясающей сложности оракла, хотя практически ничего, выходящего за пределы книги Вирта "Алгоритмы и структуры данных" там нет. Те же структуры индексов, хэш-алгоритмов, сортировок слянием. Для того, кто знаком с файловой системой ничего нового нет в распределении сегментов и экстентов.

Короче, кроме некоторой общей подготовки и определенной усидчивости и желания, ничего не надо.

2 softbuilder

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

2 softbuilder

to Al: хорошо, давай тогда спокойно разберёмся без всяких обид и эмоций.
Чем тебя не устраивает определение: "Что такое сущность - это всё что нас окружает - обьекты реального мира."?

То что говоришь ты - "по определению, сущность - это объекты бизнеса" - это подмножество окружающего мира.

Сам по себе обьект - человек, бог, книга - могут быть частью бизнесса, но не только. Человек может быть просто чьим родственников, бог в качестве книги о нём - может быть бизнессом для тех кто зарабатывает на продаже книг.
Книга может быть частью гуманитарной помощи бедным.

Но нельзя же весь окружающий нас мир называть бизнессом.

Ты не согласен?

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

Поэтому, определение сущности как "все, что нас окружает" - непрофессионально. Так можно говорить на кухне под водочку и новости ТВЦ, а не в форуме по базам данных. Тогда определение сущности в ИТ как класс бизнес-объектов, информацию о которых необходимо хранить - профессионально. Это определение моментально выбивает Бога, гуманитарную помощь и абстрактного человека из сущностей. И я не согласен с родителем топика, что надо строить максимально общие модели. Тогда появится необходимость для каждого клиента строить собственного клиента. Кроме того, полученная система будет работать неоптимально. Более правильно использовать общие модели в настраиваемой части и детальные - в статической части ИС.

2 softbuilder

Разве у организации, занимающейся гуманитарной помощью не может быть своей учётной системы?

Может (и должна быть). Но сущностная структура определяется бизнес-функциями. Правильно? В одной ИС тогда спонсор - сущность, у другой - нет. Но в любом случае Бог никогда сущностью не станет, как не станет сущностью и киловатт-час электроэнергии.

Предлагаю закончить эту дискуссию. Или перенести ее из форума в личные письма. У меня емеля открыта.