Тема поднялась на форуме "Работа" (см. здесь) после высказывания оппонентом следующего утверждения.\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 тут же отправится на свалку истории. Ну а менеджеры с клиентами?.. Привыкнут рано или поздно ;-)

Ну и топик получается... Малоконструктивный. Так сразу и не разберешься. Попробуем по одному. Надеюсь, Эксель в повседневной жизни все видели ;-)? Буду проводить аналогии с его интерфейсом.

brahew - знает плюсы FS, сейчас внедряет CS. Согласен, что выборку в CS желательно делать поуже, и не стесняется это сказать.
Фраза "тетка говорит, Рома почему я не могу просмотреть ВЕСЬ(!!!!!!) справочник улиц в задаче абонентского?Это так надо!" многих ввела в заблуждение, но это понятно, с точки зрения тетки именно так все и происходит: как будто мгновенно появляется весь справочник. Потому что она, как в Экселе, может нажать PgDn - и тут же увидеть следующую страничку. Может подергать за бегунок линейки прокрутки - и тут же оказаться в прогнозируемом месте. Может и поиском пользоваться. Кстати, поиск простым пользователям понятнее выборки ;-).

Ermak - Не читал первый пост - там я говорил о незащищенности как о первой проблеме. Задал 2 вполне резонных вопроса.
1. В чем разница между FS и CS технологиями, если в обеих все начинается с поиска?
Поиск в случае FS означает поиск как в Экселевской таблице, в другом подразумевает запрос к базе и получение выборки (ее тоже можно оформить как в Экселе, но при ошибке в наборе искомого в первом случае можно перелистать до его нахождения, а во втором придется набивать искомое заново - впрочем, зависит от реализации, может, придется только букву поменять).
2. Почему в Вашей реализации CS не видно ни цены, ни остатков???
Потому что это EBS. На самом деле, их видно, потом. Для выбранного препарата. Кто знает, скорее подтвердит, чем опровергнет: сообществом внедрятелей EBS любая чрезмерная его настройка под нужды конкретного пользователя считается злом (слова не мои, проходили в форуме по Oracle, автора не помню, но ему не возражали). Сложные стандартные формы вообще не берутся переписывать (и правильно делают, поскольку EBS все время развивается, патчи ставить - бытовое дело). Впрочем, сказанное не значит, что настроить в принципе нельзя. Только учти, что цену придется добавлять ценой трех табличек, с range scan, а на текущие остатки влияет состояние еще трех табличек, с групповыми функциями в каждой. Тормозить не будет? Да, учти, изменять структуру данных вообще запрещено!

alex_k - придерживается нейтралитета. Знает недостатки CS, но не собирается делиться опытом, как с ними бороться. Поклонник firebird. Цитата: "только надо _программу писать_ а не собирать из кубиков на форме". Вероятно, введен в заблуждение словами "стандартная функциональность".

Веревкин - скорее, настроен благодушно. Ленив ;-) Первый из оппонентов, который что-то предложил. Знает EBS, судя по фразам "Форму только надо свою рисовать" и "custom.pll можно обойтись". Узнал во мне какого-то своего знакомого. Отвечу: там, где я работаю, трамваи не ходят. Попрошу далее не отклоняться от темы.
По поводу предложенного решения. Ты хочешь сказать, что сначала мы выгружаем все данные, а потом при перепозиционировании курсора обновляем поля, вероятность изменения которых высока, в той записи, куда приходит курсор? Почти то самое, но не совсем. Вот если бы был триггер на запись, которой до этого не было на экране, а потом появилась ;-)... А так - сначала данные будут хорошо соответствовать, а потом все хуже и хуже. А почему, собственно, я (читай: пользователь) должен мириться с тем, что цена и остаток видны только по той записи, на которой стоит курсор? Движения глаз быстрее движений рук, и если запись об интересующем меня товаре уже на экране, зачем мне еще переводить на нее курсор? (Черт подери!)

