Господа.
По моему мнению, причина спора не в уровне квалификации программиста, а в очень частом явлении - конфликте интересов. С этим постоянно приходится сталкиваться каждому и в жизни: в магазине, транспорте и т.д. В данной теме - это конфликт интересов пользователя/заказчика и разработчика/исполнителя. Чего обычно хочет пользователь? Получить всё, быстро, в том виде как захочется, сделать с этим всё что захочется, и чтобы в результате всё было "правильно" (т.е. так как он считает правильно). А чего обычно хочет разработчик? Ну вы и сами знаете. Выдать только самое необходимое, вид - чёткий, структурированный, жёстко ограничить возможности доступа и изменений по правилам. А в результате ... ну понятно, чтобы всё было "правильно" (уже по своему представлению о правилах).
Решения в этой извечной проблеме нет. Любая крайность приводит к печальным последствиям. Единственно верный путь - идти на компромисс.
А значит, чтобы быть хорошим разработчиком, мало быть крутым спецом по SQL и в совершенстве владеть C++, ObjectPascal, ... и тд и тп. Надо быть немножко и художником, и политиком, и психологом.
В книгах по SQL и Delphi про это обычно не пишут, приходится набираться жизненного опыта. Многим, к сожалению, мешает этакий "профессиональный" снобизм, присущий и пользователям и разработчикам. "Я знаю, моя база сделана по всем правилам, а запросы - оптимизированы. А кто этого не понимает - просто тупой юзверь." Ответное отношение - "Я здесь не первый год работаю, знаю свою работу вдоль и поперёк. И нечего меня учить как правильно нужно работать. И нафига вы мне сдались с вашими базами и запросами".
Моё мнение: в каждой конкретной ситуации решение будет своё. Бессмысленно спорить - "надо ограничить пользователя или не надо, а если надо, то насколько". Это зависит от конкретной задачи.
Применительно к примеру "отфонарной задачки" _svr. Вариант 1. Один пользователь, один запрос в час, в таблице 3 поля, размер записи .. ну 100 байт. Пользователь не всегда может чётко задать, по каким условиям отбирать записи (например: "помню, в названии слово какое-то китайское". Человек-то меня поймёт, а попробуйте на SQL паписать).
Стоит ли городить огород и мешать человеку работать вопросами типа: "Записей слишком много, уточните запрос.", "Записей попрежнему слишком много, уточните запрос.", "Вы уверены, что хотите получить все записи?", "А Вы точно уверены, что хотите получить все записи?", "Последний раз спрашиваю. Подтверждаете?".
Р-р-р...!!!
Вариант 2. 1000 пользователей, один запрос в 10 сек, в таблице 33 поля, размер записи 500 Кбайт. Не правда-ли, совсем другой подход?

Заранее извиняюсь, если кого обидел. Просто затронутые темы весма болезненные.

Извините Сергей.
Согласен, что пора прекратить эту затянувшуюся дискуссию. Но не могу удержаться.
Не первый раз слышу рассуждения, дескать в мелком проекте подходы одни, а в крупных - там всё по другому. Да ничего подобного! Всё, что нужно сделать в маленьком проекта, требуется и для большого. Просто маленький проект в состоянии выполнить один человек, обладающий достаточным уровнем квалификации в различных аспектах и разработки и взаимоотношений с заказчиком. Для крупных-же проектов требуется больше человеческих ресурсов - отсюда разделение труда и специализация (одно из великих изобретений человечества). Но это должна быть не просто аморфная толпа специалистов (с резко выделяющимся супер-сисадмином вроде qu-qu ), а хорошо организованная пирамидальная структура. Я для упрощения не включаю сюда финансово-экономическую сферу.
Так вот, на вершине пирамиды - руководитель проекта. Он несёт ответственность за весь проект в целом, и в любом случае должен ориентироваться во всех вопросах, хотя акцентироваться на руководящих функциях. Следующий слой - руководители направлений (или разделов) проекта. Они тоже должны быть достаточно развиты по всему проекту, но больше специализироваться на своём направлении.
Вот эти две категории я и называю "разработчики".
Когда-же пирамида достигает 4 слоёв, то нижний слой, как правило, чистой воды исполнители. От них не требуется ни инициативы, ни коммуникабельности, ни широты знаний. Узкая специализация, толковость и исполнительность - вот их основные достоинства.
При этом можно даже не обращать внимания на ворчливость или манию величия (платят мало, а ведь тут всё от мене зависит, щас нажму кнопку, все на уши встанут), главное чтобы дело делал и волю не давать.
Ну а если проявляет способности разработчика, то вперёд, пусть попробует принимать решения и нести ответственность за себя и подчинённых.

Так что, по моему мнению, различия между мелким и крупным проектом есть, но лишь в нарастании нижних слов у пирамиды и смещении профиля деятельности руководителей.

Ещё раз извиняюсь.
С уважением, Владимир Смирнов.