sphinx_mv "Вы не любите кошек? Да, Вы просто не умеете их готовить!" (с)
Их готовить умеют даже студенты первого курса. Очень рад за твой профессионализм, который таки осилил хранимые процедуры.

sphinx_mv"Вскрыть" один пароль от логина для подключение апп-сервера к базе данных - и все данные "на блюдечке" с полным комплектом прав доступа. Вот такая "небольшая проблемка" с безопасностью в апп-серверах...
"Вскрытие" пароля даже администратора сервера баз данных не всегда гарантирует получение доступа к данным базы даже для элементарного селекта - сугубо "к сведению"... Такая вот "чисто небольшая" разница...
И не будем "о грустном" - про встроенные возможности серверов баз данных в части аудита, когда реализация даже минимального их набора в приложении на апп-сервере обойдется дороже всей заказной системы...
1. "Вскрыть" один пароль от логина для подключение апп-сервера к базе данных - это глупости, которые не несут в себе смысловой нагрузки. БД недоступна вне периметра серверов + dmz для внешнего использования. Даже зная user password, ты не сможешь выполнять команды.
2. "Вскрытие" пароля даже администратора сервера баз данных - это такой же бред, как и выше. Защищаться от администратора - это больше похоже на сигнализацию в автомобиле. Во-вторых, защита самих данных - это другой вопрос, который решается с помощью криптографии и алгоритмов шифрования. Так что тут опять мимо.

sphinx_mvМСУ масштабировать решение на порядки сложнее

А Вы точно пробовали? "Терзают смутные сомнения" (с)
Точно пробовал. Сомнения засунь себе в штаны, им там будет лучше.

sphinx_mvПонятно, что это делается не по щелчку пальцев, но явно, что без "надрыва" - и в самом "тяжелом" случае с таким же самым уровнем сложности.
В случае нечерезжопной архитектуры это делается по щелчку пальцев. В случае использования хранимых процедур это вообще никак не делается. Полностью переписывается код с просадами по времени разработки, потерями человеко-лет в пустую, просирания бюджета. Кому нужно такое решение? Правильно, только мусорному баку.

sphinx_mvМСУ масштабировать логику на порядки сложнее

А с чего бы это логику надо было "масштабировать"?! Логика должна просто работать!
Просто даже мухи не сношаются. Масштабировать можно даже мух с котлетами

http://habrahabr.ru/post/113992/ Большинство web-приложений априори являются распределёнными, так как в их архитектуре можно выделить минимум три слоя: web-сервер, бизнес-логика (приложение), данные (БД, статика). Каждый их этих слоёв может быть масштабирован. Поэтому если в вашей системе приложение и БД живут на одном хосте – первым шагом, несомненно, должно стать разнесение их по разным хостам.


Логику очень удобно масштабировать с помощью SOA.

sphinx_mvИ если логики нет - тут не поможет не только масштабирование, но даже Г.Б-г
Если головы на плечах нет, тут уже ничего не поможет. Ни логика, ни её масштабирование.

sphinx_mvМСУ логике в бд не место, бд - это только данные и порядок их хранения (constraints, required)
А зачем Вам констрэйнты? У Вас же "умный" сервер приложений - вот пусть приложение на нем и занимается обслуживанием "логики".
Отслеживать корректность данных - задача БД, поэтому констреинты всегда прерогатива хранилища данных. Легкая валидация и простые предпроверки на клиентах - можно и нужно, только, чтобы не нагружать сервер баз данных лишними запросами.

sphinx_mvПо нынешним временам использовать в качестве тупого склада таблиц сервер баз данных - мягко говоря, не умно.
Яркий пример, аксапта. Классическая трезхвенка с тонкой БД. А вообще, я тебе уже советовал ни раз, читай архитектурный гайд от MS. Пора умнеть, что ли.

ViPRosну вощем пока Муси нет поговорили, счас он там отчет нашлепает и придет :) пора бечь
Я в отпуске. Прошу понять и простить

Alex KuznetsovМСУ, "Апологету" АПП серверов

защищенность ничем не лучше, чем в случае апп сервера но и не хуже (доводы про логин и пароль уже были приведены), вместе с тем, наличие АПП сервера не отрицает возможности использования хранимых процедур для решения поставленных задач - они как-бэ параллельны, мухи отдельно, котлеты отдельно...

Эти "доводы" высосаны из пальца. По поводу хранимок: зачем они тебе, если есть полноценный сервер приложений?

Alex Kuznetsov масштабировать решение на порядки сложнее Про масштабируемость : что мы вкладываем в данное понятие? Развитие (сиречь расширение) объектов и соответственно увеличение количества столбцов в таблице? Ну так в любом случае надо допиливать напильником и объект в БД и его отражение в конечном приложении. Не важно АПП сервер это или что-то другое... Надеюсь, что с этим Вы не станете спорить...

Вот тут подробно: 7 этапов построения масштабируемых веб-приложений. Стратегии для системных архитекторов

Alex Kuznetsov масштабировать логику на порядки сложнее

логике в бд не место, бд - это только данные и порядок их хранения (constraints, required)Эти два пункта, на мой взгляд, выступают вместе...
Про логику в БД полностью согласен. В крупных решениях, зашивать логику в БД ещё тот геморрой, тем не менее для мелких решений элементарные проверки можно выполнять в CRUD на уровне хранимых процедур (IMHO).

Ну так а какая польза от тупых крудов в хп? С этим отлично справляется ORM и без лишних объектов в СУБД.

Alex KuznetsovСкажу даже более, богатый опыт работы с SAP ERP в сравнении с тем-же Oracle App Server, показывает, что вынесение логики из БД есть благо, потому как не нужно править код в нескольких местах, т.е. нет лапшы, которая тянется через несколько слоёв. Вместе с тем сервер БД выполняет свою прямую работу - обеспечивает доступ к данным и их хранение, ни больше ни меньше.
Где отсутствует возможность централизованной интеграции и модификации существующего функционала, это просто единственный способ сделать хоть как-то, что-бы работало.

Alex KuznetsovPS. "Апологет" - это по доброму (обидеть не хотел, потому и в кавычках), т.к. сам являюсь сторонником серверов приложений :-) тем не менее, не на них одних всё крутится, иногда, для проезда в магазин за пивом, ракета не нужна, достаточно просто самоката (или лисапеда) :-)
Ок :)

sphinx_mvСказки Венского леса.
Если есть возможность "поломать" (точнее, уже реально "поломали") сервер приложений (или можете попробовать расказать еще про какие-то принципиально "другие способы" получения пароля для логина сервера приложений для доступа к БД), уже никакая DMZ не спасет. Доступ сервера приложений в DMZ к серверу БД не ограничен - в рамках слабо ограниченных прав сервера приложений можно выполнять ЛЮБЫЕ команды сервера БД.
Фантазеры пошли в лес по грибы? Совсем недавно ты говорил про получение "пароля от логина для подключение апп-сервера к базе данных", а тут уже и сам сервер подломили, получили к нему логин и пароль, подключились и начали шаманить с БД. Ты как тот клоун факир, что поджигает всё вокруг и мрачно улыбается. С таким же успехом я могу сказать про "подлом" учетки sa в MSSQL и радостно из любой точки зрения интрасети плести пряжу и надсмехаться над глупыми администраторами БД. Ты это, выйди из сумрака.

sphinx_mvЭто ничего, что кроме знания пароля администратора может потребоваться выполнение еще некотрых определенных дополнительных условий?
Это ничего, что это уже задача не аутентификации с авторизацией, а задачи логики? Которая отвечает на вопрос: как, что и где нужно зашифровать отдельными устойчивыми алгоритмами.

sphinx_mvНапример, ограничение на вход администратора только с определенного узла сети или вообще только "локально"? Самый "простой пример - MySQL... Привязка логина и пароля к хосту. Для одного логина может быть несколько паролей для входа с разных хостов. И реализовано это хз сколько версий этого сервера БД назад...
Великолепно. Завтра нужно будет выбросить мускул из-за стремной лицензионной политики оракла на мусорку и поставить ms sql server. И вся твоя мускульная секьюрная нативщина мягко сливается в унитаз. Решать безопасность приложений средствами БД - идиотизм и утопия.

sphinx_mvДля "более продвинутых" серверов БД доступны еще более "интересные" (встроеные!) способы защиты... Откройте для себя "fine-grained access control" , который позволяет прозрачно для приложений гибко (хоть по расположению звезд на небе) ограничивать доступ пользователей к отдельным записям таблиц... И так далее и тому подобное...
См. выше. Моя апп безопасность вполне может описываться честными независимыми провайдерами членства, типа мощного мембершип, симпл мембершип, win и так далее. И твой оракел нафик не упал.

sphinx_mvВ-общем, слабовато у Вас с безопасностью серверов БД...
Напротив, это что-то ты несешь горемычное и не здравое. Почитай букварь, писал же.

sphinx_mvКриптография - наше фсе... Ага... Типа, и сертификаты безопасности ни разу ни у кого не пропадают - даже в удостоверяющих центрах сертификации...
Ты решил под сомнение поставить сертификационные удостоверяющие центры и криптографию как науку? Подожди, я сбегаю за попкорном.

sphinx_mvИ, кстати... Вам "привет" о Сноудена...
Очередной мифический персонаж с конкретной целью, очень похожий на неудачный предыдущий вброс? Не, не знаю. Иди дальше сказки смотри по телевизору.

sphinx_mvО, как!
Оказывается, наш супер-пупер-спец по кластеризации серверов БД совершенено "не в курсе", что приложения НЕ НАДО не только ПЕРЕПИСЫВАТЬ, но и ИЗНАЧАЛЬНО ПИСАТЬ каким-то "определенным" образом для доступа к БД, лежащей на кластере. То есть - ВООБЩЕ!
Подумать только, даже обезьянки нонче в курсе, что способы кластеризации сервера баз данных никоим образом не сказываются на том, что нужно что-то переписывать. Иди это балансировщику нагрузки расскажи, он посмеется над твоим незнанием обсуждаемого предмета. Да и мы вместе с ним.

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

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

sphinx_mvВас уже приняли в отряд архитектурных астронавтов ? Ну, и как? Кислорода в балонах в высях Ваших абстракций хватает?
А обезьянки сидят на пальмах по колено в коде и радуются нативной безопасности msql. Забавно. И как, не жмет черепной короб от перенасыщения ума?

sphinx_mvМСУЛогику очень удобно масштабировать с помощью SOA.Масштабирование ради масштабирования - бред сивой кобылы!
Глупость ради тупости - непонимание того, что ты делаешь и зачем это нужно. А в остальном всё хорошо.

sphinx_mvПредположим, что вся бизнес-логика вынесена в библиотеку классов (сборка).
Она может быть просто включена в пользовательское приложение и дергаться "прямым" вызовом методов...
А может быть "опубликована" с бубенами, танцами, шлюхами и блэкджеком на сервере приложений - и это требует определенных "манипуляций" как для публикации сборки на сервере приложений, так и для обеспечений подключений пользовательского приложения к серверу приложений.
Это ж подумать только, какие такие несусветные сложности нужно преодолеть, чтобы на сервере приложений опубликовать общедоступную логику в той же DLL. Невообразимо просто. Зато при любом изменении этой логики не нужно обновлять всех подписчиков. Централизованный шлюз не так страшен как кажется, ты просто еще не дорос до понимания этой сути. Твой джедайский путь еще не окончен, странник. Читай букварь и наполняй пустую чашу до верху, а потом приходи сюда и вещай правду матку.

sphinx_mvПрактически это означает, что вместо одного полнофункционального пользовательского приложения необходимо вести два проекта: один - приложение для размещения на сервере приложений, и еще один - пользовательское приложение для доступа к первому прилоению на сервере приложений.
Ого, да ты неописуемо талантлив. Признайся, сам дошел до такого понимания или кто подсказал? А вот тут еще и плюсы:
http://ru.wikipedia.org/wiki/Трёхуровневая_архитектура масштабируемость
конфигурируемость — изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней
высокая безопасность
высокая надёжность
низкие требования к скорости канала (сети) между терминалами и сервером приложений
низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон.

И ты только представь себе, та самая масштабируемость на первом месте. О как бывает
Пора уже выходить из стадии непокорных кодеманок, безумно молотящих код в хранимых процедурах. С феерично приподнятым носом кверху и вещающим всем о том, что вот они какие млекопитающие, не такие как остальные.

sphinx_mvНу, и в каком месте возникает необходимость масштабирования? Правильный ответ - только для сервера приложений, который физически не способен выделить на каждого подключенного пользователя такое же количество ресурсов, как "локальная" пользовательская машина. А сервер базы данных, который в обоих случаях один и тот же, даже "не заметит" разницы от того, какой из "клиентов" делает к нему запросы - будь то локальное пользовательское приложение или сервер приложений.
Необходимость масштабирования возникает не сразу, а через некоторое время. Не понимать эту необходимость в будущем - удел простых смертных кодеманок вроде тебя. Когда эта необходимость возникнет, ты просто уныло разведешь руками и твой не менее сносный начальник опустит глаза в пол и "попросит" еще пару человеко-лет на модернизацию кода и адаптацию по потребностям. А задача-то банальна, масштабировать систему для подключения внешних юзеров через интернет. Проще его уволить вместе с тобой по статье за тупость, особенно когда вы будете предлагать такую глупость. А нормальный архитектор, по-честному спланировавший систему как 3 уровненую, будет радоваться и жить.

sphinx_mvИ отмечу особо - проблем с обновлением программного робеспечения НЕ существует... У кого они есть - пусть для начала научится менять адрес сервера в строке подключений хотя бы без затрат "человеко-лет"...
Проблемы с обновлением всегда существуют и существовали. Тебя бы на денек макнуть в саппорт на первую линию, хоть там мозгов набрался бы.

sphinx_mvТерзают смутные сомнения в адекватности содержимого головы у разработчика, который путает логическое выделение слов в приложении с обязательным физическим выносом бизнес-логики на отдельный сервер приложений...
Всё намного хуже, терзают смутные сомнения в адекватности содержимого головы у разработчика, который не видит пользы в разрезе масштабирования трехзвенки по сравнению с убогой двухзвенкой. Это даже пионеры знают из статеек на википедии. Но у тебя совсем другой случай.

sphinx_mvКстати, знакомьтесь - http://www.oracle.com/us/products/database/options/real-application-clusters/overview/index.html]"Real Application Clusters" ( опция , кстати), производитель которого вполне реально и адекватно позиционирует его гораздо выше "тупого сервера баз данных"...
Разницу между кластеризацией с балансировкой нагрузки и трехзвенной архитектурой понимаем? Ясен пень нет. Тогда развожу руками.

sphinx_mvЯ Вам еще раз говорю - это ПРЕКРАСНО делал парадокс!
У него были первичные и внешние ключи и прочие "дефолты и констрайнты", которые Вам так сильно нужны от сервера БД!
Все проблемы, которые с ним возникали - проблемы с многопользовательским доступом. Но, так как мы в курсе, что единственным клиентом для базы на парадоксе будет только сервер приложений, то это - "не актуально". Так почему наши "прадвинутые орхетектары" рвутся к использованию именно серверов БД, если с их "потребностями" справляется "древняя" файловая БД?
Во-первых, твой парадокс MS скинуло с рынка настольных БД своей профессиональной версией офиса с акцессом в 95. Во-вторых, продукт перестал развиваться, каким бы он хорошим не был (а-ля фокспро). В-третьих, как ни крути, но сервер баз данных отлично горизонтально и вертикально масштабируется стендартными средствами. Сделать тот же самый финт с wcf + embedded database будет на порядки сложней. Да и не нужно это никому. В-четвертых, я тебе десятый раз говорю, не путай кластеризацию сервера БД с понятием третьего уровня. Это параллельные вещи. В-пятых, у сервера БД в кластере может быть 10 серверов приложений. А это, вообще-то, уже несколько клиентов у БД, так что твоя "неактуально" еще как актуально.

