comparator,
Про выбор всё просто: где больше опыт - ту и выбирай. Если отойти от опыта, и порассуждать вообще, то: если ос винда, пишется всё под фреймфорк (VS) , приложение многоуровневое - ms sql оптимальный выбор. Т.к. ос, средства разработки, сервер бд представляют одно целое.

vadiminfoОсобенно, если этот Один в наши дни весит, скорее всего, нет так много в общем случае.
И где, этот Один, весит не так много в общем случае? В наши дни, именно, благодаря этому имеем повсеместный успех продвижения mssql и фреймворка в массы.

vadiminfoНу вроде как бы ...
Да вроде в ...
Представление о ситуации и проблемах в разработке сегодня, вроде как бы , понятно...

Victor MetelitsaмимоЕсли отойти от опыта, и порассуждать вообще, то: если ос винда, пишется всё под фреймфорк (VS) , приложение многоуровневое - ms sql оптимальный выбор. Т.к. ос, средства разработки, сервер бд представляют одно целое.
Огород, бузина, Киев и дядька не представляют собой одно целое. В частности, вместо огорода можно взять сад, вместо бузины - яблоки, вместо Киева - Москву, вместо дядьки - тётьку. Так почему же бузина оптимальный выбор?
Нельзя брать "вместо огорода сад", точнее неудобно и муторно.
Простой пример: допустим клиент написан под фреймворк, который использует понятные типы (int16,int32,буля и т.д.). Соответственно, получая данные с сервера бд для обработки необходимо, чтоб типы данных с сервера можно было замапить с типами клиента(фреймворк). Если вы используете связку net - ms sql - это делается автоматом: и там и там есть и инт и буля. Если же вы захотите вместо скл использовать оракл, то сразу возникают вопросы: а как там (в оракле) с интом и булей. Это можно конечно решить, но уже самодельщина. Не говоря уже об всяких орм, об "интегрировании" фрейворка в скл и т.д. и т.п.
Поэтому если винда и фреймворк, то скл наиболее выгодное решение, по соотношению "производительность/стоимость".

vadiminfoмимо...необходимо, чтоб типы данных с сервера можно было замапить с типами клиента(фреймворк). Если вы используете связку net - ms sql - это делается автоматом: и там и там есть и инт и буля. Если же вы захотите вместо скл использовать оракл, то сразу возникают вопросы: а как там (в оракле) с интом и булей. Это можно конечно решить, но уже самодельщина. Не говоря уже об всяких орм, об "интегрировании" фрейворка в скл и т.д. и т.п.
Поэтому если винда и фреймворк, то скл наиболее выгодное решение, по соотношению "производительность/стоимость".
Найдено решающее узкое место в "производительности/стоимость". Всякие там индексы, секционирование, материализованные представления, оптимизаторы можно теперь забыть. Им нуно было просто добавить типы "инт и буля" и готово "наиболее выгодное решение, по соотношению ".
"Всякие индексы и секционирование" и в скл есть и работают достостойно (некоторые могут не поверить, но факт). Материализованных представлений нет, но есть индексированные. А уж оптимизатор - на порядок лучше ораклового. Если сравнивать производительность оракла (11г) и скл (2008р2) на винде (на одинаковом железе) для селектов, инсертов, апдейтов, делитов при одинаковой структуре и объемах, то ораклу ловить нечего. Я не скажу, что скл на порядок быстрее, но оракл тут не интересен ни в каком виде.

vadiminfoКак бы ожидалось, что Вы сделали открытие, что производительность приложений БД решается на клиенте, а не как это считалось до сих пор на сервере.

И где я такое писал? Причем тут клиент, когда писал: мимоЕсли сравнивать производительность оракла (11г) и скл (2008р2) на винде (на одинаковом железе) для селектов, инсертов, апдейтов, делитов при одинаковой структуре и объемах, то ораклу ловить нечего.
Можете сами (если есть возможность) написать "пару процедур" выполнить их и познать истину.

vadiminfoмимоИ где я такое писал? .

Вот Вы писали.

мимоПростой пример: допустим клиент написан под фреймворк, который использует понятные типы
...
Если же вы захотите вместо скл использовать оракл, то сразу возникают вопросы: а как там (в оракле) с интом и булей. Это можно конечно решить, но уже самодельщина. Не говоря уже об всяких орм, об "интегрировании" фрейворка в скл и т.д. и т.п.
Поэтому если винда и фреймворк, то скл наиболее выгодное решение, по соотношению "производительность/стоимость".
.
Как видно "клиент написан" и "выгодное решение по соотношению "производительность/стоимость".

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

