Тема поднялась на форуме "Работа" (см. здесь) после высказывания оппонентом следующего утверждения.\r
\r
Latuk писал:Мне кажется, что не реже, чем раз в пять лет, надо платформу менять. Например, файл серверные технологии сейчас потихоньку вымирают.\r
\r
Стараясь не задевать ничьих чувств, я выступил в защиту файл-серверных технологий:\r
\r
\r
По-видимому, не сумел объяснить доходчиво, что имею в виду... :-( Потому что получил следующее сообщение:\r
\r
alex_k писал:"В клиент-сервере такого не сделаешь..."\r
Ничего я не понял из абзаца, следующего за цитатой.\r
\r
Сделал еще одну попытку, видимо, опять неудачную:\r
\r
\r
Получил в ответ от viman и Duce.\r
\r
viman писал:Да ни фига оракл не валится на больших выборках. И вот объясните мне:\r
допустим, я выбираю 100000 записей, и, как вы говорите, они появляются на файл-сервере мгновенно,\r
а теперь объясните мне, как даже на 100мб сетке мгновенно они перешлются? Также и на клиент-сервере,\r
причем вся табличка и не грузится, ставишь например 50 записей, остальные подгружаются, когда требуется. А с товарами пример неудачный был, это называется руки кривые...\r
\r
Duce писал:то, что Вы изложили pro FS и kontra CS - ерунда исключительная. \r
Просто ужасная чепуха.\r
...\r
Предложу Вам воздержаться от изложения подобных соображений перед работодателем,\r
и в данной рубрике в том числе. Перенести тему в сравнение СУБД \r
и узнать много полезного.\r
\r
С одной стороны, не вижу, чем это я запятнал себя в глазах работодателя.\r
С другой стороны, знаю, что многого не знаю, и хотел бы узнать "много полезного". Кроме того, считаю, что Duce прав, подобным разговорам не место в разделе "Работа". Наконец, чувствую себя достаточно уверенно, чтобы отстоять свою точку зрения.\r
Вобщем, давайте это обсудим!\r
\r
PS: viman\'у отвечу немного погодя. Кроме того, хочу немного конкретизировать разговор, т.е. ждите дополнений!

Итак, продолжаем разговор ;-)

Преамбула
---------
Во-первых, прошу сразу отметить, что я против чего-либо не выступаю и, тем более, не агитирую.
Во-вторых, прошу учесть, когда я буду сравнивать FS и CS, я поневоле буду сравнивать старую нашу систему на FoxPro - FS - со всеми ее недостатками и кривыми руками, с одной стороны, и стандартную функциональность Oracle EBS - CS (фактически, трехзвенка, но в данном случае не принципиально) - со всеми ее недостатками и кривыми руками, с другой. Обращайте внимание на оговорки типа "это я к примеру, реализаций может быть много разных".
В-третьих (Lepsik, это тебя касается), прошу не искать в моих словах чего-то такого, чего в них нет. Если я говорю о табличке в 20000 записей, я имею в виду ровно 20000 условных записей. Одна моя условная запись при этом содержит гораздо меньше 100 МБайт ;-)
В-четвертых, и последних, оставляю за собой право изрекать двусмысленности, ошибаться и даже нести полнейшую чепуху ;-).


Конкретизируем задачу
---------------------
Это важно, чтобы потом не упрекали, что пример неудачный, а руки кривые.
Рассмотрим конкретную задачу - формирование заказов.
Теперь привяжем ее к конкретному бизнесу. Пусть фирма торгует мелким оптом широким ассортиментом товаров (скажем, 20 тысяч наименований, из которых ежедневно в продаже есть 5 тысяч). Это чтобы исключить предположение, что состояние склада и прейскурант легко запомнить.
Пусть клиенты от заказов отказываются редко, а если уж что-то заказали, то непременно хотят получить, и на следующий день, а не через месяц. Это значит, товар должен резервироваться под заказ незамедлительно. И становиться недоступным для других клиентов.
Пусть в день фирма принимает 1000 заказов, а в каждом заказе бывает от 1 до 1000 и более позиций, но в среднем - 20. Это для оценки общего объема транзакций.
Пусть одновременно заказы принимают 50 человек, и все по телефону. Ну, это просто так - чтоб вы прочувствовали, какой галдеж стоит ;-)
Пусть небольшая часть товаров дефицитная и расходится в течение 10 минут с момента пуска в продажу. Это для оценки максимальной интенсивности транзакций.
Пусть у компании есть несколько конкурентов с приблизительно одинаковым предложением, и клиентам все равно, у кого покупать. Покупают у всех. Задача менеджера в нашем примере проста: если клиент хочет купить конкретный товар, уболтать его так, чтобы догнать общее количество позиций в его заказе хотя бы до среднего (тут, конечно, все гораздо сложнее, но это не наши проблемы ;-)).
Пусть цены в прейскуранте могут изменяться в любой момент. Причем, если цена изменилась во время формирования заказа , это изменение должно быть тут же принято к исполнению. Это чтобы жизнь медом не казалась ;-)
Пусть офис расположен в одном здании, сервер приличный, сетка очень хорошая. Уфф... Кажется, этого будет довольно ;-).
Во избежание аналогий, этот пример я только что выдумал. У нас в компании все совсем не так... ну, разве что сетка тоже очень неплохая ;-)

