Сранение серверов. 3-х звенная архитектура ИЛИ Стоит ли городить огород.

[Dracosha Andrew]

Несколько постулатов и кооментариев

1. Бесплатный сыр бывает только в мышеловке.
(без комментариев)
2. Дорогая лицензия не значит дорогая разработка
(например 80% российских разработок на Оракле не включают в себя стоимость лицензии на Оракл, а MSDE ( настольный вариант MS SQL сервера не требует лицензирования разработчиком)
3. Скорость работы любого сервера зависит от задач и как программист сумеет воспользоваться его преимуществами. (Напрмер MS SQL операци типа Update и Insert производит быстрее чем Oracle, но Oracle быстрее выполняет запросы типа SELECT, особенно сложносвязанные запросы)
4. Если все обращения к серверу производить через серверные процедуры, то в этом случае работа серверов будет абсолютна идентична и разницы между ними не будет. (Ведь результатом всегда будет таблица (рекордсет))
5. А нафига тогда 3-звенка?? (сомнительное утверждение)
6. К сожаление несмотря на все вышенаписанное трехзвенная многплатформенная архитектура остается мечтой (и моей в том числе). Ибо вопрос "на чем писать клиента" остается вопросом вопросов.
7. PosgreSQL нее так прост как хотелось бы. Я имею в виду в обслуживании (попробуйте научить бухгалтера делать BACKUP и RESTORE)

[Демидова Татьяна]

попробуйте научить бухгалтера делать BACKUP и RESTORE

я бы попросила! Если ужэ обезьяну научили курить, то почему бухгалтера нельзя научить?

[ToT]

я бы попросила! Если ужэ обезьяну научили курить, то почему бухгалтера нельзя научить?

А зачем этой гадости учить бухгалтера?

[Демидова Татьяна]

ToT ну мало ли...... вдруг потребуется? А вообще по теме вопроса даже и не спорю, так как не понимаю вообщео чем речь.

[wanderer]

> 1. Бесплатный сыр бывает только в мышеловке.
> (без комментариев)
Помилуйте, никто и никогда не говорил о бесплатности вообще и в данном контексте в частности.
> 2. Дорогая лицензия не значит дорогая разработка
Согласен, но говорить руководителю фирмы о необходимости приобретения весьма дорогостоящего
программного продукта на платформе которого работает менее дорогостоящий, неудобно.
> 3. Скорость работы любого сервера зависит от задач и как программист сумеет воспользоваться
Никак не могу с этим спорит. Конечно Oracle или DB2 заметно лучше PostgreSQL.
Но и Postgres пойдет, особливо для экспериментов.
> 4. Если все обращения к серверу производить через серверные процедуры, то в этом случае работа серверов будет абсолютна идентична и разницы между ними не будет. (Ведь результатом всегда будет таблица (рекордсет))
> 5. А нафига тогда 3-звенка?? (сомнительное утверждение)
Сомнение - корень поиска .
а) Если допустить мысль что система должна работать в Internet и клиенты могут быть географически
удалены друг от друга, надо понимать что сервер баз данных надо публиковать в сети. Даже принимая
во внимание наличие SSL, VPN и прочие аппаратные и програмные штуки публиковать базу в сети не очень
безопасно. Даже если она надежно закрыта, пользователь (вполе аутентичный) может набезобразничать
в таблицах используя то же Excel. (прошу заметить что я "отдаленно" слышал про триггеры и протоколирование).
Все же мне было бы приятно думать что клиент ходит на сервер через иной, контролируемый протокол.
б) Многие запросы могут быть велики, равно как и получаемые в результате кортежи. И часто их при
работе с одним клиентским интерфейсом бывает много и часто результаты запросов надо еще обработать
немного а это заметно отяжеляет клиента и приводит к увеличению транспортных расходов.
в) Если правильно скомпоновать сервер приложения, то отдельные части системы могут быть отделены
друг от друга и представлены в виде некой клиентской интерфесйной библиотеки, которая может быть
оспользована сторонним программистом и даже в стороннем приложении. Ну разве было бы не приятно
работать с библиотекой проводок ( к примеру) при разработке склада (к примеру) и не думать о
лишнем, не ковыряться в таблицах и серверных встроенных процедурах.
> 6. К сожаление несмотря на все вышенаписанное трехзвенная многплатформенная архитектура
> остается мечтой (и моей в том числе). Ибо вопрос "на чем писать клиента" остается вопросом
> вопросов.
Да, но ответы на него дает каждая фирма(группа) самостоятельно.
> 7. PosgreSQL нее так прост как хотелось бы. Я имею в виду в обслуживании (попробуйте
> научить бухгалтера делать BACKUP и RESTORE)
И не буду учить. Просто предложу набор интерфейсных утилит.
А что касается самой новой темы. Если так пойдет дальше, то очень скоро возникнут ветки
об использовании Corba/COM, XML, JAVA, VRLM , C++, Perl, Windows, Linux, AIX, MACOS.
Будут биться Ораклисты с DB2-шниками и SYBas-ники будут подливать масло в огонь.
Для этого есть другие форумы и, как показывает практика, истина там не рождается.
Люди которые уже пишут, технологии выбрали. Группы или компании которые собираются писать
будут принимать решения после тщательного анализа и исходя из своих соображений.

