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

S>Ничего, что я сразу на 2 поста тов. gandjustas отвечу?

G>>Еще раз. Зачем хранимые процедуры для CRUD? Я работал в проекте где для каждой сущности писались 4 CRUD процедуры. На 20 сущностях вносить исправления было очень трудоемкой задачей. Кроме того изменения БД плохо поддаются контролю версий.

S>Сразу — говорю исключительно про SQL Server. Опыта длительной эксплуатации других СУБД нет — исключительно "поиграться".
S>Видно вы меня не так поняли — я не утверждял, что CRUD должно быть и должно быть через хранимые процедуры.
S>Я писал, что если СУБД для вас не just storage, если одни и те же данные используются несколькими приложениями, то рано или поздно вам придётся заводить отдельные прослойки, представления — что хотите — для каждого приложения. Как это делать уже дело десятое. Я исповедую хранимые процедуры, по целому ряду причин: инкапсуляции SQL кода, лёгкость администрирования, возможность разграничения доступа, возможность сложных алгоритмов и т.п.
Ну вьюхи темиже возможностями обладают, развечто кроме сложных алгоритмов, которых в базе лучше держать по минимуму.
С другой стороны вьюхи можно индексировать, на вьюхах можно здавать дополнительные условия фильтрации, проекции и оптимизатор запросов вам в этом будет помогать.

S>Как success story: переход на SQL Server 2008 занял 2 дня с момента получения диска. Причём это не было просто восстановление из бэкапа, добавилось хранение файлов ч/з FILESTREAM (раньше файлы хранились напрямую на жёстком, доступ был ч/з CLR stored procedures), и включен полнотекстовый поиск по этим файлам (раньше коннектились ч/з ODBC к IndexingServices, который индексировал файлы на диске). Изменилось то ли 5, то ли 6 мест на сервере. Клиент ничего не почуствовал.
Удивился если было бы по-другому при использовании ХП.

S>Про редактирование изменений. Умейте готовить SQL Server Management Studio умеет контроль версий (как минимум TFS и Source Safe, ещё был бодяжный плогин к тортойзу).
Сложен не сам котроль версий, а синхронизация и непротиворечивость изменений во всем проекте при командной разработке.

S>Да! можно спросить, вы сразу 20 сущностей редактировали?
Слава богу нет, но когда приходилось рабоать сразу с тремя сущностями уже становилось плохо.

G>>Если использовать ХП для выборок, то оптимизировать запросы станет гораздо сложнее. В большенстве случаев для разных сценариев придется писать разные хранимки.

S>Да что вы говорите Ну дык никто не мешает создать view и дать доступ к нему. Как минус — чуть сложнее реализовать нетривиальную фигню типа чтения файлов, приходится отслеживать возможность SQL-инъекций, ну и крайне муторно пытаться оптимизировать узкие места, когда завтра какой-нибудь [censored] поломает твой запрос потому что некрасиво.
Во-первых SQL-иньекции надо отслеживать на уровне приложения, а не на уровне базы.
Во-вторых офигенный способ оптимизации "тяжелых" запросов — создание индексированных вьюх по ним, если возможно.
В-третьих, если у вас в процедуре выборка, а для программы нужно подмножество записей, возвращенных процедурой (выполняется select .. where запрос), то серверу придется подять все страницы данных для записей, возвращаемых процедурой, несмотря на то что часть окажется ненужной. Аналогично с проекцией.

G>>Зачем имперсонация для CRUD?

S>Ну сценарий я тебе приводил: приложения имеют доступ только к хранимкам, права, необходимые каждому приложению раздаются ролям, пользователи приложений включаются в эти роли. Прямого доступа к таблицам нет. На этом этапе можно вместо хранимок использовать представления.
Это понятно.

S>Сценарий 2: часть хранимок особо критична (допустим, у них внутри создаётся SQL код и возможна инъекция) — эти хранимки работают с пониженными правами.
Причем здесь CRUD? Диначмическая генерация SQL для CRUD — это сильно.

S>Сценарий 3: хранимка работает с удалённым сервером (Linked Server в терминах MS SQL). Она запускается от имени служебного пользователя, имеющего доступ к этому серверу. Больше никак к этому серверу не подрубиться.
S>На самом деле эта ситуация не так уж и часто встречается, тем не менее ещё +1 в пользу хранимых процедур.
sp_addlinkedsrvlogin + ограниячения на Linked сервере не пробовали?


S>>>3) EF
S>>>Один из раздражающих моментов в EF — стремление по любому поводу пинать сервер. Загрузка согласованного набора данных — щитай вообще недостижимая мечта. Если будет время, потрэйстье SQL запросы, которые сыпятся на сервер, особенно запросы с eager loading.
G>>Я смотрел запросы. Очень прилично получается, особенно если не писать выборки в виде EntitySet.Include("Все") и не загружать каждую ссылку вручную.

S>Да. Согласен. Сценарий: у вас список чего-то, вы по переходу показываете детали. У вас всего 2 варианта: либо дёргаете данные по мере необходимости, либо загружате их скопом заранее. Во втором случае как раз и получается кошмарные запросы с кучей жойнов и вложенных запросов. В первом — вы получаете рассогласованные во времени наборы данных.
А вы план запросов видели? Зачастую они получаются эффективнее, чем написанные вручную.
Если вам нужен согласованный набор — грузите все сразу.

S>Как пошлый пример: В мегагитлерредакторе каждая страничка подгружается при прокрутке. В результате первая страница договора отражает ваши изменения, вторая — внесённые главбухом, который ваши изменения не читал, третья удалена ещё кем-то, кто видит первые две страницы ДО изменений. Попа
Это всегда попа независимо от технологии доступа к данным.

S>>>Как-то больще исповедую пакетную обработку аля пнул сервер — получил согласованный набор данных — отсоединился, поработал — пнул сервер....
G>>Нагрузка очень хорошо сглаживается и распределяется по клиентам.
G>>ADO.NET Data Servces вам в помощь.

S>Ггг. Вы их щупали/читали/пользовали? Astoria — это эмуляция EAV хранилища через вебсервисы поверх EF поверх SQL Server'a. Всё оптимизируем ?)))
Пробовал, использовал. Хорошо работает, небольшой геморрой доставляет изменение связей. Едиственный недостаток — невозможно описать проекцию, надо тянуть полные сущности. Хотя наверное можно изватиться через батчи, но не хочется.

S>Под нагрузкой имелось в виду другое — вся логика, относящаяся к работе клиента, живёт на клиенте. Он работает с данными, которые нужны пользователю. Эти данные заблаговременно загружены, клиент отсоединён от серера до того момента, пока не требуется сохранить изменения или попросить сделать что-то эзотеричное, допустим тот же полнотекстовый поиск, к серверу не подсоединяется.
S>Вот такой вот сценарий на EF реализовать тяжелоато будет.
Снова ADO.NET DataServices и все оказывается легко.
Если нужно действительно occasionally connected apllication, то смотри в сторону Sync Services.

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

G>Ну вьюхи темиже возможностями обладают, развечто кроме сложных алгоритмов, которых в базе лучше держать по минимуму.
G>С другой стороны вьюхи можно индексировать, на вьюхах можно здавать дополнительные условия фильтрации, проекции и оптимизатор запросов вам в этом будет помогать.

Эммм. И о чём мы спорим?

S>>Как success story: переход на SQL Server 2008 занял 2 дня с момента получения диска. Причём это не было просто восстановление из бэкапа, добавилось хранение файлов ч/з FILESTREAM (раньше файлы хранились напрямую на жёстком, доступ был ч/з CLR stored procedures), и включен полнотекстовый поиск по этим файлам (раньше коннектились ч/з ODBC к IndexingServices, который индексировал файлы на диске). Изменилось то ли 5, то ли 6 мест на сервере. Клиент ничего не почуствовал.
G>Удивился если было бы по-другому при использовании ХП.
Было. Ой как было... но это будет не сацесс стори. Там на конкретный алгоритм всё было очень завязано, так что пришлось переписывать конкретный кусок приложений. Blocking issue, блин.

S>>Про редактирование изменений. Умейте готовить SQL Server Management Studio умеет контроль версий (как минимум TFS и Source Safe, ещё был бодяжный плогин к тортойзу).
G>Сложен не сам котроль версий, а синхронизация и непротиворечивость изменений во всем проекте при командной разработке.

Этто да ИМХО, за СУБД должен отвечать очень узкий круг товарищей, очень хорошо знающий, что они ломают. Ибо чревато.

G>Слава богу нет, но когда приходилось рабоать сразу с тремя сущностями уже становилось плохо.
Иногда спасает возможность VSTS DB edition рефакторить код и показывать зависимости. Иногда нет

G>>>Если использовать ХП для выборок, то оптимизировать запросы станет гораздо сложнее. В большенстве случаев для разных сценариев придется писать разные хранимки.

G>Во-первых SQL-иньекции надо отслеживать на уровне приложения, а не на уровне базы.
Если доступ только через хранимые процедуры — то нет //сорри, уже стебаюсь

G>Во-вторых офигенный способ оптимизации "тяжелых" запросов — создание индексированных вьюх по ним, если возможно.
Угу. А можно создать вьюху и процедуру поверх неё //сорри, ещё раз стебаюсь

G>>>Если использовать ХП для выборок, то оптимизировать запросы станет гораздо сложнее. В большенстве случаев для разных сценариев придется писать разные хранимки.
[skipped]
G>В-третьих, если у вас в процедуре выборка, а для программы нужно подмножество записей, возвращенных процедурой (выполняется select .. where запрос), то серверу придется подять все страницы данных для записей, возвращаемых процедурой, несмотря на то что часть окажется ненужной. Аналогично с проекцией.
Угу. Ещё раз. Если у нас известна структура данных — то ХП. Нет — вьюхи. Я ж не против.

S>>Сценарий 2: часть хранимок особо критична (допустим, у них внутри создаётся SQL код и возможна инъекция) — эти хранимки работают с пониженными правами.
G>Причем здесь CRUD? Диначмическая генерация SQL для CRUD — это сильно.
На самом деле эзотерика. Единственный вариант был — обращение к чужому серваку по запросу снаружи. Структуру сервака наружу светить низзя, запросы нужны сложные, данных много. Вот и игрались...

S>>Сценарий 3: хранимка работает с удалённым сервером (Linked Server в терминах MS SQL). Она запускается от имени служебного пользователя, имеющего доступ к этому серверу. Больше никак к этому серверу не подрубиться.
S>>На самом деле эта ситуация не так уж и часто встречается, тем не менее ещё +1 в пользу хранимых процедур.
G>sp_addlinkedsrvlogin + ограниячения на Linked сервере не пробовали?

Так и делалось. Там было слегка шизофреничное требование чтоп никто кроме sa не мог написать код, который дёргает linked server. Если честно не помню, но реально там БЫЛО НАДО. Хотя тоже изотерика.


S>>>>3) EF
G>А вы план запросов видели? Зачастую они получаются эффективнее, чем написанные вручную.
Для единичной подгрузки — да.
G>Если вам нужен согласованный набор — грузите все сразу.
Создаётся либо 1 жуткий запрос с денормализацией, либо n+1 запросов по числу главных записей. Пару раз получалось 2 запроса — 1 для мастера, 1 для details, но так и не смог понять по какому принципу, ибо меня нашёл дедлайн.

