Какую технологию выбрать для трехзвенки?

← →
Andriano (2003-09-17 09:23) [0]

Есть 8 компьютеров в одной сети Интранет с каналами минимум 64кбит/с.
Требуется написать упрощенный оперативный торговский учет.

1.Если тонким клиентом будет Web-браузер, то придется много разбираться с Java или HTML (синтаксис и доступ к данным).
2.Есть ещё возможность использовать Remoute Data Module.

Привык использовать компоненты FIB plus. Получается, чтобы использовать все наработки и опыт, да и вообще писать в любимой среде Delphi, придется выбрать 2-ой вариант. Насколько это надежно и безглючно?

Есть ли другие варианты?
Может вообще обойтись грамотной двухзвенкой (широко использовать внутренние процедуры и тригеры)? При предварительном расмотрении задачи, кажется, что очень больших потоков данных не будет.

Кто писал трехзвенку, поделитесь опытом.

← →
Reindeer Moss Eater (2003-09-17 09:33) [1]

Трехзвенка никогда не решала проблему тонких каналов. Она не для этого придумана.

← →
Jeer (2003-09-17 09:38) [2]

Сервер приложений на базе w2k Terminal

← →
Sergey13 (2003-09-17 09:38) [3]

Если каналы связи более-меннее надежные, то можно вообще без всяких трехзвенок обойтись легко. У меня на 33кбс (реально 26-28) филиал крутится - одновременно до 5 машин (обычно 2). Главное условие - вылизывать программы на предмет минимизации трафика.

← →
stone (2003-09-17 09:43) [4]

Можно использовать SOAP. Обмен данными по HTTP. 64кбит/с более, чем достаточно.
Простенький пример здесь:
http://delphiplus.nagano.ru/articles/delphi/soap_it_is_easy/index.html

← →
Reindeer Moss Eater (2003-09-17 09:49) [5]

64К для двузвенки - за глаза и за уши.
И если про трехзвенку вспомнили только в связи с толщиной канала - то это ошибочный ход мысли.

← →
Andriano (2003-09-17 10:08) [6]

> Reindeer Moss Eater ©
Трехзвенка обеспечивает большую надежность и служит для минимизации трафика. Так написано во всех статьях о трезвенках.

> stone
Прочел. SOAP примерно тоже самое что и MIDAS.

Спасибо за ответы. Буду тестировать двухзвенку.

← →
Reindeer Moss Eater (2003-09-17 10:13) [7]

Трехзвенка обеспечивает большую надежность и служит для минимизации трафика. Так написано во всех статьях о трезвенках.

На сарае тоже много чего написано, а лежат там дрова.

← →
Reindeer Moss Eater (2003-09-17 10:16) [8]

Назначение трехзвенки:
1. Облегчить клиента. Основное назначение.
2. Бизнес-правила. Если на сервере не удается реализовать все бизнес правила, а на клиенте не хочется - то реализуются они в третьем звене.
3. Ну и все пожалуй.

← →
Reindeer Moss Eater (2003-09-17 10:20) [9]

Трехзвенка обеспечивает большую надежность
Система из трех компонентов не может быть надежнее системы из двух компонентов по определению.

и служит для минимизации трафика.

Берем форму классического двузвенного приложения с DataAware контролами. Что бы заполнить их данными с сервера запрашивается запись из таблицы (у нее есть определенный размер).
Переделываем приложение в N-звенное. Вспоминаем про нашу форму редактирования записи и замечаем, что те же самые данные того же размера пришли с сервера приложений на клиента.

← →
Vlad (2003-09-17 10:27) [10]

>Reindeer Moss Eater © (17.09.03 10:16) [8]
>Назначение трехзвенки:
>1. Облегчить клиента. Основное назначение.

Боюсь, что это не основное назначение.
"Более основное" намой взгляд является разгрузка сервера БД.
Если сотни пользователей ежеминутно получают запросы с сервера, а там заложена куча математики (т.е. хранимок, триггеров), то это значительно замедляет процесс. Именно в этом случае вся математика с сервера БД выносится на среднее звено. А их (средних звеньев), может работать несколько штук параллельно, что при грамотной балансировке нагрузки между ними, позволит значительно ускорить выполнение запросов.

← →
Reindeer Moss Eater (2003-09-17 10:29) [11]

Vlad ©

Ну значит бизнес правила в середине - основное назначение, а не облегчение клиента.

Но только не минимизация трафика.

← →
Sandman25 (2003-09-17 10:33) [12]

Vlad & Reindeer Moss Eater

Я вижу, вы неплохо разбираетесь в этом. А в чем выигрыш, если сервером приложений служит сервер БД? Или применение здесь трехзвенной архитектуры связано только с тем, что не всю бизнес-логику легко реализовать в хранимых процедурах и триггерах?

← →
Vlad (2003-09-17 10:38) [13]

>Reindeer Moss Eater © (17.09.03 10:29) [11]
Согласен,трафик тут совсем не причем.

>Andriano (17.09.03 09:23)
Почему бы не использовать в качестве упрощения COM/DCOM, коль сеть локальная ? MIDAS в Дельфи неплохо с этим справляется, я вроде лично пользовался...

← →
Vlad (2003-09-17 10:41) [14]

>Sandman25 © (17.09.03 10:33) [12]
>сервером приложений служит сервер БД
В этом случае единственный выигрыш может быть, как сказал Reindeer Moss Eater, в облегчении клиента.
Поскольку сервер БД - один (если не кластерная система) и несколько App-серверов внутри него в параллель не поставишь :)

← →
app (2003-09-17 10:47) [15]

