Посоветуйте. Имеется планы написать специализированную систему электронного документооборота на C#+MSSQL, порядка 500 пользователей. Насколько необходим промежуточный компонент в виде сервера приложений или можно обойтись клиент-серверным вариантом (клиент — десктоп-клиент на C#, БД на MSSQL, клиенты напрямую пишут-читают из БД)?
Здравствуйте, symantis, Вы писали:
S>Добрый день!
S>Посоветуйте. Имеется планы написать специализированную систему электронного документооборота на C#+MSSQL, порядка 500 пользователей. Насколько необходим промежуточный компонент в виде сервера приложений или можно обойтись клиент-серверным вариантом (клиент — десктоп-клиент на C#, БД на MSSQL, клиенты напрямую пишут-читают из БД)?
А сколько пользователей одновременно читают-пишут в БД?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, symantis, Вы писали:
S>Добрый день!
S>Посоветуйте. Имеется планы написать специализированную систему электронного документооборота на C#+MSSQL, порядка 500 пользователей. Насколько необходим промежуточный компонент в виде сервера приложений или можно обойтись клиент-серверным вариантом (клиент — десктоп-клиент на C#, БД на MSSQL, клиенты напрямую пишут-читают из БД)?
Я бы логику БД выносил бы в серверный компонент. А уж клиенты имели бы дело с ним, а он уж разруливал можно\нельзя и.т.п. Имхо, гибче будет архитектура, клиент будет абстрагирован от самого MSSQL.
Здравствуйте, symantis, Вы писали:
S>Добрый день!
S>Посоветуйте. Имеется планы написать специализированную систему электронного документооборота на C#+MSSQL, порядка 500 пользователей. Насколько необходим промежуточный компонент в виде сервера приложений или можно обойтись клиент-серверным вариантом (клиент — десктоп-клиент на C#, БД на MSSQL, клиенты напрямую пишут-читают из БД)?
Во-первых веб, во вторых незачем писать, есть SharePoint
Здравствуйте, symantis, Вы писали:
S>Посоветуйте. Имеется планы написать специализированную систему электронного документооборота на C#+MSSQL, порядка 500 пользователей. Насколько необходим промежуточный компонент в виде сервера приложений или можно обойтись клиент-серверным вариантом (клиент — десктоп-клиент на C#, БД на MSSQL, клиенты напрямую пишут-читают из БД)?
Зависит от будущих планов.
Мы обошлись без промежуточного слоя, но только за счёт отсоединённого режима работы клиента. Разруливание доступа и проверка на допустимость операций делается силами СУБД. Клиенту доступен только API в виде набора SP/View. Логика, отвечающая за поведение клиента живёт на самом клиенте.
Сейчас ~ 200 пользователей, "сервер" — дохлый P4 2.8 c 2 гигами памяти (в серверной есть нормальное железо, лень переезжать, да и незачем). Проблем с производительностью/надёжностью не наблюдается.
Здравствуйте, symantis, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Во-первых веб, во вторых незачем писать, есть SharePoint
S>Мне не нравятся веб-клиенты, и Шарепойнт тоже.
Вам или клиентам? Или клиенты не знают о вебе?
Здравствуйте, symantis, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Во-первых веб, во вторых незачем писать, есть SharePoint
S>Мне не нравятся веб-клиенты, и Шарепойнт тоже.
Ваше личное мнение никого не интересует. Есть миллион объективных причин не использовать десктопные клиенты для таких задач.
Здравствуйте, symantis, Вы писали:
S>Здравствуйте, Sshur, Вы писали:
S>>А сколько пользователей одновременно читают-пишут в БД?
S>Думается, 100-200 одновременно будут читать из БД, проверка изменений состояний документов и т.д.
Если все только читают, то это не проблема. Вопрос сколько из них будет вносить изменения? 100 одновременно пишущих в одну таблицу прямой путь к тормозам из-за блокировок. Ну или как минимум, огромная головная боль для разработчика, чтобы их развести таким образом, чтобы они друг другу не мешали.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Здравствуйте, symantis, Вы писали:
S>>Здравствуйте, Sshur, Вы писали:
S>>>А сколько пользователей одновременно читают-пишут в БД?
S>>Думается, 100-200 одновременно будут читать из БД, проверка изменений состояний документов и т.д.
S>Если все только читают, то это не проблема. Вопрос сколько из них будет вносить изменения? 100 одновременно пишущих в одну таблицу прямой путь к тормозам из-за блокировок. Ну или как минимум, огромная головная боль для разработчика, чтобы их развести таким образом, чтобы они друг другу не мешали.
Вы систему документооборота представляете? Она соответствует довольно типичному профиилю использования 98 запросов на чтение и 2 на запись. То есть при 500 пользователях реально одновременных записей будет 10. Причем все они пойдут по ключу. В таких условиях схватить эскалацию блокировки очень сложно, даже если пользователей станет в разы больше. Для оптимизации можно SNAPSHOT\NOLOCK применить для большинства выборок.
Здравствуйте, gandjustas, Вы писали:
G>Вы систему документооборота представляете? Она соответствует довольно типичному профиилю использования 98 запросов на чтение и 2 на запись. То есть при 500 пользователях реально одновременных записей будет 10. Причем все они пойдут по ключу. В таких условиях схватить эскалацию блокировки очень сложно, даже если пользователей станет в разы больше. Для оптимизации можно SNAPSHOT\NOLOCK применить для большинства выборок.
Систему документооборота не представляю, потому и спросил. Если все так, то при грамотном подходе у ТС проблем с параллельной работой 500 пользователей не будет.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, symantis, Вы писали:
S>Добрый день!
S>Посоветуйте. Имеется планы написать специализированную систему электронного документооборота на C#+MSSQL, порядка 500 пользователей. Насколько необходим промежуточный компонент в виде сервера приложений или можно обойтись клиент-серверным вариантом (клиент — десктоп-клиент на C#, БД на MSSQL, клиенты напрямую пишут-читают из БД)?
Причины появления трёхзвенной архитектуры следующие
Высокая масштабируемость
Лучшие возможности обеспечения безопасности
Более высокая надежность
Возможность балансировки нагрузки
Увеличение скорости работы
Упрощается обновление
Кардинально снижаются требования к пропускной способности сети между клиентом и средним звеном
Снижаются требования к производительности клиентских машин, следовательно — снижение стоимости эксплуатации
Может ещё чего забыл
На сегодняшний день значимость этих факторов снизилась, но вряд-ли можно сказать, что преимуществ совсем не осталось. Кроме того, если доступ через web Вам сегодня не нужен, то завтра вполне может потребоваться.
Исходя из этого и оцените, нужна-ли Вам трёхзвенка.
Здравствуйте, Jolly Roger, Вы писали:
JR>Может ещё чего забыл
Имхо, забыл сочетание недостаточной надёжности сети с разбросанностью пользователей и высокой важностью программы. Тогда, может, есть смысл в многозвенной архитектуре -- чтобы при разрыве связи таки как-то можно было работать...
Здравствуйте, symantis, Вы писали:
S>Добрый день!
S>Посоветуйте. Имеется планы написать специализированную систему электронного документооборота на C#+MSSQL, порядка 500 пользователей. Насколько необходим промежуточный компонент в виде сервера приложений или можно обойтись клиент-серверным вариантом (клиент — десктоп-клиент на C#, БД на MSSQL, клиенты напрямую пишут-читают из БД)?
Ну ещё как промежуточный вариант смарт клиент с собственным локальным кэшем и заливкой обновлений порциями.
Здравствуйте, Jolly Roger, Вы писали:
JR>Здравствуйте, symantis, Вы писали:
S>>Добрый день!
S>>Посоветуйте. Имеется планы написать специализированную систему электронного документооборота на C#+MSSQL, порядка 500 пользователей. Насколько необходим промежуточный компонент в виде сервера приложений или можно обойтись клиент-серверным вариантом (клиент — десктоп-клиент на C#, БД на MSSQL, клиенты напрямую пишут-читают из БД)?
JR>Причины появления трёхзвенной архитектуры следующие JR>
JR>Высокая масштабируемость JR>Лучшие возможности обеспечения безопасности JR>Более высокая надежность JR>Возможность балансировки нагрузки JR>Увеличение скорости работы JR>Упрощается обновление JR>Кардинально снижаются требования к пропускной способности сети между клиентом и средним звеном JR>Снижаются требования к производительности клиентских машин, следовательно — снижение стоимости эксплуатации JR>Может ещё чего забыл JR>
JR>На сегодняшний день значимость этих факторов снизилась, но вряд-ли можно сказать, что преимуществ совсем не осталось. Кроме того, если доступ через web Вам сегодня не нужен, то завтра вполне может потребоваться.
JR>Исходя из этого и оцените, нужна-ли Вам трёхзвенка.
Лично для меня сервер вэб является не 2 а 3 звеном, как и десктопные приложения.
Здравствуйте, gandjustas, Вы писали:
G>Ваше личное мнение никого не интересует. Есть миллион объективных причин не использовать десктопные клиенты для таких задач.
Например, из веба удобнее печатать странички без адреса сверху и ещё удобнее сканировать подписанные документы.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Ваше личное мнение никого не интересует. Есть миллион объективных причин не использовать десктопные клиенты для таких задач.
A>Например, из веба удобнее печатать странички без адреса сверху и ещё удобнее сканировать подписанные документы.
Формы для печати отлично делаются и в вебе, а сканеры умеют отправлять сканы на email или складывать в папки. Причем в случае поточного сканера другого варианта и нету.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Формы для печати отлично делаются и в вебе
A>ActiveX'ами.
Не говори глупости. в css указываются стили для печати.
G>>а сканеры умеют отправлять сканы на email или складывать в папки. A>О да, это весьма информационно-безопасно.
Не понимаю о чем ты.
G>>Причем в случае поточного сканера другого варианта и нету. A>Ты не прав.
Ага, конечно. Гораздо лучше привязать поточный сканер к конкретному рабочему месту, хотя он может сотни документов в минуту сканировать.
Собственно поточные сканеры и были придуманы для того чтобы не ставить сканеры конкретным пользователям, а использовать один на организацию\этаж\отдел.
"Нормальные герои всегда идут в обход!"
