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

S>Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.
S>Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

S>Тут я сумбур написал, вот выдержки:
S>1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged (я знаю примеры объектных баз на .net, но хочеться знать ваше мнение). То есть подходит ли c# для написания баз данных, работающих с крупными массивами данных? Сомнения у меня в gc есть, не будет ли тормазить выборки/операции с базой?
S>2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

S>p.s. если это баян, жестоко извиняюсь.

Я бы начал прежде всего с вопросов сколько у Вас есть ресурсов под этот проект?
Временных, денежных, человеческих?

Объектные базы писать — задача довольно тяжелая и трудоемкая, как тут уже упоминалось, к тому времени как Вы ее допишете — стандартные клиентские машины будут раза в 2 быстрее По затратам получается намного быстрее и дешевле написать объектный диспетчер и повесить его над существующей системой protected storage: SQL, Oracle, MySQL (если хотите конечно

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

Опять же, нам будет гораздо легче Вам помочь, если Вы расскажете немного о специфике задачи — объемы данных, к-рые необходимо передавать с сервера на клиенты (только недавно читал о проблематичности загрузки длинного 300 000+ списка товаров на вебклиента), род этих данных и т.д.

ERP очень красивый термин, конечно даа, только к сожалению черезчур всеобъемлющий

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

V>Интересный момент. Вы хотите сказать, что создать свою промышленную СУБД будет дешевле готовых, таких, как Oracle, MS SQL etc.? Стоимость их покупки и линензий — это несколько тысяч долларов, в большинстве случаев всего примерно до двух десятков ли меньше. А это, с другой стороны, зарплата команды двух-трех профессиональных разработчиков максимум на 2-3 месяца. Плюс время обкатки своей СУБД на реальных объемах, которые даст только запуск проекта промышленного масштаба, т.е. эксперимент над заказчиком, а он чаще всего не любит отрицательных результатов
Мы не создаем "промышленную СУБД", мы создаем, если можно так выразиться, объектный персистентный компонент erp системы, который используют другие подсистемы для хранения информации. Но так как функциональность в принципе схожа с СУБД, то мы называем этот компонент СУБД. Но еще раз отмечаю, что это не "промышленное" СУБД (которое может быть использовано другими разработчиками или продоваться отдельно), функциональность пересикается (обрабоктка sql (скорее oql) ), но всё же это не то. Потом наше ВСУБД (внутренее СУБД) использует расширяемые компоненты для хранения, то есть в готовом решении заказчик получает ВСУБД с нашим компонентом сохранения, если он нам не доверяет, может либо заказать компонент под конкретное СУБД, либо использовать уже написанные компоненты для хранения в MS SQL или ORACLE, ВСУБД можно назвать объектной надстройкой над другими СУБД, но с большой натяжкой.
V>Создание объектной СУБД поверх SQL для обработки больших объемов данных задача также нетривиальная. Есть мысль, что выбор серверных технологий и технологий обработки данных (сервер приложений, web сервисы etc.) окажет решающее влияние на производительность системы.
Да, задача не из простых, поэтому наше ВСУБД имеет свой компонент сохранения, чтоб минимизировать лишние операции мапинга таблиц и объектов (лишнее запросы sql к внешним базам), но если заказчик хочет использовать sql базу, он просто пишет свой компонент расширения (соответственно с ручным мапингом, хотя есть идеи упростить этот этап в разы).
Web сервисы нам не подходят по одной простой причине: невозможность легко организовать работу клиента в оффлайне. Хотя есть идеи, что можно тащить web сервисы к клиенту, но получается осложнения для сторонних разработчиков компонент (наши девелоперы всё стерпят). Поэтому у нас есть свои "web сервисы", называемые компонентами, но с функциональностью, которая нам нужна (работа в оффлайне, простота в разработке). Если заказчику нужны будут веб сервисы, он их с легкостью прикрутит, но мы на них ставку не делаем. Сервер приложений имеется. У нас 3 тирная (или 2 тирная, если нет внешних субд) среда.
V>Я бы не стал рисковать и делать всё своё одним проектом, их нужно делать и проверять как отдельные этапы.
Мы так и делаем

Из за неких проблем, мне придется писать из под анонима.
Shady

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

BTA>Вот беру ILDASM и натравливаю его не exe-шник Navision 3.7. Результат не удивляет — "error: '...\fin.exe' has no valid CLR header and cannot be disassembled." То есть исполняемый файл не дотнетовский (как вариант — может быть запакован какой-нить гадостью). Берем все основные длл-ки — тот же результат. Вопрос — а что в нем дотнетовского-то?

Тоже самое ILDASM говорит на MSCOREE.DLL.

И на devenv.exe из поставки Visual Studio.Net 2003. И на VCSExpress.exe из Visual C# Express. И еще на многие другие "совершенно не-дотнетовские программы".

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

BG>Я бы начал прежде всего с вопросов сколько у Вас есть ресурсов под этот проект?
BG>Временных, денежных, человеческих?
Ресурсы, так сказать, неограничены. Но все же не хочеться, чтоб разработка была вечно.

BG>Объектные базы писать — задача довольно тяжелая и трудоемкая, как тут уже упоминалось, к тому времени как Вы ее допишете — стандартные клиентские машины будут раза в 2 быстрее По затратам получается намного быстрее и дешевле написать объектный диспетчер и повесить его над существующей системой protected storage: SQL, Oracle, MySQL (если хотите конечно
Да, я уже то же склоняюсь к этой мысли.

BG>Вы наверняка собираетесь двигаться в направлении клиент-сервер. дотНет в этом смысле позволяет сделать распределенную аппликуху при минимальных затратах — будь это веб клиент или десктоп клиент. Дальше если сервер, делающий основную работу начинает часто засыпать — можно поставить второй такой серевер и третий.
Продукт для всего рынка, это не "контрактный" продукт под определенную фирму (где можно прогнуть модернизацию PC). Тут такие финты ушами, как "для нашей erp нужны самые передовые компьютеры и гигабитные сети" не прокатят (мыж не ms)

BG>Опять же, нам будет гораздо легче Вам помочь, если Вы расскажете немного о специфике задачи — объемы данных, к-рые необходимо передавать с сервера на клиенты (только недавно читал о проблематичности загрузки длинного 300 000+ списка товаров на вебклиента), род этих данных и т.д.
Мы стараемся как можно сильнее минимизировать пересылки между клиентом и сервером, при этом не потерять безопасность и валидность данных. Данные варьируются от простых данных, до документов.

BG>ERP очень красивый термин, конечно даа, только к сожалению черезчур всеобъемлющий
У нас так же всеобъемлющая erp, которая "может всё (с)"

Shady

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

S_>Не надо издеваться над несчастными компьютерами со 128 ram. Операционная система столько сьедает, и на таких компьютерах желательно больше вобще ничего не запускать (в том числе и .NET приложения). А что дороже стоит дополнительные +128 ram каждому клиенту или цена вашей системы?
S_> Дык эти дополнительные +128 они ж не только для запуска вашей системы могут использоваться...
Мы бы рады, но такая конфигурация вылезла из анализа наших гипотетических клиентов. Потом у нас идея фикс: erp со скоростью света.
Еще раз повторюсь, если есть какое то недопонимание, наша erp не "заказная", она для всего рынка. Мы не можем себе позволить, если клиент покупает нашу erp, чтоб он заменял все свои компьютеры.

Shady

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

А>Создал многопользовательскую систему для работы с удалёнными данными. Её архитектура и основные функции описаны в статье "К вопросу построения прототипа защищённых информационных систем". Проверить работу с 1000 клиентами нет возможности. Хотя можно убрать шифрование и оценить производительность. Работаю с двумя версиями — через .Net Remoting сервис поверх IIS и через .Net Remoting сервис поверх .Net Remoting Server. Большой разницы в производительности не наблюдаю. Но факт — через IIS работают тысячи клиентов. В вашей ситуации видимо надо переложить основные операции по работе с данными на уровень бизнес-логики (по возможности), клиентской части оставить отображение. Крайне важно не передавать на клиентский компьтер не нужную информацию. Детализация данных (по возможности) должна передаваться по дополнительному запросу. Например — выбрать покупателей Ивановых (SELECT на уровене бизнес логики и закачка результирующего набора данных в локальный DataSet) и показать в гриде. Выбор Иванова Петра Егоровича (например правой клавишей мышки) вызовет показ в другом гриде его заказов.
А>Могу утверждать, что клиентский компьютер с таким камнем будет работать, может придется увеличить память до 256.
Дело в том, что у нас "аморфный" клиент, у нас существует уникальная технология (патентуется), которая позволяет не теряя валидность, проводить операции бизнес логики на клиенте, когда он отправляет результаты своей работы, то все данные (обновление, или создание) перепроверяются на сервере. Тем самым клиент не сможет саботировать бизнес логику или проварачивать левые операции (чего не скажешь о axapte, 1c и т.д. (если не использовать их app server'ы) ).

А>Относительно создания собственной базы данных — это горячка. Крепко подумайте, особенно о том, как будете её сопровождать.
Наверное вы правы.

А>Успехов Вам.
Большое спасибо.

Shady

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

PPA>Сколько попросит "самодельный" SQL сервер с 1000-коннектами?
PPA>Не будет он течь, но не по причине того что у .Net есть сборка мусора,
PPA>...а потому, что на машине от такой нагрузки ресурсы кончатся


Shady

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

VD>Ты про развитие по спирали слышал? Вот это оно тебя задело лично. Ну, а что касается до рекламных криков, то их нужно уметь слушать с здравой долей скепсиса. Иначе уши до пола оттянутся от лапши.
Я знал, что это была большая чушь. Просто офигивал от промывки мозгов (когда со всех сторон, во всех статьях rich client MUST DIE!!!! ), а вот теперь обратное действо. sic.

Shady

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

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

S>>1) Проект stand alone — всё в себе, в том числе и база. То есть заказчик не будет платить за продукт + еще базу (причем база может дороже продукта), а сразу получить всё готовое (mysql, или другие бесплатные базы не подходят), хотя клиент может выбрать и готовую через драйвер базы.

VD>Есть совершенно бесплатный MSSQL Express (теперича, ранее Desctkp Edition). Нистоит ничего. При этом дает возможность если что легко перепрыгнуть на полноценный MSSQL в плодь до энтерпразной версии. Почему не рассмотреть его?
Для некомерческих проектов и для баз с < 4 гигами

VD>Так же есть InterBase в бесплатном варианте. Да и вообще много чего есть.
Для некомерческих проектов.

VD>Создание собственной СУБД — это оечнь большой труд, даже если сама СУБД очень простенькая. Такие вещи как отказоустойчивость и производительность требуют нехилых знаний и очень больших временных затрат. Самый дохлый сервер вроде майсиквела писался многие годы чтобы достичь хотя бы текущего состояния. По-моему, вы делаете стратегический просчет.
Спасибо за совет. Вроде желанее писать ВСУБД отпало Мы просто оставим место для оной, что впоследствии можно было прикрутить, а пока сделаем персистные компоненты под MS SQL, ORACLE, MYSQL.

Я сейчас всё больше и больше склоняюсь к c#.

Shady

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

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

PPA>>>p.s.
PPA>>> А чем Вам готовые СУБД не подошли?
S>>1) Проект stand alone — всё в себе, в том числе и база.

PPA>Это условие клиента?
У нас нет клиента, мы делаем продукт для рынка.

S>>То есть заказчик не будет платить за продукт + еще базу (причем база может дороже продукта), а сразу получить всё готовое (mysql, или другие бесплатные базы не подходят),

PPA>Написать свою субд, способную держать одновременно 1000 активных коннектов...
PPA>Вы случаем не камикадзе?
Мы вообще сумасшедние люди

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

PPA>Тут я не понял, что еще за драйвер?
PPA>т.е. пользователь может выбрать любую субд?
PPA>тогда что будет делать ваша самодельная БД?
У нас идея: с erp по дефолту поставляется наша база (уменьшает стоимоть), если клиент хочет использовать что-то от грандов, то пожалуйста. Эта идея (с нашей БД) частично отпала. Мы может быть сделаем нашу БД в будущем, взамен в дефолтной поставке будут драйвера для бесплатных баз.

PPA>Имхо если не завязываться под конктретный сервер — тормоза на уровне
PPA>БД гарантированны.
У нас "хитрые" дравера. Описать я их не могу (то же вроде патентуется). Прошли испытания, никаких тормазов
Причем можно очень легко писать новый драйвер под новую БД.

PPA>Создание ERP, (а особенно ее внедерение) сложная задача, а Вы еще
PPA>беретесь за создание своей субд...
Сейчас браться не будет (создавать БД), в будущем... А про сложность erp: "волков бояться, в лес не ходить"

PPA>Рисковано... Что хоть Вам сделают если не получится?
Как говоил Ильич: "РАССТРЕЛЯТЬ!". Мне лично ничего не сделают (уж слишком я уникальный) Рисковано да, потом в нашей erp реализовано очень много уникальных фич, коотрые у sap и ms могут появиться только в будущем. Потом наша erp сама по себе уникальна, она позволяет построить на своей основе от CRM до документооборота, причем без последствий для производительности и удобства использования. Она "мега расширяема" (так в драфтах проекта ) без потери целостности и безопастности

>>Тоже самое ILDASM говорит на MSCOREE.DLL.

>>И на devenv.exe из поставки Visual Studio.Net 2003. И на VCSExpress.exe из Visual C# Express. И еще на многие другие "совершенно не-дотнетовские программы".

Хочешь гадость скажу? А кто тебе сказал, что ЭТИ exe-шники на дотнети написаны? Написаны они на C++, не более того!



—

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Приветствую,
вы знаете, приведу еще пару доводов по данному вопросу.

Во-первых, для тех, кто еще помнит, как создавалось ПО на Visual Studio 6.0, сколько там было разных сущностей для работы, например, со строками.
Давайте посчитаем: char *, basic_string template из STL, CString, BSTR, CComBSTR из ATL, класс _bstr_t, всякие макросы типа OLESTR, L"", _T() и т.д. Затем, String из Visual Basic 6, на котором писались ActiveX визуальные компоненты. Наверняка я не все вспомнил. И сколько памяти, утечек и времени уходило в результате таких преобразований?
Неужели наличие одного типа System.String в .NET Framework не убеждает в большей производительности создания и готового кода?

И второе.
>MS SQL или ORACLE, ВСУБД можно назвать объектной >надстройкой над другими СУБД, но с большой натяжкой.
Есть такой опыт. Что называется, не оглашая имен, скажу, что одна московская фирма, между прочим, как считается, российский лидер автоматизации одной из отраслей промышленности, два года делала проект, включающий в себя объектную СУБД поверх SQL, как минимум Oracle и MS SQL Server. Так вот, как раз это ядро весьма далеко от совершенства, и ему предстоит серьезная переделка после эксплуатации в реальных условиях. А время и деньги затрачены.
Вот такие бывают истории.
Желаю вам удачи в выборе технологий.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

VD>>Так же есть InterBase в бесплатном варианте. Да и вообще много чего есть.
А>Для некомерческих проектов.

Это не так.

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

А>Приветствую,
А>вы знаете, приведу еще пару доводов по данному вопросу.

А>Во-первых, для тех, кто еще помнит, как создавалось ПО на Visual Studio 6.0, сколько там было разных сущностей для работы, например, со строками.
А>Давайте посчитаем: char *, basic_string template из STL, CString, BSTR, CComBSTR из ATL, класс _bstr_t, всякие макросы типа OLESTR, L"", _T() и т.д. Затем, String из Visual Basic 6, на котором писались ActiveX визуальные компоненты. Наверняка я не все вспомнил. И сколько памяти, утечек и времени уходило в результате таких преобразований?
Да почему, в VS 7.1 ничего не изменилось. Еще Variant — чума com.

А>Неужели наличие одного типа System.String в .NET Framework не убеждает в большей производительности создания и готового кода?
Где то я слышал, что стринги нета быстрее stl.

А>И второе.
>>MS SQL или ORACLE, ВСУБД можно назвать объектной >надстройкой над другими СУБД, но с большой натяжкой.
А>Есть такой опыт. Что называется, не оглашая имен, скажу, что одна московская фирма, между прочим, как считается, российский лидер автоматизации одной из отраслей промышленности, два года делала проект, включающий в себя объектную СУБД поверх SQL, как минимум Oracle и MS SQL Server. Так вот, как раз это ядро весьма далеко от совершенства, и ему предстоит серьезная переделка после эксплуатации в реальных условиях. А время и деньги затрачены.
А>Вот такие бывают истории.
А>Желаю вам удачи в выборе технологий.
Спасибо за пример.

Shady

Кстати, стоит ли забивать на unix? Я понимаю, что тема не раз вроде всплывала, и всё таки?
Маркетологи где то нашли цифры в 10-15% клиентов, пожелавших чтоб сервер работал на unix, и что это одна из фич, на которую смотрят клиенты. Когда там .net перекатит на unix, и будет ли это бесплатным (хотя проект mono заслуживает внимания, только я там не понял, бесплатный ли он будет).
Да и снежение стоимости опять. Так как мне принимать решение (маркетологи и так мозги все прожужали), это теперь главный вопрос в выборе платформы для меня.

Shady

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

VD>>>Так же есть InterBase в бесплатном варианте. Да и вообще много чего есть.
А>>Для некомерческих проектов.

iT>Это не так.

Да действительно, извините, если кого ввел в заблуждение.

Shady

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

VD>Ты про развитие по спирали слышал?
Это типа:

Что в этом году не спёрли, то в следующем поспирали!

Здравствуйте, <Аноним>, Вы писали:

А>Мы бы рады, но такая конфигурация вылезла из анализа наших гипотетических клиентов. Потом у нас идея фикс: erp со скоростью света.
А>Еще раз повторюсь, если есть какое то недопонимание, наша erp не "заказная", она для всего рынка. Мы не можем себе позволить, если клиент покупает нашу erp, чтоб он заменял все свои компьютеры.

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

Shhady -> "Стоит ли делать на .net erp систему?" :

S> Хотел поинтересоваться, можно ли реализовать erp систему на c#,
S> которая может обслуживать до 1000 юзеров одновременно, да еще и
S> распределенно (юзеры частично выполняют бизнес логику), да еще со
S> своей объектной базой данных (то же на .net)? Клиенты smart'ы.
S> Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)?
S> Да еще в наших суровых условиях (когда компы у юзеров ну
S> максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и
S> бутерброды с колбасой хавали, пока клиентское приложение удасужит
S> загрузиться?

Я так думаю, что к тому времени как все это допишется — у пользователей
будут стоять нормальные машины с виндой 2010

Yury Kopyl aka hrg | http://id.totem.ru | Все вышесказанное является моим
личным мнением и может быть использовано против вас

Здравствуйте, <Аноним>, Вы писали:

VD>>Есть совершенно бесплатный MSSQL Express (теперича, ранее Desctkp Edition). Нистоит ничего. При этом дает возможность если что легко перепрыгнуть на полноценный MSSQL в плодь до энтерпразной версии. Почему не рассмотреть его?
А>Для некомерческих проектов и для баз с < 4 гигами

Почему для некомерческих? Это не так. Ну, на на чет 4 гиг... Если компания работает с таими объемами, то или она занимается фигней, или ей просто таки прямая дорога к полноценному коммерческому серверу БД.

А>Спасибо за совет. Вроде желанее писать ВСУБД отпало Мы просто оставим место для оной, что впоследствии можно было прикрутить, а пока сделаем персистные компоненты под MS SQL, ORACLE, MYSQL.

Это намного более разумно. Но я бы посоветовал остановиться на одном сервере. Или хотя бы выбрасить MYSQL. Дело в том, что создать полноценное высокопроизводительное решение для серверов с таким разным АПИ и возможностями тоже очень не просто. А MYSQL вообще слишком убог и не имеет ни одного приемущества перед MSSQL Express.

А>Я сейчас всё больше и больше склоняюсь к c#.

Ну, c# для безнес — софта, на мой взгляд — это лучший выбор.