[training1C]

Я программист по образованию и по текущей работе.
Когда занимался альпинизмом, то там один мой друг (не программист), когда слышал, как мы общаемся с другими программерами говорил:
"Кончайте на своем птичьем языке трындеть" :-).
Это не критика. Просто вспомнилось.

[Dracosha Andrew]

А зачем этой гадости учить бухгалтера?

Увы, но иногда приходиться. Не держать же специального человека при парке из 3-4 компов? Проще бухгалтера научить. На таких системах как PostgeSQL это не так просто , как например в MS SQL.

И не буду учить. Просто предложу набор интерфейсных утилит.

Тоже решение. Если они есть, я, например ничего подходящего под PosgeSQL не видел.

Даже если она надежно закрыта, пользователь (вполе аутентичный) может набезобразничать
в таблицах используя то же Excel.

Не может, если правов ему таких не давать. Впрочем тему лучше не продолжать.

Будут биться Ораклисты с DB2-шниками и SYBas-ники будут подливать масло в огонь

Не будут - они сюда не заходят

Я поднял эту тему просто для того, что бы было четкое обоснование платформы. Для чего? Например у разработчиков поятвится инвестор (а почему бы и нет) и не пошло к коту под хвост, то что уже наработано. Или не возникло желание сменить платформу из-за того, что то плох рассчитали (ну например трудозатраты написания каких-нибудь библиотек).

"Кончайте на своем птичьем языке трындеть" :-).

Вот для этого и вынес из основной ветки

[wanderer]

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

[Flatter]

Исходное сообщение Dracosha Andrew


Увы, но иногда приходиться. Не держать же специального человека при парке из 3-4 компов? Проще бухгалтера научить. На таких системах как PostgeSQL это не так просто , как например в MS SQL.

Ну если ты пишешь конечный програмный продукт, то зачем чему то учить буха? Помоему просто в твоем чудесном продукте должна быть кнопочка BACKUP, а точнее утилита в которой ты при устагновке сам настраиваешь BACKUP по какомуто таймауту!

[просто Дмитрий]

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

[Старый ворчун]

А зачем вообще нужны все эти $дорогостоящие трёхступенчатые страсти с непроизносимыми названиями при парке из 3 - 4 компов?

[просто Дмитрий]

Ворчалка
А зачем вообще нужны все эти $дорогостоящие трёхступенчатые страсти с непроизносимыми названиями при парке из 3 - 4 компов?

3 уровневая страсть нужна для реализации "тонкого" клиента, когда либо комп слабый( по классике) либо канал связи с сервером маленький, например сервер в инете стоит(ASP технологии) реально приложение крутится где-то, а на пользовательской машине только отображаются обработанные данные. На самом деле на 2 уровневой тоже возможно, у Борланда( для примера) есть такие технологии, сервер баз данных + сервер приложений как надстройка на СУБД. могу привести пример тонкого клиента при 2 уровнях( сам использовал через инет), если будет интерсно.

