![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Какую технологию выбрать для трехзвенки? [D6, FB 1.0]
Andriano © (2003-09-17 09:23:00)
Есть 8 компьютеров в одной сети Интранет с каналами минимум 64кбит/с.
Требуется написать упрощенный оперативный торговский учет.
1.Если тонким клиентом будет Web-браузер, то придется много разбираться с Java или HTML (синтаксис и доступ к данным).
2.Есть ещё возможность использовать Remoute Data Module.
Привык использовать компоненты FIB plus. Получается, чтобы использовать все наработки и опыт, да и вообще писать в любимой среде Delphi, придется выбрать 2-ой вариант. Насколько это надежно и безглючно?
Есть ли другие варианты?
Может вообще обойтись грамотной двухзвенкой (широко использовать внутренние процедуры и тригеры)? При предварительном расмотрении задачи, кажется, что очень больших потоков данных не будет.
Кто писал трехзвенку, поделитесь опытом.
Reindeer Moss Eater (2003-09-17 12:21:00) [61]
Romkin ©
У IB и MSSQL базы существуют в виде дисковых файлов на томах, созданных ОС и ею же поддерживаемых.
ОС пишет и читает данные из файла, а не IB и MSSQL.
То же самое происходит когда программа из папки Delphi\Demos работает с БД DBDEMOS.
С точностью до миллиметра.
Romkin (2003-09-17 12:16:00) [62]
2Reindeer Moss Eater
forced writes посмотри в параметрах IB
Romkin (2003-09-17 12:13:00) [63]
IB - да, старается. Хотя бы контролировать, что данные физически записаны в базу, а не валяются в кеше
MSSQL - точно сам :)
Reindeer Moss Eater (2003-09-17 12:13:00) [64]
Romkin ©
IB и MSSQL - точно НЕ САМ.
Anatoly Podgoretsky (2003-09-17 12:11:00) [65]
Reindeer Moss Eater © (17.09.03 12:08) [45]
Да не стоит про всех говорить
Reindeer Moss Eater (2003-09-17 12:08:00) [66]
Клиент-сервер первое, что делает, посылает нафиг услуги ОС по работе с файлами, и работает с базой сам.
Это IB то "сам" ???
Anatoly Podgoretsky (2003-09-17 12:07:00) [67]
Наверно вводит в заблждение, различная надежно приложений, но так это относится к клиент/серверным тоже. В целом при одинаковых условиях более многозвенное ниже по надежности менее многозвенного. Но только сравнивать надо корректно.
В случае файл серверной это выглядит иначе
Много приложений -> один файл (одновременно долбят этот файл)
В случае клиент серверной это выглядит так
Много приложений (одновременно долбят этот сервер) -> один сервер -> один файл (один долбит этот файл)
Romkin (2003-09-17 12:06:00) [68]
:) Оригинально. Вероятность сбоя системы равна произведению вероятности сбоя ее составных частей.
Повысить надежность системы в целом можно двумя путями: снизить количество звеньев либоповысив надежность этих звеньев.
Иначе мы бы и в космос не летали.
О чем я и толкую.
Во-первых, двухзвенка выглядит немного не так, между файлом и приложением есть прослойка в виде ОС, которая, в частности, и обеспечивает работу с файлами, а приложение общается с файловыми ее буферами. Клиент-сервер первое, что делает, посылает нафиг услуги ОС по работе с файлами, и работает с базой сам.
Плюс сервер обеспечивает дополнительную защиту данных от неправильных действий клиента. РЕзультат - во втором случае надежность звеньев выше, чем в первом, чаще всего и суммарная надежность системы повышается.
Vlad (2003-09-17 12:05:00) [69]
>Sandman25 © (17.09.03 12:03) [41]
А еще ведь питание могут отрубить ! :)
Так что прав Reindeer Moss Eater. Чем больше звеньев - тем меньше суммарная надежность системы.
Vlad (2003-09-17 12:03:00) [70]
>Sergey13 © (17.09.03 11:54) [38]
Согласен, клиентская часть не зависит от сервера, т.е. удобство перевода под другую СУБД, и вобще под другую структуру данных - налицо.
Но зачастую, особенно в небольших компаниях с небольшим числом пользоватетей - соотношение выгоды к затратам - минимальное, при разработке трехзвенки.
Sandman25 (2003-09-17 12:03:00) [71]
[39] Reindeer Moss Eater © (17.09.03 11:57)
Лучше не так объяснять. Сервер приложений кто-то стер с диска и система перестала работать. У файл-сервера ничего подобного нет, поэтому он будет работать как ни в чем не бывало :)
Reindeer Moss Eater (2003-09-17 11:57:00) [72]
Romkin ©
Я, например, гарантирую, что данные в моем приложении на IB потеряются только при физическом повреждении диска, остальное - не касает. При файл-сервере такого я гарантировать не могу.
Опять ты про данные. Я что, так неразборчиво пишу по-русски?
Что такое система файл-сервер?
Есть приложение, которое открывает файл на запись/чтение. Все.
Что такое система клиент-сервер?
Есть приложение, которое открывает файл на запись/чтение.
Есть приложение, общающееся с первым приложением. Все.
Вторая система более уязвима. Потому что в ней больше элементов, каждый из которых имеет свою надежность.
Система файл-сервер более надежна чем система клиент-сервер.
Так понятно?
Sergey13 (2003-09-17 11:54:00) [73]
Вот это дискуссия рарослась!!!
ИМХО, лучше всех (как всегда 8-) АП отразил основные преимущества.
От себя добавлю (в чем то повторяя АП), что многозвенка с ее изоляцией от БД, позволяет использовать в работе разнородные БД и платформы, и делает клиента независимым от изменения этой разнородности (он о ней даже не подозревает). Т.е. не надо ставить всякие клиенты доступа при переходе например с М$ на Оракл. Достаточно поменять сервер приложений. Но это наиболее актуально для ЗДОРОВЕННЫХ и распределенных проектов. В работе с одним сервером БД преимущества смазываются, хотя для разработчиков "коробочных" продуктов удобно "приделывать" к своим проектам разные БД, переписав только сервер приложений.
Vlad (2003-09-17 11:51:00) [74]
В конечном итоге, считаю, что автору стоит задуматься, а нужна ли ему вобще трехзвенка ?
Защиту данных от клиента можно ведь организовать путем запрета их изменения (только через хранимки, например), отображение - через View.
И если соотношение - мощность сервера БД/количество одновременно работающих пользователей, приличное, то тут вполне можно обойтись и двухзвенной архитектурой.
Romkin (2003-09-17 11:50:00) [75]
Если бы она была выше, то никто бы сервера БД не использовал. И не выше она, не может этого быть. И что ты подразумеваешь под "Система в целом"? Я, например, гарантирую, что данные в моем приложении на IB потеряются только при физическом повреждении диска, остальное - не касает. При файл-сервере такого я гарантировать не могу.
Reindeer Moss Eater (2003-09-17 11:47:00) [76]
Romkin © да забудь ты про файлы.
Я тебе про надежность системы в целом говорю.
У файлсервера она выше.
Romkin (2003-09-17 11:45:00) [77]
Если файл-сервер не трогать, то пофиг. А вот когда работаешь, то практически любой сервер заботится о своих файлах, даже Interbase контролирует запись в базу, помимо ОС. Хотя он опирается на имеющуюся файловую систему, но его база фактически его файловая система. Остальные сервера делают как минимум так, именно для повышения надежности.
Sandman25 (2003-09-17 11:40:00) [78]
[32] Reindeer Moss Eater © (17.09.03 11:37)
Ну да, естественно. Наверное, надежность даже снижается - ведь физическая запись происходит не так часто, как обычно. Впрочем, время между этими checkpoints настраивается.
Reindeer Moss Eater (2003-09-17 11:37:00) [79]
Не всегда так. У нас стоит Informix в режиме raw, он хранит данные не в файлах ОС, а работает с жестким диском напрямую.
Согласен, не всегда. Только raw partition сами по себе опять таки не снижают и не повышают надежности хранения данных.
Разработчики надеются с их помощью увеличить скорость I/O операций.
Sandman25 (2003-09-17 11:33:00) [80]
[30] Reindeer Moss Eater © (17.09.03 11:28)
>И те и другие хранят свои данные на жестких дисках, которые ничего не знают про сами системы, и обслуживаются ОС.
Не всегда так. У нас стоит Informix в режиме raw, он хранит данные не в файлах ОС, а работает с жестким диском напрямую.