viman - по начальным постам складывается впечатление, что человек совсем не знаком с FS, хотя пишет, что работал. Потом появляются проблески узнавания ;-) Въедливый. Придирается к словам (и правильно делает, пожалуй, без его участия мне бы не пришло в голову заглаживать некоторые корявости в своих предыдущих постах ;-)) Работает с IB и Oracle. Любит цифры. Особенно тысячи. (Хочется закончить: особенно долларов, но повода нет ;-)). Интересный собеседник, хотя любит уклоняться от темы. Приводит контрзадачи. Надо бы разобрать предложенный им пример, да лень. Скажу только, что в его примере реализация FS была явно неудачная. Гораздо бОльшие объемы данных перерабатывались моими отчетами в FS на порядок быстрее. Правда, для ускорения выполнения больших аналитических отчетов на FS есть своя специфика. В частности, не нужно стараться слепить один большой запрос. Лучше разбивать на несколько маленьких запросов, попутно забирая выборки на клиента, на клиенте индексировать по ключевым полям и уже здесь строить окончательный отчет.
Предложил как панацею вложенный селект. С учетом ответа на вопрос Ермака №2 и условий поставленной в моем посте от 03:24 15 октября, отвечу. Усложнение селекта приведет к увеличению времени на его выполнение. Да хоть (select sysdate from dual) вложи в другой запрос - и такая малость (пусть 1 миллисекунда на запрос) с учетом того, что общее количество запросов в течение дня составляет (см. предложенную задачу) уж никак не меньше физического минимума 1000 (заказов) * 20 (строк в заказе в среднем) = 20000, а фактически намного больше (заметьте, случай, когда менеджера спрашивают "А что у вас вообще есть" - вообще предпочитают не рассматривать) - и то отъест у сервера 20 лишних секунд!
Кстати, уж коли ты помянул события, есть еще одно избитое словосочетание: "событийно-управляемый интерфейс". Покажите мне хоть один не событийно-управляемый интерфейс! (Пакетная обработка не считается, у нее вообще интерфейса нет, кроме параметров ;-)).

eddi - ну что же, если бы некоторые из обсуждающих сходили по его ссылке, тема стала бы более конструктивной - рекомендую . Правда, у меня несколько иное мнение по поводу комментария о физическом порядке записей и его отсутствии в SQL (но оно ничего не изменит, потому что даже если бы таковой был, не знаю, как его можно было бы использовать).

Серега - краток, метафоричен и во многом прав. В первом посте. Потом Остапа понесло ;-).
Взять хотя бы утверждение, что по сети все происходит медленно. Может, у Сереги плохая сеть?
Далее, по-твоему что получается, если сделать FOPEN и FSEEK в конец файла - файл при этом будет прочитан от начала до конца в память? И еще, цитата: "А как ты например обеспечишь права доступа, когда конкретному юзеру из этих 600 000 записей читать можно только 600 (остальные не его)? Правильно, скачаешь ВСЕ и отфильтруешь." На самом деле так неправильно. В этом случае я подумаю об SQL SELECT или SET KEY (а никак не о SET FILTER).
Впрочем, это тоже проблемы незащищенности.

q - интересуется: а что означает файл сервер (в этом топике)? файл сервер типа ENCINA? или может просто файловая система? Отвечаю: ENCINA не знаю, речь идет о базах данных, доступ к таблицам которых осуществляется как к файлам, расположенным на файл-сервере. Т.е. приложение СУБД, запущенное на клиенте, читает файлы базы данных и пишет в них само, а не передает запросы серверу. Задача сервера при этом - иметь быстрый дисковый массив, быстрый сетевой канал и ОС, заточенную на обслуживание обращений к файлам, расположенным на сервере. Логику работы с данными реализует клиентская часть.

tygra - краток и категоричен. В FS не въезжает. Одно из двух: или не любит пользователей, или давно познал истину. Не завидует моим заказчикам. Ошибается, заказчики меня любят ;-). Особенно девушки ;-).

U-gene & tygra - докажите, что с сервера можно часто забирать много информации, и я вам все прощу ;-) (только ДЕЙСТВИТЕЛЬНО часто и ДЕЙСТВИТЕЛЬНО много). Я о том, что даже если все оптимизировать донельзя, предел обслуживания с увеличением нагрузки рано или поздно наступит.

eNose - Веселый человек. Знает тайну черепахи Тортиллы напару с viman, но не делятся (я про компоненты Query и Table не знаю).

Crip - ну, этот свой ;-) Намекнул на какие-то вещи и ушел. Абыдна! Вернись, расскажи подробнее!

andrew_Pr - THE BEST! ;-))))) Но пользователей все равно надо любить!

Пока побеждает Веревкин. Но решение нельзя назвать вполне удовлетворительным...