Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Клиен-сервер и терминал  [new]
ВЧ
Guest
>>Протоколирование изменений с возможностью восстановления на момент сбоя реализуется и на
>>ФС системах без проблем. Можно восстанавливать не только всю базу целиком, но и отдельные
>>проблемные таблицы.

>Ни горячий бэкап, ни откат, ни накат транзакций вы нормально не сделаете, если одна сессия ничего >не знает о другой.

Не совсем понимаю, что значит - одна сессия ничего не знает о другой?
У себя я спокойно вижу, какие пользователи работают с базой данных, как и когда подключились,
какие таблицы и какие записи в них редактируют, могу посмотреть записи других таблиц, связанные
с редактируемой записью и т.п.
Накат лога - это реально работающий механизм. Выполняется, конечно, не в процессе много-
пользовательской работы. Лог, кстати, используется не только для восстановления при сбоях, но и
для анализа изменений, вывода статистики и т.д.
Иными словами, часть функционала, который Вы используете в готовом виде в SQL-сервере,
встраивается в монолитное приложение. Причем, замечу, для этого не нужно писать ни единой
строчки кода - все генерится атоматически на основании описаний структуры базы данных на этапе
сборки приложения.

>>Про акцесс не знаю, но ФС системы работают обычно через один вход, либо несколько приложений,
>>использующих общие dll, в одной из которых содержится логика модификации БД.
>ну и что, что одна DDL ? У них (приложений) есть общие области для согласования действий ?

Запись в базу данных осуществляет один и тот-же код, который опять же генериться автоматически
на основании описания структуры базы данных. Этот код составляет слой процедур, в который
включается контроль целостности, установка дефолтных значений, ведение лога, подсчет оперативных
остатков, если нужно (аналогично генерится код блока проверки содержимого базы данных).
Все остальное работает через этот слой.
Запись в базу данных разруливается на уровне операционной системы. Прежде всего, речь о
транзакциях. Тут могут быть разные варианты. В моем случае нужные таблицы блокируются на
запись, все изменения накапливаются в оперативной памяти, затем пачкой заливаются в черновые
страницы, затем происходит замена адресов страниц. Критичный к сбоям период оставляет небольшие
доли секунды на этапе замены адресов страниц. Транзакции отрабатывают очень быстро. Я, конечно, понимаю, что SQL-сервер более эффективно распараллелит большое число транзакций, но тут речь нужно вести о количестве конкурентных пользователей, начиная с которого это реально нужно.

>>Если приложение мульти-dll и работает под терминалом, то на каждого клиента запускается
>>отдельная копия exe. dll-ки грузятся один раз. Например, если все приложение 20МБ, exe
>>обычно занимает порядка 200 кб. Общий расход памяти будет ~20МБ (dll)+200кб * количество
>>пользователей.[/quote]

>То есть кэшированием данных вы принципиально не пользуетесь ? Ну тогда быстродействие того... >загнется одномоментно. А если каждое приложение отхватит себе для кэша ну хотя бы скромных 50-100 >мег, то как быстро кончится память на вашем супер-пупер компьютере ?

Кэширование обеспечивается на уровне операционной системы и на уровне приложения. В виндовом
сервере, кстати, кэш работает достаточно эффективно. На уровне приложения в составе описанного
слоя работы с базой данных создается ряд процедур, который кэширует данные, но, конечно, для
конкретного пользователя. Последним можно пользоваться, можно нет.
50-100 мег - это цифра не маленькая. Реально каждый пользователь откусывает меньше. Конкретная
величина зависит от задачи. В просмотре данных используется постраничная загрузка информации,
расходы на которую минимальны. Тяжелый отчет в торговом приложении по всем ассортименту может
достигать нескольких мб, но, как правило, более одного такого отчета пользователь делает редко,
далее вызывает из него расшифровки. Да и сам отчет по полному ассортименту делается не так
часто - используются ограничители выборки.
Если бызы большие, то при плохо спроектированном приложении имеется вероятность переполнения
кэша винды. Ну тут, как говорится, делайте все правильно. Проще всего хранить сводные итоги в
закрытых периодах. Далее дело приложения - определить их наличие и использовать, не лопатя
всю базу данных.