sphinx_mvНу, и то, что Вы боитесь нагружать сервер баз данных запросами, для выполнения которых он, собственно, предназначен - Ваши личные религиозные проблемы...
Всё гораздо хуже. Печально осознавать, что "разработчик" не умеет работать с клиентской и unobtrusive валидацией. И самое главное, своей головой не понимает, для чего она придумана и каковы плюсы от нее. Это прискорбно.

sphinx_mvПокажите мне того поумневшего идиота, который сможет доказать, что выделение слоев в приложении требует обязательног о выноса слоя бизнес-логики на отдельный, быстро выдыхающийся при росте нагрузки "железный" сервер приложений.
Я тебе не говорю про обязательную нужность выноса логики из апп сервера на отдельное звено (хотя, никто не запрещает так делать). Я тебе говорю о необходимости иметь центральный апп сервер, через который работают клиенты. А как можно еще разнести апп сервер и на какие составляющие - это дело десятое и решается по мере определенного скоупа требований. Не мешай мух и котлет.

sphinx_mvГрустно, что некотрые "профессионалы" даже не осилили реляционные базы данных и при этом пытаются повсеместно их использовать...
С использованием технологий прошлого века - ISAM их все, однако...
Эти реляционные базы данных были "осилены", когда тебя указкой школьный учитель по макушке лупил за непонимание второго закона Ньютона. О чем ты? Выше уже писал - выйди из сумрака со своим непомерным "опытом" в СУБД. Просто смешно.

sphinx_mvНу, а периодически раздающиеся "крики" про "исключительную новизну" EF и про "трудности" при проектировании приложений для работы с реляционными БД без использования ORM - это вообще сказка!
Чё-то ляпнул, а что хотел этим сказать - непонятно. В чем суть впрыска, разъясни?

sphinx_mvМСУФантазеры пошли в лес по грибы? Совсем недавно ты говорил про получение "пароля от логина для подключение апп-сервера к базе данных", а тут уже и сам сервер подломили, получили к нему логин и пароль, подключились и начали шаманить с БД. Ты как тот клоун факир, что поджигает всё вокруг и мрачно улыбается.И это весь Ваш хваленый "оргументированный атфет" на выделенное? Маладца!
Это всё, что смогло осилить твое воображение? Честно говоря рассчитывал на адекватный ответ, а получился как всегда пук в кусты. Ну что ж поделать...

sphinx_mvМСУС таким же успехом я могу сказать про "подлом" учетки sa в MSSQL и радостно из любой точки зрения интрасети плести пряжу и надсмехаться над глупыми администраторами БД. Ты это, выйди из сумрака.Ну-ну.. "Подломите" логин sa... Ага...
А я тем временем за попконом схожу - закончился...
Отлично получается, значит у тебя пароли от сервера приложений щелкаются как скорлупа от ореха, а пароль sa - это что-то из ряда фантастики? И мне не забудь купить попкорна.

sphinx_mvХотя, квалификация Вашего админа вполне может соответствовать Вашей - и пароль, не менявшийся со времен установки сервера, и бумажка (на которой он записан), приклееная на лицевой панели монитора, вполне ожидаемы...
Если следовать твоей денормальной логике и твоему практически нулевому экспириенсу, то получается, что админа сервера приложений, который рассылает через "Ответить всем" пароли от апп сервера, тоже на кол? Забавно. Значит, политика паролей в БД должна вестись должным образом, а политика апп серверов нет? Даешь двойную порцию попкорна.

sphinx_mvМСУЭто ничего, что это уже задача не аутентификации с авторизацией, а задачи логики? Которая отвечает на вопрос: как, что и где нужно зашифровать отдельными устойчивыми алгоритмами. Ржунимагу! Слова-то какие! "Устойчивые алгоритмы"! Вот оно как!
Немудрено, особенно для кодеманок, которые впервые слышат о криптостойкости . Даже детвора знает о том , когда в TLS устанавливается соединение и сервер выбирает из списка, предоставленного клиентом, наиболее устойчивые алгоритмы, которые также поддерживаются сервером, и сообщает о своем выборе клиенту. Не знал? Знаю.

sphinx_mvМожет, по-Вашему, SSL (Secure Sockets Layer) надежен и безопасен?!
Смотря о какой длине ключа идет речь. Если рассматривать длину ключа 40 бит, то с такой секурностью можно только макак в зоопарке смешить. Если 256 бит, то такое шифрование максимально надежно и безопасно. Я тебе эту тему уже разжевываю не впервые, поиск в руки.

sphinx_mvА это ничего, что его уязвимость давно доказана и продемонстрирована даже при использовании в нем ОЧЕНЬ устойчивых алгоритмов шифрования? Ах, да... Вы же не в курсе... Ничего... Бывает... Но не у всех проходит...
Я тебе еще в прошлый раз говорил, что ничего там не доказано, это была игра двух конкурентов - центров, выпускающих сертификаты. Друг друга поливали грязью и вешали лапшу на уши. Иди эти сказки своему Сноудену расскажи.

sphinx_mvВ-общем, в криптографию Вам с такими познаниями в самом предмете, так и ситуацией с ним "в-целом" лучше не лезть. Еще лучше - даже не заикаться...
Проблема в том, что с твоими нулевыми скиллами вообще лучше не появляться на форуме. Засмеют и забросают шкурками от бананов. Ты как был бестолочью в криптографии, дотнете, БД - так ей и остался. Пока не прочитаешь букварь, толку не будет. Я думаю, ты и сам это прекрасно понимаешь.

sphinx_mvМСУВеликолепно. Завтра нужно будет выбросить мускул из-за стремной лицензионной политики оракла на мусорку и поставить ms sql server. И вся твоя мускульная секьюрная нативщина мягко сливается в унитаз. Решать безопасность приложений средствами БД - идиотизм и утопия.А еще каким бредом Вы нас порадуете?
Ты прямо брызжешь аргументами. Что именно бред, тупая политика оракла? Это даже дети знают. Но это не твой случай, я так и думал.
http://www.opennet.ru/opennews/art.shtml?num=37215
Иди лучше MariaDB изучай, для клоунов в цирке для "масштабных" проектов на двухзвенке - то, что доктор прописал

sphinx_mv
"Честные"... "Независимые"... Ага.. Аж прослезился...
Я заметил уже, от отсутствия мозгов в голове у тебя то слезы, то понос, то золотуха. Крепись там.

sphinx_mvА Ваши "честные и независимые мумбершит-провайдеры" ограничат доступ к данным аналогично запросу


таким образом, чтобы из таблицы "table" с миллионом строк вывести в результат ровно ничего, если подключившийся пользователь не должен иметь доступ к этим данным? Кстати, если к этим данным в принципе не должен иметь доступ администратор, результат запроса "в первом приближении" будет точно такой же... И такой результат будет получен при любом способе выполнения запроса с применеием любого "клиента".
Мембершип провайдеры ничего не ограничивают, деревня. Они реализовывают членство. Рассказывать, что это такое или хватит ума открыть гугел мугел?
Безопасность можешь описывать хоть декларативно, хоть в таблицах, хоть на луне. Для твоей миллионной таблички используется подход с нативными ролями. Роль 1 - просмотр сущности (не конкретной записи). Прибивай пользователя к этой роли и отсеивай левых юзеров сразу, даже без обращения к таблице. Ролевыми политиками можно описать всё, что угодно. А потом это радостно использовать на апп сервере. И даже если через время сменится СУБД или часть хранения данных (например, данные берутся из других источников) - я не буду с вылупленными глазами смотреть на задачу как баран на новые ворота. А вот ты пару раз обосрешься от такого поворота событий и придется тебя уволить. За тупость же.

sphinx_mvМСУНапротив, это что-то ты несешь горемычное и не здравое. Почитай букварь, писал же.
Ну, Вы бы свой букварик дочитали для начала...
Так я-то давно это сделал, в отличие от тебя.

sphinx_mvМСУТы решил под сомнение поставить сертификационные удостоверяющие центры и криптографию как науку? Подожди, я сбегаю за попкорном.Да хоть подавись попкорном!
Регулярные "приколы" с сертификатами в CA - это уже давно НЕ новость. Только наша муся об этом как-то "не в курсях"...
Бывает... Не у всех проходит...
Зачем мне им давиться, я лучше поглумлюсь над очередной твоей тупостью. Согласен?
Приколы, а тем более, регулярные - могут быть только в воспаленном воображении того, кто не понимает что это и для чего нужно. Весь мир сидит на SSL/TLS и в ус не дует. А у него все панические страхи. Но при этом учетка от sa - непробиваема! Ты бы это, в цирк бы сходил

sphinx_mvМСУОчередной мифический персонаж с конкретной целью, очень похожий на неудачный предыдущий вброс? Не, не знаю. Иди дальше сказки смотри по телевизору.Уже ВСЕ "заинтересованные" (включая ФБР и АНБ) подтвердили, что информация, таки, собиралась... Одному только мусе розовые очки не позволяют это "принять"... Ниче... Тоже (когда-нибудь) пройдет...
Ты эту информацию лично подтверждал в ФБР и АНБ? Я так и понял. sphinx_mv все жевал-жевал как лошадь, да по сторонам смотрел (с)

sphinx_mvМСУПодумать только, даже обезьянки нонче в курсе, что способы кластеризации сервера баз данных никоим образом не сказываются на том, что нужно что-то переписывать. Иди это балансировщику нагрузки расскажи, он посмеется над твоим незнанием обсуждаемого предмета. Да и мы вместе с ним.Бла-бла-бла... И весь это бред при том, что один "особоодаренный" рассказывал детские страшилки про невозможность масштабирования серверов баз данных. Или в детском саде будущему программисту не рассказывали про масштабирование серверов баз данных через кластеризацию?
Мда-с... Даже обезьянки знают об этом... А наш уе"недо-гуру" не в курсе...
Посмотрим дальше, о чем это "гуро" еще не в курсе...
Ты там у себя завязывай с наркотиками, серьезно. А то твоя шизофрения порядком надоела. Для тех, кто заперся в танке: я где-то говорил о том, что нельзя масштабировать сервера БД? Речь о другом, бестолочь. Дело в том, что все твое масштабирование накроется медным тазом, когда придет приказ сменить поставщика БД, или часть данных брать из другой системы через SOA шлюзы, или обеспечить работу через интернет и т.д. Пора бы уже начать думать, а не писать бредятину.

sphinx_mvМСУТут вообще цирк. Научи свой гавнокод работать с различными поставщиками СУБД, а потом мы с тобой продолжим говорить о перескоках.И с какими же поставщиками СУБД у меня есть какие-то проблемы?!
Ты вообще в вакууме? Со всеми поставщиками у тебя проблемы.

sphinx_mvИли, может, это Вы со своими "поделиями" перепутали? Ну, так у Вас, вполне возможно, проблемы и есть...
Вот только у меня с доступом к разным источникам данных проблем нет. То есть ВООБЩЕ. Каким образом? ЭЛЕМЕНТАРНЫМ!
Откройте для себя распределенные и гетерогенные запросы!
Да, походу ты точно в вакууме. Почитай букварь, не позорься - гетерогенные запросы выбрось на свалку. Ты хоть знаешь определение этого термина?

sphinx_mvИ еще - откройте для себя, что они доступны "искаропки" для любого вменяемого сервера баз данных.
А для "очень вменяемых" серверов доступна даже геетерогенная репликация данных...
За твое ноухау по поводу репликации - сразу на кол. Без выплаты заработной платы. Ты хоть раз работал с репликацией, чудо?
Безумные бараны, не умеющие делать распределенные механизмы через SOA, всегда будут предлагать идиотизм в виде репликации. Более адекватные люди в это болото даже вступить откажутся. Тебе еще расти и расти, мальчик...

sphinx_mvМСУСменой адреса в строке подключения ты можешь детвору в садику смешить, а тут речь о различных провайдерах, которые подключаются к приложению как факт.Бред сивой кобылы!
Не существует серьезных заказчиков , котрые в угоду идиотам-архитекторам будут под каждую новую версию ПО поднимать инфраструктуру на серверах БД от разных производителей! Просто ФИЗИЧЕСКИ!
Не, Вы, конечно, можете попытаться рассказать, какие сложности возникают у Вас при работе на разных платформах, но, к Вашему сожалению, к моим проблемам Ваши проблемы никаким боком...
Очередной понос говнокодера с нулевым опытом в разработке ПО. Во-первых, версия ПО и наличие 3 звена - это вещи ортогональные. Во-вторых, централизованный шлюз, это не только плюсы в масштабировании, но и низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Иди расскажи заказчику про то, что стоимость - это угода архитекторов. Так что иди лучше пиши свои тупые хранимки, на что-то большее ты не способен.

sphinx_mvМСУТонкая база и толстый сервер апп, вот основной принцип создания масштабируемых решений. Ты даже не осилил то, чем я тычу в тебя уже пятый раз - букварь с базовыми архитектурными вариантами создания ПО.
Вам кто-то сказал, что у Вас "самый правильный" букварь"? Ну, так он Вас обманул...
А какой смысл миру какому-то дурачку на лодке рассказывать, что он дурачек и один на лодке? Вот и я так думаю. Плавай.
Весь мир и более менее серьезное ПО в архитектуру закладывает распределенность в виде n звенки. А этот старшеклассник радует всех своими опусами про замечательность тупой небезопасной двухзвенки? Купи пионерский галстук и иди в курятник, посмеши курочек.

sphinx_mvУ меня у самого есть достаточное количество "букварей", где черным по белому и не всегда на понятном Вам русском языке написано, как правильно масштабировать сервера баз данных. Самое прикольное - не делая никаких различий между "тонкой" и "толстой" базами данных, и совершенно безразлично к "тонкости" используемого пользователями клиентского приложения.
Да ничего у тебя нет и не было, о чем ты. Масштабировать сервер БД может даже дурак, а отмасштабировать приложение - совсем другая задача. Для тебя неподъемная. Как я могу тебе писать о плюсах масштабирования приложения, если ты даже не знаешь, что это такое? Да и по поводу безопасности, сто раз уже писал, что можно элементарно под windbg снять строку соединения к БД, подкчлючиться через клиента management studio, открыть транзакцию, выполнить селект и пойти курить. Всё, система легла - срочно читать про изоляции транзакций и их виды. И это самое меньшее зло, что может быть с твоей убогой двухзвенкой.

sphinx_mvВот Вам про MSSQL
Вот Вам про Oracle
Вот тебе про 3 уровневую архитектуру. Вот тебе еще немного буков.

sphinx_mvМСУА до бюджета тебе еще далеко, обезьянок с хранимыми процедурами туда не пускают и на пушечный выстрел.
Посмеялсо!
Да, мне оно и не надо к бюджету!
Мне достаточно того, что Вашими порносайтам, для которых Вы писали свои "мумбершиты", ОЧЕНЬ далеко до тех задач, которые выполняют написаные мной хранимые процедуры на более чем высоконагруженном сервере баз данных. Телеком, однако... Мобильная связь... Фиксированная... Интернет... В одном не самом маленьком (но региональном) операторе. Нагрузку разрешаю оценить самостоятельно и среднепотолочно.
Так оно тебя и не пустят туды. Тут достаточно того, что ты так и не осилил эти сайты с мембершипами. Впрочем, как и не осилил вообще прикладное программирование. А выражать тупость в виде хранимых процедурок можно научить даже мартышку. Ни о каких высоких нагрузках ты ничего и не слышал, врунишка. Сидишь у себя в ларьке по продаже семячек и пишешь какую-то муть про нужность двухзвенки. Я плакал. Ты еще шнурки не научился завязывать, а уже про бюджеты, архитектуру, нагрузку.

sphinx_mvМСУА обезьянки сидят на пальмах по колено в коде и радуются нативной безопасности msql. Забавно. И как, не жмет черепной короб от перенасыщения ума?
И что из кода, показанного по Вашей ссылке взято не из Ваших "поделий"?
Это показан весь твой скоуп экспириенса, не более того. Примеряйся.