Основное назначение изоляция клиента от БД, остальное все в придачу и трафик и процее. Бизнес правила делаются на промежуточном звене. При отсутствии безнес правил не получается даже разгрузки БД

← →
Sandman25 (2003-09-17 10:49) [16]

[14] Vlad © (17.09.03 10:41)

Понятно, спасибо. У них на этом сервере стоит много разных БД и много разных App-серверов, недавно вынуждены были сделать upgrade машины, чтобы справляться с нагрузкой. Вот я и подумал, может, им стоит перенести часть бизнес-логики на клиента. Клиентские машины у них совсем не слабые, и математические операции можно было бы выполнять на них.

← →
Sandman25 (2003-09-17 10:53) [17]

[15] app © (17.09.03 10:47)

>изоляция клиента от БД

Вы имеете ввиду, чтобы можно было изменить структуру БД без изменения клиента (аналог инкапсуляции в ООП)? Но если изменений в системе не планируется (и даже точно не будет), то главное преимущество трехзвенки исчезает?

← →
Vlad (2003-09-17 10:56) [18]

>app © (17.09.03 10:47) [15]
Да уж, кому как не Вам знать об этом все от и до! :)

← →
Romkin (2003-09-17 10:56) [19]

2Reindeer Moss Eater
>Система из трех компонентов не может быть надежнее системы из двух компонентов по определению.
Ну это ты погорячился. Следуя этой логике, клиент-сервер менее надежен, чем файл-сервер :) Лишнее звено же есть...
И трафик минимизируется, достаточно его замерить. По нескольким причинам, кстати. У меня при юзании IB трафик между клиентом и сервером приложений был 56 КБайт (самая массивная операция), сжимался модемом на 60 % а между сервером приложений и IB та же самая операция уже 1.2 Гб (правда, сжатие на 80%). Вот и прикинуть можно.
Получается так во-первых, потому, что в MIDAS передача пакетная, и пакеты весьма компактны, а во-вторых, достаточная доля данных просто не доходит до клиента, не нужны ему данные для расчета, только то, что видеть надо. В-третьих, уж выбор по минимизации трафика гораздо шире, мне постоянно выбирать приходится, как минимум, между количеством обращений к серверу и размером данных

← →
Reindeer Moss Eater (2003-09-17 11:05) [20]

Ну это ты погорячился. Следуя этой логике, клиент-сервер менее надежен, чем файл-сервер :) Лишнее звено же есть...

Клиент-сервер и файл сервер сожержат принципиально разные компоненты. Это как один запорожец и один лексус.
Трехзвенка и двузвенка имеют 2 почти идентичных компонента плюс в трехзвенке одно дополнительное звено.
Так что все верно.

У меня при юзании IB трафик между клиентом и сервером приложений был 56 КБайт (самая массивная операция), сжимался модемом на 60 % а между сервером приложений и IB та же самая операция уже 1.2 Гб (правда, сжатие на 80%). Вот и прикинуть можно.

Ну модем и сжатие данных - это не принадлежность исключительно той или иной технологии. У АДО и SQLlinks тоже трафик различный, но это не значит, что изобретались они именно для снижения трафика.

Получается так во-первых, потому, что в MIDAS передача пакетная, и пакеты весьма компактны, а во-вторых, достаточная доля данных просто не доходит до клиента, не нужны ему данные для расчета, только то, что видеть надо. В-третьих, уж выбор по минимизации трафика гораздо шире, мне постоянно выбирать приходится, как минимум, между количеством обращений к серверу и размером данных

Все эти приемы так же доступны и для классического клиент-сервера. Трехзвенка тут не причем.

← →
Romkin (2003-09-17 11:06) [21]

2Sandman25 Трехзвенка дает возможность балансировки нагрузки на этапе разработки, разработчик определяет, где и как будут обрабатываться данные. Ничто не мешает и на клиента их перенести, ничто не мешает и сервер сделать невыделенным, вместе с клиентом...

← →
Sandman25 (2003-09-17 11:11) [22]

[21] Romkin © (17.09.03 11:06)
>Ничто не мешает и на клиента их перенести, ничто не мешает и сервер сделать невыделенным, вместе с клиентом...

То же самое верно и для двузвенки - либо DB alias указывает на локальную машину, либо на удаленный сервер. Хотя дополнительная возможность перенести обработку на вообще третью машину - это действительно полезно.
Интересно, есть ли смысл делать 4-звенную архитектуру, с двумя уровнями серверов приложений?

← →
Reindeer Moss Eater (2003-09-17 11:11) [23]

клиент-сервер менее надежен, чем файл-сервер :)
Парадокс, но это так! :) (Не логическая целостность прикладных данных, а как система)

← →
Anatoly Podgoretsky (2003-09-17 11:11) [24]

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

← →
Anatoly Podgoretsky (2003-09-17 11:13) [25]

Vlad © (17.09.03 10:56) [18]
Как раз я не знаю, поскольку не использую. Но общии положения базовых технологий всегда знать полезно.

← →
Vlad (2003-09-17 11:16) [26]

>Anatoly Podgoretsky © (17.09.03 11:11) [24]
Защита сервера БД от посягательств клиента, путем введения промежуточного звена ? Это вы имеете ввиду ? Ну это, думаю, тоже не самое основное преимущество трехзвенки. Это можно сделать и другими средствами.

← →
Romkin (2003-09-17 11:22) [27]