>>Типовой современный компьютер с гигом ОЗУ вполне тянет 20 конкурентных пользователей в
>>терминале.
>Такой же сервер потянет сотни и тысячи конкурентных пользователей.

Не знаю, не пробовал.
В крупных системах нужно использовать SQL-сервера, они для этого и созданы. Не будет эффективно
работать одно и то-же приложение на предприятиях с 20-30 пользователями и 100 пользователями.
То же самое и наоборот. Разная идеология организации бизнес-процессов. Вообще же, делать системы
нужно на том, на чем лично Вам выгоднее, не оглядывясь на рекламу каких-либо продуктов, за каждым
из которых стоят чьи-либо экономические интересы.
18 ноя 06, 00:09    [3418555]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
OS/360
Guest
автор
В крупных системах нужно использовать SQL-сервера, они для этого и созданы. Не будет эффективно
работать одно и то-же приложение на предприятиях с 20-30 пользователями и 100 пользователями.
То же самое и наоборот. Разная идеология организации бизнес-процессов.


А почему в мелких системах SQL сервер не нужно использовать? Инстумент нужно выбирать с запасом прочности

20-30 и 100 пользователей - один порядок. Правда если из ФС системы выжали всё на что она способна и 30 пользоватей оня тянет, то сотне на она загнётся, согласен.

А про "идеологию бизнес процессов" - лучше не здесь
18 ноя 06, 00:23    [3418603]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Yo.!!
Guest
ВЧ

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

потрясающе, а идиота которому баба не дала, методично забивающего нулями файл бд тестовым редактором вы тоже видете ? а проворовавшегося лоха, котрый мимо вашего "функионала" подправляет цифирки видете ?

ВЧ

Запись в базу данных разруливается на уровне операционной системы. Прежде всего, речь о
транзакциях. Тут могут быть разные варианты. В моем случае нужные таблицы блокируются на
запись, все изменения накапливаются в оперативной памяти, затем пачкой заливаются в черновые
страницы, затем происходит замена адресов страниц. Критичный к сбоям период оставляет небольшие
доли секунды на этапе замены адресов страниц. Транзакции отрабатывают очень быстро. Я, конечно, понимаю, что SQL-сервер более эффективно распараллелит большое число транзакций, но тут речь нужно вести о количестве конкурентных пользователей, начиная с которого это реально нужно.

свежо придание, но верится с трудом. кто/что чистит " черновые страницы" оставшие от неудачных транзакций ?
18 ноя 06, 00:36    [3418621]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
ВЧ
Guest
Не автор...
>А почему в мелких системах SQL сервер не нужно использовать? Инстумент нужно выбирать с запасом >прочности
>
>20-30 и 100 пользователей - один порядок. Правда если из ФС системы выжали всё на что она способна >и 30 пользоватей оня тянет, то сотне на она загнётся, согласен.

Я придерживаюсь мнения, что в системах, ориентированных на малый и средний бизнес,
использование втроенных форматов в связке с терминалом более целесообразно.
Дело, конечно, не в чисто технических характристиках. Просто в системах "все в одном
флаконе" гораздо проще организовать автоматизированный процесс сборки и тестирования
приложений. Затраты на поддержку автономных приложений в условиях, когда у заказчика
нет в штате ИТ-специалистов, также существенно ниже. Время, которое придется тратить
на изучение косяков чужого продукта и всяких нестыковок, возникающих в процессе
межпрограммного взаимодействия, можно более продуктивно потратить на развитие
своего инструментария и углубленное изучение бизнес-процессов заказчика. То есть
мне так выгоднее.
Про количество пользователей, более 20, воздержусь комментировать. Скажу лишь, что
у меня есть коллеги, которые в реальных проектах имеют гораздо больше пользователей.

Есть еще такая система - битрив. Я ее не использую по идеологическим соображениям.
В основном, потому что нужно дополнительно лицензировать каждое рабочее место, а у
меня весь поставляемый софт с лицензией. Битрив - это правильный ISAM-клиент сервер,
перход на него практически не требут модификации приложения, работающего со встроенным
форматом. Судя по доке, в нем есть и кэширование, и пакетное чтение записей, и пересылка
по сети отдельных полей записи, сверху приделан SQL-сервер. Если потребуется более
100 пользователей, можно подключить его. Но это уже из области предположений.
18 ноя 06, 00:49    [3418629]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Yo.!!
а проворовавшегося лоха, котрый мимо вашего "функионала" подправляет цифирки видете ?