sphinx_mvМСУГлупость ради тупости - непонимание того, что ты делаешь и зачем это нужно. А в остальном всё хорошо.
Золотые слова!
Вас уже 4-ю страницу просят продемонстрировать необходимость использования трехзвенной архитектуры...
Но вместо вменяемого ответа Вы наглядно демонструете Ваше непонимания того, что Вы делаете... Уже хорошо, что Вы можете "своими словами" правильно охарактеризовать эту ситуацию...
Я тебе уже 10 раз дал ответ на этот вопрос.
Раз Два Три
Уже даже жираф бы понял про все плюсы трехзвенки. Но это не твой случай. Ты тупо смотришь за любые задачи узко и однобоко, как подабает несмышленому падавану.

sphinx_mvКроме "простоты масштабирования" трехзвенки Вы никаких других приемлемых аргументов ("потому что так принято" - не в счет) не привели... При этом и вменяемого опровержения моего утверждения о том, что в двузвенке (классическом клиент-сервере при работе с базами данных) проблемы с необходимостью масштабирования начинаются гораздо позже (при большей интенсивности нагрузки и большем объеме обрабатываемых данных), чем при использовании сервера приложений. И к тому же Вы самостоятельно пришли к выводу, что масштабируются сервера баз данных очень неплохо "стандартными" средствами...
Кроме "простоты масштабирования" трехзвенки, там еще есть и конфигурируемость, высокая безопасность, высокая надёжность, низкие требования к скорости канала (сети) между терминалами и сервером приложений, низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон. Если тебе этого мало, срочно в зоопарк. Там уже ждут.

sphinx_mvМСУЭто ж подумать только, какие такие несусветные сложности нужно преодолеть, чтобы на сервере приложений опубликовать общедоступную логику в той же DLL. Невообразимо просто. Зато при любом изменении этой логики не нужно обновлять всех подписчиков. Централизованный шлюз не так страшен как кажется, ты просто еще не дорос до понимания этой сути.
Наши "особым образом одаренные гуру" все еще не в курсе, что проблем с обновлением программного обеспечения НЕ СУЩЕСТВУЕТ? То есть ВООБЩЕ?
Я даже больше скажу!
Свои приложения я строю таким образом, чтобы при изменении логики в 99% случаев даже не приходилось перекомпилировать исполняемые файлы пользовательского приложения! Рассказать секрет? Рассказываю: размещение логики в хранимых процедурах на сервере баз данных!
Глупенький, твой секрет идет прямиком в мусорное ведро, если потребуется сменить СУБД или отстыковать логический кусок с сущностями и привязать интеграцию с внешним ресурсом. Во-вторых, в чем боязнь перекомпилировать код сервера приложений? Клиенты тут же получат обновления. Точно так же, в одном месте меняем. В-третьих, твой декларативный говнокод не поддается ни нормальному документированию, ни нормальному рефакторингу, ни человеческому интелиссенсу, и так далее. Рано или поздно, твои лохмотья превращаются в кусок неуправляемого линейного гавна на несколько тыщ строк кода. Не раз сталкивался с таким явлением в сторонних системах, разработчика этого отродия хотелось бы повесить за ноги без объяснения причин. И ты следуешь именно этому допотопно-ориентированному принципу. Больше гавна, больше! Вся твоя суть.

sphinx_mvМСУНеобходимость масштабирования возникает не сразу, а через некоторое время. Не понимать эту необходимость в будущем - удел простых смертных кодеманок вроде тебя. Когда эта необходимость возникнет, ты просто уныло разведешь руками и твой не менее сносный начальник опустит глаза в пол и "попросит" еще пару человеко-лет на модернизацию кода и адаптацию по потребностям. А задача-то банальна, масштабировать систему для подключения внешних юзеров через интернет. Проще его уволить вместе с тобой по статье за тупость, особенно когда вы будете предлагать такую глупость. А нормальный архитектор, по-честному спланировавший систему как 3 уровненую, будет радоваться и жить.Когда Ваш трехуровневый говнопродукт с теми же затратами сможет обеспечить хотя бы такую же производительность, что у нас в системе имеется сейчас - тогда и будете рассказывать, как оно замечательно - но вот только это вряд ли...
Наш весьма адекватный начальник, не кидающийся на всякую "рыгламную мишуру" о том как хорошо живется на серверах приложений, провел небольшое исследование и получил ОЧЕНЬ интересные результаты: после внедрения разных заказных или коробочных систем, построенных на трехуровневой архитектуре с использованием серверов приложений, независимо от наличия/отсутсвия поддерки вендоров (вопрос стоимости работ и их качества не рассматриваем), ВСЕГДА получалось падение суммарной производительнсоти практически в каждом случае. И там, где раньше без проблем справлялся (грубо) один сервер, начинает задыхаться пара серверов - при том же количестве пользователей и тех же объемах работы.
Да какие там затраты на продукт, что за бред ты несешь? Затраты почти такие же, а на этапе развития и поддержки всё окупается с лихвой. О какой производительности идет речь? О разнице в две наносекунды на реквест? Не смеши мои носки, они уже улыбаются. Третье звено - это не рекламная мишура, это банальная обыденность, которой должна владеть любая вменяемая респределенная система. А твоим унылым поделкам место в цирке, не более того. По поводу твоего "исследования" я вообще чуть от смеха не упал пацтол Где доказательства, факты, явки, пруфы, графики? А то сиранул в кусты и дело в шляпе. Не годится, попробуй еще раз.

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

sphinx_mvМСУВсё намного хуже, терзают смутные сомнения в адекватности содержимого головы у разработчика, который не видит пользы в разрезе масштабирования трехзвенки по сравнению с убогой двухзвенкой. Это даже пионеры знают из статеек на википедии. Но у тебя совсем другой случай.
Разницу между кластеризацией с балансировкой нагрузки и трехзвенной архитектурой понимаем? Ясен пень нет. Тогда развожу руками.;))) Рхжака!!! Падсталом!!!
Тут кое-кто с пеной у рта бьется головой об пол, что трехзвенка масштабируется, а сервера баз данных - нет. Когда ему показывают, насколько просто это делается, это "неадекватный" человек "уходит в несознанку", типа, кластер серверов баз данных к масштабированию не относится... Ага... Тот самый случай...
Ну, а то, что Вам была дана ссылка на RAC - ну, выделено-то было "application" - та самая часть которая соотносится с апп-сервером. И именно так оно позиционируется...
Ты настолько туп, что даже до сих пор не понял, о чем идет речь. Покажи пальцем, где я сказал о том, что сервер баз данных не масштабируется? Если ты не видишь никакой разницы между сервером БД и сервером апп, то я же уже писал - спасет только цирковое творчество. Там твое место, рядом с макаками, моржами и тюленями.

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

sphinx_mvМСУВ-третьих, как ни крути, но сервер баз данных отлично горизонтально и вертикально масштабируется стендартными средствами . ЙЕССС!!!
А кто-то жаловался на отсутствие возможности масштабирования в серверах БД - даже не набралось 10-ти страниц набрасывания дерьма на вентилятор, а у пациента уже улучшение!
А ты готов привести ссылку на то место, где я жаловался на отсутствие возможности масштабирования в серверах БД? А то ведь приклеется клеймо форумной балаболки. Не? Копай-рыщи, бобер. Ты должен найти пруф.

sphinx_mvМСУВ-четвертых, я тебе десятый раз говорю, не путай кластеризацию сервера БД с понятием третьего уровня . Это параллельные вещи.
А можно ссылочку, где я их уравнивал? Или, может, это кое-кто кое-чего кое-где и совсем чуть-чуть привирает?
Кластеризацию серверов БД я ВСЕГДА относил к масштабированию . И то, что масштабирование серверов БД даже с выносом логики на сервер баз данных в хранимые процедуры совершенно никак не сказывается на возможностях этого масштабирования - факт, опровергающий весь Ваш бред про какие-то невнятные сложности масштабирования логики в хранимых процедурах.
Ссылочку? Ты смеешься? Я тебе уже битый день об этом пишу, что ты как идиот с флагом ходишь по комнате и орешь о том, что я якобы доказываю всем о невозможности масштабировать сервер БД. Клиника

sphinx_mvМСУВсё гораздо хуже. Печально осознавать, что "разработчик" не умеет работать с клиентской и unobtrusive валидацией. И самое главное, своей головой не понимает, для чего она придумана и каковы плюсы от нее. Это прискорбно.
Вам не надоело срать себе в штаны?
И какими еще "страшшшными словами" Вы попробуете меня испугать?
Особенно - при том, что у меня НЕТ проблем ни с архитектурой, ни с производительностью, ни с сопровождаемостью моих приложений. ДЛя меня даже не актуальна Ваша проблема масштабирования - нет у меня ее! Все и так работает в строгом соответствии со спецификацией!
Для нормального разработчика это не страшные слова, а обыденность. Для кодеманки саппортёрши, которая уткнулась носом в гавнокод хранимых процедур, это, может, и сложные слова. У тебя есть проблемы не только в архитектуре и масштабировании, но и в голове в целом. Пока ты не отлепишь свой лоб от хранимых процедур и не оглянешься вокруг, так и помрешь гавнокодером. Даже спецификации не помогут.

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

sphinx_mvУгу... Очень хочется понаблюдать за Вашими "трехзвенными" потугами при обслуживании RADIUS-серверов (аутентификация, авторизация, аккаунтинг)... Еще можно предложить поломать голову над сбором данных Netflow... И что самое характерное - весь этот "шит" должен быть "он-лайн" с минимальной задержкой и максимально гарантировано сложен в базу данных.
Вообще никаких проблем. Всё уже написано, бери и юзай:
http://wcfradiusservice.codeplex.com/
http://www.codeproject.com/Questions/574399/RadiusplusAuthenticationplususingplusWCFplusServic
http://www.developerfusion.com/project/16278/wcf-radius-service/
Но ведь ты не знаешь, как пишутся приложения для апп серверов, я ж забыл. Отседова и пробелы в знаниях. Даже не пробелы, а знаний вообще нет

sphinx_mvКстати, с обработкой всех исходных данных в базе ОЧЕНЬ легко справляется совсем не сервер приолжений в виде банального задания агента..
Возникают опять вопросы масштабирования, надежности и качества. С агентом иди в лес зайцев пугать.

sphinx_mvМСУЯ тебе не говорю про обязательную нужность выноса логики из апп сервера на отдельное звено (хотя, никто не запрещает так делать). Я тебе говорю о необходимости иметь центральный апп сервер, через который работают клиенты. А как можно еще разнести апп сервер и на какие составляющие - это дело десятое и решается по мере определенного скоупа требований. Не мешай мух и котлет.
Ну, вот нахрена козе баян, а мне - сервер приложений?!
Сервер приложений в распределенных системах не нужен только ламерам, которые не понимают сего предназначения. Для чего он нужен - я уже раз 10 сказал. Перечитай.

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

sphinx_mvМСУ
Эти реляционные базы данных были "осилены", когда тебя указкой школьный учитель по макушке лупил за непонимание второго закона Ньютона. О чем ты? Выше уже писал - выйди из сумрака со своим непомерным "опытом" в СУБД. Просто смешно.Если все эти ужасы, которые Вы вынесли из детства - правда, вынужден согласиться: Ваш учитель несколько перестарался, когда бил Вас по голове линейкой. Иначе у Вас хватило бы сообразительности разобраться, к чему в реальности приводит замена SQL-запросов к серверу баз данных даже на "самые новомодные" и, якобы, "эффективные" алгоритмы обработки данных на клиенте.
Проблема в том, что твой мозг смотрит очень и очень однобоко на задачи, которые могут возникать и возникают у бизнеса. Тот факт, что ты тут предлагал безумие с репликациями с вызовом вебсервисов из хранимых процедур с жестко захардкоженным xml - достойно отдельной похвалы: уволить за тупость. Вариант развития только один - читать нормальный букварь, т.к. со своим горе багажом ты далеко не уедешь. Так и будешь тормозить процессы на первом уровне поддержки

sphinx_mvМСУЭто всё, что смогло осилить твое воображение? Честно говоря рассчитывал на адекватный ответ, а получился как всегда пук в кусты. Ну что ж поделать...
Иди проспись!
Иди убейся об кирпичи!

sphinx_mvМСУОтлично получается, значит у тебя пароли от сервера приложений щелкаются как скорлупа от ореха, а пароль sa - это что-то из ряда фантастики?Ржака!!!
SSL вскрывается как скорлупа из ореха.
Уязвимость TLS тоже не вызывает особого сомнения.
Глупая мартышка, ты пойди это расскажи пенсионерам с ранними версиями SSL и TLS. И то они будут долго смеяться над твоими хакерскими страшилками столетней давности. Во-вторых, если твоя башка хоть капелькой наделена мозгами, там речь идет о том, что "все HTTPS-соединения остаются безопасными, если на странице отключен JavaScript". Откуда в трехзвенке на WCF HTTPS может взяться js? Этопять!

sphinx_mvИ по поводу логина sa у Вас явный, как бы помягче, "громкий плюх в лужу".
Нет, я понимаю, что у Вас было трудное детство, тяжелые игрушки, привинченая к полу мебель, но уж во взрослом-то возрасте догадаться задизэйблить дефолтную учетную запись администратора, а для выполнения его функций создать новый логин, догадаться-то можно было! Но, очевидно, не в Вашем случае...
Я так понимаю, что и тут у тебя опять просад по мозгоналичию. Видимо тебе в школе не разъяснили, что сиквельный админ может быть не только дефолтный sa, но и любая другая учетная запись, в том числе и доменная. Таким образом можно "подломить" и её, точно так же, как и sa. И снова ты обосрался со своими недалекими мыслями по поводу учеток.

sphinx_mvМСУи твоему практически нулевому экспириенсу, то получается, что админа сервера приложений, который рассылает через "Ответить всем" пароли от апп сервера, тоже на кол? Забавно. Значит, политика паролей в БД должна вестись должным образом, а политика апп серверов нет?
Пароль, передаваемый по сети на удаленный сервер базы данных для установки соединения даже через защищенное соединение - уязвим.
Вы этого не знали? Теперь будете знать. И просто запомните простую вещь: права доступа к БД у логина сервера приложений практически НЕОГРАНИЧЕНЫ!
А теперь напрягите остатки своего ничтожного воображения и попробуйте внятно сформулировать, что данные в БД при использовании апп-сервера имеют хоть какую-то защиту после кражи логина и пароля для подключения к БД.
В случае с подключением пользователя к базе данных, ну, увидит злоумышленник список хранимых процедур для запуска для украденного логина. И что дальше он с этим списком будет делать? Даже если и запустит ("не с того рабочего места", "не в то время" или "не при правильном расположении звезд") - пустой рекордсет выходе...
Пароль, передаваемый по сети на удаленный сервер базы данных для установки соединения даже через защищенное соединение - неуязвим. Срочно читать свои же статейки про js. И просто осознай простую вещь: права доступа к БД у сервера приложений ровно такие, как требует задача. Про неограниченность можешь в цирк сходить и там сказки рассказать. А теперь потереби своих мусорным хламом, который остался у тебя вместо головного мозга, и осознай, что при таком же успехе, как ты подломил учетку сервера приложений, так же я и подламливаю учетку db администратора. Имя права администратора баз данных, я могу точно так же крутить данными как хочу, в обход твоих убогих хранимок.

sphinx_mvМСУДаже детвора знает о том , когда в TLS устанавливается соединение и сервер выбирает из списка, предоставленного клиентом, наиболее устойчивые алгоритмы, которые также поддерживаются сервером, и сообщает о своем выборе клиенту. Не знал? Знаю.
Ну, и какой же из "наиболее устойчивых" алгоритмов выберет Ваш сервер? RSA? AES? DES? Или RC4?
Такой вот "скромный" списочек алгоритмов шифрования, уязвимость которых уже доказана - и это в довесок к уязвимости самих протоколов - что SSL, что TLS, которые эти алгоритмы используют.
Доказана кем? Пионерами с хабра при использовании js на странице? Иди посмеши своих коллег - цирковых клоунов на лисапедах, жонглирующих медведями.