S>>Как пошлый пример: В мегагитлерредакторе каждая страничка подгружается при прокрутке. В результате первая страница договора отражает ваши изменения, вторая — внесённые главбухом, который ваши изменения не читал, третья удалена ещё кем-то, кто видит первые две страницы ДО изменений. Попа
G>Это всегда попа независимо от технологии доступа к данным.
Да, но тут неинтуитивная попа какая-то. Пользватель не просил "обновись", а оно, ссука...

G>>>ADO.NET Data Servces вам в помощь.
S>>Ггг. Вы их щупали/читали/пользовали? Astoria — это эмуляция EAV хранилища через вебсервисы поверх EF поверх SQL Server'a. Всё оптимизируем ?)))
//Извиняюсь за неоправданный сарказм. Возможно не так вас понял.
G>Пробовал, использовал. Хорошо работает, небольшой геморрой доставляет изменение связей. Едиственный недостаток — невозможно описать проекцию, надо тянуть полные сущности. Хотя наверное можно изватиться через батчи, но не хочется.

ИМХО, накладные расходы всё-таки великоваты Если честно, так и не понял в чём цимус, если не нужны EAV и веб-сервисы.

G>Если нужно действительно occasionally connected apllication, то смотри в сторону Sync Services.
Да нет, тру OCA не требуется, так просто львиную долю задач удаётся организовать по принципу "открыл/сохранил". Удобно.

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

G>>В-третьих, если у вас в процедуре выборка, а для программы нужно подмножество записей, возвращенных процедурой (выполняется select .. where запрос), то серверу придется подять все страницы данных для записей, возвращаемых процедурой, несмотря на то что часть окажется ненужной. Аналогично с проекцией.
S>Угу. Ещё раз. Если у нас известна структура данных — то ХП. Нет — вьюхи. Я ж не против.
Даже если известна выборка (фильтр и проекция), минимально необходимая для каждой задачи, то для каждой такой выборки надо писать ХП. В итоге количество хранимок оказывается гораздо больше чем 4*кол-во таблиц.

S>>>>>3) EF
G>>А вы план запросов видели? Зачастую они получаются эффективнее, чем написанные вручную.
S>Для единичной подгрузки — да.
И не для единичной тоже.

G>>Если вам нужен согласованный набор — грузите все сразу.
S>Создаётся либо 1 жуткий запрос с денормализацией, либо n+1 запросов по числу главных записей. Пару раз получалось 2 запроса — 1 для мастера, 1 для details, но так и не смог понять по какому принципу, ибо меня нашёл дедлайн.
Время выполнения и план запроса оценивать надо, а не внешний вид выборок.

G>>>>ADO.NET Data Servces вам в помощь.
S>>>Ггг. Вы их щупали/читали/пользовали? Astoria — это эмуляция EAV хранилища через вебсервисы поверх EF поверх SQL Server'a. Всё оптимизируем ?)))
S>//Извиняюсь за неоправданный сарказм. Возможно не так вас понял.
G>>Пробовал, использовал. Хорошо работает, небольшой геморрой доставляет изменение связей. Едиственный недостаток — невозможно описать проекцию, надо тянуть полные сущности. Хотя наверное можно изватиться через батчи, но не хочется.

S>ИМХО, накладные расходы всё-таки великоваты Если честно, так и не понял в чём цимус, если не нужны EAV и веб-сервисы.
Какие накладные расходы? Как вы решаетет эту задачу другими средствами?

G>>Если нужно действительно occasionally connected apllication, то смотри в сторону Sync Services.
S>Да нет, тру OCA не требуется, так просто львиную долю задач удаётся организовать по принципу "открыл/сохранил". Удобно.

Здравствуйте, Sinix.
хорошо, что решили ответить и задаете вопросы — так будет легче проверить задуманое на "устойчивость". отвечать буду по мере постановки вопросов, а на дальнейшее спрашивайте критикуйте и главное предлагайте альтернативы — это мне полезно... и так :

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

S>Вы знаете, из моего опыта — это будет ОЧЕНЬ большой проект.

очень не очень — но большой, после того как я работал в компании где проекты длились 6-12 месяцев я пришел в компанию где большим проектом считался проект 3-4 месяца. но вообще, по моим меркам, проект будет боьшим.

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


// Я не беру в расчёт всякие справочники. Вы не сможете запихнуть такой объём в одну модель EF (не, я верю что сможете, но вот пользовать такого динозавра )

и не хочу ее туда пихать я где-то уже на этот форуме писмал о невозможности декомпозиции модели в EF.

S>ИМХО, у вас в конце-концов получится несколько десятков моделей EF, которые будут частично перекрываться. И вот тут вам грядёт попа. Потому как
S>а) в разных моделях вам понадобится разный набор атрибутов для одной и той же сущности
для моего понимания того что вы сказали: вы имеете в виду что будут модели котрые будут разделять между собой некторые сущности — абсолютно. и общий набор атрибутов характеризующий разделяемую сущность будет разбросан между несколькими (как правило 2, максимум 3) моделями? — это правда. при наличии техник, позволяющих с этим бороться (придется вмешиваться в генеренный код или мапинг как я сказал ранее — не очень нравиться но работает) это помжно назвать не жопой, а скорее неудобством.
S>б) БЛ в этих моделях будет очень слабо пересекаться.
искренне надеюсьчто пересекаться вообще не будет. а разделяемые сущности хотя и будут присутсвовать на нескольких моделях, но все же в результате это будет одна сущность, так как определяеться она как партиал и соответственно логика работы с ней будет одинакова... или я не понял ...

S>в) эти два представления должны быть соответствовать одним и тем же данным.
ну да это я ответил в б)
S>г) Сам доступ к этим данным желательно проводить ч/з обёртки-представления (аудит, контроль доступа и т.п.)
как по мне в идеале было бы хорошо везде сипользовать именно эти сущности полученные в результате генерации EF и при помощи атрибутов указывать и права доступа и чкто как сериализоваться должно и т.д. по моему это было бы "желательно", но поскольку это не совсем так, то да иногда приходиться писать овертки — например для того чтобы передать сущности на уровень представления для SL.

S>Решать такие пролемы в терминах объектной модели — ещё большая попа. Если интересует — отпишусь подробней, пока оставим. весьма интересует, хотя бы потому что я не понял почему жопа решать проблемы в оьектной модели (всмысле не вообще а в контексте нашего разговора). было бы весьма полезно узнать о том кто на какаие граблли наступал чтобы самому их обойти — так что очень даже интреесно... только здесь нужно четко сформулировать проблему о которой вы говорите...

S>Из последней цитаты следует наличие аппсервера. Поправьте если не прав.
я не совсем знаком с шаблоном Application Server — бля меня это скорее не шаблон а реальный сервер где выполняются Java приложения, по этому я попытаюсь ответить в терминах определение которых можно найти например у мартина фалера. так вот у меня есть слой служб (ServiceLayer), в них выполняется логика домена, доступ к ServiceLayer удаленным клиентам предоставляется через RemoteFasade. RemoteFasade использует DTO для переноса данных между слоями и в моем случае между уровнями.

S>Воот. Видите, проекту ещё жить и жить. А вы уже ограничиваете клиентов одной платформой,
относительно платформы — рассматривалась возможность доступа к сервисам со стороны Java -но разработка на нескольких платформах не планируетс я- да и зачем? одна платформа — одни проблемы — две платформы — две проблемы на самом деле не вижу смысла учатсия нескольких платформ — проблемы разработки — нужен персонал котрый бы разирался и в Java и .Net а таких днем с огнем, проблема интеграции, сопровождения, а какой смысл — котороче я не вижу для себе бенефитов от испоьзования нескольких платформ по этому сознательно ограничиваю разработку одной — нетом. а при необхоимлости взаимодействия WS нам поможет

да ещё и одним фреймворком. Не, сначала это некритично, но вот потом, когда EF объявят слегка устаревшим (как недавно Linq for SQL)... Здесь я конечно передёргиваю — такая радость наступит очень и очень нескоро — очень уж много на EF поставлено.
обявление ODBC устаревшой технологией не означает что приложения с ее использованием необходимо переписывать — драйвера ODBC до сих используются... так что если появиться следующее развитие EF это не будет сигналом для того чтобы переписывать ее, а на собственном опыте вижу что технологии как правило нарастают как мышцы на скелете по этому мне до сих пор никто не мешает пользоваться ADO в случае необхоимости

Но посмотрите, сколько программ умеют ODBC/OLEDB, и сколько — EF. ну это и понятно — сколько ODBC и сколько EF.
Допустим, когда вам потребуются отчёты, вы с удивлением увидите, что МС умеет свой репортсервер или датасеты, кристал репортс умеет свой формат и слегка произвольные объекты, у остальных вендоров — не лучше.
отчеты думаю делать при помощи Reporting Services, но окончательного решения пока нет... если есть рекомендации и т.д. буду плагодарен.

Эксель, допустим — вообще только OLEDB|ODBC // не пробовали аналитику в экселе 2007? очень советую — весчь, если готовить. Если у вас половина систем (не забываем про интеграцию) будет лезть напрямую к СУБД — что вам дают ваши сервисы? ну как я сказал лазить напрямую это грех хотя для аналитики думаю позволительно, так как она не делает изменений, а при наличии необходимости может давать возможность делать аналитику более гибкой и т.д. так что для аналитики прямой доступ наверное возможен.


S>Про одноразовость проекта. Скажите, индивидуальный дух компании так влияет на подсистемы контроля доступа, развёртывания, администрирования? Все эти велосипеды тоже заново пишутся?
не совсем понял: — если Вы о том что я собираюсь писать свой велосипед — то это совершенно не так — подход абсолютно противополжный — я где-то об этом уже писал — чем меньше мы пишем и больше используем библиотек тем лучше — не буду распыляться на эту тему. а относительно контроль доступа — CardSpace, тоносительно развертывания — обыная инсталяция — но не факт что "продукт" вообще будет иметь инсталяшку как таковую — в это не коробочная версия, хотя сделать инсталяшку обычными средствами не преставляется сложности...ну да ладно не тема...относительно администрирования — хотел бы сказать что администрирование будет сделано на основе WMI и с MMC консолью т.д. но... а нафиг ? никому это не нужно а на написание толко приблуды для управления с консоли нужно тратить время ресурсы — а потребности в этом никакой — легче написать кастом средство по управлению правами пользователй, моделью згрузки и т.д. а перформенс каунтеры администратор сможет посмотреть со своей консоли... так что про удобство админов я честно говоря заморачиваюсь мало лишь бы можно было определить что сервисы доступны и работают, и нагрузку системы.

