|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Sergey Pratch 2:5020/400 06 Mar 2001 01:20:16 To : All Subject : Re: MS SQL 2000 -------------------------------------------------------------------------------- Hi! "Andrey" <Andrey@p5.f13.n5083.z2.fidonet.org> сообщил/сообщила в новостях следующее: news:2855865105@p5.f13.n5083.z2.ftn... > SP> Попрошу не передергивать, не надо путать "божий дар с > SP> яишницей". И уж AS/400 точно не божий дар. Просто довольно > SP> неплохо узкоспециализированная, сбалансированная система. > AS/400 это пожалуй самый дешовый вариант ядра высоконадежной корпоративной > системы. К сожалению текстовый терминал при количестве рабочих мест более 100 > по прежнему является единственно правильным решением для развертывания реально > работающих корпоративных систем.По крайней мере это гарантированно работающее > и прикрасно отлаженное решение. Какой то альтернативой текстовому терминалу > является только Жаба и X-Windows,но лично я живьем не видел еще реально > работающих информационных систем на их основе. Дык, в Инет-е куча сайтов на Жабе сделано, и обслуживают они, как ты понимаешь не одну сотню клиентов. Хотя илюзи Жабы тают каждый день. А на счет текстовых терминалов - AS/400 + 50 шт. фирменных терминалов будут стоить не намного дешевле, чем один хороший Dell-ский 2-х процессорный сервер и 50 шт. персоналок на Celeron 400. А если приложить к этой суме стоимость разработки ПО и его внедрения, то картина может оказатся далеко не в пользу AS/400. Эта штука хороша там, где уже есть аналогичные решения на ней и необходимо сделать только самую малость - настроить, подправить выходные формы, т.е. "на все про все" - не более 2-3 месяцев притирки. В любом случае, к этим терминалам необходимо еще и как-то притеры прикрутить. Матричники - вчерашний день и по нынешним меркам дорогостоящие в обслуживании, да и стыдно будет перед конкурентами, лазерники - довольно тяжело с ними сопрягаются, струйники - практическин не сопрягаемы, да и для своей работы в большинсте случаев требуют растеризации выходных форм, а при 50 терминалах для этих целе придется ставить отдельный ящик. Hо самая большая проблема в этом случае - огромная завивисимость всей системы от комманды программистов. Малейшие изменения в системе завязываются полностью на них. А если используются персоналки, то первый удар берут на себя сами пользователи - с помощью того же Excel. А программисты идут уже по проторенной дорожке, что позволяет вывести их руководителю их комманду из цейнтнота. Только не надо мне рассказывать сказки о том, что в настоящих которах все реализовывается средствами БД и Excel даже на показ нет. Когда изменения в отчетах меняются за 2-3 дня до их сдачи, будь у тебя в комманде сам БГ, ничего ты не успеешь по нормальному переделать. А вот то, что прожило после этапа своего рождения некий период времени легко переносится в приложения. -- С уважением, Сергей Прач ================= Please, send you private mail to: s_pratch@mail.ru --- ifmail v.2.15dev5 * Origin: Solver Ltd. site #2 (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/15014749748e0.html, оценка из 5, голосов 10
|