sphinx_mvИ ведь намекалось Вам - даже не высовывайтесь в вопросах безопасности: Вам в них даже до уровня профана еще расти и расти...
А ведь сколько я писал тебе, заканчивай про секьюрити, обосрешься как и в прошлый раз... Но упрямость тебя так и втаптывает в лужу позора.

sphinx_mvМСУСмотря о какой длине ключа идет речь. Если рассматривать длину ключа 40 бит, то с такой секурностью можно только макак в зоопарке смешить. Если 256 бит, то такое шифрование максимально надежно и безопасно. Я тебе эту тему уже разжевываю не впервые, поиск в руки. Падсталом!
Гуглем, таки, Вы не научились пользоваться: BEAST, 2 секунды на байт и, соответственно, максимум, полчаса на полное вскрытие аутентификационных данных защищенной сессии. Про "надежность" сертификатов даже не буду Вам в очередной раз рассказывать - все равно до Вас это НЕ доходит.
Я плакал Вот она чистая ламерская натура, прочитать какую-то постную бредятину с хабра и выдать за истину. Или со своим BEAST смеши гусей на пастбище, уже сто лет в обед все браузеры обновлены поддержкой протоколов защищенных сокетов. Ты будешь эту пургу нести и своим внукам через полвека? В мемориз!

sphinx_mvМСУЯ тебе еще в прошлый раз говорил, что ничего там не доказано, это была игра двух конкурентов - центров, выпускающих сертификаты. Друг друга поливали грязью и вешали лапшу на уши. Иди эти сказки своему Сноудену расскажи.И кто же Вам такую забористую траву продает?
Может, и в ведроиде тоже были "грязные игры двух конкурентов", когда из-за ошибки в системе можно произвольным образом изменять содержимое апэкашки приложения, и даже после этого подписаное приложение все равно проходило проверку системы безопасности????
Да тот же, кто и такие вести с полей и генерирует. Может в винде тоже была дыра в SSL, когда обнаружился баг в калькуляторе при делении числа 529 на 23? Пацталом Твоя тупость на высоте!

sphinx_mvМСУТы прямо брызжешь аргументами. Что именно бред, тупая политика оракла? Это даже дети знают. Но это не твой случай, я так и думал.
http://www.opennet.ru/opennews/art.shtml?num=37215
Иди лучше MariaDB изучай, для клоунов в цирке для "масштабных" проектов на двухзвенке - то, что доктор прописал
Вам ЭТО доктор прописал?!
Ну, что ж, идите... Употребляйте...
Жаль, конечно... Если бы не Ваши проблемы с Вашим лечащим врачом, Вы бы знали, что ВСЯ документация на MySQL все еще находится и все еще будет находиться в открытом и свободном доступе. Официальную, а не ту, которую Вам "сосед напел", ссылку дать?
И, кстати, Оракл совершенно бесплатно представляет ВЕСЬ перечень своих продуктов разработчикам для скачивания - для разработки, прототипирования тестирования и на любой срок.
Доктора держатся за животы при чтении бреда, который ты извергаешь тут Для идиотов десятого лвл могу еще раз повторить, что свободный доступ - это феерическая байка для тугодумов, который не понимают то, что происходит с продуктом. Оракел давно уже закручивает гайки по мускулу и вся эта официальность - очередной вздор для детворы. От мускула уже повально начали отказываться, кому понравится утаивание информации об уязвимостях, из состава исключён тестовый набор, закрыт доступ к большей части системы отслеживания ошибок и прекращена публикация сгруппированного лога изменений, позволяющего судить о привязке патчей к конкретным изменениям. Постучись головой об стену, может что и прояснится.

sphinx_mvМСУМембершип провайдеры ничего не ограничивают, деревня. Они реализовывают членство. Рассказывать, что это такое или хватит ума открыть гугел мугел?
Поздравляю вас с Вашим очередным бредом!
У сервера БД - законченая и полностью интегрированная в сервер система безопасности, позволяющая гибко управлять правами пользователей по доступу к данным и по выполнению определенных действий на сервере.
У сервера приложений - НИЧЕГО такого нет... И этот тип приложений какие-то идиоты еще считают более защищенным, чем двузвенка...
Пожми руку макаке и почувствуй себя на порядок умнее. У сервера приложений и поставщика членства - такая же законченая и полностью интегрированная в сервер система безопасности, позволяющая гибко управлять правами пользователей по доступу к данным и по выполнению определенных действий на сервере. База данных тут нафик не упала. Сменится СУБД, всё будет так же работать как и раньше. А ты своей недосистемой безопасности будешь соску сосать, пока пендаля тебе под зад не отвесит руководство.

sphinx_mvМСУБезопасность можешь описывать хоть декларативно, хоть в таблицах, хоть на луне. Для твоей миллионной таблички используется подход с нативными ролями. Роль 1 - просмотр сущности (не конкретной записи). Прибивай пользователя к этой роли и отсеивай левых юзеров сразу, даже без обращения к таблице. Ролевыми политиками можно описать всё, что угодно. А потом это радостно использовать на апп сервере. И даже если через время сменится СУБД или часть хранения данных (например, данные берутся из других источников) - я не буду с вылупленными глазами смотреть на задачу как баран на новые ворота. А вот ты пару раз обосрешься от такого поворота событий и придется тебя уволить. За тупость же.Муся - дебил!
Он все еще не понял, что при использовнаие его "мумбершитов" зная логин и пароль сервера приложений для подключения к базе данных ПОФИГ на всякие "мембершиты"! То есть - совсем! Повесить на сервер приложений "черный ход" к серверу баз данных - и делай с данными в базе что хочешь в любое время! Это что касалось безопасности.
sphinx_mv - околопоносный придурок
Ведь ему невдомек, что зная пароль администратора базы данных можно сделать все что угодно с данными.

sphinx_mvТеперь рассмотрим вопрос удобства... Муся совершенно не в курсе, что на большом предприятии (обычно) много разных приложений используется. Самое прикольное - это НОРМАЛЬНО! Куда Муся пойдет со своим "шитом", когда приложение (даже трехзвенное с сервером приложений) на предприятии МОЖЕТ работать с сервером баз данных и НЕ может работать с его "шитом"? К бабке не ходить - в пешую прогулку с эротическим уклогном!
А что, давай рассмотрим вопрос удобства. У sphinx_mv нет мозгов осознать тот факт, что на большом предприятии как раз и удобно иметь централизованный шлюз на SOA для реализации членства. Ведь тупорылый sphinx_mv никогда не работал на таких предприятиях и не знает, что такой подход обеспечивает на порядки больше гибкости и удобства, чем тупое расшаривание базы данных для всех пользователей интрасети, не говоря уже про интернет. Советую тебе сразу убить себя об стену, чтобы избавить бизнес от таких йопнутых кретинов как ты

sphinx_mvНо вот если бы Муся знала, что использование "правильных" средств авторизации, доступных в серверах баз данных, вполне позволяет ПРОЗРАЧНО обеспечить аутентификацию и авторизацию пользователя для ЛЮБОГО типа приложения, управляя всего лишь стандартным списком логинов и паролей непосредственно (и по умолчанию) входящим в состав БД. ПРи этом логин сервера приложений для доступа к базе данных может иметь права только на подключение, а "реальный" пользователь, используя свои "реальные" логин и пароль к доступу базе данных "транзитом" через него подключается к базе данных - и получает СВОИ актуальные права... И работать "реальные" логин и пароль пользователя будут при любом способе подключения из любого приложения.
Вот если бы sphinx_mv понимала, что СУБД на предприятии может быть 100500 самых разных и разнообразных, то бы не предлагала такие глупости, от которых даже у ламеров с нулевым опытом работы уже выносит моск. Твои БД-шные юзеры и прочая авторизация не впилась даже задаром, это не масштабируется и не расширяется. Смени поставщика - вся твоя нелепость летит в мусорное ведро.

sphinx_mvТот самый случай, когда кривые "лисипеды" с квадратными колесами (в виде "мумбершитов") нафиг никому не падали.
И, кстати, предположим, Мусе хватило мозгов "спионЭрить" логин и пароль, которыми к базе данных устанавливает сессию сервер приложений. ну, так ему ОЧЕНЬ не повезло: ну, спионЭрил, ну, подключился, ну, и ничего не увидел - право у этого логина всего лишь только на коннект. Все, досвидос: сервер Мусю послал на... И Муся со своим "мумбершитом" весь такой радостный пошел, так и не поняв, кто кого и каким образом на самом деле сексуально удовлетворил.
А если я подломил учетку администратора БД? Как ты тогда запляшешь? Открывать доступ к БД в масштабе всего предприятия - это идиотизм, который у тебя мертвым грузом осел в пустоголовой черепной коробке.

sphinx_mvМСУПриколы, а тем более, регулярные - могут быть только в воспаленном воображении того, кто не понимает что это и для чего нужно. Весь мир сидит на SSL/TLS и в ус не дует.Муся! Уровень плинтуса - недостижимая для Вас вершимна с Вашей исключительной неосведомленностью!
Про реальную уязвимость SSL/TLS знают даже дети в ясельной групе детского сада! И для этого воспитатели им не читают специальных курсов по информационной безопасности!
Ну, и вылазьте уж из клозета, куда Вы провалились по собственной дурости. Ознакомьтесь с ситуацией на местах:
Развитие информационных угроз в первом квартале 2013 года . Рекомендую ВНИМАТЕЛЬНО ознакомиться ссо списком компаний, которые, ну, совсем "не беспокоятся" о своей безопасности - в пункте об очередном отзЫве сертификатов.
sphinx_mv, твоя искрометная тупость достойна, минимум, медали
Накой мне твой TurkTrust, который обосрался со своими сертификатами? Пока есть защита, будут нападения, и наоборот.
http://www.iqcard.ru/security IQcard использует Secure Sockets Layer (SSL) технологии, чтобы предоставить Вам самый надежный и защищенный сервис для передачи информации. SSL технологии позволяют шифровать конфиденциальную информацию, включая пароли и номера кредитных карт, во время онлайн-транзакций. Все формы на нашем сайте защищены SSL-технологией, так что мы можем гарантировать безопасность Ваших личных данных.
Компания IQcard прилагает серьезные усилия для обеспечения полной безопасности при проведении операций в вашем личном кабинете. Для входа в личный кабинет вам понадобятся пароль и логин.

http://www.symantec.com/ru/ru/theme.jsp?themeid=compare-ssl-certificates 10 основных средств обеспечения безопасности


sphinx_mvМСУНо при этом учетка от sa - непробиваема! Ты бы это, в цирк бы сходил

Муся так и не понялО, что нельзя "пробить учетку", которая на сервере "убита"? Ну, а о том, как это делается, знают даже 1С-ники. Но тут аж цельный дотнетовец с "охренительно богатым опытом и невъепомерными познаниями" - и не в курсе!
Так в каком говорите цирке Вы работаете клоуном, чтобы я сходил и посмотрел?
Вот это нонсенс, глупая мартышка вещает о убогости SSL, при этом заявляя, что учетка sa является самой безопасной в природе? Сходи на ресепшен, тебе даже там девочки объяснят, что ты непомерно жжешь напалмом

sphinx_mvМСУТы эту информацию лично подтверждал в ФБР и АНБ? Я так и не понял: я все жевал-жевал как лошадь, да по сторонам смотрел (с)
Исправил - так оно лучше соответсвует действительности.
Любишь жевать? Это твоё кредо, смирись с ним

sphinx_mvМСУЯ где-то говорил о том, что нельзя масштабировать сервера БД?Всегда! (с)
Потому, что Муся отказывала в возможности масштабирования двузвенных приложений, которое (на самом деле) делается через масштабирование сервера БД.
Я тебя спрашиваю о том, "где я такое говорил", а ты пишешь - "всегда". Ты идиот?
Еще раз для танкистов: ссылку в студию на то, где я говорил о том, что нельзя масштабировать сервера БД.

sphinx_mvИ, кстати, мы очень даже в курсе, что в действительно серьезных и "долгоиграющих" проектах наша Муся никогда не участвовала.
Весьма странно читать про какие-то проекты от мартышки, сидящей на первой линии поддержки.

sphinx_mvМСУДело в том, что все твое масштабирование накроется медным тазом, когда придет приказ сменить поставщика БД, или часть данных брать из другой системы через SOA шлюзы, или обеспечить работу через интернет и т.д. Пора бы уже начать думать, а не писать бредятину.Вы всегда себе подбираете начальство по уровню собственной адекватности? И почему я не удивлен?!
Ни один из известных мне промышленных серверов баз данных не имеет ни одного явного преимущества перед всеми остальными. Соответственно, причины "внезапно" менять платформу нет. Если кто-то их "увидит" - адекватный специалист должен знать, какие контр-аргументы против этого нужно привести.
Если какяя-то Муся в-припрыжку несется исполнять чей-то явно плохо обдуманный приказ - сразу видно насколько наша Муся "специалист".
Твое начальство всегда подбирает себе кадры в разрезе своего опыта и деградационной составляющей? Этого и следовало ожидать.
Бестолочь, речь тут даже не идет о сразу поменять СУБД. Речь идет о поддержке различных СУБД. Речь идет о масштабировании логики: например, появилось новое требование работать с юридическими и физическими лицами через стороннюю систему Axapta. Вся твоя говнологика в хп идет лесом. А я тупо создам новый класс от IPhysicalPersonService с десятью методами и подсуну в реализацию. И всё заработает как и раньше. Трудозатрат на несколько порядков меньше. И это только самая маленькая польза от сервера приложений.

sphinx_mvМСУТы вообще в вакууме? Со всеми поставщиками у тебя проблемы.Счас проверю...
Ау, поставщики! У меня с Вами проблемы есть? (отвечают, что нет)
Эй, поставщики! А тут один непризнаный гений говорит, что есть... (отвечают, что этот гений 3.14здит)
Ты там на наркоте сидишь, чтоле?

sphinx_mvМСУДа, походу ты точно в вакууме. Почитай букварь, не позорься - гетерогенные запросы выбрось на свалку. Ты хоть знаешь определение этого термина?
Ну, так перечитайте еще раз свой букварик - там ВСЕ написано про гетерогенные распределенные запросы к разным источникам данных. Или в Вашем букварике такого нет?! Ну, тут уж какой хозяин, такой и букварик...

Не понятно, что я делаю не так: сижу в коннекте на оракл и спокойно выполняю запросы к таблицам на MSSQL'е... И не поверите - даже джойны между таблицами на MSSQL и Oracle работают!.. Пробую наоборот: сижу в коннекте на MSSQL и делаю запросы к таблицам в базе на Oracle-сервере. И тоже приджойненые таблицы на разных серверах лежат... И так - для ЛЮБОГО поставщика, для которого у меня есть ODBC- или OLEDB-провайдер.

Вас не учили такому? Может, плохой учитель попался... Хотя, больше похоже, что в тупую Мусю эти знания просто не поместились - слишком много букаф в букварике было, и Муся ниасилилО... А таким "ИкспЭртом" прикидывается!
О, ужас... Я ж тебе уже писал, можешь сходить к коллегам - макакам в цирке, и посмешить их гетерогенными запросами. Я плакал от того, что твое говноприложение напрямую шлет запросы всей этой петрушке из сиквелов с оракулями Может оно еще и репликацией отруливает? Можешь смело убить себя об стену с такой говноархитектурой.

sphinx_mvМСУЗа твое ноухау по поводу репликации - сразу на кол. Без выплаты заработной платы. Ты хоть раз работал с репликацией, чудо?
Безумные бараны, не умеющие делать распределенные механизмы через SOA, всегда будут предлагать идиотизм в виде репликации. Более адекватные люди в это болото даже вступить откажутся. Тебе еще расти и расти, мальчик...
И этот Муся все еще на что-то претендует!? Тупая Муся так и не поняла, что при работе в "он-лайн" возможность выполнять распределеннные запросы к разным базам позволяет не заниматься репликацией?!
Кретиноподобный sphinx_mv доселе не внял, что репликация - это гвоздь в онлайн системы? Немудрено, твоя тупость уже выливается через край.