он то как раз не лох...
18 ноя 06, 01:00    [3418641]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
ВЧ
Guest
>потрясающе, а идиота которому баба не дала, методично забивающего нулями файл бд тестовым >редактором вы тоже видете ? а проворовавшегося лоха, котрый мимо вашего "функионала" подправляет >цифирки видете ?

Я бы предложил сохранять корректность в высказываниях, если хотите, чтобы я Вам отвечал.
В терминальном сервере пользователь не имеет доступа к физическим таблицам, как и в
случае SQL-сервера. Не имеет доступа к удаленному рабочему столу. При подключении
сразу попадает в прикладное приложение. Некоторые клиенты успешно используют терминальные
станции вместо ПК на рабочих местах - компактно (небольшая подставка под монитор), не
шумит, практически не греется, не требует установки софта вообще. То есть с точки
зрения безопасности все в порядке.

>>Запись в базу данных разруливается на уровне операционной системы. Прежде всего, речь о
>>транзакциях. Тут могут быть разные варианты. В моем случае нужные таблицы блокируются на
>>запись, все изменения накапливаются в оперативной памяти, затем пачкой заливаются в черновые
>>страницы, затем происходит замена адресов страниц. Критичный к сбоям период оставляет небольшие
>>доли секунды на этапе замены адресов страниц. Транзакции отрабатывают очень быстро. Я, конечно, >>понимаю, что SQL-сервер более эффективно распараллелит большое число транзакций, но тут речь >>нужно вести о количестве конкурентных пользователей, начиная с которого это реально нужно.

>свежо придание, но верится с трудом. кто/что чистит " черновые страницы" оставшие от неудачных >транзакций ?

Зачем? Черновые страницы в случае обвала транзакции будут использоваться в следующей
транзакции.
18 ноя 06, 01:01    [3418642]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
ВЧ
Guest
>потрясающе, а идиота которому баба не дала, методично забивающего нулями файл бд тестовым >редактором вы тоже видете ? а проворовавшегося лоха, котрый мимо вашего "функионала" подправляет >цифирки видете ?

Я бы предложил сохранять корректность в высказываниях, если хотите, чтобы я Вам отвечал.
В терминальном сервере пользователь не имеет доступа к физическим таблицам, как и в
случае SQL-сервера. Не имеет доступа к удаленному рабочему столу. При подключении
сразу попадает в прикладное приложение. Некоторые клиенты успешно используют терминальные
станции вместо ПК на рабочих местах - компактно (небольшая подставка под монитор), не
шумит, практически не греется, не требует установки софта вообще. То есть с точки
зрения безопасности все в порядке.

>>Запись в базу данных разруливается на уровне операционной системы. Прежде всего, речь о
>>транзакциях. Тут могут быть разные варианты. В моем случае нужные таблицы блокируются на
>>запись, все изменения накапливаются в оперативной памяти, затем пачкой заливаются в черновые
>>страницы, затем происходит замена адресов страниц. Критичный к сбоям период оставляет небольшие
>>доли секунды на этапе замены адресов страниц. Транзакции отрабатывают очень быстро. Я, конечно, >>понимаю, что SQL-сервер более эффективно распараллелит большое число транзакций, но тут речь >>нужно вести о количестве конкурентных пользователей, начиная с которого это реально нужно.

>свежо придание, но верится с трудом. кто/что чистит " черновые страницы" оставшие от неудачных >транзакций ?

Зачем? Черновые страницы в случае обвала транзакции будут использоваться в следующей
транзакции.
18 ноя 06, 01:22    [3418661]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
ВЧ

Я придерживаюсь мнения, что в системах, ориентированных на малый и средний бизнес,
использование втроенных форматов в связке с терминалом более целесообразно.
Дело, конечно, не в чисто технических характристиках. Просто в системах "все в одном
флаконе" гораздо проще организовать автоматизированный процесс сборки и тестирования
приложений. Затраты на поддержку автономных приложений в условиях, когда у заказчика
нет в штате ИТ-специалистов, также существенно ниже. Время, которое придется тратить
на изучение косяков чужого продукта и всяких нестыковок, возникающих в процессе
межпрограммного взаимодействия, можно более продуктивно потратить на развитие
своего инструментария и углубленное изучение бизнес-процессов заказчика. То есть
мне так выгоднее.
Про количество пользователей, более 20, воздержусь комментировать. Скажу лишь, что
у меня есть коллеги, которые в реальных проектах имеют гораздо больше пользователей.