2Reindeer Moss Eater Парадокс в том, что это не так! Просто надежность системы неотделима от технологии, в ней применяющейся.
Сервер БД предусматривает средства для контроля целостности базы, причем такие, которые невозможно реализовать в случае файловой системы. (Это не ссылочная целостность и тд, я говорю именно о физической структуре базы). ТАкже и трехзвенка может отличаться от двухзвенки как боинг от лексуса :)))
2Sandman25 Ага, локальная база. А остальные клиенты тоже каждый со своей базой? :) Тут принцип именно в том, что место обработки данных выбирается произвольно. Для клиента, как правило, объем расчетов выбирается от двухзвенного клиента (много) до плоского клиента (только показывает, браузер, например). Если хочется считать больше, чем в двухзвенке, то увы, придется кропотливо переносить расчеты из БД на клиент, как и в двухзвенке.

← →
Sandman25 (2003-09-17 11:25) [28]

Romkin

Ясно.

← →
Anatoly Podgoretsky (2003-09-17 11:28) [29]

Vlad © (17.09.03 11:16) [26]
Конечно нет, это просто побочный эффект.

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

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

Можно применить и тонкого клиента, то есть полное отсутсвие клиентской стороны, в качестве ее может использоваться стандартный Интернет Браузер. Или специализированный клиент, задача которого только отображать и выдавать обратно данные и запросы. По сути многие страницы в сети и есть демонстрация этого принтера, не статические, а хотя и даже статические тоже.
Клиент, сервер, данные.

Дает гибкость за счет сложности.

Да и суть отражена в самом названии три (много) звеньев. Трехзвенка частный случай названия, многозвенка общий случай.

← →
Reindeer Moss Eater (2003-09-17 11:28) [30]

Romkin ©
Ты рассуждаешь про сохранность при выполнении операций (даже не про надежность хранения).
А я рассуждаю про надежность системы.
Так вот надежность системы файлсервера выше надежности системы Клиент-Сервер.

я говорю именно о физической структуре базы.
И те и другие хранят свои данные на жестких дисках, которые ничего не знают про сами системы, и обслуживаются ОС.

← →
Sandman25 (2003-09-17 11:33) [31]

[30] Reindeer Moss Eater © (17.09.03 11:28)

>И те и другие хранят свои данные на жестких дисках, которые ничего не знают про сами системы, и обслуживаются ОС.

Не всегда так. У нас стоит Informix в режиме raw, он хранит данные не в файлах ОС, а работает с жестким диском напрямую.

← →
Reindeer Moss Eater (2003-09-17 11:37) [32]

Не всегда так. У нас стоит Informix в режиме raw, он хранит данные не в файлах ОС, а работает с жестким диском напрямую.

Согласен, не всегда. Только raw partition сами по себе опять таки не снижают и не повышают надежности хранения данных.
Разработчики надеются с их помощью увеличить скорость I/O операций.

← →
Sandman25 (2003-09-17 11:40) [33]

[32] Reindeer Moss Eater © (17.09.03 11:37)

Ну да, естественно. Наверное, надежность даже снижается - ведь физическая запись происходит не так часто, как обычно. Впрочем, время между этими checkpoints настраивается.

← →
Romkin (2003-09-17 11:45) [34]

Если файл-сервер не трогать, то пофиг. А вот когда работаешь, то практически любой сервер заботится о своих файлах, даже Interbase контролирует запись в базу, помимо ОС. Хотя он опирается на имеющуюся файловую систему, но его база фактически его файловая система. Остальные сервера делают как минимум так, именно для повышения надежности.

← →
Reindeer Moss Eater (2003-09-17 11:47) [35]

Romkin © да забудь ты про файлы.
Я тебе про надежность системы в целом говорю.
У файлсервера она выше.

← →
Romkin (2003-09-17 11:50) [36]

Если бы она была выше, то никто бы сервера БД не использовал. И не выше она, не может этого быть. И что ты подразумеваешь под "Система в целом"? Я, например, гарантирую, что данные в моем приложении на IB потеряются только при физическом повреждении диска, остальное - не касает. При файл-сервере такого я гарантировать не могу.

← →
Vlad (2003-09-17 11:51) [37]

В конечном итоге, считаю, что автору стоит задуматься, а нужна ли ему вобще трехзвенка ?
Защиту данных от клиента можно ведь организовать путем запрета их изменения (только через хранимки, например), отображение - через View.
И если соотношение - мощность сервера БД/количество одновременно работающих пользователей, приличное, то тут вполне можно обойтись и двухзвенной архитектурой.

← →
Sergey13 (2003-09-17 11:54) [38]

Вот это дискуссия рарослась!!!
ИМХО, лучше всех (как всегда 8-) АП отразил основные преимущества.
От себя добавлю (в чем то повторяя АП), что многозвенка с ее изоляцией от БД, позволяет использовать в работе разнородные БД и платформы, и делает клиента независимым от изменения этой разнородности (он о ней даже не подозревает). Т.е. не надо ставить всякие клиенты доступа при переходе например с М$ на Оракл. Достаточно поменять сервер приложений. Но это наиболее актуально для ЗДОРОВЕННЫХ и распределенных проектов. В работе с одним сервером БД преимущества смазываются, хотя для разработчиков "коробочных" продуктов удобно "приделывать" к своим проектам разные БД, переписав только сервер приложений.

← →
Reindeer Moss Eater (2003-09-17 11:57) [39]

Romkin ©
Я, например, гарантирую, что данные в моем приложении на IB потеряются только при физическом повреждении диска, остальное - не касает. При файл-сервере такого я гарантировать не могу.

Опять ты про данные. Я что, так неразборчиво пишу по-русски?

Что такое система файл-сервер?
Есть приложение, которое открывает файл на запись/чтение. Все.

Что такое система клиент-сервер?
Есть приложение, которое открывает файл на запись/чтение.
Есть приложение, общающееся с первым приложением. Все.

Вторая система более уязвима. Потому что в ней больше элементов, каждый из которых имеет свою надежность.