sphinx_mvSOA... Вы бы еще про "облака" рассказали!.. Когда Ваш директор попытается подключиться к Вашему приложению, отдыхая где-нибудь на яхте в Тихом океане, я не сомневаюсь - когда он вернется, Вы получите ХОРОШЕГО пинка кованым сапогом под голый зад - даже штанов Вам не оставят!
Я плакал Ты предлагаешь директору на тихом океане использовать свою чудо-двухзвенку? Пацталом
Для окончательно забронировавшихся в танке довожу до сведения, что только SOA помогут в этой лапидарной ситуации. Купи себе голову.

sphinx_mvПро "офф-лайн" клиентов, Вы не слыхали? Для "особоодаренных" рассказываю - синхронизация данных между "центральной" и "локальной" базами как раз и является репликацией, для которой имеются стандартные, оптимизированные для этой задачи средства - у ЛЮБОГО уважающего себя поставщика. Даже у "бесплатных"!
Чудилко, открой для себя великолепно масштабируемого оффлайн клиента на вцф сервисе



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

Да ничего у тебя нет и не было, о чем ты. Масштабировать сервер БД может даже дурак, а отмасштабировать приложение - совсем другая задача. Для тебя неподъемная. Как я могу тебе писать о плюсах масштабирования приложения, если ты даже не знаешь, что это такое?Айдане3.14зди!
Муся НЕ ЗНАЕТ, что ни что такое масштабирование приложения, ни то, как оно правильно выполняется!
Для профилактики читать тут - там про Вас все рассказано!
МСУДа и по поводу безопасности, сто раз уже писал, что можно элементарно под windbg снять строку соединения к БД, подкчлючиться через клиента management studio, открыть транзакцию, выполнить селект и пойти курить . Всё, система легла - срочно читать про изоляции транзакций и их виды. И это самое меньшее зло, что может быть с твоей убогой двухзвенкой. Да... Давно мне так не "доставляло" - это ж полярный пушной зверек какой-то!!!
Мало того, что случай идиота-разработчика, который Вы тут являете во всей красе, может всерьез рассматривать только точно такой же идиот-разработчик, так еще и только полный идиот-разработчик может считать, что SELECT к данным в базе как-то влияет на блокировку данных!
Вот Вам элементарный тест-кейс для sql2008r2 (на "стандартной" базе Northwind):

Жду, когда Вы положите "параллельную" сессию с точно таким же запросом - и курить любую траву при этом можете сколь угодно долго.
А у меня рядом стоит миска, полная попкорна...

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

Это показан весь твой скоуп экспириенса, не более того. Примеряйся.
Померил - размерчик Вам в самый раз...МСУпропущено...

Уже даже жираф бы понял про все плюсы трехзвенки. Но это не твой случай. Ты тупо смотришь за любые задачи узко и однобоко, как подабает несмышленому падавану.Как ни странно, но даже жирафы знают, что в программировании вообще не существует ни одного решения - идеологического, архитектурного, программного, которое бы подходило в абсолютно всех случаях. И только до одного Муси это все никак не дойдет.
Ну, не понимает наша Муся, что есть множество решений, когда идеальное решение - двузвенка. Очевидно, у этого жирафа слишком толстая лобная кость черепа, и умным мыслям пробить эту толщу очень трудно...
И Муси никак не сожет сообразить,что масштабирование сервера приложений по нагрузке в "вырожденом" случае упрется в схему один клиент на один сервер... И никак наш Муся не поймет, что в этом случае сервер приложений - лишнее звено. Клиентское приложение в двузвенной архитектуре само себе "сервер приложений" - с гибко настраиваемой, централизованной авторизацией на сервере баз данных.
МСУпропущено...

Кроме "простоты масштабирования" трехзвенки, там еще есть и конфигурируемость, высокая безопасность, высокая надёжность, низкие требования к скорости канала (сети) между терминалами и сервером приложений, низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон. Пипец аргументация!
Это ничего, что сервера приложений как класс появились гораздо позже, чем двузвенные приложения?
А диалап-модемы - Вы такое счастье в руках, хотя бы держали? А представить себе, как через соединение в 32 килобита в секунду полноценно работается в 1С, можете? "Терзают смутные сомнения" (с) по каждому из поставленных вопросов...
И ведь сказано же было Вам - не пугайте ежей голой жопой!
МСУЕсли тебе этого мало, срочно в зоопарк. Там уже ждут.На Ваше место?!
Спасибо, конечно, за предложение, но "нас и тут хорошо кормят.".. (с)
МСУесли потребуется сменить СУБД или отстыковать логический кусок с сущностями и привязать интеграцию с внешним ресурсом.Мои заказчики как 15 лет не меняли СУБД, так еще лет ...надцать менять не будут!
И даже про связь с еще одним "внешним" ресурсом никак не собираются беспокоиться: на фоне уже имеющегося и так достаточно большого количества внешних источников входных данных (особенность сферы деятельности, однако) одним внешним ресурсом больше, одним ресурсом меньше - никто ничего особо исключительного даже и не заметит.
МСУВо-вторых, в чем боязнь перекомпилировать код сервера приложений?То есть, в детском саду Вас не научили, что боязнь и "нахрен не нужно за ненадобностью" - это совсем не одно и то же? И где же такие продвинутые детсадовцы воспитываются?
МСУКлиенты тут же получат обновления. Точно так же, в одном месте меняем.Для "особо упертых" ЕЩЕ раз говорю: у меня обновления доступны всем пользователям в момент публикации без необходимости разворачивать сервер приложений.
МСУВ-третьих, твой декларативный говнокод не поддается ни нормальному документированию, ни нормальному рефакторингу, ни человеческому интелиссенсу, и так далее.Чо за бред?!
С каких это пор нельзя задокументировать код для сервера базы данных?! Какой дебил и, самое главное, когда это запретил?
Может, Вы не в курсе, что документирование кода для сервера БД ничем не отличается от документирования кода хоть на С#, хоть на васике, хоть на сях, хоть на любом другом языке программирования? И структура базы прекрасно документируется - даже в графическом представлении!
И интелисенс работает: пишу запрос, ввожу алиас таблицы в даже еще ни разу не запущенном запросе, ставлю точку - получаю список всех доступных алиасу полей. В процедуре навожу курсор мыши на функцию - разворачивается ее декларация. Что не так? Может, просто что-то не так с Вашими инструментами для работы с БД? Сменить не пробовали?
МСУРано или поздно, твои лохмотья превращаются в кусок неуправляемого линейного гавна на несколько тыщ строк кода. Не раз сталкивался с таким явлением в сторонних системах, разработчика этого отродия хотелось бы повесить за ноги без объяснения причин. И ты следуешь именно этому допотопно-ориентированному принципу. Больше гавна, больше! Вся твоя суть.
Ай, да не... не врите - ведь это же именно Вас подвешивали и совсем не за ноги за Ваш говнокод и в совсем не "в сторонних" системах!
Я прекрасно помню Ваши "перлы" Вашего "идеального" t-sql-ного кода - это было НЕЧТО! "Полярно-пушное", если Вы не поняли....
МСУДа какие там затраты на продукт, что за бред ты несешь? Затраты почти такие же, а на этапе развития и поддержки всё окупается с лихвой.
Не знаешь - не 3.14зди!
Что такое "унаследованное" програмное обеспечение Вам известно?
Вы в курсе, что "новая" система должна как минимум функционально соотвествовать "старой" системе? Вам это понятно?
Стоимость разработки не забыли? Стоимость внедрения с разворачивание новой системы на независимой от "старой" системы платформе обучение пользователей, снижение качества предоставляемых услуг из-за еще недостаточной качества обслуживания новой системы в комплекте с параллельным обслуживанием "старой", с оттоком недовольных пользователей - Вы это учли/посчитали?
А еще есть такая хрень - накопленные за время оперативной деятельности данные,с которыми должна уметь работать "новая" система...
И эта миграция данных - практически отдельный проект с весьма "интересными" затратами и возможными последствиями...
МСУО какой производительности идет речь? О разнице в две наносекунды на реквест? Не смеши мои носки, они уже улыбаются.
Вам - домашнее задание, хотя сомневаюсь, что осилите: построить два простейших тестовые приложения: одно в двузвенной, второе - в трехзвенной архитектуре, и провести реальное нагрузочное тестирование с полным профилированием на сервере приложений и на сервере БД - вот тогда и увидите, как Ваши "наносекунды" начнут "внезапно" трансформироваться в секунды и часы...
МСУТретье звено - это не рекламная мишура, это банальная обыденность, которой должна владеть любая вменяемая респределенная система. [/b]Где доказательства, факты, явки, пруфы, графики?[/b]Не вижу ничего подобного про трехзвенку.
А по поводу Ваших хотелок - проведите тест, и в зеркале увидите и пруф, и явку, и с кого графики требовать.
МСУпропущено...

О как! Так ты не разработчик даже, ты тупо поддержка? А что ты тогда делаешь в этом форуме? Как-то некомильфо разговаривать с поддерженцем о бюджетах, сроках, надежности, распределенности. С особенностями внутрикорпоративной разработки, значится, Вы как-то "не в курсе"...

Соотвественно, Вы "как бы не в курсе", что от сроков зависит не только получу ли я зарплату в этом месяце, но и будет ли в следующем месяце моя фирма физически присутсвовать на рынке...

"Не в курсе" Вы и о том, что внутренняя разработка находится в ОЧЕНЬ жестких ресурсных рамках и по деньгам, и очень часто по не очень большому количеству людей - это что касалось вопроса о бюджетировании...

И требование к надежности ПО у меня стоит на пару десятичных порядков выше - от ошибок в "заказном" приложении, которое содержит невыявленные ошибки исполнитель уже получил свои деньги в полном объеме и уже ни за что больше не отвечает, а ошибки в моих приложениях для внутреннего использования у моего работодателя - моя отвественность до самого моего увольнения, сроки которого из-за некачественно написаного приложения могут "внезапно" приблизиться с неплохим "шансом" смены сферы деятельности на что-то менее связанное с программированием в частности и компьютерами вообще.

Ну, а то, что в отделах разработки внутреннего программного обеспечения этот же отдел отдел отвечает и за обучение пользователей, и за решение пользовательских проблем, и за устранение выявленных ошибок, т.е. непосредственно находится в "первой линии" - это тоже Вам, как-то "не знакомо"...

Действительно... Какое может быть "комильфо" обсуждать с Вами вопросы, в которых Вы, мягко говоря, "ни в зуб ногой"?!МСУпропущено...

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

А ты готов привести ссылку на то место, где я жаловался на отсутствие возможности масштабирования в серверах БД?Да, без проблем!
Вот тут 14549572 один псих по поводу использования хранимых процедур жаловался:
МСУ масштабировать решение на порядки сложнее

масштабировать логику на порядки сложнее
Оно?
МСУА то ведь приклеется клеймо форумной балаболки. Не? Копай-рыщи, бобер. Ты должен найти пруф.
Не переживайте Вы так!
Я на Ваше место не претендую, да и четко осознаю, что мне до Вашего балабольского уровня ой как далеко...
МСУпропущено...

Ссылочку? Ты смеешься? Я тебе уже битый день об этом пишу, что ты как идиот с флагом ходишь по комнате и орешь о том, что я якобы доказываю всем о невозможности масштабировать сервер БД. Клиника Да уж, действительно клиника...
Вот тут 14549572 один псих по поводу использования хранимых процедур жаловался:
МСУ масштабировать решение на порядки сложнее

масштабировать логику на порядки сложнее
Все еще будете пытаться опровергать? Или лучше на процедурки сходите?
МСУпропущено...

Для нормального разработчика это не страшные слова, а обыденность. Для кодеманки саппортёрши, которая уткнулась носом в гавнокод хранимых процедур, это, может, и сложные слова. У тебя есть проблемы не только в архитектуре и масштабировании, но и в голове в целом. Пока ты не отлепишь свой лоб от хранимых процедур и не оглянешься вокруг, так и помрешь гавнокодером. Даже спецификации не помогут.
Уж, кто бы 3.14здел!
Можно подумать, что это у меня хранимые процедуры не поддаются документированию и рефакторингу!
И можно подумать, что это у меня не работает интелисенс!
МСУпропущено...

Для множества клиентов, особенно разнородных, как-раз и подходит сервер приложений. О каком агенте идет речь и почему ты решил, что он не может иметь доступ к серверу приложений? Очередная бредятина? Вывод напрашивается один - ты не представляешь себе, что такое апп сервер и как делается распределенность. Поэтому что-то доказывать кодеманке о правильности в архитектуре - заранее утопично.Утопия - пихать в каждую дырку сервер приложений и надеяться, что получится хотя бы просто работающее, не говоря уже о надежном, решение.
Я понимаю, что говноархитекторы не в курсе, что система тем надежнее и управляемее, чем меньше в ней меньше взаимодействующих частей - но в отличие от говноархитекторов, это известно более другим разработчикам. В более других, чем порноиндустрия отраслях деятельности.
МСУпропущено...

Вообще никаких проблем. Всё уже написано, бери и юзай:
http://wcfradiusservice.codeplex.com/
У "продукта" альфа-статус с 2009 года... Бессмысленно даже просто рассматривать как кандидата для использования в реальной системе. Но, возможно, для уровня Ваших говноподелок как раз годится...
МСУ http://www.codeproject.com/Questions/574399/RadiusplusAuthenticationplususingplusWCFplusServic Вообще ничего нового...
От использования IAS уже никто и не помнит когда отказались - но это точно было задолго до 2003 года...
МСУ http://www.developerfusion.com/project/16278/wcf-radius-service/
Тут снова переход на первую ссылку...
И, даже если забыть про статус "альфа", есть один ключевой недостаток - WCF работает только на Win-платформе. Что еще круче - нужно использовать как минимум винсервер... И серверов таких (по требованиям отказоустойчивости) нужно не меньше двух штук... Итого, цена вопроса только по лицензированию - примерно пару-тройку килограмм американской капусты. Добавим сюда преодоление альфа-статуса, чтобы можно было без особых зазрений выкладываться на рабочую платформу, а еще минимум полгода разработки, тестирования, внедрения - еще килограмм "20 капусты" (по самым скромным расценкам) на "бригаду"...

А вот это - то что мы используем - модульное, расширяемое, компактное, легкое в настройке и обслуживании универсальное решение. Немаловажным оказалось, конечно, что оно еще и кроссплатформенное оказалось, а линукс как был практически бесплатным, так и остался - съэкономили по паре-тройке кило только на лицензировании каждого комплекта RADIUS-серверов... Кстати, Вам разрешается начать писать для него мождуль для использования WCF... Когда напишите хотя бы до альфа-версии, тогда и будете срать "в тему".

Итого, все Ваши ссылки не более чем ложь, пи... и провокация.
МСУпропущено...

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

Вот для таких лапидарных систем на пару тройку форм ты и нужен. На реализацию чего-то более серьезного, ты сдуешься как мыльный пузырь.
Зашибись!...
Чмо, котрое никогда не писало двузвенку, будет считать сколько сишарповых модулей в моем проекте...
И все бы ничего, но рядом (в соседней группе разработчиков) проект совсем не шарповый, но очень двузвенный, и в откомпилированном виде в общей сложности занимает полсотни мегабайт...
МСУВопросы безопасности уже обсудили, двухзвенка небезопасна (легко получить строку соединения и открыть транзакцию, это минимум).
Мусье, Вы - тупица!
Для двузвенки в самом худшем случае будет получен уровень прав одного конкретного пользователя.
Перехват строки подключения сервера приложений в подавляющем большинстве случаев дает МАКСИМАЛЬНО ПОЛНЫЙ набор прав всех пользователей, работающих с этим трехзвенным приложением. Минимальный остаток, который ограничивает права при использовании перехваченой строки подключений должен использовать средства аутентификации сервера баз данных - капля в море!
МСУДвухзвенка не масштабируется (для тех, кто в танке - речь о не сервере БД, а о ПО).Для тех, кто танка никогда не видел: Вы совершенно не в курсе, что такое масштабирование! И кроссплатформенность, в частности, поддержка разных поставщиков серверов баз данных к этому процессу ни разу никаким образом не стояла! То есть - СОВСЕМ! И чтобы убедиться в этом необходимо и достаточно просто ознакомиться с терминами "вертикальное" и "горизонтальное" масштабирование - гугель в помощь...
Просто запомните - масштабирование в двузвенке выполняется через масштабирование сервера БД. Вот такая "хитрая" стратегия масштабирования...
МСУЛогика в хп - зло, тыщу раз обсуждали. Не документируется, не рефакторится, не интелисится, просто катастрофические проблемы при смене СУБД - нужно тупо заново всё переписывать.Все прекрасно и документируется, и рефакторится, и интелисенсится... О! - и даже тестируется!!! В автоматическом режиме!!!
Просто некоторые не вполне адекватные, якобы, разработчики либо пользуются неадекватными инструментами, либо не умеют адекватно настраивать "правильные" инструменты. И в обоих случаях это - диагноз.
МСУДвухзвенка приемлема для детских систем с минимальным порогом вхождения в разработку. Собралась кучка хлопцев, что-то наклепала и втюхала заказчику.
А потом померла и разбежалась о того, что это говно даже саппортить по-человечески нельзя со всеми твоими репликациями, не то, что развивать. Вот для таких "систем" это работает.
Ничего, чего нельзя сказать про трехзвенку... Соотвественно, мимо тазика...

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