Проблема в том, что при перерастании порога пользователей, систему приходится выбрасывать и начинать с нуля. За это местных CIO по головке не гладят.
Но если организация не растет, и расти не собирается, то можно и на Фоксе писать, и на Аксессе, у них небось и CIO никакого нет :-)
18 ноя 06, 02:01    [3418688]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
Выбегалло
Проблема в том, что при перерастании порога пользователей, систему приходится выбрасывать и начинать с нуля.
Да уж. Это, конечно, проблема.
Зато, пока не переросла, затраты на ее поддержку (и развитие), как правильно указал ВЧ, существенно ниже.
18 ноя 06, 02:46    [3418712]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
freebeer
Member

Откуда:
Сообщений: 61
Urri

Зато, пока не переросла, затраты на ее поддержку (и развитие), как правильно указал ВЧ, существенно ниже.

Рекомендую посмотреть стоимость лицензиии на терминал-сервер и на стоимость паков
лицензии для пользователей(устройств)
Далее сравнить стоимость со стоимостью десктопового решения для SQL сервера и учесть что в
затаратах на развитие при использовании файл-сервера необходимо предусмотреть полное переписывание задачи. Насчет того, что затраты на поддержку существенно ниже -Вы погорячились...
18 ноя 06, 11:41    [3418961]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
ВЧ
Guest
>Проблема в том, что при перерастании порога пользователей, систему приходится выбрасывать и >начинать с нуля. За это местных CIO по головке не гладят.
>Но если организация не растет, и расти не собирается, то можно и на Фоксе писать, и на Аксессе, у >них небось и CIO никакого нет :-)

Какой CIO, если нет штата ИТ-специалистов?
Организации в большинстве случаев развиваются, но перещагнуть из категории небольших в
категорию средних и, тем более, в категорию крупных, не так просто. Если такое
происходит, то обязательно будет сопровождаться кардинальным пересмотром бизнес-
процессов. В этом случае, разумеется, может потребоваться существенная модификация
приложения не зависимо от того, как оно сделано Однако, уверяю Вас, проблем, связанных с ростом, гораздо больше, чем необходимость переделки софта. Я наблюдаю сейчас пару клиентов, которые превратились из компаний с 3-4 компьютерами и штатом в 20-30 работников в компании с 15 компьютерами и штатом порядка сотни работников. Приток новых сотрудников, распределение обязанностей, согласование порядка работы и взаимодействия, банальное использование единой терминалогии... Главное, чтобы система работала максимально эффективно на данном конкретном этапе разития бизнеса.
Да и разбег настолько большой, что мне сложно придумать ситуацию, когда у кого-то из существующих заказчиков возникнет реальная необходимость в использовании SQL-серверов. Много ли Вы видели
компаний, выросших от 10 рабочих мест до 100? И будут ли такие выросшие компании работать с
небольшим софтверным партнером - вопрос больше политический, там другие правила игры.
18 ноя 06, 12:18    [3419014]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
ВЧ
Guest
>Рекомендую посмотреть стоимость лицензиии на терминал-сервер и на стоимость паков
>лицензии для пользователей(устройств)
>Далее сравнить стоимость со стоимостью десктопового решения для SQL сервера и учесть что в
>затаратах на развитие при использовании файл-сервера необходимо предусмотреть полное переписывание >задачи. Насчет того, что затраты на поддержку существенно ниже -Вы погорячились...