Система файл-сервер более надежна чем система клиент-сервер.
Так понятно?

← →
Vlad (2003-09-17 12:03) [40]

>Sergey13 © (17.09.03 11:54) [38]
Согласен, клиентская часть не зависит от сервера, т.е. удобство перевода под другую СУБД, и вобще под другую структуру данных - налицо.
Но зачастую, особенно в небольших компаниях с небольшим числом пользоватетей - соотношение выгоды к затратам - минимальное, при разработке трехзвенки.

← →
Sandman25 (2003-09-17 12:03) [41]

[39] Reindeer Moss Eater © (17.09.03 11:57)

Лучше не так объяснять. Сервер приложений кто-то стер с диска и система перестала работать. У файл-сервера ничего подобного нет, поэтому он будет работать как ни в чем не бывало :)

← →
Vlad (2003-09-17 12:05) [42]

>Sandman25 © (17.09.03 12:03) [41]
А еще ведь питание могут отрубить ! :)
Так что прав Reindeer Moss Eater. Чем больше звеньев - тем меньше суммарная надежность системы.

← →
Romkin (2003-09-17 12:06) [43]

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

← →
Anatoly Podgoretsky (2003-09-17 12:07) [44]

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

В случае файл серверной это выглядит иначе
Много приложений -> один файл (одновременно долбят этот файл)

В случае клиент серверной это выглядит так
Много приложений (одновременно долбят этот сервер) -> один сервер -> один файл (один долбит этот файл)

← →
Reindeer Moss Eater (2003-09-17 12:08) [45]

Клиент-сервер первое, что делает, посылает нафиг услуги ОС по работе с файлами, и работает с базой сам.

Это IB то "сам" ???

← →
Anatoly Podgoretsky (2003-09-17 12:11) [46]

Reindeer Moss Eater © (17.09.03 12:08) [45]
Да не стоит про всех говорить

← →
Romkin (2003-09-17 12:13) [47]

IB - да, старается. Хотя бы контролировать, что данные физически записаны в базу, а не валяются в кеше
MSSQL - точно сам :)

← →
Reindeer Moss Eater (2003-09-17 12:13) [48]

Romkin ©

IB и MSSQL - точно НЕ САМ.

← →
Romkin (2003-09-17 12:16) [49]

2Reindeer Moss Eater
forced writes посмотри в параметрах IB

← →
Reindeer Moss Eater (2003-09-17 12:21) [50]

Romkin ©

У IB и MSSQL базы существуют в виде дисковых файлов на томах, созданных ОС и ею же поддерживаемых.
ОС пишет и читает данные из файла, а не IB и MSSQL.

То же самое происходит когда программа из папки Delphi\Demos работает с БД DBDEMOS.

С точностью до миллиметра.

← →
Vlad (2003-09-17 12:24) [51]

>Romkin © (17.09.03 12:06) [43]
>Клиент-сервер первое, что делает, посылает нафиг услуги ОС по >работе с файлами
Это глупость.
Еще скажи что одно и то же клиент-серверное приложение будет под разными ОС работать одинаково.

← →
Romkin (2003-09-17 12:24) [52]

Ты ошибаешься, и очень сильно

← →
Romkin (2003-09-17 12:26) [53]

2Vlad IB - будет :)
Ессно, посылает не generic доступ к файлам через ОС, а именно услуги, вроде кеширования, упреждающего чтения и тд. Стараются выкинуть все, кроме самого необходимого

← →
Romkin (2003-09-17 12:30) [54]

НАсколько я еще помню, даже у MSSQL есть вариант установки, при котором база ставится на чистый раздел диска, и работа идет фактически напрямую с секторами. У IB исходно свой кеш для данных, и жесткий контроль за их чтением-записью системой.

← →
Vlad (2003-09-17 12:38) [55]

>Romkin © (17.09.03 12:30) [54]
Я точно не скажу, но по моему это что-то из области фантастики.
Даже Oracle так до сих пор еще не решился выпустить версию, не зависящую от операционной системы, т.е. со своей встроенной ОС

← →
Reindeer Moss Eater (2003-09-17 12:39) [56]

Romkin ©
По порядку.

1.
IBSERVER.EXE, MSSQL сервер и БДЕ пользуются услугами kenel32.dll для работы с данными, а вовсе не сами пишут/читают диск.

2. Если Oracle имеет поддержку баз данных на RAW разделах, то это ничего не означает кроме того, что есть такая поддержка.

Надежность самих данных на диске зависит от конкретных реализаций методов работы с данными и никак не зависит от различных ситуаций описанных в п.2 и п.2

← →
Reindeer Moss Eater (2003-09-17 12:41) [57]

Кстати, поспрашивайте у опытных (имеющих многолетний опыт) администраторов БД часто ли они пользуются фичами "сырых" разделов.

← →
Romkin (2003-09-17 12:51) [58]

Все, убедили, сдаюсь! Файл-сервер гораздо надежнее клиент-сервера, и данные в dBase теряются реже, чем в MSSQL, срочно перехожу. Это ж как клиенты обрадуются!

← →
Romkin (2003-09-17 12:55) [59]

Вот только одного не пойму: была у меня системка на фай-сервере, всего два пользователя работало... ТАк каждый день то индекс сбойнул, то сбой питания и файлы чинить... Переписал на IB - год работы, хоть бы строчка потерялась. Скууучно!

← →
Reindeer Moss Eater (2003-09-17 12:55) [60]

Romkin ©

Неужели так трудно понять, что рассуждения приведенные выше не относятся конкретно к БДЕ+Dbase и IB?
Рассуждения касаются системы файл-сервер и системы клиент-сервер