Проблема в том, что твой мозг смотрит очень и очень однобоко на задачи, которые могут возникать и возникают у бизнеса. Тот факт, что ты тут предлагал безумие с репликациями с вызовом вебсервисов из хранимых процедур с жестко захардкоженным xml - достойно отдельной похвалы: уволить за тупость. Вариант развития только один - читать нормальный букварь, т.к. со своим горе багажом ты далеко не уедешь. Так и будешь тормозить процессы на первом уровне поддержки Муся-уборщица совершенно не в курсе, что для быстрого решения проблем пользователей системы в нормальных организациях ставят специалистов, которые действительно могут решить проблему клерка-пользователя, над которым в данный конкретный момент стоит пришедший клиент с пачкой денег и острым желанием оставить их в кассе компании, а не всяких говноархитекторов, которые не могут ни задокументировать, ни отрефакторить кода, не говоря уже о том, чтобы настроить интелисенс...[/quot]

sphinx_mvМСУЭто всё, что смогло осилить твое воображение? Честно говоря рассчитывал на адекватный ответ, а получился как всегда пук в кусты. Ну что ж поделать...
Иди проспись!
Иди убейся об кирпичи!

sphinx_mvМСУОтлично получается, значит у тебя пароли от сервера приложений щелкаются как скорлупа от ореха, а пароль sa - это что-то из ряда фантастики?Ржака!!!
SSL вскрывается как скорлупа из ореха.
Уязвимость TLS тоже не вызывает особого сомнения.
Глупая мартышка, ты пойди это расскажи пенсионерам с ранними версиями SSL и TLS. И то они будут долго смеяться над твоими хакерскими страшилками столетней давности. Во-вторых, если твоя башка хоть капелькой наделена мозгами, там речь идет о том, что "все HTTPS-соединения остаются безопасными, если на странице отключен JavaScript". Откуда в трехзвенке на WCF HTTPS может взяться js? Этопять!

sphinx_mvИ по поводу логина sa у Вас явный, как бы помягче, "громкий плюх в лужу".
Нет, я понимаю, что у Вас было трудное детство, тяжелые игрушки, привинченая к полу мебель, но уж во взрослом-то возрасте догадаться задизэйблить дефолтную учетную запись администратора, а для выполнения его функций создать новый логин, догадаться-то можно было! Но, очевидно, не в Вашем случае...
Я так понимаю, что и тут у тебя опять просад по мозгоналичию. Видимо тебе в школе не разъяснили, что сиквельный админ может быть не только дефолтный sa, но и любая другая учетная запись, в том числе и доменная. Таким образом можно "подломить" и её, точно так же, как и sa. И снова ты обосрался со своими недалекими мыслями по поводу учеток.

sphinx_mvМСУи твоему практически нулевому экспириенсу, то получается, что админа сервера приложений, который рассылает через "Ответить всем" пароли от апп сервера, тоже на кол? Забавно. Значит, политика паролей в БД должна вестись должным образом, а политика апп серверов нет?
Пароль, передаваемый по сети на удаленный сервер базы данных для установки соединения даже через защищенное соединение - уязвим.
Вы этого не знали? Теперь будете знать. И просто запомните простую вещь: права доступа к БД у логина сервера приложений практически НЕОГРАНИЧЕНЫ!
А теперь напрягите остатки своего ничтожного воображения и попробуйте внятно сформулировать, что данные в БД при использовании апп-сервера имеют хоть какую-то защиту после кражи логина и пароля для подключения к БД.
В случае с подключением пользователя к базе данных, ну, увидит злоумышленник список хранимых процедур для запуска для украденного логина. И что дальше он с этим списком будет делать? Даже если и запустит ("не с того рабочего места", "не в то время" или "не при правильном расположении звезд") - пустой рекордсет выходе...
Пароль, передаваемый по сети на удаленный сервер базы данных для установки соединения даже через защищенное соединение - неуязвим. Срочно читать свои же статейки про js. И просто осознай простую вещь: права доступа к БД у сервера приложений ровно такие, как требует задача. Про неограниченность можешь в цирк сходить и там сказки рассказать. А теперь потереби своих мусорным хламом, который остался у тебя вместо головного мозга, и осознай, что при таком же успехе, как ты подломил учетку сервера приложений, так же я и подламливаю учетку db администратора. Имя права администратора баз данных, я могу точно так же крутить данными как хочу, в обход твоих убогих хранимок.

sphinx_mvМСУДаже детвора знает о том , когда в TLS устанавливается соединение и сервер выбирает из списка, предоставленного клиентом, наиболее устойчивые алгоритмы, которые также поддерживаются сервером, и сообщает о своем выборе клиенту. Не знал? Знаю.
Ну, и какой же из "наиболее устойчивых" алгоритмов выберет Ваш сервер? RSA? AES? DES? Или RC4?
Такой вот "скромный" списочек алгоритмов шифрования, уязвимость которых уже доказана - и это в довесок к уязвимости самих протоколов - что SSL, что TLS, которые эти алгоритмы используют.
Доказана кем? Пионерами с хабра при использовании js на странице? Иди посмеши своих коллег - цирковых клоунов на лисапедах, жонглирующих медведями.

sphinx_mvИ ведь намекалось Вам - даже не высовывайтесь в вопросах безопасности: Вам в них даже до уровня профана еще расти и расти...
А ведь сколько я писал тебе, заканчивай про секьюрити, обосрешься как и в прошлый раз... Но упрямость тебя так и втаптывает в лужу позора.

sphinx_mvМСУСмотря о какой длине ключа идет речь. Если рассматривать длину ключа 40 бит, то с такой секурностью можно только макак в зоопарке смешить. Если 256 бит, то такое шифрование максимально надежно и безопасно. Я тебе эту тему уже разжевываю не впервые, поиск в руки. Падсталом!
Гуглем, таки, Вы не научились пользоваться: BEAST, 2 секунды на байт и, соответственно, максимум, полчаса на полное вскрытие аутентификационных данных защищенной сессии. Про "надежность" сертификатов даже не буду Вам в очередной раз рассказывать - все равно до Вас это НЕ доходит.
Я плакал Вот она чистая ламерская натура, прочитать какую-то постную бредятину с хабра и выдать за истину. Или со своим BEAST смеши гусей на пастбище, уже сто лет в обед все браузеры обновлены поддержкой протоколов защищенных сокетов. Ты будешь эту пургу нести и своим внукам через полвека? В мемориз!

sphinx_mvМСУЯ тебе еще в прошлый раз говорил, что ничего там не доказано, это была игра двух конкурентов - центров, выпускающих сертификаты. Друг друга поливали грязью и вешали лапшу на уши. Иди эти сказки своему Сноудену расскажи.И кто же Вам такую забористую траву продает?
Может, и в ведроиде тоже были "грязные игры двух конкурентов", когда из-за ошибки в системе можно произвольным образом изменять содержимое апэкашки приложения, и даже после этого подписаное приложение все равно проходило проверку системы безопасности????
Да тот же, кто и такие вести с полей и генерирует. Может в винде тоже была дыра в SSL, когда обнаружился баг в калькуляторе при делении числа 529 на 23? Пацталом Твоя тупость на высоте!

sphinx_mvМСУТы прямо брызжешь аргументами. Что именно бред, тупая политика оракла? Это даже дети знают. Но это не твой случай, я так и думал.
http://www.opennet.ru/opennews/art.shtml?num=37215
Иди лучше MariaDB изучай, для клоунов в цирке для "масштабных" проектов на двухзвенке - то, что доктор прописал
Вам ЭТО доктор прописал?!
Ну, что ж, идите... Употребляйте...
Жаль, конечно... Если бы не Ваши проблемы с Вашим лечащим врачом, Вы бы знали, что ВСЯ документация на MySQL все еще находится и все еще будет находиться в открытом и свободном доступе. Официальную, а не ту, которую Вам "сосед напел", ссылку дать?
И, кстати, Оракл совершенно бесплатно представляет ВЕСЬ перечень своих продуктов разработчикам для скачивания - для разработки, прототипирования тестирования и на любой срок.
Доктора держатся за животы при чтении бреда, который ты извергаешь тут Для идиотов десятого лвл могу еще раз повторить, что свободный доступ - это феерическая байка для тугодумов, который не понимают то, что происходит с продуктом. Оракел давно уже закручивает гайки по мускулу и вся эта официальность - очередной вздор для детворы. От мускула уже повально начали отказываться, кому понравится утаивание информации об уязвимостях, из состава исключён тестовый набор, закрыт доступ к большей части системы отслеживания ошибок и прекращена публикация сгруппированного лога изменений, позволяющего судить о привязке патчей к конкретным изменениям. Постучись головой об стену, может что и прояснится.

sphinx_mvМСУМембершип провайдеры ничего не ограничивают, деревня. Они реализовывают членство. Рассказывать, что это такое или хватит ума открыть гугел мугел?
Поздравляю вас с Вашим очередным бредом!
У сервера БД - законченая и полностью интегрированная в сервер система безопасности, позволяющая гибко управлять правами пользователей по доступу к данным и по выполнению определенных действий на сервере.
У сервера приложений - НИЧЕГО такого нет... И этот тип приложений какие-то идиоты еще считают более защищенным, чем двузвенка...
Пожми руку макаке и почувствуй себя на порядок умнее. У сервера приложений и поставщика членства - такая же законченая и полностью интегрированная в сервер система безопасности, позволяющая гибко управлять правами пользователей по доступу к данным и по выполнению определенных действий на сервере. База данных тут нафик не упала. Сменится СУБД, всё будет так же работать как и раньше. А ты своей недосистемой безопасности будешь соску сосать, пока пендаля тебе под зад не отвесит руководство.

sphinx_mvМСУБезопасность можешь описывать хоть декларативно, хоть в таблицах, хоть на луне. Для твоей миллионной таблички используется подход с нативными ролями. Роль 1 - просмотр сущности (не конкретной записи). Прибивай пользователя к этой роли и отсеивай левых юзеров сразу, даже без обращения к таблице. Ролевыми политиками можно описать всё, что угодно. А потом это радостно использовать на апп сервере. И даже если через время сменится СУБД или часть хранения данных (например, данные берутся из других источников) - я не буду с вылупленными глазами смотреть на задачу как баран на новые ворота. А вот ты пару раз обосрешься от такого поворота событий и придется тебя уволить. За тупость же.Муся - дебил!
Он все еще не понял, что при использовнаие его "мумбершитов" зная логин и пароль сервера приложений для подключения к базе данных ПОФИГ на всякие "мембершиты"! То есть - совсем! Повесить на сервер приложений "черный ход" к серверу баз данных - и делай с данными в базе что хочешь в любое время! Это что касалось безопасности.
sphinx_mv - околопоносный придурок
Ведь ему невдомек, что зная пароль администратора базы данных можно сделать все что угодно с данными.

sphinx_mvТеперь рассмотрим вопрос удобства... Муся совершенно не в курсе, что на большом предприятии (обычно) много разных приложений используется. Самое прикольное - это НОРМАЛЬНО! Куда Муся пойдет со своим "шитом", когда приложение (даже трехзвенное с сервером приложений) на предприятии МОЖЕТ работать с сервером баз данных и НЕ может работать с его "шитом"? К бабке не ходить - в пешую прогулку с эротическим уклогном!
А что, давай рассмотрим вопрос удобства. У sphinx_mv нет мозгов осознать тот факт, что на большом предприятии как раз и удобно иметь централизованный шлюз на SOA для реализации членства. Ведь тупорылый sphinx_mv никогда не работал на таких предприятиях и не знает, что такой подход обеспечивает на порядки больше гибкости и удобства, чем тупое расшаривание базы данных для всех пользователей интрасети, не говоря уже про интернет. Советую тебе сразу убить себя об стену, чтобы избавить бизнес от таких йопнутых кретинов как ты

sphinx_mvНо вот если бы Муся знала, что использование "правильных" средств авторизации, доступных в серверах баз данных, вполне позволяет ПРОЗРАЧНО обеспечить аутентификацию и авторизацию пользователя для ЛЮБОГО типа приложения, управляя всего лишь стандартным списком логинов и паролей непосредственно (и по умолчанию) входящим в состав БД. ПРи этом логин сервера приложений для доступа к базе данных может иметь права только на подключение, а "реальный" пользователь, используя свои "реальные" логин и пароль к доступу базе данных "транзитом" через него подключается к базе данных - и получает СВОИ актуальные права... И работать "реальные" логин и пароль пользователя будут при любом способе подключения из любого приложения.
Вот если бы sphinx_mv понимала, что СУБД на предприятии может быть 100500 самых разных и разнообразных, то бы не предлагала такие глупости, от которых даже у ламеров с нулевым опытом работы уже выносит моск. Твои БД-шные юзеры и прочая авторизация не впилась даже задаром, это не масштабируется и не расширяется. Смени поставщика - вся твоя нелепость летит в мусорное ведро.

sphinx_mvТот самый случай, когда кривые "лисипеды" с квадратными колесами (в виде "мумбершитов") нафиг никому не падали.
И, кстати, предположим, Мусе хватило мозгов "спионЭрить" логин и пароль, которыми к базе данных устанавливает сессию сервер приложений. ну, так ему ОЧЕНЬ не повезло: ну, спионЭрил, ну, подключился, ну, и ничего не увидел - право у этого логина всего лишь только на коннект. Все, досвидос: сервер Мусю послал на... И Муся со своим "мумбершитом" весь такой радостный пошел, так и не поняв, кто кого и каким образом на самом деле сексуально удовлетворил.
А если я подломил учетку администратора БД? Как ты тогда запляшешь? Открывать доступ к БД в масштабе всего предприятия - это идиотизм, который у тебя мертвым грузом осел в пустоголовой черепной коробке.

sphinx_mvМСУПриколы, а тем более, регулярные - могут быть только в воспаленном воображении того, кто не понимает что это и для чего нужно. Весь мир сидит на SSL/TLS и в ус не дует.Муся! Уровень плинтуса - недостижимая для Вас вершимна с Вашей исключительной неосведомленностью!
Про реальную уязвимость SSL/TLS знают даже дети в ясельной групе детского сада! И для этого воспитатели им не читают специальных курсов по информационной безопасности!
Ну, и вылазьте уж из клозета, куда Вы провалились по собственной дурости. Ознакомьтесь с ситуацией на местах:
Развитие информационных угроз в первом квартале 2013 года . Рекомендую ВНИМАТЕЛЬНО ознакомиться ссо списком компаний, которые, ну, совсем "не беспокоятся" о своей безопасности - в пункте об очередном отзЫве сертификатов.
sphinx_mv, твоя искрометная тупость достойна, минимум, медали
Накой мне твой TurkTrust, который обосрался со своими сертификатами? Пока есть защита, будут нападения, и наоборот.
http://www.iqcard.ru/security IQcard использует Secure Sockets Layer (SSL) технологии, чтобы предоставить Вам самый надежный и защищенный сервис для передачи информации. SSL технологии позволяют шифровать конфиденциальную информацию, включая пароли и номера кредитных карт, во время онлайн-транзакций. Все формы на нашем сайте защищены SSL-технологией, так что мы можем гарантировать безопасность Ваших личных данных.
Компания IQcard прилагает серьезные усилия для обеспечения полной безопасности при проведении операций в вашем личном кабинете. Для входа в личный кабинет вам понадобятся пароль и логин.