Терминальный сервер встроен в Win2000 и Win2003 серверные оси. Дополнительно лицен-
зируется каждое рабочее место. Если не ошибаюсь, порядка 100 у.е.
Если у Вас Win2000 (до 20 пользователей этого чаще достаточно), то есть встроенные
лицензии для Win2000 и WinXP станций. В этом случае дополнительно оплачивать лицензии
на рабочее место не нужно. в Win2003 это прикрыли...
Наиболее эффективно использование терминального сервера в связке с терминальными
станциями. Цены на них несколько зашкалены, т.к. считается, что основное достоинство -
это низкая стоимость владения. Примерно считайте, что стоимость полностью укомплектованной
терминальной станции со всеми лицензиями будет равна стоимости железа обычного ПК.
Для более крупных контор серьезный выигрыш может получиться от использования старой
техники в качестве станций.
Речь идет о MS-терминалах. Если Вы поищете в интернете, то найдете ряд альтернативных
проектов, появившихя за последние 2-3 года. Но это сейчас пока экзотика.
18 ноя 06, 12:35    [3419041]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Мимо пробегал...
Да нагрузка на канал снижается. По своему опыту до 50 раз (сравнение трафика по протоколам citrix'а и MSSQLя). Однако это не делает систему клиент-серверной. Сервер в КС системе - он один. Для ФС на каждого клиента запускается своя копия программы.
Что-то у меня сомнения в адекватности запросов к MSSQL тогда, что-то много лишнего на клиента тянется.
18 ноя 06, 13:07    [3419092]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Мимо пробегал...
Guest
Что-то у меня сомнения в адекватности запросов к MSSQL тогда, что-то много лишнего на клиента тянется.
ГЫ-ГЫ .... а кто бы сомневался ... Клиент Navision'а - это такой толстый клиент, что вам ине снилось :) Если бы нормальная КС система была, то глядишь и терминал не потребовался бы.
18 ноя 06, 15:58    [3419306]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Снова никто не упомянул современные технологии, позволяющие сетереть различия между ФС и КС , например, Web Services...

С помощью них Вы можете почти любую ФС превратить в КС... Делал это с FoxPro - проблем особо нет сколько клиентов - 40 или 400 процесс контролируется полностью Вами, пишите если надо журнал транзакций, следите за кэшем... Всего одна копия DLL на серевер... Надо расширить до 4000 клиентов - проблем нет - поставили дополнительные сервера в параллель...

Но, есть одно большое но... То, к чему Вы прийдете после 100 пользователей - как тут правильно до меня заметили - это повторение функционала SQL серевера... А учитывая, что программисты FoxPro - одни из самых высокооплачиваемых сегодня по причине универсальности и уникальности - дешевле купить промышленный SQL server со всеми вытекающими отсюда последствиями...
18 ноя 06, 20:21    [3419867]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Мимо пробегал...
ГЫ-ГЫ .... а кто бы сомневался ... Клиент Navision'а - это такой толстый клиент, что вам ине снилось :) Если бы нормальная КС система была, то глядишь и терминал не потребовался бы.
Ну вообще-то Microsoft пообщал исправить этот недостаток и перевести "the next heneration" на MS SQL Server + клиент на .NET
18 ноя 06, 20:23    [3419868]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
alexmsp
Member

Откуда:
Сообщений: 3573
Мимо пробегал...
Да нагрузка на канал снижается. По своему опыту до 50 раз (сравнение трафика по протоколам citrix'а и MSSQLя). Однако это не делает систему клиент-серверной. Сервер в КС системе - он один. Для ФС на каждого клиента запускается своя копия программы.


Для КС РСУБД на сервере терминальной службы на каждого клиента тоже запускается своя копия клиентской программы.
20 ноя 06, 12:00    [3423281]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Мимо пробегал...
Guest
автор
Для КС РСУБД на сервере терминальной службы на каждого клиента тоже запускается своя копия клиентской программы.
Грандиозное замечание!
20 ноя 06, 12:27    [3423554]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Yo.!!
Guest
ВЧ

В терминальном сервере пользователь не имеет доступа к физическим таблицам, как и в
случае SQL-сервера.


да и как вы это представляете под виндой ? кто сказал что на терминальном сервере нельзя запускать другие приложения ?

ВЧ
При подключении сразу попадает в прикладное приложение. Некоторые клиенты успешно используют терминальные станции вместо ПК на рабочих местах - компактно (небольшая подставка под монитор), не шумит, практически не греется, не требует установки софта вообще. То есть с точки зрения безопасности все в порядке.

те терминалы к которым я приценивался все имели встроеный аутгюк и ие, которые выполнялись на станции, наверника этот ие может запускать все что душе угодно. да и кому нужно рабочее место без мс офиса, с помощью которого с access/dbf файлами можно делать все что душе угодно.

ВЧ

Зачем? Черновые страницы в случае обвала транзакции будут использоваться в следующей
транзакции.

тогда должен быть заголовок в котором указаны где черновые страницы, пока похоже на буйную фантазию, можно урл на msdn ?
20 ноя 06, 12:38    [3423666]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Yo.!!
Guest
Sergey Ch
Снова никто не упомянул современные технологии, позволяющие сетереть различия между ФС и КС , например, Web Services...


думаю это от того, что отличия не сотрутся ... транзакции в фокспро не появятся, лог транзакций не прикрутится, уровни изолированости транзакций не возникнут из неоткуда, да и оптимизатор не станет cost based ....
20 ноя 06, 15:13    [3424834]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
OS/360
Guest
Yo

думаю это от того, что отличия не сотрутся ... транзакции в фокспро не появятся, лог транзакций не прикрутится, уровни изолированости транзакций не возникнут из неоткуда, да и оптимизатор не станет cost based ....


Репликация,горячий бэкап, стендбай сервер и т д и т п тоже не появятся...

А вот веб-сервисы не без пользы вполне могут быть прикручены к серверу.

P.S.
- Может ли сын генерала стать маршалом?
- нет, у маршала тоже есть сын
20 ноя 06, 15:22    [3424933]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
ВЧ
Guest
>да и как вы это представляете под виндой ? кто сказал что на терминальном сервере нельзя запускать >другие приложения ?

Это зависит от настройки прав пользователя на терминальном сервере. Если указать
приложение, выполняемое при подключении, то все остальное от него будет закрыто.

>кому нужно рабочее место без мс офиса, с помощью которого с access/dbf файлами можно делать все >что душе угодно.

Думаю, что это стереотип. Но, действительно, некоторые пользователи привыкли к наличию
такой прилады. Я использую только как дополнительную возможность. Т.е. основная
работа не требует наличия постороннего софта, но пользователь может сохранить отчет в
Excel/Calc и дальше с ним работать. Для каждого пользователя можно назначить каталог
по-умолчанию. Если на рабочем месте обычный ПК, то каталог обычно располагается на нем. В
этом случае отчет пользователь сохраняет отчет, переключается на локальный компьютер и работает
с отчетом дальше. Со станций обычно работают те, кому в Офисе делать нечего. Но если потребуется, тоже, думаю, вопрос решаемый. Еще раз заострю внимание, что использование Офиса - это дополни-
тельны сервис. Есть серьезное неудобство - проблематично организовать навигацию по информации
(сводный отчет - более детальный отчет - график - первичнй документ и т.п.)
Кстати, я с access и dbf файлами не работаю. У меня базы шифрованные, 512-битный ключ...

>тогда должен быть заголовок в котором указаны где черновые страницы, пока похоже на буйную >фантазию, можно урл на msdn ?

Ну так я вроде написал, что после заливки информации в черновые страницы выполняется замена
адесов страниц и что это этап, на котором может произойти сбой. Однако он настолько маленький,
что при работе на локальном компьютере (или под терминалом)вероятность близка к нулю. Замечу еще,
что перед заменой адресов создается специальный лог, в котором фиксируются таблицы и адреса
замещаемых страниц. Если все же произойдет сбой, то драйвер должен откатить изменения. Хотя
тут может быть не все так гладко. В целом, как показывает опыт, уронить базу на терминальном
сервере можно только вырубив питание в момент замещения страниц. Но при таком раскладе думаю,
что последствия для SQL-сервера будут еще плачевнее.
Насчет msdn я что-то не понял. Вам, наверно, нужно что-нибудь про организацию b-деревьев
почитать. Например, старенькую книжку Ульмана "Базы данных на Паскале" или что-то подобное.
20 ноя 06, 15:44    [3425163]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
ВЧ
Guest
Здравствуйте, Сергей!
>Снова никто не упомянул современные технологии, позволяющие сетереть различия между ФС и КС , >например, Web Services...

Но тогда, как я понимаю, будет Web-интрфейс, что не всегда допустимо.
В принципе, сейчас для распространенных форматов ( т.ч. и для dbf, насколько знаю),
есть IP-сервера. Схема примерно такая. На "сервере" (ос не ниже Win2k, не обязательно
серверная) запускается сервис. В этом сервисе регистрируем dll, в которой собраны
декларации базы данных. Эта dll генерится автоматически при сборке проекта. В основ-
ных модулях проекта автоматчески выполняется подмена драйвера, после чего мы уже не
напрямую модифицируем файло по сети, а шлем запросы на серверную dll, которая и
выполняет реальную модификацию данных. Сам серверный компьютер на прямую по сетке может
быть не доступен. Структурно это несколько напоминает работу битрива. При этом доступна
фильтрация нформации на сервере, чтение блока записей за одно обращение и возможность создания серверных переменных и процедур. Серверные процедуры пишутся на том-же языке, что и основной проект, и располагаются в dll на сервере.
Стоимость такого решения в моем случае составляет 8-12 тыс.руб., если покупать у
российского дистрибьютора, и зависит от периодически проводимых ценовых акций.
Для твоих пользователей дальнейшее распространение бесплатно.
Один зарубежный коллега писал,что без проблем работает 50 пользователей, часть через
интернет. Добавлю еще, что опсаный подход может быть использован и в саязк с SQL-сер-
верами, поскольку создает защищенный канал.
Однако, поскольку я тяготею к монолитным приложениям, то в реальных проектах не
пользую.
20 ноя 06, 16:05    [3425330]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
Yo.!!
Guest
ВЧ

Т.е. основная работа не требует наличия постороннего софта, но пользователь может сохранить отчет в Excel/Calc и дальше с ним работать. Для каждого пользователя можно назначить каталог
по-умолчанию. Если на рабочем месте обычный ПК, то каталог обычно располагается на нем. В
этом случае отчет пользователь сохраняет отчет, переключается на локальный компьютер и работает с отчетом дальше. Со станций обычно работают те, кому в Офисе делать нечего. Но если потребуется, тоже, думаю, вопрос решаемый. Еще раз заострю внимание, что использование Офиса - это дополни- тельны сервис. Есть серьезное неудобство - проблематично организовать навигацию по информации (сводный отчет - более детальный отчет - график - первичнй документ и т.п.)

во первых, что нада, а чего ненада решает бизнес, во вторых какой бизнес смысл покупать терминал, чтоб запускать только одно приложение, а остальные в винде на клиенте ?? потому что кривое приложение страшно запускать по другому как отмазка не канает. в третих если мы говорим о терминальных станциях, там этот фокус не прокатывает. да и заострю внимание без МС офиса юзер по сути не может работать с майлами, а без майла в 21 веке не сурьозно...

ВЧ
Кстати, я с access и dbf файлами не работаю. У меня базы шифрованные, 512-битный ключ...

да чихать Васе, что у вас там, зашифровано XORом или DECом, гадо ему разбиратся, он нулями затрет и уволится.

ВЧ

Ну так я вроде написал, что после заливки информации в черновые страницы выполняется замена
адесов страниц и что это этап, на котором может произойти сбой.

лана, щаз все же загляну в описание mdb, разберемся в вашей фантазии.

ВЧ
Но тогда, как я понимаю, будет Web-интрфейс, что не всегда допустимо.

это из другой оперы.
20 ноя 06, 16:31    [3425551]     Ответить | Цитировать Сообщить модератору
 Re: Клиен-сервер и терминал  [new]
OS/360
Guest
ВЧ

Но тогда, как я понимаю, будет Web-интрфейс, что не всегда допустимо.
В принципе, сейчас для распространенных форматов ( т.ч. и для dbf, насколько знаю),
есть IP-сервера. Схема примерно такая. На "сервере" (ос не ниже Win2k, не обязательно
серверная) запускается сервис. В этом сервисе регистрируем dll, в которой собраны
декларации базы данных. Эта dll генерится автоматически при сборке проекта. В основ-
ных модулях проекта автоматчески выполняется подмена драйвера, после чего мы уже не
напрямую модифицируем файло по сети, а шлем запросы на серверную dll, которая и
выполняет реальную модификацию данных. Сам серверный компьютер на прямую по сетке может
быть не доступен.


А почему сразу не взять SQL сервер?

Сообщение было отредактировано: 20 ноя 06, 18:09
20 ноя 06, 17:17    [3425911]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить