Serzh KZМСУДвухзвенка - моветон, зло, небезопасность, немасштабируемость.
Тут прокоменть плз?
Есть факты взлома скуля?
Тема баян, я уже устал это разжевывать...

Для тебя сделаю исключение, ок. Подломить строку соединения можно через любой дебаггер, пойдет даже родной windbg от майкрософта. То есть более или менее подготовленный юзер получает строку соединения к БД, а дальше хоть конь не валяйся.

Если ты в двухзвенке заложился в строке соединения на "супер юзера" (так многие делают, быстро и просто), то это вообще алес капут.

Serzh KZНу вообщет, если мне не изменяет память то у скуля есть средство шиврования.
Шифрование канала, а он тут вообще идет лесом за ненадобностью. В экземпляр SqlConnection ты подставляешь конкретное значение ConnectionString. Именно его я перехватываю через отладчик и радуюсь жизни.

Serzh KZУ меня юзер только паблик на базу, далее открыты основные процедуры на ехекут и все, в процедурах индентификация юзера проверка его полномочий и все такое в общем все по взрослому. :)
Всё это от лукавого. У пользователя есть доступ на чтение таблиц или вьюх?

Serzh KZЕсли у меня юзер под своей учеткой зайдет через MS то увидет с десяток процедур с которыми по понятным причинам ни чего сделать не сможет.
Пользователь вообще ничего не должен знать про базу данных, она для всех участников в интрасети (и интернета тоже) должна быть в черном ящике и спрятана за семью замками. Только сервисный слой должен ходить в базу, всё

Serzh KZТут я упустил, момент дебага, а я про сниф подумал, в общем не вижу в этом смысла, ведь сламают юзера который в БД ни каких прав к таблам не имеет. :)
Почему не имеет? Есть куча двухзвенного софта, в котором у пользователей есть прямого доступ чтения данных из таблиц. Поэтому я тебя и спросил, могут ли юзеры читать данные из таблиц и вьюх?

Serzh KZЧет прям как то не логично, зачем ломать залогиненого юзера, если и так доступ в програму есть?
В большинстве случаев информация, которая закрыта через программу, можно получить через базу данных. Различные шпионские крючки вида сиквел инъекций, подлома строки соединения и пр.

Serzh KZНет, я ведь написал только с десяток процедур открыт екзекут, все остальное закрыто
Отлично, логика на хранимках - это полная жесть. Про масштабирование в виде смены поставщика БД я молчу.

Serzh KZМСУПользователь вообще ничего не должен знать про базу данных, она для всех участников в интрасети (и интернета тоже) должна быть в черном ящике и спрятана за семью замками. Только сервисный слой должен ходить в базу, всё Ну тут вообще какая то пораноя :) сори
Это не параноя, это правильная архитектура ПО. Про вариант использования твоего софта вне домена я вообще молчу. Он это просто архитектурно не поддерживает.

Кому нужна система, которая:

1. Не масштабируется в разрезе смены поставщика данных (различные виды СУБД). У заказчика могут быть лицензии на оракл, к примеру. Твой сиквел ему и даром не вперся.
2. Не масштабируется в разрезе смены провайдера аутентификации (жестко зашита только вин аутентификация). У заказчика могут быть свои таблицы с логинами и хешами паролей, которые используются в различном ПО компании.
3. Не масштабируется наличием сервера приложений, на котором располагается логика и управление клиентами. Вся логика зашита в хранимках и толстом клиенте.

P.S. Такие системы идут прямиком на свалку ибо представляют мало интереса для потребителя.

Serzh KZУ меня все процедурки генерятся, что мне мешает переписать генератор под другую СУБД?
Как можно "сгенерировать" логику? Логика непостоянна.

Serzh KZМСУ, Можно мне в двух словах, о тебе? :)
В прошлом году окончил школу, 11 классов, сдал с успехом ЕГЭ по математике. Сейчас работаю помощником программиста в РЖД, изучаю технологии и учусь правильно проектировать схемы БД. Люблю пиво с раками. Ну вкратце :)

Serzh KZЭто к завершению о безопасности у меня в БД.
По поводу безопасности обвинения снимаются. Единственный вариант, когда база защищена, это логика в хранимках без доступа к таблицам и представлениям. Если бы был доступ хоть к одной таблице, то пользователь всегда может открыть транзакцию, выполнить селект и на закрыть транзакцию. Тем самым, он залочит данные для остальных участников, которые решили не грязно (уровень изоляции без nolock) работать с данными.

Serzh KZМСУКому нужна система, которая:

1. Не масштабируется в разрезе смены поставщика данных (различные виды СУБД). У заказчика могут быть лицензии на оракл, к примеру. Твой сиквел ему и даром не вперся.
2. Не масштабируется в разрезе смены провайдера аутентификации (жестко зашита только вин аутентификация). У заказчика могут быть свои таблицы с логинами и хешами паролей, которые используются в различном ПО компании.
3. Не масштабируется наличием сервера приложений, на котором располагается логика и управление клиентами. Вся логика зашита в хранимках и толстом клиенте.

P.S. Такие системы идут прямиком на свалку ибо представляют мало интереса для потребителя.

:) Ну местами ты прав, пока я работаю с мс скулем, то мне это и не нужно пока и на клиентом которых я нацелен у них нет ни какого СУБД и требования по нему не будет ни каких.
1. Как ты собираешься привлечь инвестиции к проекту и впоследствии внедрять решение заказчикам, если не продумал такие базовые вещи?
2. То, что ты работаешь с MS SQL, мало интересует заказчика. Его в первую очередь интересует, с чем он работает.
3. Я не понимаю предложения "мне это пока не нужно". Ты пишешь программу сам для себя?
4. Сейчас даже в ларьках по продаже прелых семячек есть СУБД, ты о чем?
5. Ты жестко сам себе ставишь палки в колеса, ограничивая круг потенциальных заказчиков твоего ПО. У них не должно быть никаких СУБД, т.к. ты "нацелен" именно на такой подход.

Что тут еще сказать. Всё плохо...

Serzh KZМСУСейчас работаю помощником программиста в РЖД, изучаю технологии и учусь правильно проектировать схемы БД.
Интересно как обстоят дела в РЖД с программистами у нас в КТЖ полный атас, мы месяц от них добивались поток данных, теперь еще ждем другой поток, все лишь три раза пока не то, что нужно выгружали из базы :)
Да как обстоят дела в РДЖ с программистами, всё нормально. Вот тот самый программист 14492063 , чьим помощником я являюсь, у него и спроси :)

Petro123не перегибай)) всю рыбу распугаешь). У него ИС не на миллиард строк.
Я боюсь, что даже на десятке миллионов записей + полсотни активных юзеров у него всё встанет раком :)

Да и, вообще, должна ли информационная система иметь такие ограничения? Миллиард нельзя, а миллион можно. Как-то несерьёзно...

Давайте спросим экспертов по этому делу: Валеру и Сахвата.

Валера и Сахват
Товарищи, нагружали ли вы свои системы большими объемами в разрезе тестирования производительности, которая выражается, к примеру, временем отклика? Производилось ли нагрузочное тестирование? Есть ли конкретные ограничения по объему? Спасибо.

Сахават, а зачем клиенту "ждать"? Почему нельзя запустить расчет и продолжить работу? Когда расчет будет закончен, пользователь будет просто уведомлен.