http://www.symantec.com/ru/ru/theme.jsp?themeid=compare-ssl-certificates 10 основных средств обеспечения безопасности


sphinx_mvМСУНо при этом учетка от sa - непробиваема! Ты бы это, в цирк бы сходил

Муся так и не понялО, что нельзя "пробить учетку", которая на сервере "убита"? Ну, а о том, как это делается, знают даже 1С-ники. Но тут аж цельный дотнетовец с "охренительно богатым опытом и невъепомерными познаниями" - и не в курсе!
Так в каком говорите цирке Вы работаете клоуном, чтобы я сходил и посмотрел?
Вот это нонсенс, глупая мартышка вещает о убогости SSL, при этом заявляя, что учетка sa является самой безопасной в природе? Сходи на ресепшен, тебе даже там девочки объяснят, что ты непомерно жжешь напалмом

sphinx_mvМСУТы эту информацию лично подтверждал в ФБР и АНБ? Я так и не понял: я все жевал-жевал как лошадь, да по сторонам смотрел (с)
Исправил - так оно лучше соответсвует действительности.
Любишь жевать? Это твоё кредо, смирись с ним

sphinx_mvМСУЯ где-то говорил о том, что нельзя масштабировать сервера БД?Всегда! (с)
Потому, что Муся отказывала в возможности масштабирования двузвенных приложений, которое (на самом деле) делается через масштабирование сервера БД.
Я тебя спрашиваю о том, "где я такое говорил", а ты пишешь - "всегда". Ты идиот?
Еще раз для танкистов: ссылку в студию на то, где я говорил о том, что нельзя масштабировать сервера БД.

sphinx_mvИ, кстати, мы очень даже в курсе, что в действительно серьезных и "долгоиграющих" проектах наша Муся никогда не участвовала.
Весьма странно читать про какие-то проекты от мартышки, сидящей на первой линии поддержки.

sphinx_mvМСУДело в том, что все твое масштабирование накроется медным тазом, когда придет приказ сменить поставщика БД, или часть данных брать из другой системы через SOA шлюзы, или обеспечить работу через интернет и т.д. Пора бы уже начать думать, а не писать бредятину.Вы всегда себе подбираете начальство по уровню собственной адекватности? И почему я не удивлен?!
Ни один из известных мне промышленных серверов баз данных не имеет ни одного явного преимущества перед всеми остальными. Соответственно, причины "внезапно" менять платформу нет. Если кто-то их "увидит" - адекватный специалист должен знать, какие контр-аргументы против этого нужно привести.
Если какяя-то Муся в-припрыжку несется исполнять чей-то явно плохо обдуманный приказ - сразу видно насколько наша Муся "специалист".
Твое начальство всегда подбирает себе кадры в разрезе своего опыта и деградационной составляющей? Этого и следовало ожидать.
Бестолочь, речь тут даже не идет о сразу поменять СУБД. Речь идет о поддержке различных СУБД. Речь идет о масштабировании логики: например, появилось новое требование работать с юридическими и физическими лицами через стороннюю систему Axapta. Вся твоя говнологика в хп идет лесом. А я тупо создам новый класс от IPhysicalPersonService с десятью методами и подсуну в реализацию. И всё заработает как и раньше. Трудозатрат на несколько порядков меньше. И это только самая маленькая польза от сервера приложений.

sphinx_mvМСУТы вообще в вакууме? Со всеми поставщиками у тебя проблемы.Счас проверю...
Ау, поставщики! У меня с Вами проблемы есть? (отвечают, что нет)
Эй, поставщики! А тут один непризнаный гений говорит, что есть... (отвечают, что этот гений 3.14здит)
Ты там на наркоте сидишь, чтоле?

sphinx_mvМСУДа, походу ты точно в вакууме. Почитай букварь, не позорься - гетерогенные запросы выбрось на свалку. Ты хоть знаешь определение этого термина?
Ну, так перечитайте еще раз свой букварик - там ВСЕ написано про гетерогенные распределенные запросы к разным источникам данных. Или в Вашем букварике такого нет?! Ну, тут уж какой хозяин, такой и букварик...

Не понятно, что я делаю не так: сижу в коннекте на оракл и спокойно выполняю запросы к таблицам на MSSQL'е... И не поверите - даже джойны между таблицами на MSSQL и Oracle работают!.. Пробую наоборот: сижу в коннекте на MSSQL и делаю запросы к таблицам в базе на Oracle-сервере. И тоже приджойненые таблицы на разных серверах лежат... И так - для ЛЮБОГО поставщика, для которого у меня есть ODBC- или OLEDB-провайдер.

Вас не учили такому? Может, плохой учитель попался... Хотя, больше похоже, что в тупую Мусю эти знания просто не поместились - слишком много букаф в букварике было, и Муся ниасилилО... А таким "ИкспЭртом" прикидывается!
О, ужас... Я ж тебе уже писал, можешь сходить к коллегам - макакам в цирке, и посмешить их гетерогенными запросами. Я плакал от того, что твое говноприложение напрямую шлет запросы всей этой петрушке из сиквелов с оракулями Может оно еще и репликацией отруливает? Можешь смело убить себя об стену с такой говноархитектурой.

sphinx_mvМСУЗа твое ноухау по поводу репликации - сразу на кол. Без выплаты заработной платы. Ты хоть раз работал с репликацией, чудо?
Безумные бараны, не умеющие делать распределенные механизмы через SOA, всегда будут предлагать идиотизм в виде репликации. Более адекватные люди в это болото даже вступить откажутся. Тебе еще расти и расти, мальчик...
И этот Муся все еще на что-то претендует!? Тупая Муся так и не поняла, что при работе в "он-лайн" возможность выполнять распределеннные запросы к разным базам позволяет не заниматься репликацией?!
Кретиноподобный sphinx_mv доселе не внял, что репликация - это гвоздь в онлайн системы? Немудрено, твоя тупость уже выливается через край.

sphinx_mvSOA... Вы бы еще про "облака" рассказали!.. Когда Ваш директор попытается подключиться к Вашему приложению, отдыхая где-нибудь на яхте в Тихом океане, я не сомневаюсь - когда он вернется, Вы получите ХОРОШЕГО пинка кованым сапогом под голый зад - даже штанов Вам не оставят!
Я плакал Ты предлагаешь директору на тихом океане использовать свою чудо-двухзвенку? Пацталом
Для окончательно забронировавшихся в танке довожу до сведения, что только SOA помогут в этой лапидарной ситуации. Купи себе голову.

sphinx_mvПро "офф-лайн" клиентов, Вы не слыхали? Для "особоодаренных" рассказываю - синхронизация данных между "центральной" и "локальной" базами как раз и является репликацией, для которой имеются стандартные, оптимизированные для этой задачи средства - у ЛЮБОГО уважающего себя поставщика. Даже у "бесплатных"!
Чудилко, открой для себя великолепно масштабируемого оффлайн клиента на вцф сервисе
Я знал, что ты бестолочь, но чтоб скатиться до такого, это уж вообще ни в какие ворота не лезет. Иди читай букварь.

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

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

sphinx_mvМСУДа ничего у тебя нет и не было, о чем ты. Масштабировать сервер БД может даже дурак, а отмасштабировать приложение - совсем другая задача. Для тебя неподъемная. Как я могу тебе писать о плюсах масштабирования приложения, если ты даже не знаешь, что это такое?Айдане3.14зди!
Муся НЕ ЗНАЕТ, что ни что такое масштабирование приложения, ни то, как оно правильно выполняется!
Для профилактики читать тут - там про Вас все рассказано!
Мыши плакали, но продоолжали прожевывать кактус Типично для тебя. Ты вообще не понимаешь о том, что есть масштабирование и зачем оно нужно. Пол топика тупил и путал его с масштабированием БД. Вот оно че

sphinx_mvМСУДа и по поводу безопасности, сто раз уже писал, что можно элементарно под windbg снять строку соединения к БД, подкчлючиться через клиента management studio, открыть транзакцию, выполнить селект и пойти курить . Всё, система легла - срочно читать про изоляции транзакций и их виды. И это самое меньшее зло, что может быть с твоей убогой двухзвенкой. Да... Давно мне так не "доставляло" - это ж полярный пушной зверек какой-то!!!
Мало того, что случай идиота-разработчика, который Вы тут являете во всей красе, может всерьез рассматривать только точно такой же идиот-разработчик, так еще и только полный идиот-разработчик может считать, что SELECT к данным в базе как-то влияет на блокировку данных!
Вот Вам элементарный тест-кейс для sql2008r2 (на "стандартной" базе Northwind):

Жду, когда Вы положите "параллельную" сессию с точно таким же запросом - и курить любую траву при этом можете сколь угодно долго.
А у меня рядом стоит миска, полная попкорна...

В-обсчем, Вам не только про уровни изоляции следует читать, но и что-нибудь про гораздо более базовую теорию по серверам баз данных.
Это просто пенки идиота на поприще мега девелоптмента
Бегом читать сюда http://ru.wikipedia.org/wiki/Уровень_изолированности_транзакций про Проблемы параллельного доступа с использованием транзакций.
Открыв транзакцию и не закрыв ее (это уже не неявная транзакция), все остальные получат лок (не для грязного чтения). Этот пример еще раз подтверждает твое тугодумство.
Так обосраться мог только самый отпетый идиот! Попробуй из под других соединений покурить таблицу dbo.Categories

sphinx_mvМСУЭто показан весь твой скоуп экспириенса, не более того. Примеряйся.
Померил - размерчик Вам в самый раз...
Ты о своей тупости? Зачем ее примерять на мне?

sphinx_mvМСУУже даже жираф бы понял про все плюсы трехзвенки. Но это не твой случай. Ты тупо смотришь за любые задачи узко и однобоко, как подабает несмышленому падавану.Как ни странно, но даже жирафы знают, что в программировании вообще не существует ни одного решения - идеологического, архитектурного, программного, которое бы подходило в абсолютно всех случаях.
Это случай не двухзвенки. Ты пытаешься оправдать свое тугодумство. Смысл?

sphinx_mvНу, не понимает наша Муся, что есть множество решений, когда идеальное решение - двузвенка. Очевидно, у этого жирафа слишком толстая лобная кость черепа, и умным мыслям пробить эту толщу очень трудно...
И Муси никак не сожет сообразить,что масштабирование сервера приложений по нагрузке в "вырожденом" случае упрется в схему один клиент на один сервер... И никак наш Муся не поймет, что в этом случае сервер приложений - лишнее звено. Клиентское приложение в двузвенной архитектуре само себе "сервер приложений" - с гибко настраиваемой, централизованной авторизацией на сервере баз данных.
Двухзвенка не может быть идеальным решением. Это такому кретину, как ты, сложно доказать. Хотя объясняется сей факт даже на пальцах. Лишнее звено - это твой мозг, но никак не сервер приложений. Центразованный шлюз всегда был и остается правильной и единственно верной практикой. В том числе и по реализации безопасности. Даже в википедиях это пишут для студентов.

sphinx_mvМСУКроме "простоты масштабирования" трехзвенки, там еще есть и конфигурируемость, высокая безопасность, высокая надёжность, низкие требования к скорости канала (сети) между терминалами и сервером приложений, низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон. Пипец аргументация!
Это ничего, что сервера приложений как класс появились гораздо позже, чем двузвенные приложения?
Это кто тебе такое сказал? Сам выдумал?
Пруф в студию! Сайтам, а они трехзвенны, уже сто лет в обед.

sphinx_mvА диалап-модемы - Вы такое счастье в руках, хотя бы держали? А представить себе, как через соединение в 32 килобита в секунду полноценно работается в 1С, можете? "Терзают смутные сомнения" (с) по каждому из поставленных вопросов...
И ведь сказано же было Вам - не пугайте ежей голой жопой!
Включи остатки головного мозга, разницы никакой, что я буду тащить данные из БД или из сервера приложений. Причем в большинстве случаев поддерживается нативное сжатие трафика.

sphinx_mvМСУЕсли тебе этого мало, срочно в зоопарк. Там уже ждут.На Ваше место?!
Спасибо, конечно, за предложение, но "нас и тут хорошо кормят.".. (с)
Тут - это в другом зоопарке? Конкуренция

sphinx_mvМСУесли потребуется сменить СУБД или отстыковать логический кусок с сущностями и привязать интеграцию с внешним ресурсом.Мои заказчики как 15 лет не меняли СУБД, так еще лет ...надцать менять не будут!
И даже про связь с еще одним "внешним" ресурсом никак не собираются беспокоиться: на фоне уже имеющегося и так достаточно большого количества внешних источников входных данных (особенность сферы деятельности, однако) одним внешним ресурсом больше, одним ресурсом меньше - никто ничего особо исключительного даже и не заметит.
Так не нужно своим говнопроектом мерять все остальные задачи. То, что твой тухлый проект по автоматизации продаж семячек уже 15 лет удовлетворяет заказчика - такой же фантастический образ, как и твой ум. Еще раз, не меряй своим ламерством все остальное.

sphinx_mvМСУВо-вторых, в чем боязнь перекомпилировать код сервера приложений?То есть, в детском саду Вас не научили, что боязнь и "нахрен не нужно за ненадобностью" - это совсем не одно и то же? И где же такие продвинутые детсадовцы воспитываются?
То есть ты так и не понял на своей унылой первой линии поддержке, что "правильно" и "лишь бы работало" - это рзные вещи? Откуда только такие ламеры берутся?

sphinx_mvМСУКлиенты тут же получат обновления. Точно так же, в одном месте меняем.Для "особо упертых" ЕЩЕ раз говорю: у меня обновления доступны всем пользователям в момент публикации без необходимости разворачивать сервер приложений.
Для идиотов в танке: помимо централизованной логики у сервера приложений есть еще масса плюсов.

sphinx_mvМСУВ-третьих, твой декларативный говнокод не поддается ни нормальному документированию, ни нормальному рефакторингу, ни человеческому интелиссенсу, и так далее.Чо за бред?!
С каких это пор нельзя задокументировать код для сервера базы данных?! Какой дебил и, самое главное, когда это запретил?
Может, Вы не в курсе, что документирование кода для сервера БД ничем не отличается от документирования кода хоть на С#, хоть на васике, хоть на сях, хоть на любом другом языке программирования? И структура базы прекрасно документируется - даже в графическом представлении!
И интелисенс работает: пишу запрос, ввожу алиас таблицы в даже еще ни разу не запущенном запросе, ставлю точку - получаю список всех доступных алиасу полей. В процедуре навожу курсор мыши на функцию - разворачивается ее декларация. Что не так? Может, просто что-то не так с Вашими инструментами для работы с БД? Сменить не пробовали?
Ты идиот? Бегом шагом марш читать про автоматическую генерацию документации в .NET
http://habrahabr.ru/post/102177/
Я плакал, как ты тоже самое реализуешь в своих хранимых процедурах. Сразу видно, что тут очередной жирный пробел в знаниях.
Это не интеллисенс, это феерическое гумно на лопате. Сравни с возможностями полноценной работы в VS. Хотя да, я ж забыл. Ты в студии дурак дураком был, есть и остаешься.

sphinx_mvМСУРано или поздно, твои лохмотья превращаются в кусок неуправляемого линейного гавна на несколько тыщ строк кода. Не раз сталкивался с таким явлением в сторонних системах, разработчика этого отродия хотелось бы повесить за ноги без объяснения причин. И ты следуешь именно этому допотопно-ориентированному принципу. Больше гавна, больше! Вся твоя суть.
Ай, да не... не врите - ведь это же именно Вас подвешивали и совсем не за ноги за Ваш говнокод и в совсем не "в сторонних" системах!
Я прекрасно помню Ваши "перлы" Вашего "идеального" t-sql-ного кода - это было НЕЧТО! "Полярно-пушное", если Вы не поняли....
Ха, попал в яблочко Эти жуткие лохмотья из потока сознания в хранимых процедурах - истинное джедайство! Убит об стену!

