> правильный - второй

Пара миллионов юзеров типа ни разу не пугает? ;) Дружище, поделитесь, пожалуйста, где Вы об этом прочли.

> В моём случае пользователей будет максимум 50 человек

Это не оправдывает кривые решения.

> отдельные пользователи БД заводятся на группу

Вот, это уже ближе к теме. И таких групп - а следовательно, и пользователей СУБД - будет сильно (на порядки) меньше, чем пользователей. Ничего общего с "каждому юзеру по пользователю СУБД".

> Если все пользователи уже являются членами домена, то третий вариант наименее кривой

Пользователи домена, дружище, это мелкомягкое изобретение. Что само по себе не подразумевает его промышленного применения. Хотите делать на основе LDAP - не вопрос, хорошее решение для ограниченного применения. А вообще решений для нормальной авторизации куча: от OpenID до универсальных SSO с кучей готовых плагинов.

> В исходном посте сразу же указывается, что речь идет о MSSQL 2005. Надо внимательнее читать.

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

Я Вам, Bely, по секрету скажу: незачем плодить полу-/недорешения. Решение, полученное в общем виде, будет отлично работать и в частных случаях. Кроме того, здесь обсуждается один из трех канонических уровней ограничения доступа, так что рассматривать его без двух остальных, как самодостаточное, - ошибка (или сильное упрощение - как больше нравится).

> Вопрос только в стоимости решения

Именно. Вы считаете только деньги, которые нужно заплатить здесь и сейчас? А не хотите посчитать затраты, скажем, лет за пять?

> Далеко не всегда решение в общем виде будет дешевле частного решения

Если говорить о проектировании баз данных - всегда. База данных - это наиболее сложно изменяемая компонента любого софта. Стратегически правильно потратить больше денег и времени на этапе проектирования, чем регулярно заниматься переписыванием. "Решение в общем виде" не означает, что должна быть и реализация в общем виде. Иногда достаточно понимать, как и куда будет развиваться база данных, чтобы ее изменение не было фатальным для приложения. Возьмите это обсуждение: всего и требуется для задачи - сопоставить не пользователя приложения пользователю СУБД, а группу пользователей приложения пользователю СУБД. Простое решение? Да. Очевидное? Да. И это маленькое простое решение позволит строить одинаковым образом приложения любого масштаба, а не только для 50 пользователей, как хотелось автору. Хорошая структура данных тем и отличается от плохой, что в каждом конкретном случае правильно решается маленькая подзадача. 90% задач - это типовые задачи, где не нужно ничего изобретать.

> Так давайте ставить ERP контор из 20 человек?

Давайте. И это будет правильно. Проблема в том, что нет ERP решений приемлемой стоимости и приемлемого качества. Вы что же, думаете, что ERP - это такая страшная софтинка, которую непременно нужно внедрять пару лет? ;)

> Которые сидели и сидеть будут на "мелкомягких изобретениях"

У Вас есть дар предвидения? ;) Мне это не кажется очевидным.

> И у них все ПРЕКРАСНО работает

Они думают, что у них все прекрасно работает. Просто потому, что не знают, как это должно работать. Я уже говорил, что альтернативы учетному софту "из коробки" нет. Всем остальным задачам - есть.
.
> вот только работать люди не смогли

Что значит "не смогли"? Браузер, почтовый клиент, офис работают точно так же, как в форточках, даже если не париться и сделать все максимально просто, устанавливая софт из штатных репозиториев. Консоль использовать не обязательно. Какие задачи вызвали затруднение?

> У каждого решения СВОЯ область применения!

Imho это однобокая точка зрения. Уникальных задач не так много, как кажется на первый взгляд.