← →
Reindeer Moss Eater (2003-09-17 12:58) [61]

В природе нет причин, мешающих Борланду написать версию БДЕ в которой Dbase файлы будут намного сохраннее данных в существующих версиях IB.

← →
Romkin (2003-09-17 13:01) [62]

А мне какая разница? ОС по-любому я не доверяю, и на откуп ей работу с БД не отдам. Пусть сервер мне обеспечивает то, что должно: полную защиту данных и проверку, как оно там записалось, да и восстановит в случае чего...
Вот именно что ты рассуждаешь обо всей системе. И количество звеньев не имеет особого значения, если бы все было так просто!
Сервер приложений делает то, до чего у ОС руки просто не доходят, и в результате этого надежность у клиент-серверной технологии гораздо выше, чем у файл-сервера.
И не надо мне говорить, что лишнее звено уменьшает надежность, не так это в общем случае, чушь. Это правильно, только если остальные звенья неизменными остаются. А тут все кардинально меняется

← →
Romkin (2003-09-17 13:02) [63]

2Reindeer Moss Eater ДА ни слова я о BDE не сказал. а вот что будут сохраннее - так это сервер БД и получится, это его задача.

← →
Reindeer Moss Eater (2003-09-17 13:04) [64]

ОС по-любому я не доверяю
Смешно. А вот сервер, на который ты молишься, только с помошью ее родимой и может работать с диском.

А тут все кардинально меняется
И что же именно?

← →
Romkin (2003-09-17 13:07) [65]

2Reindeer Moss Eater Не молюсь я ни на чего. Это во-первых.
Во-вторых, что меняется, я уже объяснил.

← →
Reindeer Moss Eater (2003-09-17 13:16) [66]

Последний раз и на пальцах.

1.Берем Dbase файл и некий механизм доступа к нему (скажем БДЕ)
2.Берем SQL сервер IB.

В обоих случаях имеем программный код (dll в первом случае и
exe во втором случае) который обращается к одной и той же kernel32.dll за функциями открытия чтения и записи файлов.

То, что данные в многопользовательском режиме более сохранны у IB говорит всего лишь о качестве кода и качестве алгоритмов в сервере IB против кода и алгоритмов реализованных в БДЕ.

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

Надежность данных IB - не следствие архитектуры клиент-сервер, а следствие умения программистов, написавших код IB.

Поэтому я м утвержал, что файл сервер надежнее. Потому, что все принципиально одинаковое, а компонентов у него меньше.

← →
Romkin (2003-09-17 13:24) [67]

Вот только не надо заявлений типа "ручки не так заточены, потому и криво получилось". О BDE я вообще молчал. Просто ни на одной файл-серверной системе принципиально невозможно достичь надежности сервера, именно потому, что невозможно обеспечить контроль за действиями всех пользователей и действиями ОС с файлами. И надежность сервера - именно в самой технологии, именно поэтому сейчас уже заканчивается миграция на клиент-серверную технологию.
И, прости, но я никогда не поверю, что файл-серверная система надежнее клиент-серверной. Таких нет. Тот же FoxPro, Access, Paradox никогда не достигнут уровня сохранности данных сервера. Это теоретически невозможно без серверного компонента

← →
Reindeer Moss Eater (2003-09-17 13:26) [68]

1. Не надо высасывать из пальца несказанных мной заявлений.

Просто ни на одной файл-серверной системе принципиально невозможно достичь надежности сервера, именно потому, что невозможно обеспечить контроль за действиями всех пользователей и действиями ОС с файлами.

В чем принципиальная невозможность этого?

← →
Reindeer Moss Eater (2003-09-17 13:36) [69]

Кроме того, пора уже вникнуть в смысл того, против чего ты возражаешь. См [9]

Система клиент-сервер уязвима потому что уязвимы:
-Процесс сервера
-Клиентские библиотеки
-Физическая БД
-Сетевые библиотеки
-Канал связи
-Протоколы работы клиента и сервера (несовпадение)
и т.д.

Система файл-сервер уязвима потому что уязвимы:
-Физическая БД
-Библиотеки доступа

← →
Romkin (2003-09-17 13:44) [70]

1. Отсутствует контроль за действиями ОС с файлом. ТЫ можешь дать команду вида FlushBuffers, но фактически запись на диск не контролируется. В случае доступа через сеть - вообще все отдается системе на сервере.
2. Отсутствует контроль за действиями других пользователей, кроме наложения блокировок на записи файла, которые также контролируются только ОС.
3. Невозможность обеспечить т.н. транзакционную целостность - изоляцию изменений данных разными пользователями и атомарность этих изменений
4. Не надо забывать и о защите собственно файлов данных от несанкционированного изменения. Увы, в файл-сервере доступ к файлу полностью открыт.

← →
Deniz (2003-09-17 13:47) [71]

Можно я тоже спрошу?
> Reindeer Moss Eater © (17.09.03 13:36) [69]
Кроме того, пора уже вникнуть в смысл того, против чего ты возражаешь. См [9]

Система клиент-сервер уязвима потому что уязвимы:
-Процесс сервера
-Клиентские библиотеки
-Физическая БД
-Сетевые библиотеки
-Канал связи
-Протоколы работы клиента и сервера (несовпадение)
и т.д.

Система файл-сервер уязвима потому что уязвимы:
-Физическая БД
-Библиотеки доступа

А где для файл-сервера ...
-Сетевые библиотеки
-Канал связи
-Протоколы работы клиента и сервера (несовпадение)
... или это не используется?
И еще, клиент сам должен управлять записью данных на файл-сервер и что бы они в кеше не лежали? Вот и зависимость от ОС.