[Старый ворчун]

Исходное сообщение просто Дмитрий
СУБД. могу привести пример тонкого клиента при 2 уровнях( сам использовал через инет), если будет интерсно.

Не надо. Я реальной "работой" с/в Comshare по горло сыт.
Слышать не хочу про "через инет"

[wanderer]

Помилуйте, так это же от качества интернета зависит. И ничто не препятствует использовать подобные технологии локально. Когда я говорю о клиент-сервере и подобных технологиях, я, прежде всего, подразумеваю использование Интернета как транспортной среды на базе TCP/IP. Никак не разномастные WEB технологии

[Dracosha Andrew]

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

Там немного выше написано

3 уровневая страсть нужна для реализации "тонкого" клиента, когда либо комп слабый( по классике) либо канал связи с сервером маленький,

Вот!!!

Но 3-х уровневая система позволяет построить более гибкую систему. Т.е. Имеем 1 комп: на нем сервер данных, сервер приложений, клиентская часть.
Имеем большую компанию - один сервер данных, несколько серверов приложений и много клиентских компов. Смысл я вижу именно в гибком наращивании, иначе купить канал на 256К будет дешевле, чем программировать "такую страсть".

[wanderer]

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

[Flatter]

А собственно зачем изобретать велосипед?
Нужен тонкий клиент w2k Terminal Server что для этого плох? или вы считаете что у вас выйдет дешевле и лучше? Все уже сделано надо просто грамотно использовать!

И не надо хаять 1С если не знаешь ее возможностей!
Вот маленький пример структуры предприятия, где используется 1С:
-Город №1
--Центральный офис 4 компа бух + 2 Рук
--Офис выписки (опт) 4 компа
--Склад №1 1 комп, Розничный Магазин 1 комп
--Склад №2 1 комп
-Город №2
--Офис выписки (опт) 3 компа
--Склад №3 1 комп, Розничный Магазин 1 комп

Выписка товара с любого склада происходит с любого офиса.

Реализовано на w2k:TE, MS SQL, 1С 77 SQL

[Dracosha Andrew]

Нужен тонкий клиент w2k Terminal Server

Во-первых - не такой уж он и тонкий, а во-вторых - сколько стоит лицензия?

И не надо хаять 1С если не знаешь ее возможностей!

Знаю, знаю... 4 года плотной работы.
К сожалению многие одноэсники ничего кроме неё не знают. (Прошу не принимать на свой счет!!)

[Flatter]

Исходное сообщение Dracosha Andrew

Во-первых - не такой уж он и тонкий, а во-вторых - сколько стоит лицензия?

Встречный вопрос: а сколько встанет зазработка своего с нуля?

[Dracosha Andrew]

Встречный вопрос: а сколько встанет зазработка своего с нуля?

Во-первых не совсем с нуля, а во-вторых в отличие от покупки устаревшего (хотя новее ничего нет, но все-таки это устаревшее решение) програмного обеспечения это перспектива.

[wanderer]

Какой нужен канал для комфортной работы по Вашей схеме для одного пользователя?(Имеется ввиду Terminal Server). Я думаю не новость сказать что TS и прочие Цитриксы - суть виндузная реализация X11 протокола.
____________________________________
А что касается существа этой дискусии. Я уже как-то говорил ранее. Можно сделать на PHP можно сделать на Java, можно просто лезть напрямую к базе. Можно все на CGI сделать. Можно использовать Citrix. Можно вообще ничего не делать!!!
Есть же 1С, пущай и работает. В чем вопрос? А вопрос в том, что если группа людей собирается предложить свое решение вопроса, то только рынок а не дискуссии рассудит разработчика.

[Flatter]

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

[просто Дмитрий]

Работа через терминал это конечно прикольно, но в реальности сервер скоро начнет тормозить

[wanderer]

Flatter
Боюсь не всем неясно.