Здравствуйте, mark_kavinski, Вы писали:

_>Здравствуйте, Algebroid, Вы писали:


A>>>>MS SQL нет на мэйнфреймах.
_>>>Много ты мейнфреймов видел?

в детстве видел ЕС ЭВМ — клон IBM 360

A>>>>для маленького предприятия конечно очень удобно. и удобно администрировать.
_>>>Для большого тоже удобно.

Для большого нужен быстрый диск.
Когда на диске миллионы записей даже индексированный запрос идёт ощутимое время.

A>>количество записей в таблице ограничено несколькими миллионами.
_>Кто тебе такую глупость сказал?

Залей миллиард записей. Какой диск по размеру для этого нужен. И посмотри скорость выполнения поисковых запросов.

A>>>>или можно поставить MSSQL на ферме серверов с RAID-массивом?
_>>>С чего бы было нельзя? Рейд-массив вообще никакого отношения к RDBMS и к фермам не имеет. Любая RDBMS становится на рейд-массив любой конфигурации.
_>>>Стандартное применение MSSQL это как-раз бекенд для разного рода ферм.

A>>рейд-массив нужен чтобы хранить одну большую базу данных.
_>Рейд-массив нужен не для этого. Рейд массив нужен для избыточного хранения информации (зеркалирование) и для увеличения I/O. Какие данные на нем хранятся это вообще перпендикулярно.

Зеркалирование нужно чтобы крах одного диска не привёл к потере критичных/критичнейших данных.

A>>>>стандартный датагрид в NET неудобный.
A>>>>а в борланде
_>>>Где?

A>>в делфи и с++билдере
_>Делфи давно не борланд.

это ещё борланд разрабатывал. а потом в его фирмах-потомках осталось.

A>>>>есть навигатор по гриду. можно соединять таблицы мастер-деталь.
_>>>UI компонент для .NET WinForms и WPF создано ВЕЛИКОЕ множество. Каких угодно.

A>>только в стандартной комплектации их нет. надо допиливать.
_>Точно та же история с Делфи — нужно допиливать под конкретные требования.

чтобы было что-то очень красиво допиливать конечно надо.

_>В любом случае для построения богатого UI WPF гораздо-гораздо удобнее.

имею ограниченное представление. но не спорю.

A>>>>браузер ограничен функционалом.
_>>>О каком функционале речь?

A>>одна загрузка страницы — одно нажатие на кнопку.

_>Открой для себя AJAX и DOM-манипуляции.

удобно только настройка пожирает много времени. плюс кроссброузерность — это всегда трата времени.
хотя конечно для одного интранета можно под один броузер писать.

A>>>>а AJAX придуман для написания толстого клиента в веб-броузере.
_>>>Жесть... Почитай чтоли что такое "толстый клиент".

A>>нет жмешь на кнопку а она генерирует скрипт который динамически обновляет страницу. возни конечно больше.
_>Какая кнопка? Какой скрипт? При чём тут "толстый клиент"?

толстый клиент — это традиционный клиент в архитектуре клиент-сервер. нажал на кнопку обновил пол-экрана. но сам экран при этом не перезагружаешь.
AJAX призван достигать той же функциональности с обычной веб-страницей.

A>>>>>>но данные к нему доставляются посредством SQL-запросов.
_>>>>>Посредством SQL-запросов данные выгружаются из базы данных в некий middle ware, а уж потом как-то подготавливаются и в каком-то виде могут быть показаны на UI конечному пользователю. А могут и не быть вовсе, если это какой-то workflow-процесс.

A>>>>это конечно круто и корпоративно но или не очень эффективно?
_>>>Не понял вопроса.

A>>миддлвэр жрёт ресурсы.
_>И?

миддлвэр требует быстрых серверов и обслуживания.
но это конечно корпоративный подход.

A>>но работает благо есть быстрые серверы.
A>>это также имеет отношение к нашей теме — быстрый нативный компонент или удобная платформа со своей виртуальной машиной но требующая больше ресурса.
_>Какого ресурса?
_>Я ещё раз повторюсь: инструмент выбирается под задачу. Почитай про тот же Erlang.

смотрел обзор.