← →
Romkin (2003-09-17 13:52) [72]

ЭЭЭ! Если говорим о сетевом доступе, тогда уж и к файл-серверу добавляй сетевые библиотеки и канал связи. Или у тебя данные из файла по воздуху читаются? Ао несовпадении протоколов... Ну-ну
И под "уязвимостью" здесь трудно что-либо понимать, мне испортить файл в файл-сервере гораздо проще, чем базу у сервера и сам сервер. Легче просто операционную систему порушить. НО это вопрос защиты, клиент-сервер я просто могу закрыть так, что при всем желании не залезешь.
Бесполезный спор. Я просто не видел файл-сервера, который был бы надежнее клиент-сервера

← →
Reindeer Moss Eater (2003-09-17 13:52) [73]

Romkin ©

Ты перечислил 4 пункта, которых нет в известных тебе системах файл-сервер, а я спросил про принципиальную невозможность их реализации.

← →
Romkin (2003-09-17 14:03) [74]

Я перечислил пункты, которые невозможно реализовать в файл-сервере, а не те, которых нет в известных мне...
Если ты считаешь, что это можно реализовать без наличия сервера. Мда...

← →
Reindeer Moss Eater (2003-09-17 14:07) [75]

Я перечислил пункты, которые невозможно реализовать в файл-сервере

Может хватит заклинаний? В чем заключается сама невозможность?

Используется один и тот же механизм доступа к диску, один и тот же кеrnel32.dll одни и те же функции OpenFile, WriteFile....

Летят два пассажира в одном и том же самолете но в разных салонах на высоте 12000 метров. Жизнь которого надежнее защищена?

← →
Vlad (2003-09-17 14:09) [76]

>Reindeer Moss Eater © (17.09.03 14:07) [75]
У которого парашют есть. :)

← →
Romkin (2003-09-17 14:11) [77]

Все, я больше не могу... :))))

← →
Romkin (2003-09-17 14:14) [78]

Опять он о своем...
Дак можно дойти до того, что все программы, работающие на одном диске под одной ОС абсолютно одинаково надежны...

← →
Vlad (2003-09-17 14:18) [79]

Так какую же технологию выбрать автору для трехзвенки ? :)))

← →
Romkin (2003-09-17 14:19) [80]

Летят два пассажира в разных самолетах. Один самолет диспетчер ведет, а другой сам, по карте. НА каком полетишь? НА с диспетчером? а ведь он уязвим, лишнее звено

← →
Romkin (2003-09-17 14:20) [81]

2Vlad А автору надо на файл-сервер переходить, он надежнее всего

← →
Vlad (2003-09-17 14:23) [82]

>Romkin © (17.09.03 14:20) [81]
Только пусть предварительно полетает на самолетах по карте, сначала в бизнес-классе, потом в обычном салоне (но не ниже 12000 метров), потом до него допрет что вы тут имели ввиду, и решит что лучше.

← →
Reindeer Moss Eater (2003-09-17 14:26) [83]

Один самолет диспетчер ведет, а другой сам, по карте.

Оба самолета ведет один и тот же kernel32.dll

← →
Romkin (2003-09-17 14:28) [84]

← →
Reindeer Moss Eater (2003-09-17 14:30) [85]

Ночего подобного, это у них двигатели одинаковы, kernel32. А вот один самолет сервер в качестве диспетчера ведет, предохраняет от столкновения с другими, маршрут подсказывает...

А теперь скажи что мешает, принципиально мешает предохранять другой самолет?

← →
Vlad (2003-09-17 14:30) [86]

Ну да, тут недавно один Kernel32 долетался. Из-за диспетчера между прочим. Сам по ящику слышал.

← →
Deniz (2003-09-17 14:30) [87]

Давай-давай, до сотни чуть-чуть осталось :)))
Кстати, а где автор?

← →
Romkin (2003-09-17 14:36) [88]

2Reindeer Moss Eater Конструкция самолета, обзор из кабины-то ограничен :))

Автор, кажись, просто обалдел. Все, заканчиваем, а то плюсов накидают...

2Vlad Ну никто же после этого не орет, что нафиг этих диспетчеров, сами долетим :)))

← →
Vlad (2003-09-17 14:39) [89]

Тогда напоследок:

С неба звездочка упала - ил, наверно восемнадцать
Два диспетчера получат лет, наверно по пятнадцать.

← →
Anatoly Podgoretsky (2003-09-17 15:36) [90]

Reindeer Moss Eater © (17.09.03 14:30) [85]
Ничего не мешает, и попытки были сделаны в Парадоксе, лучше бы они их не делали, рещультат оказался противоположным, системы без этого много стабильнее - оправдалась теория о лишних звеньях.

← →
Andriano (2003-09-17 16:16) [91]

Э-э-э...м-да...

Ну так вот, готовлю тест для Интранет пока. Ещё раз спасибо за помощь.

Меня вообще не интересует безопасность, я её простым FireWall-ом обеспечу за пять минут.
Про надежность - FB очень надежен в локальной сети, примерно тоже самое будет и в Интранет.

Вот что уже увидел. Просто добавляем 10000 записей в таблицу с одним полем VarChar(300). Добавляю строки длиной 80 символов. Транзакцию подтверждаю через каждые 1000 записей. Использую TpFIBQuery. Операция занимает 30 сек. За это время передается 3Мб, а читается 6Мб. Чё то это страшно. Чем он там занимается, ведь в теории должен передать ЗАПРОС+ДАННЫЕ=~100 байт, 100*10000=1Мб ну пусть 2Мб, ну не 9 же. Операция конечно большая, но всё равно. Это всё в локальной сети 100Мбит.