Basil A. SidorovмимоНа сегодня ситуация такая, что если рассматривать винду, то альтернативы разработки кроме как под фреймворк и нет.Ява работает и под виндой. Может убавите категоричности?
Под виндой работает и ассемблер. Но я не буду писать на ассемблере, имея не то что фреймворк, но даже голимый си. Т.к. это не производительно.

Basil A. SidorovОтсюда и выбор субд ясен.Если некто может разработывать исключительно под дотнет , то выбора, наверное, нет.
В яве нет и половины того, что есть во фреймворке по обработке/доступу к данным (адо.нет, датасет, linq и т.д. и т.п.)

Поэтому, с точки зрения производительности и эффективности разработки (графику не рассматриваю), альтернативы фрейморку нет и, соответственно, скл.

Basil A. SidorovмимоВ яве нет и половины того, что есть во фреймворке по обработке/доступу к данным (адо.нет, датасет, linq и т.д. и т.п.)
Поэтому, с точки зрения производительности и эффективности разработки (графику не рассматриваю), альтернативы фрейморку нет и, соответственно, скл.Эхе-хе ...
M$, конечно, стремится к монопольному положению, но до этого ей (M$) ещё далеко.
Разработку ведут не только для ms windows, но и для других систем.
Ява позволяет взять почти любой проект и "перенести" его с винды или на винду путём тривиального переписывания стартовых скриптов.
Если клиентская база становится (реально или потенциально) шире, то вопросы удобства программистов - последнее, что будет волновать бизнес.
Поэтому, если вас всё устраивает, то вы - правы. Но не надо считать собственную точку зрения истиной в последней инстанции.
Для сравнения необходим какой-то базис (знаменатель). Если брать в рассмотрение скл, то в не винды его нет. На люнехе майскл лучше майкрософтовского по всем параметрам.
Насчет монопольности: для домохозяек и дизайнеров с андроидами и маками, да макрософт упустил. Но насчет предприятий, где нужна безопастность (домены, соответствующая аутенификация), совместимое программное обеспечение - безальтернативно ( практика, как известно - критерий истины).
Насчет удобство программиста - это затраты на программиста. Чем больше зоопарк, тем дороже программист, соответственно меньше прибыль. Если программист знает фрейворк (с#) он может писать виндового клиента, веб (asp.net), сервер приложений, расширенные процедуры для скл. А уж удобство студии и интеграция с отладкой скл - увеличивает производительность программиста на порядок.

comparatorЯ долго крепился.
Но уже не выдерживаю.

Если один программист разрабатывает и database-tier и middle-tier и client-tier, то это не проект, а так, поделка, сделанная одним человеком. А если это творится на достаточно крупном проекте, то это не проект, а ....здец.

Всем спасибо за продуктивное обсуждение, не вышедшее далее первой страницы :-)
Крепиться - это правильно, главное не переусердствовать.
Как будете писать обработку(сложную) бизнес-логики данных с использованием сервера приложений? Как показывает практика, часть операций выгодно выполнить в бд, перед отправкой данных на сервер-приложений (что- то сложить, поделить, преобразовать и т.д.), так же существует часть операций, которые необходимо выполнить при возрате данных на сервер (какие-то преобразования, дополнительные запросы на основание обработанных данных и т.д.). Кто ж будет распределять, что и где делать? Для этого нужен человек, который понимает, что выгодней сделать на бд, а что на сервере приложений. Т.е. чтобы принять правильно решение он должен хорошо представлять все плюсы и минусы того или другого уровня. А без хорошей практики этого не добиться. Приняв решение он может озадачить двух падаванов (один на сервере приложений, другой на бд). Но постоянно так продолжаться не может, если сам не будет практиковаться, потеряет квалификацию. И соответственно, велика вероятность принятия неправильного решения, а проект то серьезный. Диалектика, однако. Каков выход?

Basil A. SidorovмимоНасчет удобство программиста - это затраты на программиста. Чем больше зоопарк"Это просто праздник какой-то" - Карабас-Барабас голосом Владимира Этуша.
Я понимаю, что монотеизм выключает логику, но не до такой же степени.
Какой, в пень корявый, зоопарк, если ява-проект на разных платформах отличается стартовыми скриптами???
Пассаж про MySQL даже и упоминать не хочется ...
Под зоопарком понимаю приложения разных производителей, которые надо состыковать и не понятно как.
Например: берем винду, домен. субд и надо состыковать аутентификацию. Если в качестве субд использовать скл - то без проблем, если оракл - то надо думать. Или берем орм, если родной и с скл - то без проблем, а если гибернейт и скл(оракл) - то надо думать и т.д.
А насчет переносимости на разные платформы: я не очень понимаю, что это за приложения такие, кроме хтмл страничек.