Решаем задачу с помощью моего FS
--------------------------------
Напомню, мой FS - FoxPro.
Что делаю я? Во-первых, забываю до поры до времени об SQL. Во-вторых, вспоминаю две принципиальные для бизнеса вещи:
1. данные как о запасах, так и о ценах должны быть актуальными с точностью до секунд,
2. менеджер должен легко, быстро и без лишних усилий получить информацию о любом товаре, имеющемся в наличии.
В-третьих, принимаю решение основным элементом для отображения данных сделать грид, и привязать его не к возвращаемому запросом рекордсету, а (вот ужас-то!) к самой таблице товаров. И манипулировать указателем в этой таблице только с помощью команд xBase (seek, locate, set key) или непосредственно с помощью грида. Соответственно, к таблице товаров привязать с помощью отношений таблицы доступных количеств, прейскуранты и прочая.
Что при этом делает FoxPro? Отображает в гриде кусочек таблицы товаров вместе с полями дочерних таблиц и вычисляемыми полями, упорядоченной по одному из возможных индексов (которые, кстати, переназначаются на лету). Позволяет перемещать указатель в таблице. А самое главное, читает по сети из расположенных на сервере таблиц только те записи , что видит пользователь на экране! Сам! Учить не надо! При этом, когда надо, читает только индексы.
Что делает менеджер? Отвечает на вопросы клиента. При этом задают следующие вопросы: "Товар X есть в наличии?", "А какие его типоразмеры есть и почем?", "А какие его аналоги есть и почем?", "А что у вас есть?", "А что еще у вас есть интересного?"
Два маленьких лирических отступления:
1. типоразмеры товара хранятся как отдельные позиции, причем наименования у них имеют одинаковое начало,
2. в бизнесе принято называть товар по наименованию, а не какому-нибудь многоэтажному коду.
Как быстрее всего в этом случае ответить на вопрос: "Товар X есть в наличии и почем?"? Найти товар по начальным буквам наименования.
Следующий вопрос, как правило, следует сразу же за первым: "А какие его типоразмеры есть и почем?"? Проще всего, если все типоразмеры будут представлены сразу. Вопрос с аналогами решить труднее - здесь задействуются иные методы поиска, но зато этот вопрос и задают реже.
Следующий вопрос, напротив, задают часто: "А что у вас есть?" Менеджер в этом случае имеет шанс показать, насколько он талантлив. Но программа должна ему в этом помочь. А что остается делать менеджеру? Перелистывать "странички" в гриде...
Вопрос: "А что еще у вас есть интересного?", как правило, можно свести к более частным: "А на какие товары были снижены цены?" "А что нового появилось с прошлой недели?" и т.д. Перестановка активного индекса или иные меры помогут собрать данные о таких группах вместе.
Как показывает практика, при выбранной схеме построения приложения менеджер уверенно отвечает на все вопросы клиента, при этом, что немаловажно, количество нажатий на клавиши минимизируется.
Нетрудно догадаться, что во время формирования заказа чтение создает основной трафик. Ну а для резервирования товара можно и SQL вспомнить или ХП использовать.

Решаем задачу с помощью моего CS
--------------------------------
Эх, учили нас в детстве интернациональной дружбе, но некоторым индусам руки бы поотрывать!
Представим, что на нашей гипотетической фирме внедрили EBS.
Теперь мы имеем следующую, стандартную , функциональность.
Шаг первый: по начальным (или любым другим) буквам наименования ищем товар. Выполняется запрос, который выводит список подходящих товаров, но пока не видно ни цены, ни доступного количества.
Шаг второй: выбираем товар. Появляется цена.
Шаг третий: клиент говорит, что это дорого. GOTO шаг 1. Или пытаемся зарезервировать 100 единиц, но товара оказывается меньше. Чтобы уточнить доступное количество, щелкаем кнопкой еще раз...
Вобщем, на практике совсем не так быстро.

Настало время ответить viman.
viman писал:Да ни фига оракл не валится на больших выборках.
То, что сервер "свалится", я, конечно, преувеличил. Но тормоза будут. Вплоть до того, что может сказать, что snapshot слишком старый...
viman писал:И вот объясните мне:
допустим, я выбираю 100000 записей, и, как вы говорите, они появляются на файл-сервере мгновенно,
а теперь объясните мне, как даже на 100мб сетке мгновенно они перешлются?
По поводу того, что на FS все 100000 записей появятся мгновенно - я такого не говорил. Мгновенно появятся первые 20. Или любые другие 20. При этом сеть будет загружена раз в 100 больше, чем при CS, судя по моим экспериментам. Т.е. для хорошей реализации FS архиважна хорошая сеть.
viman писал:Также и на клиент-сервере,
причем вся табличка и не грузится, ставишь например 50 записей, остальные подгружаются, когда требуется.
Речь о том, что в описанных выше бизнес-условиях требуется совместить две несовместимые вещи: актуальность данных (а это потребует постоянных перезапросов) с широтой восприятия (менеджер хочет свободно перемещаться по данным).
viman писал:А с товарами пример неудачный был, это называется руки кривые...
Ну да, руки, безусловно, кривые. Но пример жизненный. Предположим, что руки прямые. Вот как это с прямыми руками реализовать нормально?

А теперь изменим условия
------------------------
Не все так плохо для CS. Если работаем через нехорошую сеть (интернет - скажем, у фирмы появился филиал) - FS тут же отправится на свалку истории. Ну а менеджеры с клиентами?.. Привыкнут рано или поздно ;-)