← →
Andriano (2003-09-17 16:18) [92]

Так вот к чему я это - подозреваю, что при трехзвенке трафик сильно уменьшится (между сервером приложений и тонким клиентом разумеется).

← →
Vlad (2003-09-17 16:24) [93]

>Andriano (17.09.03 16:18) [92]
Естественно уменьшится. Ровно на величину запроса. Объем данных как был так и останется.

← →
Romkin (2003-09-17 16:38) [94]

FB1.0 ? Вроде туда опять вернули благополучно фиксенное свойство, когда varchar передается по сети полностью :) То есть, твои 80 символов никого не касают, идет 300... А FIBQuery вроде потом перечитывает...
Переходи на FB1.5.
А попробовать, насколько уменьшится трафик - так сделать TRemoteDataModule с одной таблицей просто и быстро, вот и посмотришь. Выигрыш, думаю, раз в десять будет. А нет, в девять :))

← →
Maestro (2003-09-17 18:24) [95]

Дискуссия очень интересная. И всё-же, несмотря на все факты, Reindeer Moss Eater не поменял своего мнения, на тему: что же всё-таки лучне и безопаснее (Файл-сервер иои клиент сервер). Попробую и я так сказать, вместе со свем миром, попробывать убедить упёртого.
1. Вначале по-поводу операционки: что касается Windows, то читал я уже давно такую историю когда wind-ы поставили на истребитель... Я думаю не я один это читал... Вообще на мой взгляд, от услуг MS по возможности стоит отказаться, и к тому же если есть желание сохранить данные и быть твёрдо уверенным что эти данные будут правельными, стоит использовать зеркалирование!!!
2. По-поводу лишнего звена: Примеры с летательными аппаратами и вообще техникой тут приведены хорошо так что попробую оюъяснить на примере машин: На сколько все знают, раньше в автомобилях испольховалась тормозная система "нога" то есть с какой силой надавишь на педаль, с той же силой и коллодки к дискам прежмуться, а сейчас, как опять таки все знают, всётаки используется гидравлика, чтобы эффект больше был. В последнем случае чисто теорретически поломк должно быть больше, но на практике их число остаётся не изменным.
Reindeer Moss Eater, не всегда "лишнее" звено даёт большую "сбойность" системы. А в случае файл-сервера никакие звенья не убираются а даже наоборот прибавляются. Потаму что за место того чтобы, допустим IB, следила за целосностью данных и уровнях доступа, следит MS win. Чем это лучше и надёжнее???
Да и сервер БД следит только за БД за продукты MS у нас уникальные они ж типа всё могут... только через зад :)...
3. Теперь про сеть: при работе файл-сервера трафик всё равно в несколько раз больше чем при клиент-серверной связке... С этим надеюсь, никто спорить не будет... :)
А от сюда и надёжность у клиент-сервера выше, ведь терять то меньше может (то есть колличество информации меньше).
4. контроль за целостностью данных в файл-сервере, по-большому счёту в принцепи отсудствует (для многопользовательского режима доступа). это написано во всех книгах по ОСНОВАМ программирования БД...

← →
Maestro (2003-09-17 18:26) [96]

← →
Reindeer Moss Eater (2003-09-17 18:27) [97]

И всё-же, несмотря на все факты, Reindeer Moss Eater не поменял своего мнения, на тему: что же всё-таки лучне и безопаснее (Файл-сервер иои клиент сервер).

Не это темой разговора было (не файл сервер против клиент-сервера)

← →
Sandman25 (2003-09-17 18:28) [98]

[95] Maestro (17.09.03 18:24)

Честно говоря, не знаю, почему Вы считаете Reindeer Moss Eater упертым и одиноким.
Строго говоря, он прав ИМХО, во всяком случае его логика корректна и не была опровергнута безупречными логическими аргументами.
Хотя я подозреваю, что все-таки современные клиент-серверные технологии ему нравятся больше файл-серверных :)

← →
Maestro (2003-09-17 18:34) [99]

[98] Sandman25 © (17.09.03 18:28)
ну дык. Может тогда скажешь в чём я не прав.... Это дискуссия и вполне может оказаться что моё мнение неправильно

← →
Reindeer Moss Eater (2003-09-17 18:35) [100]

1. Вначале по-поводу операционки: что касается Windows, то читал я уже давно такую историю когда wind-ы поставили на истребитель... Я думаю не я один это читал... Вообще на мой взгляд, от услуг MS по возможности стоит отказаться, и к тому же если есть желание сохранить данные и быть твёрдо уверенным что эти данные будут правельными, стоит использовать зеркалирование!!!

И как это зеркалирование связано с отказом от услуг Windows?

2. По-поводу лишнего звена: Примеры с летательными аппаратами и вообще техникой тут приведены хорошо так что попробую оюъяснить на примере машин: На сколько все знают, раньше в автомобилях испольховалась тормозная система "нога" то есть с какой силой надавишь на педаль, с той же силой и коллодки к дискам прежмуться, а сейчас, как опять таки все знают, всётаки используется гидравлика, чтобы эффект больше был. В последнем случае чисто теорретически поломк должно быть больше, но на практике их число остаётся не изменным.

Откуда такие данные?

Reindeer Moss Eater, не всегда "лишнее" звено даёт большую "сбойность" системы. А в случае файл-сервера никакие звенья не убираются а даже наоборот прибавляются. Потаму что за место того чтобы, допустим IB, следила за целосностью данных и уровнях доступа, следит MS win. Чем это лучше и надёжнее???
Да и сервер БД следит только за БД за продукты MS у нас уникальные они ж типа всё могут... только через зад :)...

