MaxiStyleПри разработке нового проекта возникла дилема между двумя концепциями проектирования:
проект строится на oracle+apache+php
Концепции:
1) разработчику надо парится с переносом всей логики в БД, никакие "костыли" и "заплатки" практически не возможны
2) - на каждый запрос придется писать представление и легко запутаться в их большом количестве
3) - возможное не правильно использование представлений: когда нужна только одна таблица, а берется представление из нескольких таблиц.

1) попарится один раз, ниче с ним не случится.
2) В реальном мире как-то чаще оперируют большим кол-вом ХП,а не View, не знаю, чем обусловлен ваш выбор. Большое кол-во - это сколько для вас?
3) Этот пункт вообще не понятен... Неправильно можно что-то использовать, только если руки кривые!

Совет: как можно больше логики на сервер. Централизация рулит, даже если это веба. Другое дело, что не стоит делать на сервере то, для чего он не предназначен(прим.:сложные мат. вычисления)...

MaxiStyle2 Megabyte :
1) париться придется всегда, т.к. проект модульный и постоянно будет дорабатываться.
2) будет около 400 таблиц, представлений думаю будет не менее 1000.
3) не правильно это когда лень заглядывать в код вьюшки, чтоб проверить на наличие не нужных таблиц. например во вьюшке соединение 4 таблиц - например выгребается инфо клиента фио, адрес, место работы, телефон. в конкретном случае нужно только фио и телефон, в итоге если пользоваться вьюшкой, то идет лишнее соединение 2-х таблиц.

по совету: ну ведь логика все равно будет на сервере, либо в PHP (как мне кажется легче), либо в БД. Ну сложные мат вычисления врядли понадобятся, а вот работа со строками - форматирование регулярками, поиск подстрок и т.п. часто.

4) Вообще интересует опыт использования 1-го метода, когда вся-вся логика в БД.
1) Заранее проектируйте так, чтобы можно было развивать структуру БД. От нее все приложение будет плясать.
2) П-Л>> будет около 400 таблиц, представлений думаю будет не менее 1000
Странная пропорция.
Какая предметная область ?
Согласен. Не проще ли будет ХП с параметрами, ну или даже View с разным условием WHERE...
3) Конечно важно не тащить лишнюю инфу на клиента, но не надо делать из этого идеологию.
Проектируйте правильно, разбивайте на сущности.
4) Так делают все нормальные люди. Ибо одна и та же БД, в идеале, может использоваться для разных приложений и по разному назначению.

з.ы. главное, если плохо в этом разбираетесь, почитайте про грамотное проектирование БД, нормализацию и т.п.