S>Дальше. Сервисы. Что собираетесь использовать? Веб-сервисы в чистом виде или WCF?
в прототипе написаны WCF сервисы которые котрые хостятся на WS.
В любом случае вам потребуется загружать в сервис данные с сервера, применять изменения, переданные клиентом, и отсылать даные обратно. Самостоятельно отслеживать изменения при сериализации EF не умеет.
это правда и весьма грустно. EF позволяет делать изменения простых типов, т.е. не навигационных полей, но вот если менять ссылки... по этому в качестве решения выбран подход когда наружные сервисы имеют интерфейс для изменения данных: например, назначить тоту-то в качестве ссылки вот это ... и передаем в качестве прарамтров обе сущности ... можно делать изменения в сущностях передавать их сервисам а там парсить — но тогда гимор становиться несоизмериьмо больше — хотя в инете находил примеры таких решений там использоввался рефекшен... но честно — зачем использовать EF вообще если придется так изголяться для апдейта... сейчас рассматриваю еще одну альтернативу DataServices — в некоторых случаях по моему может быть отличным решением... но пока мало повозился.

Одно это уже удерживает меня от совместного использования EF и аппсервера.
да, соглашуусь с тем что выполнение изменений вне контекста — это не то что гимор, а самая самая настоящая жжжжжжж....... делает использование EF в nTire приложениях весьма сомнитеьным счастьем кто не согласен — аргументы — буду рад поменять свое мнение.

S>Безопасность. Как у вас будет проходить авторизация?
сейчас аторизация на ASp.Net, но сейчас исследую CardSpace. и скорее всего будет следующий сценарий:
клиент регистрируется, получает сертификат, при логине UI позволяет выбраеть сертификат, пользователь выбирает сертификат и отсылает его, система получает сертификат проверяет и таким образом аутентифицирует пользователя и назначает ему роль в системе. а дальше все права пляшут от роли.
пока это работает для пользователя, но пока работа сервтификатов не прикручена для WCF сервисов — дело времени. я кстати, пока не знаю как правильно организовать рботу сервисов(они без состояния -это обязательно) с тем чтобы не аутентифицировтаь пользователя каждый раз при вызове метода сервиса... а однажды аутентифицировавшись использовать какой-то токен в последующих вызовах, так что если будут подсказки — буду рад помощи...

Где будет разграничиваться разрешения пользователя? На сервисах, или на СУБД?
на сервисах: права пользователя будут соответсвующими его роли,
Как будет защищаться соединение с СУБД? ясно что сервер внутри домена, права на логин, а дальше — предложения, советы ?

Как вы снизите риск от утечки строки подключения к СУБД? // Это только начало
подключение к базе осуществляться сервисом под системной учетной записью NetworkService, а DB инстанс и база — это единственное, что остается в строке подключения — шифруется стандартным механизмом шифровки web.config файла. получить web.config от iis будет тяжеловато, но если преположить что файл был получен другим путем, то строка подключения защищается настройкой конфигурационного провайдера: RSAProtectedConfigurationProvider or DPAPIProtectedConfigurationProvider и шифруется утилитой aspnet_regiis.
если что не так — советы, рекомендации ...


S>2) CRUD и прослойка из представлений на уровне СУБД.

S>Во-первых, ребят, постарайтесь изучить что умеет ваша СУБД. Потому как оказывается, что добрая половина велосипедов — своя авторизация, протоколы, псевдотранзакции, аудит, репликация, репорты, ETL, полнотекстовый поиск по документам — всё это уже есть. И если даже и делать обёртки, то выносить их в отдельное приложение-шлюз смысла я не вижу.
меньше всего бы хотелось изобретать свой велосипед — и как показывает моя практика это происходит из-за недостатка знаний технологии... технологий много, и разные, по этому и понятно что такое случается — лично я сячески пытаюсь по мере своих сил восполнять это пробел — не везде и во всем это удается — на я работаю над этим
относительно аудита — мне было бы весьма интересно и полезно узнать о стандартных механизмах аудита — например пользователь такой-то создал новую запись, пользователь такой-то изменил значение такого-то поля на значение такое-то... прользователь такой-то удалил запись, при этом запись не удалилась была помечена как удаленная, т.е. поменялся статус на удаленную... — было бы весьма полезно узнать о стандартнтых средствах поддержки такой работы, а то сейчас это мои проблемы — а как бы хотелось бы это переложить на СУБД. — подскажите как?

S>Дальше. Как уже говорил, у вас будет куча приложений, у которых общими будут только обрабатываемые данные, да и то — потребуется разные представления одних и тех же данных. Это всё умеет СУБД. Как реализовать такую прослолйку дело десятое. Я предпочитаю хранимые процедуры по следующим причинам — output parameters, no sql injection и имперсонация. Про последнее: допустим, для создания пользователя СУБД вам нужны права администратора. Вы не даёте их всем пользователям
— не не даю это точно - даже под дулом пистолета сильно бы задумался давать или нет — а без него и думать не буду... срокой подключения с sa правами я не страдаю
, а создаёте хранимку, прописываете EXECUTE AS (для SQL Server), даёте доступ к этой хранимке какой-то группе пользователей — всё работает. В чём фишка: Даже если утечёт строка подключения, то пользователь не сможет натворить ничего такого, что он не мог бы сделать через клиентское приложение. согласен это еще один уровень защиты... впринципе я пользуюсь ролевой секрити на стороне кода в бизнес логике... если пользователь получит доступ к базе то в таком случае он действительно сможет там создать пользователя используя хранимку, то тогда у меня другой вопрос ... а что помешает ему просто в таблицу вбить данные о новом пользователе минуя хранимку... если у него и так есть уже доступ к базе ? тем более что создание простого пользователя это еще не есть упех — ему необходимо назначить роль, в соотвествии с приложением, подписать на модули ... все он это сможет сделать при наличии знаний как функционирует приложение и при наличии свободного доступа к базе данных... так что это еще вопрос давать ему одну хранимку на создание польщователя или вынести это в бизнес логику а базу пусть админы хранят... честно говоря у меня большие сомнения что пользователь сможет попась в базу, но с другой сторооны для того и замки на дверях чтобы усложнить этот процесс.. но честно — это сомнительное преимущество — нужно обдумать ....

В результате, вы без боязни можете использовать репорты, EXCEL, что угодно в качестве клиента — перимет безопасности у вас ограничен SQL сервером. Да, имперсонацию можно организовать и ч/з представления, но это сложнее. не буду утверждать но по моему excel может использовать WS в качестве источников данных — лично не пользоватлся утверждать не буду — но если это так то это решает проблему.

S>Главный недостаток: СУБД у вас перестаёт быть just storage — она становится тру сервером. Если вы на это не готовы — то сорри. Пока хватит
это меньше всего чего бы я хотел — очень хочется использовать базу как ханилище и только... а все остальное пусть будет самостоятельным — т.е. бизнес логика отдельно, отчетность отдельно и т.д. а все пихать в сервер мне не нравиться ... при наличии отдельных сервисов я могу поставить дополнительную коробку и на какое-то время забыть о производительности а в случае если все в одном то можно забыть про масштабирование вширь, а масштабирование вглубь ограничено... практика гугла показывает что подход с отдельной дополниетельной коробкой более правильный ... гавное чтобы сервисы были без состояний... работая с железаяным кластером я вынес для себя однин подход: сервисы без состояний и сетевая балансировка — это решение имеет не плохой запас прочности.

S>Повторюсь. Я побоюсь использовать сырую неотстоявшуюся технологию
согласен — а когда она остоится ? это слодный вопрос, в моей практике было такое:нет только вышел — я пока его крутил для себя, на одном из совещаний "что делать и как быть" я предложил написать компонент с использованием COM и один старый дяденька скала: — а вы не боитесь все же технология новая... в результате было таки написано приложение с COM/DCOM но все же ... что такое устоявлеестя ил и нет... в другом телекоме я от админа услышал следующее утверждение: мы не пререходим на новую OS пока к ней не выйдет 4SP, я давно уже не работаю в том телекоме, и незнаю перешли они на XP или нет — но 4SP к нему так и нет .... я для себя это воспринимаю как нежелание обучаться новому ... с одной стороны правильно не переходить же каждый день на новую винду если мелкомягкие ее будут выпускать всему должно быть целесообразно
, с которой я ещё не поимел опыта,
любая даже самая длинная дорого начинается с первого шага... вы не имели опыта и я не имел вот мои первые шаги в этом направлении... по роду своей деятельности я консультант — и обязан знать и уметь пользоваться новыми технологиями ... особенно знать что они могут и могут ли вообще помочь сократить стоимость разраотки ... вот тринеруюсь на кроликах
как core foundation для нового проекта. Тем более для такого масштабного.
практически все проекты в которых я участвовал или очень масштабны или не мальенькие — мне так интересней... так что по большому счету выбирать не приходиться... а учиться когда-то нужно... технологические риски в этом проекте учтены — в смысле заложены.
Как одну из технологий на клиенте, которая не требует изменения архитектуры сервера — почему бы и нет.

S>Один из раздражающих моментов в EF — стремление по любому поводу пинать сервер. Загрузка согласованного набора данных — щитай вообще недостижимая мечта. Если будет время, потрэйстье SQL запросы, которые сыпятся на сервер, особенно запросы с eager loading.
да, нуно будет как-нить заняться ... но честно, пока у меня просто херова туча других забот.

S>Как-то больще исповедую пакетную обработку аля пнул сервер — получил согласованный набор данных — отсоединился, поработал — пнул сервер.... Нагрузка очень хорошо сглаживается и распределяется по клиентам.
соглашусь с таким подходом. я ктсати намерн использовать Velocity в качестве распределенного кеша — посмотрим как это поможет жить искренне надеюсь что многие запросы обойдут сервер стороной

S>Щастья вам
спасибо за проявленный интерес и советы. если что буду рад и ругим. а Вам так же удачи

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

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

S>>2) CRUD и прослойка из представлений на уровне СУБД.

S>>Дальше. Как уже говорил, у вас будет куча приложений, у которых общими будут только обрабатываемые данные, да и то — потребуется разные представления одних и тех же данных. Это всё умеет СУБД. Как реализовать такую прослолйку дело десятое. Я предпочитаю хранимые процедуры по следующим причинам — output parameters, no sql injection и имперсонация. Про последнее: допустим, для создания пользователя СУБД вам нужны права администратора. Вы не даёте их всем пользователям, а создаёте хранимку, прописываете EXECUTE AS (для SQL Server), даёте доступ к этой хранимке какой-то группе пользователей — всё работает. В чём фишка: Даже если утечёт строка подключения, то пользователь не сможет натворить ничего такого, что он не мог бы сделать через клиентское приложение. В результате, вы без боязни можете использовать репорты, EXCEL, что угодно в качестве клиента — перимет безопасности у вас ограничен SQL сервером.

G>Еще раз. Зачем хранимые процедуры для CRUD? Я работал в проекте где для каждой сущности писались 4 CRUD процедуры. На 20 сущностях вносить исправления было очень трудоемкой задачей. Кроме того изменения БД плохо поддаются контролю версий.

G>Если использовать ХП для выборок, то оптимизировать запросы станет гораздо сложнее. В большенстве случаев для разных сценариев придется писать разные хранимки.

S>>Да, имперсонацию можно организовать и ч/з представления, но это сложнее.
G>Зачем имперсонация для CRUD?
согласен — зачем имперсонализация для круд? как тогда понять кто в ответе — с кого потом в случае чего кровь пить?, а если серьезно, то отслеживание того, кто и что сделал в системе это весьма критично если замешаны жизни или деньги — в моем случае деньги

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

S>Ничего, что я сразу на 2 поста тов. gandjustas отвечу?