Какой-то сплошной поток сознания. Лучше расскажите про "сервер сам следит" каков механизм этого слежения? И почему код библиотеки доступа файл-сервера не может "следить"?

3. Теперь про сеть: при работе файл-сервера трафик всё равно в несколько раз больше чем при клиент-серверной связке... С этим надеюсь, никто спорить не будет... :)

Если такой умный, то наверное заметил, что я не советовал автору вопроса заменять клиент-сервер файл-сервером?

А от сюда и надёжность у клиент-сервера выше, ведь терять то меньше может (то есть колличество информации меньше).
4. контроль за целостностью данных в файл-сервере, по-большому счёту в принцепи отсудствует (для многопользовательского режима доступа). это написано во всех книгах по ОСНОВАМ программирования БД...

В каком таком принцепи отсутствует?

← →
Sandman25 (2003-09-17 18:36) [101]

[99] Maestro (17.09.03 18:34)

И ты прав :)

Его противники не пытались его опровергнуть, а доказывали собственное утверждение, которое никак не было связано с утверждением Reindeer Moss Eater.

← →
Vlad (2003-09-17 18:38) [102]

Дорогой Маэстро.
1) Отказываться от использования Windows - идея хорошая, но попробуй ка воплоти ее на более-менее крупном предприятии. Да и работает она вобщем-то нормально, если грамотно с ней обращаться
2)По поводу гидравлики. Ты в этом уверен ? Наверное мало на машинах ездил.
3)Наверное ты никогда не работал с Btrieve например.
4)Целостность данных обеспечивается в программе. И если руки не кривые, то можно обеспечить ее не хуже чем в клиент-сервере.

← →
Romkin (2003-09-17 18:43) [103]

НУ остается мне еще подсыпать :)
http://www.partmotor.com/psites/delphikmb/csvcfs.htm

← →
Romkin (2003-09-17 18:47) [104]

ЗАбыл сказать: по данному тексту хай сюда http://delphimaster.net/view/-1061375903/

← →
Reindeer Moss Eater (2003-09-17 18:51) [105]

Romkin ©

Предлагаю вспомнить с чего все началось, и не продолжать меня убеждать в преимуществах клиент-серверных систем.

1. Я сказал, что система из двух элементов надежнее системы из трех элементов. (имелось ввиду самостоятельное промежуточное звено, а не звено дублирующее функции одного из двух звеньев)

2. Romkin отвечает, что :
Ну это ты погорячился. Следуя этой логике, клиент-сервер менее надежен, чем файл-сервер :) Лишнее звено же есть...

Итак, я не приходил в эту ветку с призывами перелезать на файл-сервер с sql серверов.
Хотя и заметил, что замечание Ромкина хоть и парадоксальное, но верное по сути своей.

← →
Maestro (2003-09-17 18:55) [106]

Reindeer Moss Eater [100]
во первых поздравляю уже 100 !! :)
Я не говорю про полный уход от ОС, я говорю про то что программа, заточенная под БД обращается с БД лучше чем ОС в принцепи...

Откуда такие данные?
Ну стаж вождения в сумме 10 лет, когда-то и в гонках участвовал (до аварии :) ). Да Vlad по-поводу гидравлики я уверен на 100% только эту тебя думаю продолжать не стоит а то опять самолёты полетят :))) согласен?

Какой-то сплошной поток сознания. Лучше расскажите про "сервер сам следит" каков механизм этого слежения? И почему код библиотеки доступа файл-сервера не может "следить"?

роли и права

Если такой умный, то наверное заметил, что я не советовал автору вопроса заменять клиент-сервер файл-сервером?

мы тут говорим про надёжность. Так вот чем меньше колличество информации, тем мнеше вероятность её потерять

В каком таком принцепи отсутствует?
в том смымле что доступ к записям может осуществляться 2-мя пользователями одновременно и изменения одного пользователя будут не видны другому...

А вообще соглашусь с Vlad-ом если руки кривые то ничего не поможкт :)

← →
Sandman25 (2003-09-17 18:58) [107]

мы тут говорим про надёжность. Так вот чем меньше колличество информации, тем мнеше вероятность её потерять

Если потерян 1 символ из предложения в 15 слов, то информация почти не потеряна.
Если потерян 1 символ из 1 символа, то мы имеем полную неопределенность. Кто его знает, что там был за символ.

Но это я так, из вредности цепляюсь, а вообще согласен :)

Иду домой, всем пока.

← →
Reindeer Moss Eater (2003-09-17 18:58) [108]

Я не говорю про полный уход от ОС, я говорю про то что программа, заточенная под БД обращается с БД лучше чем ОС в принцепи...

Да расскажи же наконец про этот магический принцип. Страсть как антиресно!

мы тут говорим про надёжность. Так вот чем меньше колличество информации, тем мнеше вероятность её потерять

Не знаю про что говорите вы, я говорю про надежность системы и ее неуклонное уменьшение с ростом числа элементов.

в том смымле что доступ к записям может осуществляться 2-мя пользователями одновременно и изменения одного пользователя будут не видны другому...

Смеятся после слова "лопата"?

← →
Maestro (2003-09-17 19:07) [109]

Reindeer Moss Eater © [108]
не цепляйся к словам... Это всего-лишь дискуссия, а не предвыборные дибаты :)
Расскажи лучше про то как именнго файл-сервере надёжно избавиться от двойново доступа без использования дополнительных таблиц учёта пользователей.

лопата :)
Ладно Всем пока.
Завтра продолжим, ежели не возражаете :)
Всем удачного вечера

← →
Reindeer Moss Eater (2003-09-17 19:08) [110]

Меня тоже нет

Какую технологию выбрать для трехзвенки? Найти похожие ветки