sphinx_mvМСУДа какие там затраты на продукт, что за бред ты несешь? Затраты почти такие же, а на этапе развития и поддержки всё окупается с лихвой.
Не знаешь - не 3.14зди!
Что такое "унаследованное" програмное обеспечение Вам известно?
Вы в курсе, что "новая" система должна как минимум функционально соотвествовать "старой" системе? Вам это понятно?
Стоимость разработки не забыли? Стоимость внедрения с разворачивание новой системы на независимой от "старой" системы платформе обучение пользователей, снижение качества предоставляемых услуг из-за еще недостаточной качества обслуживания новой системы в комплекте с параллельным обслуживанием "старой", с оттоком недовольных пользователей - Вы это учли/посчитали?
Ты там завязывай с травой. Во-первых, речь не идет о том, что система должна заменять что-то старое. Во-вторых, стоимость разработки такая же, не рублем больше. Качество на выхлопе на порядок выше, безопасность тоже, масштабирование тоже. В двухзвенке нет плюсов, только минусы. Впрочем, это нормальное средство для прожигания бюджета группой бездарностей вроде тебя.

sphinx_mvА еще есть такая хрень - накопленные за время оперативной деятельности данные,с которыми должна уметь работать "новая" система...
И эта миграция данных - практически отдельный проект с весьма "интересными" затратами и возможными последствиями...
Вообще никаких проблем. В чем ты видишь нерешаемость и последствия? Купи голову.

sphinx_mvМСУО какой производительности идет речь? О разнице в две наносекунды на реквест? Не смеши мои носки, они уже улыбаются.
Вам - домашнее задание, хотя сомневаюсь, что осилите: построить два простейших тестовые приложения: одно в двузвенной, второе - в трехзвенной архитектуре, и провести реальное нагрузочное тестирование с полным профилированием на сервере приложений и на сервере БД - вот тогда и увидите, как Ваши "наносекунды" начнут "внезапно" трансформироваться в секунды и часы...
Эти супер тестовые приложения я строил еще тогда, когда тебя еще преподы линейкой по рукам били. Пруф будет?

sphinx_mvМСУТретье звено - это не рекламная мишура, это банальная обыденность, которой должна владеть любая вменяемая респределенная система. [/b]Где доказательства, факты, явки, пруфы, графики?[/b]Не вижу ничего подобного про трехзвенку.
А по поводу Ваших хотелок - проведите тест, и в зеркале увидите и пруф, и явку, и с кого графики требовать.
Отличная аргументация. Трезвенка тормозит! Не веришь - сделай тест
Тебе самому не смешно? Чудик, срочно читай про tcp байдинги в wcf. Твои базы данных курят в сторонке.

sphinx_mvМСУО как! Так ты не разработчик даже, ты тупо поддержка? А что ты тогда делаешь в этом форуме? Как-то некомильфо разговаривать с поддерженцем о бюджетах, сроках, надежности, распределенности. С особенностями внутрикорпоративной разработки, значится, Вы как-то "не в курсе"...
Соотвественно, Вы "как бы не в курсе", что от сроков зависит не только получу ли я зарплату в этом месяце, но и будет ли в следующем месяце моя фирма физически присутсвовать на рынке...
Какая зарплата? За что? За твою поносную тупость? Да с тебя вычитать нужно, а не платить.

sphinx_mv"Не в курсе" Вы и о том, что внутренняя разработка находится в ОЧЕНЬ жестких ресурсных рамках и по деньгам, и очень часто по не очень большому количеству людей - это что касалось вопроса о бюджетировании...
Я тебе уже десять раз говорил о том, что сроки и бюджет трехзвенки такой же. Более того, в будущем еще в n раз окупится.

sphinx_mvИ требование к надежности ПО у меня стоит на пару десятичных порядков выше - от ошибок в "заказном" приложении, которое содержит невыявленные ошибки исполнитель уже получил свои деньги в полном объеме и уже ни за что больше не отвечает, а ошибки в моих приложениях для внутреннего использования у моего работодателя - моя отвественность до самого моего увольнения, сроки которого из-за некачественно написаного приложения могут "внезапно" приблизиться с неплохим "шансом" смены сферы деятельности на что-то менее связанное с программированием в частности и компьютерами вообще.
У трехзвенки надежность на порядки выше, это даже в википедии написано

sphinx_mvНу, а то, что в отделах разработки внутреннего программного обеспечения этот же отдел отдел отвечает и за обучение пользователей, и за решение пользовательских проблем, и за устранение выявленных ошибок, т.е. непосредственно находится в "первой линии" - это тоже Вам, как-то "не знакомо"...
Первой линии пофиг, что саппортить, двухзвенку или трехзвенку.

sphinx_mvДействительно... Какое может быть "комильфо" обсуждать с Вами вопросы, в которых Вы, мягко говоря, "ни в зуб ногой"?!
Я плакал. Индеец учит спецназовца пользоваться копьем

sphinx_mvМСУТы настолько туп, что даже до сих пор не понял, о чем идет речь. Покажи пальцем, где я сказал о том, что сервер баз данных не масштабируется? Если ты не видишь никакой разницы между сервером БД и сервером апп, то я же уже писал - спасет только цирковое творчество. Там твое место, рядом с макаками, моржами и тюленями.Идите почитайте свой букварик на тему масштабирования. В масштабирование в двузвенке означает масштабирование сервера.
Сам выдумал али пруф будет?

sphinx_mvМСУВ целях повышения нулевого уровня познаний горе-поддерженцев первого уровня саппорта, настоящим докладываю, что речь идет о масштабировании приложения (в некоторых случаях и логики, если потребуется). Если до сих пор это не понятно, могу посоветовать еще кирпичную стену. Надеюсь, стена поможет.
Вам помогла?
Если не пробовали, чего другим советуете?
А если помогла, то результаты, которые Вами были получены как-то не впечатляют.
И мне помогла и всем помогла. Она не может не помочь. Только идиот это не может понять.

sphinx_mvМСУА ты готов привести ссылку на то место, где я жаловался на отсутствие возможности масштабирования в серверах БД?Да, без проблем!
Вот тут 14549572 один псих по поводу использования хранимых процедур жаловался:
МСУ масштабировать решение на порядки сложнее

масштабировать логику на порядки сложнее
Оно?
МСУА то ведь приклеется клеймо форумной балаболки. Не? Копай-рыщи, бобер. Ты должен найти пруф.
Не переживайте Вы так!
Я на Ваше место не претендую, да и четко осознаю, что мне до Вашего балабольского уровня ой как далеко...
Кретинам комментирую: Где там сказано, про отсутствие возможности масштабирования именно сервера БД?
Понимаешь разницу между логикой и сервером БД?

sphinx_mvМСУСсылочку? Ты смеешься? Я тебе уже битый день об этом пишу, что ты как идиот с флагом ходишь по комнате и орешь о том, что я якобы доказываю всем о невозможности масштабировать сервер БД. Клиника Да уж, действительно клиника...
Вот тут 14549572 один псих по поводу использования хранимых процедур жаловался:
МСУ масштабировать решение на порядки сложнее

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

sphinx_mvМСУДля нормального разработчика это не страшные слова, а обыденность. Для кодеманки саппортёрши, которая уткнулась носом в гавнокод хранимых процедур, это, может, и сложные слова. У тебя есть проблемы не только в архитектуре и масштабировании, но и в голове в целом. Пока ты не отлепишь свой лоб от хранимых процедур и не оглянешься вокруг, так и помрешь гавнокодером. Даже спецификации не помогут.
Уж, кто бы 3.14здел!
Можно подумать, что это у меня хранимые процедуры не поддаются документированию и рефакторингу!
И можно подумать, что это у меня не работает интелисенс!
Не поддаются. И это не интеллисенс, а гумно на лопате. Уже писал.

sphinx_mvМСУДля множества клиентов, особенно разнородных, как-раз и подходит сервер приложений. О каком агенте идет речь и почему ты решил, что он не может иметь доступ к серверу приложений? Очередная бредятина? Вывод напрашивается один - ты не представляешь себе, что такое апп сервер и как делается распределенность. Поэтому что-то доказывать кодеманке о правильности в архитектуре - заранее утопично.Утопия - пихать в каждую дырку сервер приложений и надеяться, что получится хотя бы просто работающее, не говоря уже о надежном, решение.
Я понимаю, что говноархитекторы не в курсе, что система тем надежнее и управляемее, чем меньше в ней меньше взаимодействующих частей - но в отличие от говноархитекторов, это известно более другим разработчикам. В более других, чем порноиндустрия отраслях деятельности.
В каждую - возможно. Но для задач с распределенностью - то, что доктор прописал. Я понимаю, что гавноразработчики хранимых процедур этого не могут понять в силу своей тупости, но что ж я могу поделать?

sphinx_mvМСУВообще никаких проблем. Всё уже написано, бери и юзай:
http://wcfradiusservice.codeplex.com/
У "продукта" альфа-статус с 2009 года... Бессмысленно даже просто рассматривать как кандидата для использования в реальной системе. Но, возможно, для уровня Ваших говноподелок как раз годится...
Да пох, какой там статус. Бери исходники и юзай. Впрочем, я тебе привел еще примеров кроме этого. Решений как грязи.

sphinx_mvМСУ http://www.codeproject.com/Questions/574399/RadiusplusAuthenticationplususingplusWCFplusServic Вообще ничего нового...
От использования IAS уже никто и не помнит когда отказались - но это точно было задолго до 2003 года...
Я тебе о том, что "задача" твоя обсасывалась уже как сто лет. А тут ты такой вырисовываешься

sphinx_mvМСУ http://www.developerfusion.com/project/16278/wcf-radius-service/
Тут снова переход на первую ссылку...
И, даже если забыть про статус "альфа", есть один ключевой недостаток - WCF работает только на Win-платформе.
Приплыли .NET тоже, прикинь
А еще и MS SQL

sphinx_mvЧто еще круче - нужно использовать как минимум винсервер... И серверов таких (по требованиям отказоустойчивости) нужно не меньше двух штук... Итого, цена вопроса только по лицензированию - примерно пару-тройку килограмм американской капусты. Добавим сюда преодоление альфа-статуса, чтобы можно было без особых зазрений выкладываться на рабочую платформу, а еще минимум полгода разработки, тестирования, внедрения - еще килограмм "20 капусты" (по самым скромным расценкам) на "бригаду"...
Не трынди о том, о чем не знаешь. Есть облака азуре, есть у винды редакция веб. Это все не дорого, не дороже лицензий на оракел с тьмой сисадминов для глючных никсов.

sphinx_mvА вот это - то что мы используем - модульное, расширяемое, компактное, легкое в настройке и обслуживании универсальное решение. Немаловажным оказалось, конечно, что оно еще и кроссплатформенное оказалось, а линукс как был практически бесплатным, так и остался - съэкономили по паре-тройке кило только на лицензировании каждого комплекта RADIUS-серверов... Кстати, Вам разрешается начать писать для него мождуль для использования WCF... Когда напишите хотя бы до альфа-версии, тогда и будете срать "в тему".
Маленький, да мне фиолетово, что ты ты там используешь в свой кастрированной команде. Я говорю о том, что теме сто лет в обед.

sphinx_mvМСУСервер приложений в распределенных системах не нужен только ламерам, которые не понимают сего предназначения. Для чего он нужен - я уже раз 10 сказал. Перечитай.Перечитал!
Сервер приложений нужен ламерам, которые не умеют пользоваться серверами баз данных и по-этому не могут писать двузвенные приложения.
А еще ламеры путают масштабирование и переход на другого поставщика баз данных.
Тугодумам невдомек, что все веб сайты трезвенны. Их писали ламеры?
Убей себя об стену, неуч.

sphinx_mvМСУВот для таких лапидарных систем на пару тройку форм ты и нужен. На реализацию чего-то более серьезного, ты сдуешься как мыльный пузырь.
Зашибись!...
Чмо, котрое никогда не писало двузвенку, будет считать сколько сишарповых модулей в моем проекте...
И все бы ничего, но рядом (в соседней группе разработчиков) проект совсем не шарповый, но очень двузвенный, и в откомпилированном виде в общей сложности занимает полсотни мегабайт...
Отлично, галимая мразь, которая не понимает сути трезвенных приложений и полная бестолочь в дотнете, будет давать какие-то советы на .NET форуме?

sphinx_mvМСУВопросы безопасности уже обсудили, двухзвенка небезопасна (легко получить строку соединения и открыть транзакцию, это минимум).
Мусье, Вы - тупица!
Для двузвенки в самом худшем случае будет получен уровень прав одного конкретного пользователя.
Перехват строки подключения сервера приложений в подавляющем большинстве случаев дает МАКСИМАЛЬНО ПОЛНЫЙ набор прав всех пользователей, работающих с этим трехзвенным приложением. Минимальный остаток, который ограничивает права при использовании перехваченой строки подключений должен использовать средства аутентификации сервера баз данных - капля в море!
Глупая обезьяна. У двузвенки я запускаю незакрытую транзакцию и все курят бамбук. Ты идиот?
Перехват прав дб админа дает любому право снять всю базу. Это капля в море?

sphinx_mvМСУЛогика в хп - зло, тыщу раз обсуждали. Не документируется, не рефакторится, не интелисится, просто катастрофические проблемы при смене СУБД - нужно тупо заново всё переписывать.Все прекрасно и документируется, и рефакторится, и интелисенсится... О! - и даже тестируется!!! В автоматическом режиме!!!
Просто некоторые не вполне адекватные, якобы, разработчики либо пользуются неадекватными инструментами, либо не умеют адекватно настраивать "правильные" инструменты. И в обоих случаях это - диагноз.
Да нихрена там не документируется, не фантазируй. Ты просто тупая обезьяна

sphinx_mvМСУДвухзвенка приемлема для детских систем с минимальным порогом вхождения в разработку. Собралась кучка хлопцев, что-то наклепала и втюхала заказчику.
А потом померла и разбежалась о того, что это говно даже саппортить по-человечески нельзя со всеми твоими репликациями, не то, что развивать. Вот для таких "систем" это работает.
Ничего, чего нельзя сказать про трехзвенку... Соотвественно, мимо тазика...

Сколько реально работающих двузвенок Вы вообще самостоятельно написали? Сколько времени сопровождали хоть одну из них?
Но похоже, ни на один из этих вопросов Вы ничего вменяемого не ответите - и ничего исключительно удивительного в этом не будет.
Сколько реально работающих трехзвенок ты вообще самостоятельно написал?
Лично я работал с несколькими двузвенками в разных конторах на начальных парах. С репликацией. Это худший опыт, смею заметить.

sphinx_mvМСУПроблема в том, что твой мозг смотрит очень и очень однобоко на задачи, которые могут возникать и возникают у бизнеса. Тот факт, что ты тут предлагал безумие с репликациями с вызовом вебсервисов из хранимых процедур с жестко захардкоженным xml - достойно отдельной похвалы: уволить за тупость. Вариант развития только один - читать нормальный букварь, т.к. со своим горе багажом ты далеко не уедешь. Так и будешь тормозить процессы на первом уровне поддержки Муся-уборщица совершенно не в курсе, что для быстрого решения проблем пользователей системы в нормальных организациях ставят специалистов, которые действительно могут решить проблему клерка-пользователя, над которым в данный конкретный момент стоит пришедший клиент с пачкой денег и острым желанием оставить их в кассе компании, а не всяких говноархитекторов, которые не могут ни задокументировать, ни отрефакторить кода, не говоря уже о том, чтобы настроить интелисенс...
Вопрос не в деньгах и т.п. Вопрос в грамотной архитектуре. В твоем случае она отсутствует как класс. Пора тебя увольнять за тупорылость