G>>Еще раз. Зачем хранимые процедуры для CRUD? Я работал в проекте где для каждой сущности писались 4 CRUD процедуры. На 20 сущностях вносить исправления было очень трудоемкой задачей. Кроме того изменения БД плохо поддаются контролю версий.

S>Сразу — говорю исключительно про SQL Server. Опыта длительной эксплуатации других СУБД нет — исключительно "поиграться".

S>Видно вы меня не так поняли — я не утверждял, что CRUD должно быть и должно быть через хранимые процедуры.
S>Я писал, что если СУБД для вас не just storage, если одни и те же данные используются несколькими приложениями, то рано или поздно вам придётся заводить отдельные прослойки, представления — что хотите — для каждого приложения. Как это делать уже дело десятое. Я исповедую хранимые процедуры, по целому ряду причин:
инкапсуляции SQL кода
нет SQL кода — нечего инкапсулироать — не так ли ? сомнительный выиграш.
, лёгкость администрирования
не факт — как наличие процедур помогает администрировать ? а вот как усложняемт могу сказать — отследить версии всех процедур если обектов много их совместимость не то чтобы сложная работа — но работа... наличие процедуры это наличие прав доступа к ней.
, возможность разграничения доступа
на стороне кода разграничение прав на основании ролей тоде работает не плохо.
, возможность сложных алгоритмов
ну вот по поводу сложных алгоритмов ... возможно я не понял, но сложные алгоритмы, по моему, как раз таки удобней делать на стороне кода, как раз для этого была добавлена поддержка менеджет кода на стороне SQL или ... ?


S>Как success story: переход на SQL Server 2008 занял 2 дня с момента получения диска. Причём это не было просто восстановление из бэкапа, добавилось хранение файлов ч/з FILESTREAM (раньше файлы хранились напрямую на жёстком, доступ был ч/з CLR stored procedures), и включен полнотекстовый поиск по этим файлам (раньше коннектились ч/з ODBC к IndexingServices, который индексировал файлы на диске). Изменилось то ли 5, то ли 6 мест на сервере. Клиент ничего не почуствовал.

S>Про редактирование изменений. Умейте готовить SQL Server Management Studio умеет контроль версий (как минимум TFS и Source Safe, ещё был бодяжный плогин к тортойзу).

S>Есть бесподобнейшая приблуда к VS Team Suite 2008 (точнее уже часть студии) — VSTS Database Edition. Недавно GDR вышел (что-то типа R2 для виндов). Оно как раз умеет создавать проект из реальной БД/БД по проекту и умеет их синхронизировать. Самое оно для массивного редактирования кода. Плюс все приятные мелочи студии. И начиная с GDR оно вроде бы умеет работать не только с SQL Server, но и с другими СУБД.

S>Да! можно спросить, вы сразу 20 сущностей редактировали?

G>>Если использовать ХП для выборок, то оптимизировать запросы станет гораздо сложнее. В большенстве случаев для разных сценариев придется писать разные хранимки.

S>Да что вы говорите Ну дык никто не мешает создать view и дать доступ к нему. Как минус — чуть сложнее реализовать нетривиальную фигню типа чтения файлов, приходится отслеживать возможность SQL-инъекций, ну и крайне муторно пытаться оптимизировать узкие места, когда завтра какой-нибудь [censored] поломает твой запрос потому что некрасиво.

G>>Зачем имперсонация для CRUD?

S>Ну сценарий я тебе приводил: приложения имеют доступ только к хранимкам, права, необходимые каждому приложению раздаются ролям, пользователи приложений включаются в эти роли. Прямого доступа к таблицам нет. На этом этапе можно вместо хранимок использовать представления.
S>Сценарий 2: часть хранимок особо критична (допустим, у них внутри создаётся SQL код и возможна инъекция) — эти хранимки работают с пониженными правами.
S>Сценарий 3: хранимка работает с удалённым сервером (Linked Server в терминах MS SQL). Она запускается от имени служебного пользователя, имеющего доступ к этому серверу. Больше никак к этому серверу не подрубиться.
S>На самом деле эта ситуация не так уж и часто встречается, тем не менее ещё +1 в пользу хранимых процедур.

S>>>3) EF
S>>>Один из раздражающих моментов в EF — стремление по любому поводу пинать сервер. Загрузка согласованного набора данных — щитай вообще недостижимая мечта. Если будет время, потрэйстье SQL запросы, которые сыпятся на сервер, особенно запросы с eager loading.
G>>Я смотрел запросы. Очень прилично получается, особенно если не писать выборки в виде EntitySet.Include("Все") и не загружать каждую ссылку вручную.

S>Да. Согласен. Сценарий: у вас список чего-то, вы по переходу показываете детали. У вас всего 2 варианта: либо дёргаете данные по мере необходимости, либо загружате их скопом заранее. Во втором случае как раз и получается кошмарные запросы с кучей жойнов и вложенных запросов. В первом — вы получаете рассогласованные во времени наборы данных. Как пошлый пример: В мегагитлерредакторе каждая страничка подгружается при прокрутке. В результате первая страница договора отражает ваши изменения, вторая — внесённые главбухом, который ваши изменения не читал, третья удалена ещё кем-то, кто видит первые две страницы ДО изменений. Попа
S>Кроме того, постоянные запросы при выделении нового элемента в списке очень сильно сношают сеть и сервер. Не все оптимизации полезны

S>>>Как-то больще исповедую пакетную обработку аля пнул сервер — получил согласованный набор данных — отсоединился, поработал — пнул сервер....
G>>Нагрузка очень хорошо сглаживается и распределяется по клиентам.
G>>ADO.NET Data Servces вам в помощь.

S>Ггг. Вы их щупали/читали/пользовали? Astoria — это эмуляция EAV хранилища через вебсервисы поверх EF поверх SQL Server'a. Всё оптимизируем ?)))
я только начал с ними разбираться — я так понимаю, что есть огрмные против их использования ? хотелось бы услышать мнение по этому поводу...

S>Под нагрузкой имелось в виду другое — вся логика, относящаяся к работе клиента, живёт на клиенте. Он работает с данными, которые нужны пользователю. Эти данные заблаговременно загружены, клиент отсоединён от серера до того момента, пока не требуется сохранить изменения или попросить сделать что-то эзотеричное, допустим тот же полнотекстовый поиск, к серверу не подсоединяется.
S>Вот такой вот сценарий на EF реализовать тяжелоато будет.

S>Ещё вопросы ?

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

S>>Да что вы говорите Ну дык никто не мешает создать view и дать доступ к нему. Как минус — чуть сложнее реализовать нетривиальную фигню типа чтения файлов, приходится отслеживать возможность SQL-инъекций, ну и крайне муторно пытаться оптимизировать узкие места, когда завтра какой-нибудь [censored] поломает твой запрос потому что некрасиво.
G>Во-первых SQL-иньекции надо отслеживать на уровне приложения, а не на уровне базы.
думаю это правильно, если мы защищаемся от пользоателй системы, то инжекшин нужно отлавливать на стороне клиента, а если мы защищаемся от инсайдеров, то скорее всего механизм проверки инжекшин здесь уже не подойдет — здесь скорее административные меры должны стать барьером.

G>>>Зачем имперсонация для CRUD?

S>>Ну сценарий я тебе приводил: приложения имеют доступ только к хранимкам, права, необходимые каждому приложению раздаются ролям, пользователи приложений включаются в эти роли. Прямого доступа к таблицам нет. На этом этапе можно вместо хранимок использовать представления.
G>Это понятно.
согласен — это довод.


S>>Как пошлый пример: В мегагитлерредакторе каждая страничка подгружается при прокрутке. В результате первая страница договора отражает ваши изменения, вторая — внесённые главбухом, который ваши изменения не читал, третья удалена ещё кем-то, кто видит первые две страницы ДО изменений. Попа
G>Это всегда попа независимо от технологии доступа к данным.
ну в конечном итоге это зависит от задачи и ее кретичности к актульности данных... в всегда можно залочить на изменения если это критично...

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


G>>Во-первых SQL-иньекции надо отслеживать на уровне приложения, а не на уровне базы.
S>Если доступ только через хранимые процедуры — то нет //сорри, уже стебаюсь
поясните мне деревянному о каком инжекшине идет речь? пользоатель на сторое клиента вызывает процедуру, в процедуру передает сущности над которыми нужно выполнить действия. сервис получает сушности и выполняет заложенный алгоритм, алгоритм работает с EF API, в результате на основе этого EF генерирует SQL — все это уже на стороне сервера и врамках кода. в результате где место инжекшина ? потом результат в виде DTO передается на клиента... как пользователь может внедрить свой SQL код ? или я не понимаю о чем речь ?



S>>>Сценарий 3: хранимка работает с удалённым сервером (Linked Server в терминах MS SQL). Она запускается от имени служебного пользователя, имеющего доступ к этому серверу. Больше никак к этому серверу не подрубиться.
S>>>На самом деле эта ситуация не так уж и часто встречается, тем не менее ещё +1 в пользу хранимых процедур.
G>>sp_addlinkedsrvlogin + ограниячения на Linked сервере не пробовали?
а почему просто не написать сервис и не дать бизнес логики получать данные с него и не нудно будет ничего изобретать с правами... по моему сервис в качестве архитектуры не плохая вещь всегдам можно расширить при необходимости, повторность исрользовани прозрачность расположения источника данных и т.д. возможно я не вкурсе особенностей той задачи которую вам приходилось рещать, но сервис мне кажется весьма приемлемым решением.

Ёк, шо ж так много-то??? Давайте по порядку.

2 gandjustas:
Мы точно на одном и том же языке разговариваем? Давайте закончим, а то у нас холивар какой-то получается Я в принципе сказал всё что хотел в предыдущих постах и не хочу повторяться. Если коротко:
1) Обёртка к СУБД должан быть, если вы не используете СУБД исключительно для хранения сериализованных объектов.
2) Как делать эту обёртку ваш выбор. Я стараюсь разруливать эти вопросы непосредственно на уровне СУБД, преимущественно посредством хранимых процедур. Я не утверждаю, что это единственно верный путь, но для меня он обладает кучей преимуществ.
3) Я не думаю, что стоит использовать EF кроме как в качестве ещё одного способа поработать с данными. Почему — уже сказано.
4) Это относится и к ADO.NET DataServices и к SyncServices.
Про последние можно похоливарить ещё, но даже сама МС позиционирует асторию как легковесную обёртку для веб-приложений, в которых не требуется хранения защищённых данных. Я не вижу смысла использовать её как-либо еще.

2 Аноним
Вы же сами говорите, что должна быть декомпозиция на отдельные модели, но EF её умеет. Что нужны сервисы, но EF их не умеет. Что ж за преимущества такие у EF, кто ёжики упорно продолжают жрать кактус?)))

Скажите, а почему нельзя использовать старые добрые датасеты? Они и сериализуются, и в хмл-е передаются, и изменения держат, и типизация есть, и LINQ, и sync services их умеют (это к вопросу об Occansionally Connected Applications), и всякие биндинги работают (есть баг с биндингом в WPF, уже год прошу починить). Чаго не хватаит-та? Да, ReportViewer их тоже могёт. Единственное, куда они не совсем подходят — для stateless веб-страничек, но там, имхо, уже проще LINQ for SQL использовать — инициализация контекстов EF ещё дороже датасетов выйдет.

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

