Технология DataSnap
Заманчиво спроектировать распределенную инф. систему построенную полностью на инструментарии Windows. Т .е . без установки стороннего ПО.
Рассматриваю такую связку (Delphi):
На сервере: ADOconnection к локальному набору данных, datasetprovider.
Клиент: DCOMconnection, clientdatasource. компоненты отображения данных.
С использованием модели BriefCase. Вобщем технология DataSnap в чистом виде.
Плюсом ко всему на стороне клиента планируется реализовать связь с ГИС (геоинформационной системой)
Есть-ли у кого-то опыт подобной реализации при использовании в малой локальной сети.
К вопросу - почему?
Некоторые на этом форуме интересуются легкими, желательно бесплатными реляционными СУБД для работы в малой локальной сети?
Мое видение ситуации - эти некоторые (в том числе и я) скорее всего занимаются разработкой коммерческого ПО, поддержкой которого будет заниматься непосредственно пользователь. А т.к. администрирование и настройка СУБД пока не входит в обязательную программу общего среднего образования , желательно на выходе получить инф. систему с минимальным набором стороннего ПО (оптимально - вообще без) и интуитивно-понятным администрированием.
Преимущества Data Snap (ИМХО) - "все включено" в ОС и логику приложения, пусть она медленее чем ФБ к примеру, но использование BriefCase позволяет снизить нагрузку на сеть, т. к. работа идет с локальным набором данных в течение сеанса.
Давайте обсудим такую реализацию.
Приложение-сервер через ADO компонеты (например ADOquery и ADOCommand) связывается с локальным (для сервера) набором данных посредством SQL-запросов, т. е. сервер общается с локальной БД как с с SQL сервером. Связывание таблиц и запросов тоже происходит через SQL. (запросы типа: Select * from mastertable, detailtable where mastertable.id=detailtable.master_id)
На стороне клиента ClientDataSource'ы получают эти данные через DCOMConnection.
Это вроде как и не файл-серверная ИС, но и не полноценная распределенная трехуровневая ИС типа Клиент-Сервер. Тем не менее клиенты получают только запршенную информация. т. е. ИС функционирует как Клиент-Сервер.
Хотя бы просто теоретически - насколько это эффективно и быстро?
Обязательно-ли (с точки зрения эффективности) на сервере использовать query- компоненты и SQL-связывание, или можно использовать обычные компоненты доступа и определить связи между таблицами через object inspector? Как правильно настроить при этом компоненты?
Возможно-ли подключиться к данным через ODBC, без использования BDE (BDE позволяет использовать драйверы ODBC)?
Это опять же к теме построения ИС средствами Windows.
З. Ы. Извините если вопросы тупые. Я не профи, только начинаю.
Задача - создать эффективную ИС на 2-10 рабочих станций с упомянутыми выше условиями.
Рассматриваю такую связку (Delphi):
На сервере: ADOconnection к локальному набору данных, datasetprovider.
Клиент: DCOMconnection, clientdatasource. компоненты отображения данных.
С использованием модели BriefCase. Вобщем технология DataSnap в чистом виде.
Плюсом ко всему на стороне клиента планируется реализовать связь с ГИС (геоинформационной системой)
Есть-ли у кого-то опыт подобной реализации при использовании в малой локальной сети.
К вопросу - почему?
Некоторые на этом форуме интересуются легкими, желательно бесплатными реляционными СУБД для работы в малой локальной сети?
Мое видение ситуации - эти некоторые (в том числе и я) скорее всего занимаются разработкой коммерческого ПО, поддержкой которого будет заниматься непосредственно пользователь. А т.к. администрирование и настройка СУБД пока не входит в обязательную программу общего среднего образования , желательно на выходе получить инф. систему с минимальным набором стороннего ПО (оптимально - вообще без) и интуитивно-понятным администрированием.
Преимущества Data Snap (ИМХО) - "все включено" в ОС и логику приложения, пусть она медленее чем ФБ к примеру, но использование BriefCase позволяет снизить нагрузку на сеть, т. к. работа идет с локальным набором данных в течение сеанса.
Давайте обсудим такую реализацию.
Приложение-сервер через ADO компонеты (например ADOquery и ADOCommand) связывается с локальным (для сервера) набором данных посредством SQL-запросов, т. е. сервер общается с локальной БД как с с SQL сервером. Связывание таблиц и запросов тоже происходит через SQL. (запросы типа: Select * from mastertable, detailtable where mastertable.id=detailtable.master_id)
На стороне клиента ClientDataSource'ы получают эти данные через DCOMConnection.
Это вроде как и не файл-серверная ИС, но и не полноценная распределенная трехуровневая ИС типа Клиент-Сервер. Тем не менее клиенты получают только запршенную информация. т. е. ИС функционирует как Клиент-Сервер.
Хотя бы просто теоретически - насколько это эффективно и быстро?
Обязательно-ли (с точки зрения эффективности) на сервере использовать query- компоненты и SQL-связывание, или можно использовать обычные компоненты доступа и определить связи между таблицами через object inspector? Как правильно настроить при этом компоненты?
Возможно-ли подключиться к данным через ODBC, без использования BDE (BDE позволяет использовать драйверы ODBC)?
Это опять же к теме построения ИС средствами Windows.
З. Ы. Извините если вопросы тупые. Я не профи, только начинаю.
Задача - создать эффективную ИС на 2-10 рабочих станций с упомянутыми выше условиями.
:facepalm:JetDB,и будет вам
Автору настоятельно рекомендуется учить матчасть. И определить как минимум конкретные цели.
Цитата:
Возможно-ли подключиться к данным через ODBC, без использования BDE (BDE позволяет использовать драйверы ODBC)?
возможно. и даже нужно. Технология BDE давным давно не используется.
По поводу "задумки" - для простого проекта это нерационально сложно. Для сложного проекта - решение неэффективно.
Цитата:
А т.к. администрирование и настройка СУБД пока не входит в обязательную программу общего среднего образования , желательно на выходе получить инф. систему с минимальным набором стороннего ПО (оптимально - вообще без) и интуитивно-понятным администрированием.
нет взаимосвязи между простотой администрирования и использованием нормальных СУБД (а для большинства нормальных людей windows - это стороннее ПО).
Тем более программа ТС - уже стороннее ПО, а для нормальной работы DCOM нужно нормальное администрирование.