Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Какую технологию выбрать для трехзвенки? [D6, FB 1.0]


Страницы:   1 2 3 4 5 6

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, он хранит данные не в файлах ОС, а работает с жестким диском напрямую.


Страницы:   1 2 3 4 5 6

Наверх

Титульная страница Поиск, карта сайта Написать письмо