Если подходить с позиций параноика, то у вас будет дыра в защите: дыра в хосте сервисов — запуск на нём произвольного кода от имени network service — прямой доступ к СУБД. Про доступ от администраторов домена к серверу вообще молчу. Из-за этого одно время на полном серьёзе не хотели включать сервера в домен. Паранойа!

Ну и не используйте без защиты на уровне СУБД windows authentification или прямую sql авторизацию для пользователей. Им ничего не помешает подконнектиться напрямую и нагадить.

Как офтоп. Был реальный случай со сторонним приложением. Строка подсоединения хранилась в отчёте (хардкод программистов) и в датасете (записана визардом). Были права на чтение ко всем табличкам (типа защитили) Информацию аккуратно слили. Хорошо, что я к той софтине не имел никакого отношения

В принципе, своё имхо уже высказал, по веб-сервисам и wcf н ничего не могу подсказать, уж извините. Радует, что проблемы осознаны и приняты во внимание. Дерзайте

2 Monkey-Bee:
Уже отвечал — импресонация использовалась всего пару раз и глубоко унутри СУБД. Там была хранимка, которая дёргала другую, которая обращалась к удалённому источнику. Задача была запустить вторую хранимку с правами другого пользователя, не поломав owner chain. Всё. Что вам так не понравилась эта имперсонация-то?

Про EAV-в ответе gandjustas.

// извините, что давлю опытом
Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.

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

Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.

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

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

S>Скажите, а почему нельзя использовать старые добрые датасеты? Они и сериализуются, и в хмл-е передаются, и изменения держат, и типизация есть, и LINQ, и sync services их умеют (это к вопросу об Occansionally Connected Applications), и всякие биндинги работают (есть баг с биндингом в WPF, уже год прошу починить). Чаго не хватаит-та?
Кто-то говорил про накладные расходы Data Services?

S>Как офтоп. Был реальный случай со сторонним приложением. Строка подсоединения хранилась в отчёте (хардкод программистов) и в датасете (записана визардом). Были права на чтение ко всем табличкам (типа защитили) Информацию аккуратно слили. Хорошо, что я к той софтине не имел никакого отношения
Доступ к базе был из внешней сети?

S>Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
S>Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.
Такое как раз решается на уровне сервера приложений, а доступ к БД открывается только серверу.

S>После этого предложения типа "написать сервисы и пускай пользователи сами берут что им надо"... неа
Как раз сервисы с политиками безопасноти внутри них в данном случае — очень хорошее врешение, а наваливать на БД эти задачи — перебор.

Вы конечно можете использовать MS SQL Server как сервер приложений, вам придется писать много кода на TSQL, что заметно удорожает поддержку и лишает вас возможности распределения нагрузки.

S>Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.

S>Я уже подустал вдалбливать элементарщину — чем проще система и чем меньше у неё периметр безопасности — тем она защищённей. В варианте с сервисами вы должны защищать сервер СУБД, канал до хоста сервисов (по сути всю локальную сеть) и сам хост.
Это решается очень просто.

S>Вы должны отслеживать бизнес-логику на сервисе и убеждаться что она не открывает непредвиденный доступ к исходным данным.
Это проверить граздо проще, чем в SQL.

S>При этом товарищи, ответственные за сервисы будут орать "Уйди, ссуко! Так надо!", ибо так действительно надо и они вовек не поймут какого от них требуют безопасного кода, который мешает медитировать на священные потребности бизнеса, отныне и вовеки — трындец!
Вы действительно работаете с такими людьми? Я в основном встречал адеквактных разработчиков, которые понимали в безопасности и знали зачем она нужна.


Вообще не стоит свой негативный опыт выставлять как архитектурные проблемы.

S>>Скажите, а почему нельзя использовать старые добрые датасеты? Они и сериализуются, и в хмл-е передаются, и изменения держат, и типизация есть, и LINQ, и sync services их умеют (это к вопросу об Occansionally Connected Applications), и всякие биндинги работают (есть баг с биндингом в WPF, уже год прошу починить). Чаго не хватаит-та?
G>Кто-то говорил про накладные расходы Data Services?

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

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

S>>Как офтоп. Был реальный случай со сторонним приложением. Строка подсоединения хранилась в отчёте (хардкод программистов) и в датасете (записана визардом). Были права на чтение ко всем табличкам (типа защитили) Информацию аккуратно слили. Хорошо, что я к той софтине не имел никакого отношения
G>Доступ к базе был из внешней сети?
Доступ к базе был из локальной сети. Хватило

S>>Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
S>>Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.
G>Такое как раз решается на уровне сервера приложений, а доступ к БД открывается только серверу.

Ребят, это, ёпть, сферический конь в вакууме. У вас сервер приложений умеет всё, что умеет СУБД? И даже тру транзакции? И даже объясняет другим системам, что он это может? И вы интегрировались с этими системами? И делали нечто похожее на тру синхронную репликацию и массивную передачу данных? И всё это работало через вебсервисы? Как я вам завидую...

S>>После этого предложения типа "написать сервисы и пускай пользователи сами берут что им надо"... неа
G>Как раз сервисы с политиками безопасноти внутри них в данном случае — очень хорошее врешение, а наваливать на БД эти задачи — перебор.

Хорошо. Простенький сценарий: Все пользователи в группе A и во всех группах, вложенных в группу A имеют право обновлять часть полей сущности B, находящейся в одной из подкатегорий категории C, но только если это обновление удовлетворяет нескольким сиюминутным требованиям, затрагивающим чуть ли не половину всех данных. Для простоты допустим, что пользователь должен иметь право на чтение сущности B2 (права раздаются аналогично — через группы и категории).

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

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

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

Если вы используете первый подход, то сгенеренные запросы можно завернуть в представления/хранимки на субд. Во вторм подходе вам придётся выгребать 5-6 разнородных структур данных, которые к тому же могут менять свою структуру от версии к версии и искать их пересечение на промежуточном уровне. Падение производительности сами можете представить.

G>Вы конечно можете использовать MS SQL Server как сервер приложений, вам придется писать много кода на TSQL, что заметно удорожает поддержку и лишает вас возможности распределения нагрузки.

Вам по-любому придётся писать часть кода на t-sql, прямо или косвенно. Если этот код будет скрыт в набор хранимых процедур или представлений, у вас будут хотя бы понимание основ того, как работает ваша система и что можно соптимайзить/что нельзя, где закрыть дыры, где не закрывать и т.п. Про нагрузку, имхо — самый большой миф. Затраты на массовую обработку однотипных запросов обычно куда меньше, чем затраты на передачу, преобразование больших объёмов данных и распределённые блокировки.

S>>Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.

S>>Я уже подустал вдалбливать элементарщину — чем проще система и чем меньше у неё периметр безопасности — тем она защищённей. В варианте с сервисами вы должны защищать сервер СУБД, канал до хоста сервисов (по сути всю локальную сеть) и сам хост.
G>Это решается очень просто.

Предложите ваш проект для интрасети. Напомню, в исходной постановке вопроса всё равно требуется прямой доступ к СУБД.

S>>Вы должны отслеживать бизнес-логику на сервисе и убеждаться что она не открывает непредвиденный доступ к исходным данным.
G>Это проверить граздо проще, чем в SQL.
Тааа? Когда у вас мегалогика бизнесс-процесса на полкило текста? Вы доверяете всей БЛ или у вас некие общие методы типа "проверь, могу ли я изменить себя", которые надо не забывать дёргать? Лукавите, ИМХО

S>>При этом товарищи, ответственные за сервисы будут орать "Уйди, ссуко! Так надо!", ибо так действительно надо и они вовек не поймут какого от них требуют безопасного кода, который мешает медитировать на священные потребности бизнеса, отныне и вовеки — трындец!
G>Вы действительно работаете с такими людьми? Я в основном встречал адеквактных разработчиков, которые понимали в безопасности и знали зачем она нужна.

О тааа, что такое безопасность своих данных они понимали. Что если я им дам права на запись, их код сможет поломать чужую работу... не объяснить никогда


G>Вообще не стоит свой негативный опыт выставлять как архитектурные проблемы.
Не надо. Этто очень позитивный опыт Очень быстро учишься видеть проблемы до того, как они придут. Или не учишься.

Плиз, читайте внимательнее. Я по сути пишу третий раз одно и то же. Давайте действительно закончим.

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

S>>>Скажите, а почему нельзя использовать старые добрые датасеты? Они и сериализуются, и в хмл-е передаются, и изменения держат, и типизация есть, и LINQ, и sync services их умеют (это к вопросу об Occansionally Connected Applications), и всякие биндинги работают (есть баг с биндингом в WPF, уже год прошу починить). Чаго не хватаит-та?
G>>Кто-то говорил про накладные расходы Data Services?

S>Ну здесь накладные расходы будут как минимум сопоставимы. Ну и писалось уже, что датасеты хороши когда надо кэшить данные. Скажите честно, вы читаете только первые предложения из каждого абзаца?
Я все читаю, но датасеты всегда полностью передаются по сети (вместе со схемой и пр.). В Data Services вы передаете и получаете только необходимое. Причем схема данных не передается.

S>Мы по ходу говорим реально про разные вещи. Вы — про систему, где реально оторвать приложения от СУБД и заставить их пользоваться _только_ вебсервисами и только через авторизацию. Причём пишет сервисы только ограниченный круг высококвалифицированнных разработчиков.
S>Я — про реалворлд систему, когда у нас есть жуткая среда, где пользователи — все от локальных секретарш и пользователей сайта до недоадминистраторов и сторонних разработчиков. И все хотят странного
По вашему в реалворд системах каждый кто захочет лезет в базу? Это скорее исключение.
Опять-таки ваш опыт в данном случае очень субъективнен.

S>>>Как офтоп. Был реальный случай со сторонним приложением. Строка подсоединения хранилась в отчёте (хардкод программистов) и в датасете (записана визардом). Были права на чтение ко всем табличкам (типа защитили) Информацию аккуратно слили. Хорошо, что я к той софтине не имел никакого отношения
G>>Доступ к базе был из внешней сети?
S>Доступ к базе был из локальной сети. Хватило
Даже в локальной сети можно ограничить доступ в базу.
Это должно быть проблемой админа, а не программистов.

S>>>Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
S>>>Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.
G>>Такое как раз решается на уровне сервера приложений, а доступ к БД открывается только серверу.

S>Ребят, это, ёпть, сферический конь в вакууме. У вас сервер приложений умеет всё, что умеет СУБД?
Нет, а зачем? Он умеет столько сколько достаточно для решения бизнес задач.

S>И даже тру транзакции?
Что такое тру транзакции? Если надо обрабатывать длительную бизнес-транзакцию, то это делается средствами, отличными от транзакций БД.

S>И даже объясняет другим системам, что он это может?
Да, веб-сервисы такое умеют

S>И вы интегрировались с этими системами?
Да

S>И делали нечто похожее на тру синхронную репликацию и массивную передачу данных?
Что значит "нечто похожее на тру синхронную репликацию" ?
Массивную передачу данных делали, открывать доступ к базе кому-попало не приходилось.

S>И всё это работало через вебсервисы? Как я вам завидую...
И отлично работало

