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

← →
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]

← →
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]

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

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