Здравствуйте, Merle, Вы писали:
V>>Ну озвучь ты плиз подробности этого "осторожно". Весь день интригуешь. M>Ничего я не интригую, я уже писал — передаешь все одним батчем, да и пулинг не забывать отключать.
Я про varbinary спрашивал. Размер батча в MS SQL — 4k в юникодном режиме.
V>>>>Отчеты по документам не строят. Их по данным строят. M>>>А данные откуда берутся? V>>Из БД. M>И откуда они в БД попадают?
Из системы ввода первички.
V>>Раздать право на одну папку и поставить политику "распространять на дочерние объекты". Думаю, секунд за 7 вложусь. В принципе, могу и как install-action прикрутить, чтобы никому не пришлось ручками это делать. M>И так каждый раз с каждым типом документов?
Ага, понял момент нестыковки. В общем нет, доступ к классам документов — на уровне всей системы (базы). Само же приложение работает с файлами только лишь по одному специальному аккаунту. Юзвери напрямую к файлам не общаются, они получают к себе копии файлов и отсылают их системе для сохранения.
V>>По мне до 50-100 мег. M>То есть все что больше этого размера не заслуживает хранения в БД? Ну, вот, скажем, та же RSDN-овская база, о которой AVK писал, 3 гига объемом и только и делает что растет. Согласно твоей логике мы должны вынести все тексты сообщений в отдельные файлы и хранить их там, для увеличения надежности...
Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени, и если бы сообщений были единицы тысяч, а размер каждого — многие метры, то да. Если же эти условия не выполняются, то в БД лучше. А если бы характер работы RSDN был другой — например, данные активно редактировались бы, то можно и 2 базы сделать — для архивного контента + OLAP и для OLTP.
Здравствуйте, vdimas, Вы писали:
V>Я про varbinary спрашивал. Размер батча в MS SQL — 4k в юникодном режиме.
Размер батча 8k*PacketSize, народ по двести метров в XML-е гоняет, и ничего...
V>>>>>Отчеты по документам не строят. Их по данным строят. M>>>>А данные откуда берутся? V>>>Из БД. M>>И откуда они в БД попадают? V>Из системы ввода первички.
То есть из документов?
V>Ага, понял момент нестыковки. В общем нет, доступ к классам документов — на уровне всей системы (базы). Само же приложение работает с файлами только лишь по одному специальному аккаунту. Юзвери напрямую к файлам не общаются, они получают к себе копии файлов и отсылают их системе для сохранения.
Ну это же все надо настраивать, отдельно в базе, отдельно в ФС...
V>Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени,
До недавнего времени там целерон девятисотый был, баксов за 400 вся система... Да и сейчас до 4 штук мы больше тысячи недобираем...
V> и если бы сообщений были единицы тысяч,
То есть пока единицы тысячь, то можно в файлах, а как за миллион перевалило, то опять в БД?
V> а размер каждого — многие метры, то да. Если же эти условия не выполняются, то в БД лучше.
Но ведь изначально речь шла о почтовой системе, а там, как правило, нету многих метров.. размер среднего почтового сообщения как раз равен размеру сообщения на rsdn...
V>А если бы характер работы RSDN был другой — например, данные активно редактировались бы, то можно и 2 базы сделать — для архивного контента + OLAP и для OLTP.
Это уже совсем отдельный разговор...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, vdimas, Вы писали:
V>>Я про varbinary спрашивал. Размер батча в MS SQL — 4k в юникодном режиме. M>Размер батча 8k*PacketSize, народ по двести метров в XML-е гоняет, и ничего...
V>>>>>>Отчеты по документам не строят. Их по данным строят. M>>>>>А данные откуда берутся? V>>>>Из БД. M>>>И откуда они в БД попадают? V>>Из системы ввода первички. M>То есть из документов?
Чаще всего нет! На самом деле реально пока существует приличный разрыв м/у данными в БД и документами обычных MS Office. В общем, это отдельная тема... Скорее, ближе к OLE и организации делопроизводства. Просто "обычная" учетная система обслуживает очень маленькую разновидность документов. Я еще не видел ни одной системы, которая полностью и качественно обслуживала приказы, заявления, контракты и т.п.
К тому же бывают еще такие стандарты и протоколы EDI-направления. Но они у нас широко не используются, и ввод первички по большей части — ручной. Для преодоления этого нужно повсеместное широкое применение стандартов B2B-EDI. Ключевое слово здесь — широкое. Ибо избавиться от ручного ввода первички можно только в случае, если партнер поддерживает совместимый стандарт.
V>>Ага, понял момент нестыковки. В общем нет, доступ к классам документов — на уровне всей системы (базы). Само же приложение работает с файлами только лишь по одному специальному аккаунту. Юзвери напрямую к файлам не общаются, они получают к себе копии файлов и отсылают их системе для сохранения. M>Ну это же все надо настраивать, отдельно в базе, отдельно в ФС...
В базе и так придется настраивать, а отдельно в ФС — не вижу проблем настроить разрешения для всего одной учетной записи для всего одного хранилища.
V>>Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени, M>До недавнего времени там целерон девятисотый был, баксов за 400 вся система... Да и сейчас до 4 штук мы больше тысячи недобираем...
До недавнего времени и база ваша вроде бы менее двух гиг была — копейки по сути.
V>> и если бы сообщений были единицы тысяч, M>То есть пока единицы тысячь, то можно в файлах, а как за миллион перевалило, то опять в БД?
стоило ли комментировать часть сообщения? даже не понятно что ответить, ибо в такой постановке сама озвучка вопроса нелепа...
V>> а размер каждого — многие метры, то да. Если же эти условия не выполняются, то в БД лучше. M>Но ведь изначально речь шла о почтовой системе, а там, как правило, нету многих метров.. размер среднего почтового сообщения как раз равен размеру сообщения на rsdn...
Хотя, я как раз "зацепился" на ветку о документообороте. Кто-то поднял одну тему, мы обсуждаем все соседние.
Да, по существу коментария так и не было.
V>>А если бы характер работы RSDN был другой — например, данные активно редактировались бы, то можно и 2 базы сделать — для архивного контента + OLAP и для OLTP. M>Это уже совсем отдельный разговор...
И я про то. Зачем натягивать мою логику на "отдельный разговор"? Для меня вообще догм и предпочтений нет. Каждый случай для меня — тот самый отдельный разговор. И я не пытаюсь натянуть какие-то "всем известные вещи" туда, где они не натягиваются.
Здравствуйте, vdimas, Вы писали:
V>Как всегда, подобные обсуждения свелись к советам насчет аппаратуры. Поздравляю, Вы не оригинальны. V>Можно вопрос на засыпку? А если на фирме НЕТ технического директора и не планируется?
Ээээ... Держитесь подальше от таких фирм, мой вам совет
V>Менять ленточки — это вообще пестня. Как ты собрался выпускать такую систему на рынок для "широкого" потребления?
Ну вообще-то есть ленточные библиотеки с ченжерами. Не такие уж и дорогие, кстати по отношению к потенциальным предотвращенным убыткам в результате краха массива.
V>Да нет, люди хотят пользоваться обычными WORD-ами и EXCEL-ами, причем, хранить там не только "свои", но и "чужие" документы.
Здравствуйте, Vladimir V Kochetkov, Вы писали:
V>>Можно вопрос на засыпку? А если на фирме НЕТ технического директора и не планируется?
VVK>Ээээ... Держитесь подальше от таких фирм, мой вам совет
Совет хороший, разумеется. Жаль, что таких фирм — 90% потенциального рынка (торговые средние и мелкооптовые предприятия).
V>>Да нет, люди хотят пользоваться обычными WORD-ами и EXCEL-ами, причем, хранить там не только "свои", но и "чужие" документы.
VVK>Что в вашем понимании "документооборот" ?
а в твоем?
Документооборот — это автоматизированные сценарии работы с документами. Конкретная степень автоматизации (и набор возможностей) зависит от расшифровки понятия "документ", которая может быть весьма широкой. Если тебе показалось, что я ограничиваю понятие документа лишь порождениями офисных ворда и екселя, то это заблуждение. Кстати, один из разработанных модулей на одной из предыдущих работ — это модуль по обслуживанию контрактов и договоров (самая интересная область в автоматизированном документообороте, ИМХО, после EDI). Никакими MS-офисными документами там и не пахло, ну разве что в момент формирования твердой копии.
Здравствуйте, vdimas, Вы писали:
V> Просто "обычная" учетная система обслуживает очень маленькую разновидность документов. Я еще не видел ни одной системы, которая полностью и качественно обслуживала приказы, заявления, контракты и т.п.
То есть документы о которых ты ведешь ресь, можно сравнить с аттачментами в почтовой системе? Как бы к реальной отчетности они отношения не имеют, но вес придают...
V>В базе и так придется настраивать, а отдельно в ФС — не вижу проблем настроить разрешения для всего одной учетной записи для всего одного хранилища.
Ну вот юзер Вася имеет правво обращаться к документу "А", а к документу "Б" не имеет, а юзер Дима — наоборот... Как разрулить? А если при этом у юзера Вася обломалась запись документа, как он из своей локальной копии документ восстановит, если у него нет соответствующих прав?
V>До недавнего времени и база ваша вроде бы менее двух гиг была — копейки по сути.
Ну да, полтора гига, что, примерно, на полтора порядка больше озвученных тобой 50-100 метров...
V>>> и если бы сообщений были единицы тысяч, M>>То есть пока единицы тысячь, то можно в файлах, а как за миллион перевалило, то опять в БД? V>стоило ли комментировать часть сообщения?
А почему не стоило?
V> даже не понятно что ответить, ибо в такой постановке сама озвучка вопроса нелепа...
Что здесь нелепого? Я полностью следую твоей логике — ты выдвигаешь ряд условий в которых БД хуже твоей системы, я привожу реальную ситуацию, которая под твои условия не подходит и делаю предположение, что, наверное, в этом случае БД все-таки подходит, в чем я ошибся?
V>Хотя, я как раз "зацепился" на ветку о документообороте.
Где в этой ветке, до тебя, хоть слово про документооборот??
V>Да, по существу коментария так и не было.
По какому существу? По существу мы давно уже уползли от существа...
V>И я про то.
Про что?
V> Зачем натягивать мою логику на "отдельный разговор"?
Это уже не логика, это уход от темы...
V> Для меня вообще догм и предпочтений нет.
Каждый волен демонстрировать свободу творчества...
V> Каждый случай для меня — тот самый отдельный разговор.
Тогда не надо натягивать свое решение, своей ситуации, в качестве ответа на чужую задачу совершенно другого класса и в других условиях. Рассматривай данную тему, как разговор отдельный от твоего опыта с документооборотом.
V>И я не пытаюсь натянуть какие-то "всем известные вещи" туда, где они не натягиваются.
Нет, ты пытаешься натянуть только тебе известные вещи, на задачу отличную от твоей, что гораздо хуже...
Здравствуйте, Merle, Вы писали:
V>> Просто "обычная" учетная система обслуживает очень маленькую разновидность документов. Я еще не видел ни одной системы, которая полностью и качественно обслуживала приказы, заявления, контракты и т.п. M>То есть документы о которых ты ведешь ресь, можно сравнить с аттачментами в почтовой системе? Как бы к реальной отчетности они отношения не имеют, но вес придают...
Странный у тебя взгляд на вещи. По твоему, документы — это только цифры? Например, приказ по предприятию сделать 9-е Марта выходным днем — вполне себе документ.
V>>В базе и так придется настраивать, а отдельно в ФС — не вижу проблем настроить разрешения для всего одной учетной записи для всего одного хранилища. M>Ну вот юзер Вася имеет правво обращаться к документу "А", а к документу "Б" не имеет, а юзер Дима — наоборот... Как разрулить? А если при этом у юзера Вася обломалась запись документа, как он из своей локальной копии документ восстановит, если у него нет соответствующих прав?
Ну уж озадачил по-взрослому... Оставляю эту "сверхсложную" диллему в качестве домашнего задания... ну или попроси какого-нибудь студента подкинуть идеи на этот счет.
V>>До недавнего времени и база ваша вроде бы менее двух гиг была — копейки по сути. M>Ну да, полтора гига, что, примерно, на полтора порядка больше озвученных тобой 50-100 метров...
Озвученные мною цифры относились к "маленькой" базе, причем здесь это? Ну не "маленькая", а "средненькая".
V>> даже не понятно что ответить, ибо в такой постановке сама озвучка вопроса нелепа... M>Что здесь нелепого? Я полностью следую твоей логике — ты выдвигаешь ряд условий в которых БД хуже твоей системы, я привожу реальную ситуацию, которая под твои условия не подходит и делаю предположение, что, наверное, в этом случае БД все-таки подходит, в чем я ошибся?
Слушай, а нужен ли нам форум, чтобы продолжать маяться подобной вот ерундой?
То есть все что больше этого размера не заслуживает хранения в БД? Ну, вот, скажем, та же RSDN-овская база, о которой AVK писал, 3 гига объемом и только и делает что растет. Согласно твоей логике мы должны вынести все тексты сообщений в отдельные файлы и хранить их там, для увеличения надежности...
Никакой моей логике ты не следовал, так что причем здесь вообще RSDN-овская база?
M>Где в этой ветке, до тебя, хоть слово про документооборот?? ...
... M>По какому существу? По существу мы давно уже уползли от существа...
... M>Это уже не логика, это уход от темы...
Не поленился просмотреть с чего началась подветка... В общем, вы, мягко говоря, загоняете, сударь...
V>> Каждый случай для меня — тот самый отдельный разговор. M>Тогда не надо натягивать свое решение, своей ситуации, в качестве ответа на чужую задачу совершенно другого класса и в других условиях. Рассматривай данную тему, как разговор отдельный от твоего опыта с документооборотом.
Еще раз, идем в самое начало. Была просьба накидать мысли, где в каких случаях приемлимо одно, а где другое (ФС vs БД). Я и накидал. Причем, весьма четко обрисовал условия, при которых хранение инф. в файлах считаю обоснованным. Специально прошелся еще раз по ветке и так и не понял, при чем тут ваша база RSDN и куда лепить эти твои последние замечания?
V>>И я не пытаюсь натянуть какие-то "всем известные вещи" туда, где они не натягиваются. M>Нет, ты пытаешься натянуть только тебе известные вещи, на задачу отличную от твоей, что гораздо хуже...
На какую задачу?
-----------------
В общем, свои мысли я высказал и добавить мне нечего. Могу лишь сделать очевидный вывод за читателя, если кто успел потерять нить беседы за 5-ю последними бесполезными обменами междометиями.
1. Из личного опыта установлено, что если база хранит "большие" блобы, то при определенных условиях может начаться быстрый бесконтрольный рост размеров логов транзакций, что накладывает определенные требования на систему резервирования и сами сценарии резервирования.
2. Эти "определенные" условия были отличительной чертой клиент-серверной архитектуры, но! Большинство даже нынешних серверов приложений способны спровоцировать описанную ситуацию. Любая ситуация, где в прикладной логие создается транзакция и выполняется более, чем одна операция по модификации данных в рамках транзакции, но не в рамках одного батча — преттендент на получение описанного эффекта. (С той оговоркой, что чем короче длительность транзакций, тем меньше вероятность нарваться на описанную ситуацию)
3. Вероятность проявления вышеописанного эффекта приводит к тому, что требуется присутствие админа возле базы, что было неприемлимым условием. Во многих случаях применений систем Автора вероятность возникновения подобного эффекта была очень высока, ввиду низкой надежности техники и сети, что потребовало доп. мер по устранению эффекта. Как одна из мер — вынести большие блобы из БД.
4. Автор согласен хранить любыые данные в БД, если технические или организационные условия позволяют.
5. Для систем "будущего", с "большими и бесконечными" ресурсами проблема не исчезает, а лишь меняет свои характеристики. Например, "большой" документ может означать для нынешний условий блоб размером от 100MB-300М (видео, "сырое" аудио, растровые макеты высокого разрешения и т.д.).
Vladimir V Kochetkov wrote: > V>Как всегда, подобные обсуждения свелись к советам насчет аппаратуры. > Поздравляю, Вы не оригинальны. > V>Можно вопрос на засыпку? А если на фирме НЕТ технического директора и > не планируется? > Ээээ... Держитесь подальше от таких фирм, мой вам совет
Да, да. Держитесь подальше, как можно дальше.
(Чтобы мы могли им продавать свой софт).
Таких фирм — подавляющее _большинство_, особенно в регионах. Так что же
теперь, наплевать на огромный рынок потенциальных клиентов?
Здравствуйте, Merle, Вы писали:
GZ>>Классификаторов с сохранением пути. M>NS как раз и есть оно самое.
В честь чего? NS это некоторое дерево, которое подстроено так чтобы удобно было выгребать данные ветками. Как результат, при вставке новой ноды приходится его апдейтить не по детски. Системы где в ноде лежит полный путь от рута до self, такой проблемы нет. Существует проблема переноса веток. Приходится апдейтить все дочерние элементы. Для OP c xml это было неважно.
GZ>>Набор аттрибутов. M>Набор атрибутов — это кортеж, а не тип кортежей.
Набор аттрибутов — это домен. M>Ты хочешь сказать, что в одном отношении получаемом после OP в кортежах разный набор атрибутов? Тогда бы это не было отношением и реляционный движек не смог бы с этим работать.
Смотря что является результатом. То что до операции UDX или после UDX.
GZ>>Не зря. Пробовал. M>Как можно таблицу не запихнуть в БД?
Проблема не в таблице, а в интерпретации. Таблицу можно и в экцел запихнуть. Проблема существует в построении предиката для получения всех дочерних элементов первого уровня. Типа select @x.query('/*'). Далее проблема в получении различных объектов, когда у нас может быть как объект person так и объект automobile. Хотя второе для моей постановки не нужно было.
GZ>>Любую операцию SQL2000 можно описать набором базовых реляционных операций. M>Не-а. Например, как раз засада с доменами — современные СУБД, позволяют выполнять операции с разными доменам, чего с точки зрения реляционной алгебры быть не должно. Одно из Коддовских SQL flaw, если я правильно помню...
Если ты о потери идентифицируемости доменов, то ее можно описать реляционными операциями.
M>>>Что в нем нереляционного? GZ>>Не путай результат, и работу. M>Я-то как раз ничего не путаю, все это время я говорю исключительно о результате, а ты почему-то пытаешься приплести именно механику работы самого OP. В данном случае меня совершенно не интересует как OP работает, о чем я уже писал ни раз. Как работает — это другой разговор, можем обсудить отдельно.
Дык результат можно посмотреть на экране. А вот работа, даже на уровне плана запросов значительно интересней. И к тому же непонятно что ты называешь OP. Для меня это всего лишь таблица. Ты по моему под этим подразумеваешь механизм полностью. Давай сначало в этом разберемся. И что является то что ты называешь результатом: набор реляционных операций которые построены по xquery и будут выполнены реляционным механизмом, или реляционное отношение как результат выполнения xquery.
Здравствуйте, vdimas, Вы писали:
V>Ты действительно не знаешь, откуда громадные логи беруться или прикалываешься? V>А характер работы с данными какой у вас? V>У вас же внесли — и забыли, потом read-only только. А представь, например, перепровести складскую накладную недельной/месячной давности (т.е. заново товар расписать). Оно же тянет удаление и расписывание по-новой всех движений, что были после перепроводимого документа. Это единовременное удаление/создание/изменение сотен тысяч строк движений в базе. И таких фокусов стабильно по нескольку в день (у крупных оптовых торгующих фирм). Вряд ли бы я особо обратил на эти проблемы сейчас, но тогда был 1999-й, система была клиент-серверной (кстати, RSDN — не клиент-сервер, а N-tier ), так вот, в случае подвисших транзакций на основном серваке банально начинало заканчиваться свободное место на дисках с устрашающей скоростью, надо срочно было делать полный бэкап и сброс логов. Поборол все, конечно... с тех пор от клиент-сервера держусь подальше
Из всего перечисленого не понял двух вещей. Во первых — какая тут разница между клиент-сервер и N-tier. Ну а во вторых — зачем тебе нужны были подвисшие транзакции?
GZ>Из всего перечисленого не понял двух вещей. Во первых — какая тут разница между клиент-сервер и N-tier. Ну а во вторых — зачем тебе нужны были подвисшие транзакции?
Давай так, ты прочтешь эту ветку, а потом опять спросишь. А то мне придется много copy&paste для тебя делать...
Здравствуйте, Merle, Вы писали:
M>То есть все что больше этого размера не заслуживает хранения в БД? Ну, вот, скажем, та же RSDN-овская база, о которой AVK писал, 3 гига объемом
Да бог с тобой. 3 гига она была года два назад. Сейчас 7.5. Лог на старой БД был > 3 гигов (это к вопросу о коротких логах на rsdn). На текущей лог 600М, видимо 2005 сиквел в этом отношении получше стал.
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
Здравствуйте, vdimas, Вы писали:
V>Чаще всего нет! На самом деле реально пока существует приличный разрыв м/у данными в БД и документами обычных MS Office.
InfoPath спасет отца русской демократии?
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
Здравствуйте, vdimas, Вы писали:
V>Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени
Во-первых не за 4, а за 3, во-вторых основные деньги там потрачены на производительность и юнитовое исполнение, в третьих это самое обычное самосборное железо, ничего необычного в нем нет, такое железо может себе позволить даже маленькая контора, не говоря уж о тех, для которых потеря нескольких минут смерти подобно.
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
Здравствуйте, vdimas, Вы писали:
GZ>>Из всего перечисленого не понял двух вещей. Во первых — какая тут разница между клиент-сервер и N-tier. Ну а во вторых — зачем тебе нужны были подвисшие транзакции?
V>Давай так, ты прочтешь эту ветку, а потом опять спросишь. А то мне придется много copy&paste для тебя делать...
Прочитал. Во многом с Merle согласен. Это ошибка архитектуры. Для справки, в то время я также работал с тиражирумым документооборотом. Особых проблем у пользователей не возникало. Подобные проблемы решались до разработки и в процессе. Теперь по сути.
1. Все имеет свою стоимость. Это настолько ясная истина которая ясна любому покупателю. Очень непонятно, почему это непонятно производителю. Итак, все имеет свою стоимость. И нормальный инкрементальный backup также. Когда я иду в магазин, я знаю что, то что дороже — чем-то лучше. И я спрашиваю у продавца, чем оно лучше. И он мне может ответить. Точно так же и в программном обеспечении. Нужно всегда знать ответ почему то, или иное решение лучше. В 1999 году, если сравнивать SQL 7.0 и Oracle 7.3+восьмерка уже появилась, это были небо и земля. И мы знали почему. В том числе и в плане надежности. И в том числе, то что у Oracle класнейший инкрементальный архивный backup который можно отвертеть до определенного времени. Что в купе с остальными достоинствами формулировалось в более надежную систему защищенную от сбоев за которую нужно больше заплатить. Если вы не можете заплатить(а достоинств у Oracle значительно больше чем только это), берите дешевле с MS SQL 7.0.
2. Насчет блобья и документов. Хранить бинарные документы в БД — в те года была плохая идея. И тут было много причин. Внедрение блобья в базы данных только началось(в Oracle 7.3 его и не было). Скорость была более чем не ахти. Повышенная нагрузка на rollback. Невозможность нормального индексирования. Достаточно много других ограничений. Поэтому выбора особо между файловой средой и базой — не было. Неструктурированные документы — на диске, структурированная информация, и информация о хранящихся документах, на сервере БД. И все должно бэкапиться.(существует правда одна проблема — рассинхронизации бэкапа, но это другая, также решаемая песня).
3. Зависшие транзакции — это проблема архитектуры решения. Они тянутся от двух вещей — невнимательность при работе с rollback + длинные транзакции. Даже если такое присутствует, нужно вполне конкретно описать пользователям что когда происходит. И что им делать в том, или ином случае. Если нету DBA — то информация должна быть предоставлена на таком уровне, чтобы это понял простой администратор. Если нету администратора, то нужно предоставлять чтобы понял пользователь. И тогда проблем уже не возникнет. А если возникает, то не по вашей вине. Мертвая БД может возникать по 3 причинам: ошибка разработчика, ошибка админа, ошибка железа. Зависшие транзакции по первым двум причинам.
AndrewVK wrote: > V>Чаще всего нет! На самом деле реально пока существует приличный разрыв > м/у данными в БД и документами обычных MS Office. > InfoPath спасет отца русской демократии?
Вы _в_ _реальной_ _жизни_ его использовали? В примерах в MSDN все
выглядит замечательно, и может с выделенным админом-MCSE оно и будет
работать.
Но не в наших фирмочках, где еще куча компов под Win98 стоит.
AndrewVK wrote: > Во-первых не за 4, а за 3, во-вторых основные деньги там потрачены на > производительность и юнитовое исполнение, в третьих это самое обычное > самосборное железо, ничего необычного в нем нет, такое железо может себе > позволить даже маленькая контора, не говоря уж о тех, для которых потеря > нескольких минут смерти подобно.
90% контор у нас в регионах удавятся за $300 на новое железо — это
жизненный факт. Например, мы продаем свой продукт по 700руб. на рабочее
место — заказы крупнее нескольких тысяч рублей идут в основном из
Москвы/Питера.
Здравствуйте, Cyberax, Вы писали:
C>Вы _в_ _реальной_ _жизни_ его использовали?
Один раз пришлось.
C> В примерах в MSDN все C>выглядит замечательно, и может с выделенным админом-MCSE оно и будет C>работать.
А чему там не работать и зачем там выделенный админ? InfoPath тупой как пробка, там и настраивать то особо нечего.
C>Но не в наших фирмочках, где еще куча компов под Win98 стоит.
У Altova есть легкое решение (чуть ли не ActiveX в браузер) на ту же тему.
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
В принципе, могу и как install-action прикрутить, чтобы никому не пришлось ручками это делать.
Мы уже победили, просто это еще не так заметно...