S>>>После этого предложения типа "написать сервисы и пускай пользователи сами берут что им надо"... неа
G>>Как раз сервисы с политиками безопасноти внутри них в данном случае — очень хорошее врешение, а наваливать на БД эти задачи — перебор.

S>Хорошо. Простенький сценарий: Все пользователи в группе A и во всех группах, вложенных в группу A имеют право обновлять часть полей сущности B, находящейся в одной из подкатегорий категории C, но только если это обновление удовлетворяет нескольким сиюминутным требованиям, затрагивающим чуть ли не половину всех данных. Для простоты допустим, что пользователь должен иметь право на чтение сущности B2 (права раздаются аналогично — через группы и категории).
S>Это правило является абсолютным и должно выполняться без исключенй вне зависимости от того, каким способом был получен доступ к системе (репорты, веб-клиент или офис — неважно).
S>При этом пользователь очень активно работает с сущностями, на которые накладываются ограничения.
S>По сути тут всего два метода реализации — либо генерить сложные запросы, которые будут отличаться всего-то айдишником изменяемой сущности, либо выгребать тонны данных на промежуточный слой и разруливать алгоритм уже там.
S>Если вы используете первый подход, то сгенеренные запросы можно завернуть в представления/хранимки на субд. Во вторм подходе вам придётся выгребать 5-6 разнородных структур данных, которые к тому же могут менять свою структуру от версии к версии и искать их пересечение на промежуточном уровне. Падение производительности сами можете представить.
Задачами авторизации пусть занимается сервис, а проверки бизнес-правил можно искапсулировать в хранимаках или триггерах. Повышение произодительности можете себе представить.
Хотя я обычно раздаю права не на основе сущностей, а на основе действий, выполняемых в системе.


S>>>Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.

S>>>Я уже подустал вдалбливать элементарщину — чем проще система и чем меньше у неё периметр безопасности — тем она защищённей. В варианте с сервисами вы должны защищать сервер СУБД, канал до хоста сервисов (по сути всю локальную сеть) и сам хост.
G>>Это решается очень просто.

S>Предложите ваш проект для интрасети. Напомню, в исходной постановке вопроса всё равно требуется прямой доступ к СУБД.
Кому требуется, клиентским приложениям? Тогда у вас 100% жопа с безопасностью.
В 99.99% случаев требуется прослойка между БД и клиентом, хотябы такая сверхтонкая как Data Services.

S>>>Вы должны отслеживать бизнес-логику на сервисе и убеждаться что она не открывает непредвиденный доступ к исходным данным.
G>>Это проверить граздо проще, чем в SQL.
S>Тааа? Когда у вас мегалогика бизнесс-процесса на полкило текста?
У меня такого нет. Я обычно пишу небольшие классы и методы.

S>Вы доверяете всей БЛ или у вас некие общие методы типа "проверь, могу ли я изменить себя", которые надо не забывать дёргать?
Для этого есть тесты.

S>Лукавите, ИМХО
Нет.


S>>>При этом товарищи, ответственные за сервисы будут орать "Уйди, ссуко! Так надо!", ибо так действительно надо и они вовек не поймут какого от них требуют безопасного кода, который мешает медитировать на священные потребности бизнеса, отныне и вовеки — трындец!
G>>Вы действительно работаете с такими людьми? Я в основном встречал адеквактных разработчиков, которые понимали в безопасности и знали зачем она нужна.
S>О тааа, что такое безопасность своих данных они понимали. Что если я им дам права на запись, их код сможет поломать чужую работу... не объяснить никогда
Как все плохо...

G>>Вообще не стоит свой негативный опыт выставлять как архитектурные проблемы.
S>Не надо. Этто очень позитивный опыт Очень быстро учишься видеть проблемы до того, как они придут. Или не учишься.
Исправляя проблемы, которых еще нет вы создаете огромный оверхед.
Если бы вы поработали над архитектурой вместе с теми, чей код сможет поломать чужую работу (с), то большенство ваших проблем и не вознило бы никогда.

S>Плиз, читайте внимательнее. Я по сути пишу третий раз одно и то же. Давайте действительно закончим.
По сути вы свои заблуждения выдаете за истину.

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

S>Ёк, шо ж так много-то??? Давайте по порядку.
да я и сам ужаснулся в дальнейшем буду лаконичен.

S>Ну и не используйте без защиты на уровне СУБД windows authentification или прямую sql авторизацию для пользователей. Им ничего не помешает подконнектиться напрямую и нагадить.
как ? ведь сиквел не доступен извне ?

S>Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
S>Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.
нет, ну и енвайронмент вы нарисовали — вы часом не в ленгли работали ?, относительно моего опыта в секрюти — как правило это лежало на плечах админов... по этому буду рад совету.

S>Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.
а как бороться с возможностью админов внедрить свой код ? все равно таблицу можно проапдейтить — он, в конце-концов, админ или кто? кроме как административного метода разруливания этим я другого не вижу... у вас есть решение ???

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

экспресивно
а вы не вдалблевайте — про ентропию, стремление к распаду, надежность цепи и окамовские бритвы я это все сам могу рассказывать долими часами... — мне бы полезных советов больше
я, например, так и не полнял почему используя SSL, сервтификат NetworkService и все равно остается дыра в сиквеле — как пользователь не будучи аутентифицирован в системе не имея сетевого доступа к коробке на которой стои сиквел сможет все равно нагадить в нем? хотя это уже получается другая тема

Гмм... ещё раз попробуем

2 gandjustas:

S>>Ну здесь накладные расходы будут как минимум сопоставимы. Ну и писалось уже, что датасеты хороши когда надо кэшить данные. Скажите честно, вы читаете только первые предложения из каждого абзаца?
G>Я все читаю, но датасеты всегда полностью передаются по сети (вместе со схемой и пр.). В Data Services вы передаете и получаете только необходимое. Причем схема данных не передается.

Вы знаете, датасеты умеют передавать pure xml (без схемы) и binary serialisation умеют. Но это наверное неправильные датасеты Но даже со схемой, поскольку вы передаёте данные скопом, а не подтягиваете по мере надобности, общая нагрузка на сеть будет меньше.

G>По вашему в реалворд системах каждый кто захочет лезет в базу? Это скорее исключение.
G>Опять-таки ваш опыт в данном случае очень субъективнен.

Ну вот смотрите. Мы говорим про интерпрайз систему. У неё есть внешние пользователи. Они ломятся к системе через сайт/службы. Есть внутренние пользователи. Они ломятся через десктопные программы/службы. Есть репорты, которые почти всегда ломятся напрямую к СУБД. Есть легаси системы и 1С. 1С работает, допустим через выгрузку по расписанию и Integration Services. Легаси системы стучатся через Linked Server. Заставить всю эту шоблу ломиться через прослойки — не важно что это будет (DCOM, вебсервисы, ваше собственное творение) — практически нереально.
Все требования к защите, тем не менее, никуда не исчезнут. Как можно их реализовать?

S>>Доступ к базе был из локальной сети. Хватило
G>Даже в локальной сети можно ограничить доступ в базу.
G>Это должно быть проблемой админа, а не программистов.
Неа Приложение работало почти целиком через вебсервисы. Строка соединения в датасете вообще не использовалась. Но! для репортов понадобился доступ к БД, поскольку структура отчёта динамически подгонялась под требования пользователя. Они решили пойти через генерацию SQL. Ну и открыли доступ. Как администратор может защитить ИХ сервер (за который ответственность несут разработчики, и они никого не пускает, потому как если делать как положено, половина систем сдыхает)?

S>>>>Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
S>>>>Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.
G>>>Такое как раз решается на уровне сервера приложений, а доступ к БД открывается только серверу.
Епть. Смотрите. У нас есть некоторая система. Несколько клиентов-подсистем. За них вы не отвечаете и сделать с ними ничего не можете. Функционал (БЛ) клиентов не пересекается, но они работают с одними и теми же данными. Для каждого клиента представление данных своё. Надо гарантировать, что весь зоопарк ничего не порушит.
У вас не будет общих сущностей и общих вебсервисов — Ни структура данных, ни функционал не пересекаются. Единственный вариант — использовать некоторые воспомогательные функции проверки и дёргать их при каждом действии.
Если вы забыли дёрнуть проверку — у вас дыра в защите.

Сферический сценарий в вакууме: есть сервис "наградить подчинённого". Принимает ID подчинённого, награждает его если товарищ подчинён авторизовавшемуся товарищу. При очередном изменении логики награждения (выдаём не фарфоровых слоников, а шоколадную медальку) вы забыли дёрнуть эту самую проверку. У вас дырка. Но поскольку это дырка в относительно редко использующемся коде — допустим есть другой сервис "наградить всех подчинённых", который используется куда чаще, она остаётся неотслеженной. У вас безопасность системы будет зависеть от надёжности кода. Поверьте опыту, поломать декларативное описание, так чтобы всё продолжало работать, но появилась дырка куда сложнее. Поскольку это описание гарантированно используется в каждом сценарии шансы на обнаружение дырки тоже растут. Видите, ничего сложного

S>>Ребят, это, ёпть, сферический конь в вакууме. У вас сервер приложений умеет всё, что умеет СУБД?
G>Нет, а зачем? Он умеет столько сколько достаточно для решения бизнес задач.

S>>И даже тру транзакции?
G>Что такое тру транзакции? Если надо обрабатывать длительную бизнес-транзакцию, то это делается средствами, отличными от транзакций БД.

Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.

Естественно заказ должен быть атомарным, либо всё, либо ничего. И, поскольку заказ может быть отправлен внешней системой в ходе другой транзакции, нужна вложенность транзакций. Проводка заказов выливается в запросы к внешним системам — склад, CRM, бухгалтерия и т.п. Они тоже должны быть в транзакциях. Если хоть одно из звеньев цепочки не реализует WS-TX (или реализует своим особым способом) — увы...

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

S>>Предложите ваш проект для интрасети. Напомню, в исходной постановке вопроса всё равно требуется прямой доступ к СУБД.
G>Кому требуется, клиентским приложениям? Тогда у вас 100% жопа с безопасностью.
G>В 99.99% случаев требуется прослойка между БД и клиентом, хотябы такая сверхтонкая как Data Services.

Да-да?
Дальнейший флейм перенёс в священные войны [http://www.rsdn.ru/forum/message/3219133.aspx

Автор: Sinix
Дата: 18.12.08

].

G>По сути вы свои заблуждения выдаете за истину.
Может быть. Разубедите

2 Аноним:
S>>Ну и не используйте без защиты на уровне СУБД windows authentification или прямую sql авторизацию для пользователей. Им ничего не помешает подконнектиться напрямую и нагадить.
А>как ? ведь сиквел не доступен извне?
ниже

А>нет, ну и енвайронмент вы нарисовали — вы часом не в ленгли работали ?, относительно моего опыта в секрюти — как правило это лежало на плечах админов... по этому буду рад совету.
Нет. Самая обычная контора. Примитивынй конфликт интересов

А>а как бороться с возможностью админов внедрить свой код ? все равно таблицу можно проапдейтить — он, в конце-концов, админ или кто? кроме как административного метода разруливания этим я другого не вижу... у вас есть решение ???

