Victor MetelitsaЯ сейчас админю некую оракловую систему (московского производства; а я в Тюмени), где в одной схеме лежит более тысячи таблиц (и ещё пару систем с несколько меньшим, но тоже большим количеством). Не могу сказать, что это так уж плохо и неудобно, поскольку приложение разбито на подсистемы (их довольно много), а имена базоданновых объектов вообще и таблиц в частности префиксованы именем этих подсистем. Нигде в коде схема не упоминается, что означает, что можно легко сделать дамп одной схемы и загрузить в другую, а это удобно для отладки.

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

Многосхемная система практически вынуждает указывать схемы в коде, что лишает возможности держать данные нескольких покупателей в одной базе, требует создания отдельных баз. На мой взгляд, это неудобно.
там есть и другие неудобства, раздача привилегий на объекты из под владельца и на вторичные ключи....., но, мое мнение, разброс по логическим схемам и жесткая привязка к схеме на больших (более 300 таблиц на схему, а тем боле когда таблиц порядка 1000) БД это +.

Victor MetelitsaКакой смысл жёстко привязываться к схемам, если вы легко можете без этого обойтись?
Пишете "схема_таблица" вместо "схема.таблица" - даже количество символов не увеличилось. Да, конечно, этот совет больше подходит для DB2 v9.5, чем для более ранних версий, с их ограничениями длин имён.
попробую "защитить" свою позицию )))
в DB2 мне не приходится заниматься разработкой, а вот в Оракле приходилось,
вот что меня привлекало в отдельной схеме:
1. реинжениринг схемы, меньше обектов - меньше проблем;
2. четкое разделение по функциональности и по зоне ответственности;
3. возможность псевдо-версионности при разработке, можно было просто сделать EXP/IMP
схемы (правда здесь есть ограничения)
4. больше свободы при именовании объектов, допустим внутри "своей" схемы можно
названиями объектов более четко указать функциональность.


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