Показать сообщение отдельно
Старый 11.03.2009, 20:38   #9
AlexSobko
Местный
 
Регистрация: 26.12.2007
Сообщений: 987
Сказал(а) спасибо: 1,328
Поблагодарили 1,901 раз(а) в 627 сообщениях
Вес репутации: 677
AlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущееAlexSobko обеспечил(а) себе прекрасное будущее
По умолчанию

Цитата:
Сообщение от Pronko Посмотреть сообщение
Приношу свои извинения за длинные сообщения.
Как раз, наоборот, хорошо, что темы СУБД, администрирования сетей и т.д. расширенно поднимаются на форуме, потому, как темы эти актуальны и востребованы, а быть специалистом во всех областях не представляется возможным. Сами столкнулись при обработке большой базы данных с сетевой проблемой файл-сервер, пришлось переходить на Terminal Server 2003 с произведением изменений и в самой пользовательской программе. В какой то из веток оговаривалось, что надо только обеспечить терминальный режим, но как я понимаю, под это должно быть заточено и пользовательское ПО.
В дополнение, сказанного Pronko:

Архитектура многопользовательских СУБД


Файл - серверные системы. Системы данного типа функционируют в рамках локальных вычислительных сетей (ЛВС), управляемых ОС соответствующего типа. При этом файловый сервер содержит файлы, нФайл - серверные системы. Системы данного типа функционируют в рамках локальных вычислительных сетей (ЛВС), управляемых ОС соответствующего типа. При этом файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлами - как показано на рис. 5.3. Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск.еобходимые для работы приложений и самой СУБД. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлами - как показано на рис. 5.3. Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск.

Очевидно, что архитектура с использованием файлового сервера обладает следующими основными недостатками:
- Большой объем сетевого трафика.
- На каждой рабочей станции должна находиться полная копия СУБД.
- Управление параллельностью, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.
Клиент-серверные системы. При данном подходе предполагается существование клиентского процесса, требующего определенных ресурсов, а также серверного процесса, который эти ресурсы предоставляет. При этом совсем необязательно, чтобы они находились на одном и том же компьютере. На практике системы данного типа реализуются в рамках информационно-вычислительных сетей (не обязательно ЛВС) под управлением клиент-серверных ОС (см. рис. 5.4).
В контексте базы данных клиентская часть управляет пользовательским интерфейсом и логикой приложения, действуя как интеллектуальная рабочая станция, на которой выполняются приложения баз данных. Клиент принимает от пользователя запрос, проверяет синтаксис и генерирует запрос к базе данных на SQL или другом языке БД, который соответствует логике приложения. Затем он передает сообщение серверу, ожидает поступления ответа и форматирует полученные данные для представления их пользователю. Сервер принимает и обрабатывает запросы к базе данных, а затем передает полученные результаты обратно клиенту. Такая обработка включает проверку полномочий клиента, обеспечение требований целостности, поддержку системного каталога, а также выполнение запроса и обновление данных. По-мимо этого, поддерживается управление параллельностью и восстановлением. Выполняемые клиентом и сервером операции приведены ниже.

Клиент:
- Управляет пользовательским интерфейсом;
- Принимает и проверяет синтаксис введенного пользователем запроса;
- Выполняет приложение;
- Генерирует запрос к базе данных и передает его серверу;
- Отображает полученные данные пользователю.
Сервер:
- Принимает и обрабатывает запросы к базе данных со стороны клиентов;
- Проверяет полномочия пользователей;
- Гарантирует соблюдение ограничений целостности;
- Выполняет запросы/обновления и возвращает результаты клиенту;
- Поддерживает системный каталог;
- Обеспечивает параллельный доступ к базе данных;
- Обеспечивает управление восстановлением.
Этот тип архитектуры обладает приведенными ниже преимуществами.
- Обеспечивается более широкий доступ к существующим базам данных.
- Повышается общая производительность системы. Поскольку клиенты и сервер находятся на разных компьютерах, их процессоры способны выполнять приложения параллельно.
- Стоимость аппаратного обеспечения снижается. Достаточно мощный компьютер с большим устройством хранения нужен только серверу - для хранения и управления базой данных.
- Сокращаются коммуникационные расходы. Приложения выполняют часть операций на клиентских компьютерах и посылают через сеть только запросы к базе данных, что позволяет существенно сократить объем пересылаемых по сети данных.
- Повышается уровень непротиворечивости данных. Сервер может самостоятельно управлять проверкой целостности данных, поскольку все ограничения определяются и проверяются только в одном месте.
- Эта архитектура хорошо согласуется с архитектурой открытых систем.
- Данная архитектура может быть использована для организации средств работы с распределенными базами данных, т.е. с набором нескольких баз данных, логически связанных и распределенных в компьютерной сети.
[свернуть]
AlexSobko вне форума   Ответить с цитированием Вверх