А>а вы не вдалблевайте — про ентропию, стремление к распаду, надежность цепи и окамовские бритвы я это все сам могу рассказывать долими часами... — мне бы полезных советов больше
А>я, например, так и не полнял почему используя SSL, сервтификат NetworkService и все равно остается дыра в сиквеле — как пользователь не будучи аутентифицирован в системе не имея сетевого доступа к коробке на которой стои сиквел сможет все равно нагадить в нем? хотя это уже получается другая тема

Уух... ребят. попробуйте повернуть мозги на 180 градусов — на позицию злонамеренного инсайдера или секретарши-студента, которому просто нех делать. И попробуйте найти точки, с которых ваше приложение могут поломать. Эти точки всё равно будут, знаете вы о них или нет. Если их скрывать — ситуация уже точно не улучшиться. В лучшем случае защищать надо только одну машину. В худшем всю сеть — сервис паки на машинах (ау, помните 2003 год и уязвимости с прямым доступом по RPC на 135,139,445 портах? Хорошо их оперативно прикрыли...), шифрование трафика, пароли админов и т.п. Дыра на любом участке убъёт вашу систему напрочь. Детальное обсуждение — в священных войнах [http://www.rsdn.ru/forum/message/3219133.aspx

Автор: Sinix
Дата: 18.12.08

].

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

S>Гмм... ещё раз попробуем

S>2 gandjustas:

S>>>Ну здесь накладные расходы будут как минимум сопоставимы. Ну и писалось уже, что датасеты хороши когда надо кэшить данные. Скажите честно, вы читаете только первые предложения из каждого абзаца?
G>>Я все читаю, но датасеты всегда полностью передаются по сети (вместе со схемой и пр.). В Data Services вы передаете и получаете только необходимое. Причем схема данных не передается.

S>Вы знаете, датасеты умеют передавать pure xml (без схемы) и binary serialisation умеют.
Без передачи схемы от датасетов толку мало. Даже бинарная реариализация не спасает, нельзя передать только необходимую часть датасета.

S>Но это наверное неправильные датасеты Но даже со схемой, поскольку вы передаёте данные скопом, а не подтягиваете по мере надобности, общая нагрузка на сеть будет меньше.
Проведите эксперимент, сколько будет трафика уходить за сеанс работы по сети с датасетами и Data Services.

G>>По вашему в реалворд системах каждый кто захочет лезет в базу? Это скорее исключение.
G>>Опять-таки ваш опыт в данном случае очень субъективнен.

S>Ну вот смотрите. Мы говорим про интерпрайз систему. У неё есть внешние пользователи. Они ломятся к системе через сайт/службы. Есть внутренние пользователи. Они ломятся через десктопные программы/службы. Есть репорты, которые почти всегда ломятся напрямую к СУБД. Есть легаси системы и 1С. 1С работает, допустим через выгрузку по расписанию и Integration Services. Легаси системы стучатся через Linked Server. Заставить всю эту шоблу ломиться через прослойки — не важно что это будет (DCOM, вебсервисы, ваше собственное творение) — практически нереально.
Все реально, было бы желание.

S>Все требования к защите, тем не менее, никуда не исчезнут. Как можно их реализовать?

S>>>Доступ к базе был из локальной сети. Хватило
G>>Даже в локальной сети можно ограничить доступ в базу.
G>>Это должно быть проблемой админа, а не программистов.
S>Неа Приложение работало почти целиком через вебсервисы. Строка соединения в датасете вообще не использовалась. Но! для репортов понадобился доступ к БД, поскольку структура отчёта динамически подгонялась под требования пользователя. Они решили пойти через генерацию SQL. Ну и открыли доступ. Как администратор может защитить ИХ сервер (за который ответственность несут разработчики, и они никого не пускает, потому как если делать как положено, половина систем сдыхает)?
Если у вас плохо с взаимодействием между разработчиками и админами, если не можете сделать отчеты через прослойку, то это не архитектурные проблемы.
Другие люди вполне смогут сделать отчеты через прослойку и им не понадобится городить кучу кода в БД.

S>Епть. Смотрите. У нас есть некоторая система. Несколько клиентов-подсистем. За них вы не отвечаете и сделать с ними ничего не можете. Функционал (БЛ) клиентов не пересекается, но они работают с одними и теми же данными. Для каждого клиента представление данных своё. Надо гарантировать, что весь зоопарк ничего не порушит.
Функционал должен быть на сервере, клиенты должны быть тонкими. Тогда ничего никто не порушит.

S>У вас не будет общих сущностей и общих вебсервисов — Ни структура данных, ни функционал не пересекаются. Единственный вариант — использовать некоторые воспомогательные функции проверки и дёргать их при каждом действии.
Тогда вам нужно несколько независимых "серверов" с различными наборавми сервисов.

S>Если вы забыли дёрнуть проверку — у вас дыра в защите.
Для этого есь тесты.

S>Сферический сценарий в вакууме: есть сервис "наградить подчинённого". Принимает ID подчинённого, награждает его если товарищ подчинён авторизовавшемуся товарищу. При очередном изменении логики награждения (выдаём не фарфоровых слоников, а шоколадную медальку) вы забыли дёрнуть эту самую проверку. У вас дырка. Но поскольку это дырка в относительно редко использующемся коде — допустим есть другой сервис "наградить всех подчинённых", который используется куда чаще, она остаётся неотслеженной. У вас безопасность системы будет зависеть от надёжности кода. Поверьте опыту, поломать декларативное описание, так чтобы всё продолжало работать, но появилась дырка куда сложнее. Поскольку это описание гарантированно используется в каждом сценарии шансы на обнаружение дырки тоже растут. Видите, ничего сложного
Используйте тестирование и будет вам счастье.

S>>>Ребят, это, ёпть, сферический конь в вакууме. У вас сервер приложений умеет всё, что умеет СУБД?
G>>Нет, а зачем? Он умеет столько сколько достаточно для решения бизнес задач.

S>>>И даже тру транзакции?
G>>Что такое тру транзакции? Если надо обрабатывать длительную бизнес-транзакцию, то это делается средствами, отличными от транзакций БД.

S>Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.
Одни вызов сервиса "разместить заказ", дальше пусть сервси внутри разбирается.

S>Естественно заказ должен быть атомарным, либо всё, либо ничего. И, поскольку заказ может быть отправлен внешней системой в ходе другой транзакции, нужна вложенность транзакций. Проводка заказов выливается в запросы к внешним системам — склад, CRM, бухгалтерия и т.п. Они тоже должны быть в транзакциях. Если хоть одно из звеньев цепочки не реализует WS-TX (или реализует своим особым способом) — увы...
См выше. Звено от клиента к серверу не поддерживает WS-TX, и ниче, работать будет.

S>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
От синхронной репликации через интернет загнется кто угодно.

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

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

S>>Вы знаете, датасеты умеют передавать pure xml (без схемы) и binary serialisation умеют.
G>Без передачи схемы от датасетов толку мало. Даже бинарная реариализация не спасает, нельзя передать только необходимую часть датасета.

Эммм... мы всё ещё обсуждаем реализацию внутреенностей системы?

G>Если у вас плохо с взаимодействием между разработчиками и админами, если не можете сделать отчеты через прослойку, то это не архитектурные проблемы.
G>Другие люди вполне смогут сделать отчеты через прослойку и им не понадобится городить кучу кода в БД.
К щастью, к тому случаю я не имею никакого отношения.

S>>Епть. Смотрите. У нас есть некоторая система. Несколько клиентов-подсистем. За них вы не отвечаете и сделать с ними ничего не можете. Функционал (БЛ) клиентов не пересекается, но они работают с одними и теми же данными. Для каждого клиента представление данных своё. Надо гарантировать, что весь зоопарк ничего не порушит.
G>Функционал должен быть на сервере, клиенты должны быть тонкими. Тогда ничего никто не порушит.

S>>У вас не будет общих сущностей и общих вебсервисов — Ни структура данных, ни функционал не пересекаются. Единственный вариант — использовать некоторые воспомогательные функции проверки и дёргать их при каждом действии.
G>Тогда вам нужно несколько независимых "серверов" с различными наборавми сервисов.

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

S>>Если вы забыли дёрнуть проверку — у вас дыра в защите.
G>Для этого есть тесты.
Тесты есть, их не может не есть. Но скажите пожалуйста, чем вы проверите корректность самого теста?

S>>Сферический сценарий в вакууме: есть сервис "наградить подчинённого". Принимает ID подчинённого, награждает его если товарищ подчинён авторизовавшемуся товарищу. При очередном изменении логики награждения (выдаём не фарфоровых слоников, а шоколадную медальку) вы забыли дёрнуть эту самую проверку. У вас дырка. Но поскольку это дырка в относительно редко использующемся коде — допустим есть другой сервис "наградить всех подчинённых", который используется куда чаще, она остаётся неотслеженной. У вас безопасность системы будет зависеть от надёжности кода. Поверьте опыту, поломать декларативное описание, так чтобы всё продолжало работать, но появилась дырка куда сложнее. Поскольку это описание гарантированно используется в каждом сценарии шансы на обнаружение дырки тоже растут. Видите, ничего сложного
G>Используйте тестирование и будет вам счастье.
// Сорри стебаюсь. Просьба коммент не учитывать.
Вы можете гарантировать, что все потенциально небезопасные методы будут проверены именно на эту уязвимость?

S>>Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.
G>Одни вызов сервиса "разместить заказ", дальше пусть сервси внутри разбирается.
Ещё раз. Сервис может колбасить внутри себя вызовы к внешним системам, которые тоже применяют транзакции...
Эти вызовы не держат транзакции. В одном из них произошла ошибка и он тихо сдох. Данные рассогласованы и вы этого не узнаете без специальной проверки.

S>>Естественно заказ должен быть атомарным, либо всё, либо ничего. И, поскольку заказ может быть отправлен внешней системой в ходе другой транзакции, нужна вложенность транзакций. Проводка заказов выливается в запросы к внешним системам — склад, CRM, бухгалтерия и т.п. Они тоже должны быть в транзакциях. Если хоть одно из звеньев цепочки не реализует WS-TX (или реализует своим особым способом) — увы...
G>См выше. Звено от клиента к серверу не поддерживает WS-TX, и ниче, работать будет.
См выше Если клиент обращается к вашему сервису внутри транзакции и ваш сервис сдохнет, он повредит уже свои данные

S>>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
G>От синхронной репликации через интернет загнется кто угодно.
Ну не надо, что ж вы так... Вполне осуществимая вешь.

G>Вообще старнно что вы отсутсвие нормальной архитектуры, остуствие взамодействия между группами и отсутствие тестирования пытаетесь заткнуть кучей кода в БД. При это выдавая такой путь как самый правильный.

Уххх. С чего вы взяли, что у меня нет ни архитектуры, ни взаимодействия между группами, ни тестирования? Есть всё это. Просто есть ещё и внешняя среда, которая [censored] на все ваши решения.

Кстати, если не помните, я никогда не предлагал запихнуть ВСЮ БЛ в субд, а исключительно представление данных и контроль доступа к ним — то, что СУБД в принципе умеет гораздо лучше любого велосипеда.

// Кажется, пошёл переход на личности. Извиняюсь если задел. Замнём?

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

G>>Если у вас плохо с взаимодействием между разработчиками и админами, если не можете сделать отчеты через прослойку, то это не архитектурные проблемы.
G>>Другие люди вполне смогут сделать отчеты через прослойку и им не понадобится городить кучу кода в БД.
S>К щастью, к тому случаю я не имею никакого отношения.
К вашему несчастью не имеете. Если все пустить через сервсиы, и не давать доступа к БД, то куча кода в БД станет ненужной.

S>>>У вас не будет общих сущностей и общих вебсервисов — Ни структура данных, ни функционал не пересекаются. Единственный вариант — использовать некоторые воспомогательные функции проверки и дёргать их при каждом действии.
G>>Тогда вам нужно несколько независимых "серверов" с различными наборавми сервисов.

S>Да. Вы предлагаете дублировать проверку доступа, или создать ещё один промежуточный уровень?
Проверка доступа разграничивает бизнес-функции, такие проверки отлчно живут в самих сервисах, эти проверки не пересекаются друг с другом.
Например есть функция F1, которая вызывает действия A, B, C. Если пользователю запрещено действие A, то ему фактически запрещена функция F1.
Кроме того разрешение\запирещение некоторых действий может зависить от того в какой функции они вызываются.
Разграничение доступа на уровне функций оказывается облее гибким и реализуется проще.

S>>>Если вы забыли дёрнуть проверку — у вас дыра в защите.
G>>Для этого есть тесты.
S>Тесты есть, их не может не есть. Но скажите пожалуйста, чем вы проверите корректность самого теста?
А чем вы докажете крорректность проверок в БД?
Не надо детский сад разводить. Тесты обычно достстаточно просты чтобы их можно было проанализировать.

S>>>Сферический сценарий в вакууме: есть сервис "наградить подчинённого". Принимает ID подчинённого, награждает его если товарищ подчинён авторизовавшемуся товарищу. При очередном изменении логики награждения (выдаём не фарфоровых слоников, а шоколадную медальку) вы забыли дёрнуть эту самую проверку. У вас дырка. Но поскольку это дырка в относительно редко использующемся коде — допустим есть другой сервис "наградить всех подчинённых", который используется куда чаще, она остаётся неотслеженной. У вас безопасность системы будет зависеть от надёжности кода. Поверьте опыту, поломать декларативное описание, так чтобы всё продолжало работать, но появилась дырка куда сложнее. Поскольку это описание гарантированно используется в каждом сценарии шансы на обнаружение дырки тоже растут. Видите, ничего сложного
G>>Используйте тестирование и будет вам счастье.
S>// Сорри стебаюсь. Просьба коммент не учитывать.
S>Вы можете гарантировать, что все потенциально небезопасные методы будут проверены именно на эту уязвимость?
Да. Для этого тестирование и применяется.

S>>>Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.
G>>Одни вызов сервиса "разместить заказ", дальше пусть сервси внутри разбирается.
S>Ещё раз. Сервис может колбасить внутри себя вызовы к внешним системам, которые тоже применяют транзакции...
S>Эти вызовы не держат транзакции. В одном из них произошла ошибка и он тихо сдох. Данные рассогласованы и вы этого не узнаете без специальной проверки.
В общем случае получается Задача двух генералов, которая без промежуточной надежной службы не решается.
Во-первых можно использовать Reliable messaging как MSMQ.
Во-вторых можно использовать компенсационные действия в случае неуспеха одной из операций, чтобы свести к минимум вероятность рассогласовния данных.
А по-хорошему надо настраивать управляемую синхронизацию между между базами.

S>>>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
G>>От синхронной репликации через интернет загнется кто угодно.
S>Ну не надо, что ж вы так... Вполне осуществимая вешь.
В локальной сети да, через инет, в случае 2-3 реплик уже слишком медленно работает. При этом все это жутко нерасширяемо.

G>>Вообще старнно что вы отсутсвие нормальной архитектуры, остуствие взамодействия между группами и отсутствие тестирования пытаетесь заткнуть кучей кода в БД. При это выдавая такой путь как самый правильный.

S>Уххх. С чего вы взяли, что у меня нет ни архитектуры, ни взаимодействия между группами, ни тестирования?
Из ваших рассказов.

S>Просто есть ещё и внешняя среда, которая [censored] на все ваши решения.
С внешней средой надо договариваться, а не давать прямой доступ к базе.

S>Кстати, если не помните, я никогда не предлагал запихнуть ВСЮ БЛ в субд, а исключительно представление данных и контроль доступа к ним — то, что СУБД в принципе умеет гораздо лучше любого велосипеда.
Вы рассказываете про контроль достпу к функциям системы, при этом пытаетесь такие задачи решать контролем доступа к данным.
Это неправльный путь.

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

Разделение привилегий на чтение через хранимки не очень понятно. Как выглядят row level security (с логикой сложнее чем where t.owner=user) & column level security реализованные на хранимках? Что-то мне подсказывает, что с декларативностью мы тут пролетаем.

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

Декларативность схемы авторизации для апп сервера довольно просто реализовать. Степень декларативности будет как минимум не хуже списка grant execute on xxx to xxx. Самое приятное в этом, что при желании мы сможем расширять DSL, например ограничениями на входные параметры, чего нельзя сделать в базе.

Я пока вижу, что для избавления от дыр в безопасности в хранимках легко потерять декларативность и напридумывать лишние сущности в базе. Можете меня разубедить?

Про транзакционность я вообще ничего не понял, чем транзакция клиента + ХП лучше транзакции сервера без ХП?

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

S>>>>Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.
G>>>Одни вызов сервиса "разместить заказ", дальше пусть сервси внутри разбирается.
S>>Ещё раз. Сервис может колбасить внутри себя вызовы к внешним системам, которые тоже применяют транзакции...
S>>Эти вызовы не держат транзакции. В одном из них произошла ошибка и он тихо сдох. Данные рассогласованы и вы этого не узнаете без специальной проверки.
G>В общем случае получается Задача двух генералов, которая без промежуточной надежной службы не решается.
G>Во-первых можно использовать Reliable messaging как MSMQ.
G>Во-вторых можно использовать компенсационные действия в случае неуспеха одной из операций, чтобы свести к минимум вероятность рассогласовния данных.
G>А по-хорошему надо настраивать управляемую синхронизацию между между базами.

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

я смотрю что вопрос CRUD в EF и целесообразность для него хранимок перерос в вопрос где размещать слой бизнес логики

2 gandjustas:

S>>К щастью, к тому случаю я не имею никакого отношения.
G>К вашему несчастью не имеете. Если все пустить через сервсиы, и не давать доступа к БД, то куча кода в БД станет ненужной.
[Ctnsored], [censored], [censored]! Был приведён пример, к чему могут привести сквозные дыры при вашем подходе. Я никаким боком в этом примере не участвовал — и слава богу, повесился бы со стыда. Но фигурально

S>>Да. Вы предлагаете дублировать проверку доступа, или создать ещё один промежуточный уровень?
G>Проверка доступа разграничивает бизнес-функции, такие проверки отлчно живут в самих сервисах, эти проверки не пересекаются друг с другом.

G>Например есть функция F1, которая вызывает действия A, B, C. Если пользователю запрещено действие A, то ему фактически запрещена функция F1.
G>Кроме того разрешение\запирещение некоторых действий может зависить от того в какой функции они вызываются.
G>Разграничение доступа на уровне функций оказывается облее гибким и реализуется проще.
Ага. Понял к чему вы клоните. К запрету нескольких базовых действий, всё остальное работает через них — получает запрет. Так?

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

S>>Тесты есть, их не может не есть. Но скажите пожалуйста, чем вы проверите корректность самого теста?
G>А чем вы докажете крорректность проверок в БД?
G>Не надо детский сад разводить. Тесты обычно достстаточно просты чтобы их можно было проанализировать.
// Не буду стебаться. На этот раз удержался.

S>>Вы можете гарантировать, что все потенциально небезопасные методы будут проверены именно на эту уязвимость?
G>Да. Для этого тестирование и применяется.
Понимаете в чём дело. При таком подходе безопасность системы гарантируется только корректностью ваших тестов. Ещё Дейкстра писал, что тесты не гарантируют надёжность системы. Они только показывают возможность её работоспособности и только в определённых условиях.

G>В общем случае получается Задача двух генералов, которая без промежуточной надежной службы не решается.
G>Во-первых можно использовать Reliable messaging как MSMQ.
G>Во-вторых можно использовать компенсационные действия в случае неуспеха одной из операций, чтобы свести к минимум вероятность рассогласовния данных.
G>А по-хорошему надо настраивать управляемую синхронизацию между между базами.

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

S>>>>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
G>>>От синхронной репликации через интернет загнется кто угодно.
S>>Ну не надо, что ж вы так... Вполне осуществимая вешь.
G>В локальной сети да, через инет, в случае 2-3 реплик уже слишком медленно работает. При этом все это жутко нерасширяемо.
Увы-увы Для медленных каналов можно в принципе сделать merge репликацию. Но всё-таки, согласитесь, лучше чем через веб-сервисы, а?

S>>Уххх. С чего вы взяли, что у меня нет ни архитектуры, ни взаимодействия между группами, ни тестирования?
G>Из ваших рассказов.
Сорри. Слишком заострял вимание на негативных моментах.

S>>Просто есть ещё и внешняя среда, которая [censored] на все ваши решения.
G>С внешней средой надо договариваться, а не давать прямой доступ к базе.
Угу

S>>Кстати, если не помните, я никогда не предлагал запихнуть ВСЮ БЛ в субд, а исключительно представление данных и контроль доступа к ним — то, что СУБД в принципе умеет гораздо лучше любого велосипеда.
G>Вы рассказываете про контроль достпу к функциям системы, при этом пытаетесь такие задачи решать контролем доступа к данным.
G>Это неправльный путь.

[Censored]!
Насколько помню, я нигде не говорил, про контроль доступа к функциям системы. Я говорил про представление данных и контроль доступа к ним. Если был не так понят — извините.

2 Ziaw:
Не так легко объяснить на пальцах, но попробую. Обычно просто пишется view, который к полям сущности добавляет bitmask операций для текущего пользователя. Далее в хранимках в запросе делается побитовое И битовой маски сущности и битовой маски запрашиваемых разрешений. Это если примитивно и без учёта всяких аццких оптимизаций.
Для примера с заказами/details — по три (четыре, если можем обновлять) хранимки на каждую сущность и одно представление на каждую сущность (если так хочется, можно тупо скопировать запрос из вьюхи внутрь каждой хранимки).
Если у вас другое приложение, которое требует другого представления заказов/details'ov (без крыльев и с перламутровыми пуговицами), вы просто добавляете три (четыре) хранимки, которые ссылаются на соответствующий view.
Разумеется, API каждого приложения разносится по разным схемам, разрешения — по разным ролям, пользователи добавляются в эти роли.

Повторюсь, в реальности всё несколько сложнее, но число воспомогательных элементов стремится к константе.

Про транзакционность — флейм ушёл в сторону. Теперь спорим ещё и о транзакциях и тестировании. Скоро будем обсуждать мирукапец.

2 Аноним:
Да флейм ушёл в сторону, вынос в другую ветку не помог Кстати, посмотрите (я давал ссылку выше), там меня определённо побеждают На редкость адекватный холивар пока складывается.