Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
 В защиту файл-сервера  [new]
Ефим Перекладин
Guest
Тема поднялась на форуме "Работа" (см. здесь) после высказывания оппонентом следующего утверждения.

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


Стараясь не задевать ничьих чувств, я выступил в защиту файл-серверных технологий:
По мне, файл-серверная технология хороша всем, кроме защищенности данных и масштабируемости.

В том виде, как она реализована в FoxPro, она в утилитарном смысле даже лучше клиент-серверной.
Вот, например, как хорошо: открыл довольно длинную табличку, тысяч на 20 записей, связал ее отношениями
с кучей других, еще более длинных, устроил кучу вычисляемых полей, открыл грид и ходишь по записям,
а вычисляемые поля тебе показывают много всякой всячины. Причем это не тормозит абсолютно,
и за актуальностью данных специально следить не нужно (ну разве что при особой необходимости освежить
отображение).
В клиент-сервере такого не сделаешь: ну да, там подход другой - получи минимально необходимую
информацию и только тогда, когда надо. Ну и ходишь, к примеру, по только тем записям первой таблички,
которые вытащил первым запросом, а для того, чтоб узнать значение вычисляемых полей, выбираешь
нужную запись и отправляешь другой запрос, который их вычислит только для этой записи (это я к примеру,
реализаций может быть много разных ;-)).
В итоге, продажный менеджер в случае файл-сервера на вопрос клиента "А есть ли у вас товар X?"
ответит: "Нет, но зато у нас есть его аналог Y, а еще вы можете заказать и Z, поскольку, как я вижу,
на него вчера снизили цены"
, а в случае клиент-сервера - "Сейчас посмотрю... Нет, товара X
сейчас нет :(."


По-видимому, не сумел объяснить доходчиво, что имею в виду... :-( Потому что получил следующее сообщение:

alex_k писал:
"В клиент-сервере такого не сделаешь..."
Ничего я не понял из абзаца, следующего за цитатой.


Сделал еще одну попытку, видимо, опять неудачную:
2alex_k: 

Каюсь, грешен, написал непонятно. Речь шла не о вычисляемых полях.
Имел в виду, что с сервера
нельзя часто запрашивать много информации. Повалим сервер. Таким образом, либо выбираем
много, но делаем это редко в ущерб актуальности данных, либо выбираем часто, но помалу, в ущерб
наглядности.
В итоге, в описанном мною примере, тетенька, которая продает, либо знает остаток на складе весьма
приблизительно, но по всем товарам (утром выпустила сводный отчет, с тех пор все уж продали давно!),
либо знает точно, но только по одному товару (создает заказ). И не говори мне, что возможно третье.
Не при нашей загрузке сервера.


Получил в ответ от viman и Duce.

viman писал:
Да ни фига оракл не валится на больших выборках. И вот объясните мне:
допустим, я выбираю 100000 записей, и, как вы говорите, они появляются на файл-сервере мгновенно,
а теперь объясните мне, как даже на 100мб сетке мгновенно они перешлются? Также и на клиент-сервере,
причем вся табличка и не грузится, ставишь например 50 записей, остальные подгружаются, когда требуется. А с товарами пример неудачный был, это называется руки кривые...


Duce писал:
то, что Вы изложили pro FS и kontra CS - ерунда исключительная.
Просто ужасная чепуха.
...
Предложу Вам воздержаться от изложения подобных соображений перед работодателем,
и в данной рубрике в том числе. Перенести тему в сравнение СУБД
и узнать много полезного.


С одной стороны, не вижу, чем это я запятнал себя в глазах работодателя.
С другой стороны, знаю, что многого не знаю, и хотел бы узнать "много полезного". Кроме того, считаю, что Duce прав, подобным разговорам не место в разделе "Работа". Наконец, чувствую себя достаточно уверенно, чтобы отстоять свою точку зрения.
Вобщем, давайте это обсудим!

PS: viman'у отвечу немного погодя. Кроме того, хочу немного конкретизировать разговор, т.е. ждите дополнений!
14 окт 03, 21:29    [376813]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
--Стараясь не задевать ничьих чувств, я выступил в защиту файл-серверных ---Вот, например, как хорошо: открыл довольно длинную табличку, тысяч на 20 записей

ADO в случае использования серверных курсоров позволяет работать с каким угодно размером рекордсета.

открыть файл-сервер размером в несколько теробайт - хм. не смешите народ
14 окт 03, 22:58    [376869]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
при наличии многих связанных таблиц с количеством записей в каждой в районе миллиона файл-серверные системы, расположенные по сети, просто даже и не поднимаются.

На небольших наборах (порядка сотни тысяч в каждой) это вполне работает.
14 окт 03, 23:47    [376930]     Ответить | Цитировать Сообщить модератору
 FS vs CS на конкретном примере  [new]
Ефим Перекладин
Guest
Итак, продолжаем разговор ;-)

Преамбула
---------

Во-первых, прошу сразу отметить, что я против чего-либо не выступаю и, тем более, не агитирую.
Во-вторых, прошу учесть, когда я буду сравнивать 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 тут же отправится на свалку истории. Ну а менеджеры с клиентами?.. Привыкнут рано или поздно ;-)
15 окт 03, 03:24    [376989]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
brahew
Member

Откуда: 61;90
Сообщений: 724
Тем кто не работал с dbf и foxpro в частности, очень тяжело объяснить как оно неплохо все работает, а ведь работатть с теми кто после файл-сервера, а еще страшней с ним работает - это вообще мука страшнейшая.
Несколько примеров (идет внедрение на фирме, где все старые програмеры писали/пишут на клиппере)
1 Сегодня тетка говорит,
Рома почему я не могу просмотреть ВЕСЬ(!!!!!!) справочник улиц в задаче абонентского?Это так надо!
Я отвечаю, мы его закачиваем из пенсионного и каждый год будем приводить в соответствие, а смотреть его, там же 600 000 записей, он на ваших раьочих станциях не откроется(166MMX 32-64 ОЗУ и мало Celeronov контора муниципальная бабок на проект не жалко а так денег нет)
тектка - а у нас на клиппере таких проблем нет.
2 Журнал документов
Спрашиваю по какому критерию выводить на экран документы, тетка говорит все в базе, я пытаюсь оптимизировать решение и торгуюсь, давайте за последний месяц, тетка - нет, а вдруг я за прошлий захочу увидеть, так я раз поиском и там, а так выборку делать надо, и нихрена им не объяснишь.
3 и тд примеров сотни

Но чего не отнять у ФС открываю таблицу на просмотр, ты думаеш как сузить открываемую информацию чтоб фильтр наложился быстрей. А при работе со скулем стараешся выборку сделать поуже еще до открытия таблиц/курсоров на станции.
15 окт 03, 05:02    [376998]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Ermak
Member

Откуда: Tomsk
Сообщений: 811
Как это делается в FS
"Как быстрее всего в этом случае ответить на вопрос: "Товар X есть в наличии и почем?"? Найти товар по начальным буквам наименования"

Как это делается в CS
"Шаг первый: по начальным (или любым другим) буквам наименования ищем товар."

В чем разница между FS и CS технологиями?

Там же далее
" Выполняется запрос, который выводит список подходящих товаров, но пока не видно ни цены, ни доступного количества."

Почему в Вашей реализации CS не видно ни цены, ни остатков???

Не в обиду, но похоже что есть большие проблеммы со структурой БД.

Ну и в качестве небольшого лирического отступления.
Давайте предложенную Вами модель компании доведем до блеска.
Добавим 2-3 молодых людей умеющих лазить в файлы *.dbf внешними средствами, и раз в месяц стирающих допустим 5-50 строк из различных таблиц, ну допустим из справочника товаров или справочника клиентов, можно ещё время от времени удалять часть спецификации выписанного счета.

Ваши действия.
15 окт 03, 06:43    [377012]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
обычно спор идет в таком духе: не знакомые(не сильно знакомые) с фс технологией люди ее лажают, а знакомые отбиваются.

в этом топике все наоборот :-)

по поводу оракла и невозможности построения эффективной системы на его основе, я конечно с ораклом не знаком, вполне возможно что он ничего не умеет и вабще лажается в любом маломальском бизнесе, но вот firebird с такой задачей справится запросто. только надо _программу писать_ а не собирать из кубиков на форме. поэтому мне как _программисту_ так и не стало понятно преимущество фс над кс. недостатки я сам знаю.
15 окт 03, 07:00    [377015]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Веревкин
Member

Откуда:
Сообщений: 5
автор писал:
[/quot]Речь о том, что в описанных выше бизнес-условиях требуется совместить две несовместимые вещи: актуальность данных (а это потребует постоянных перезапросов) с широтой восприятия (менеджер хочет свободно перемещаться по данным).
[quot автор]

Ефим, ты раньше написал, что не работал с формсами. О чем вопросы-то тогда? :) Конкретно на этот вопрос - повесь триггер When-new-record-instance и будет он тебе обновлять информацию в текущей строке. Просто один из вариантов. Форму только надо свою рисовать, а может и custom.pll можно обойтись. Лень глубоко вникать.
Ты на остановке трамвая ул.Душинская работаешь, если я не ошибаюсь?
15 окт 03, 07:23    [377025]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
viman
Member

Откуда: Тамбов
Сообщений: 1111
>То, что сервер "свалится", я, конечно, преувеличил. ...
НИ РАЗУ (за год) ТАКОГО НЕ ВИДЕЛ. База "маленькая" - 2 гб. Вообще к серверу не подходим, все на автомате

>По поводу того, что на FS все 100000 записей появятся мгновенно - я такого
Пример другой. Формируется отчет по табличкам с суммарным колвом строк 100-200 тыс (а может и больше...), сколько потратит на это FS? Было с чем сравнивать, так вот 2 разные программы с одинаковым набором данных и с одинаковыми задачами, FS тратил на это 30 минут, CS (IB) 40 секунд.... Сейчас пишу под оракл, выборка из таблички в 60000 записей занимает меньше 1 сек. Если смотреть все, то вообще ненапряжно, данные при этом подгружаются еще из 4х словарей. А как оракл ворочает таблички по 3000-5000 записей... песня :-) А у вас, даже если поставить 4х процессорный сервер (как у нас :-) ), скорости не прибавится.

>Почему в Вашей реализации CS не видно ни цены, ни остатков???
>>Не в обиду, но похоже что есть большие проблеммы со структурой БД.
Нет, проблемы с sql, причем серъезные... Проблемы с структурой БД, легко правятся грамотным применением sql.
15 окт 03, 08:27    [377054]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Zaxx
Guest
2 brahew

>Рома почему я не могу просмотреть ВЕСЬ(!!!!!!) справочник улиц в задаче абонентского?Это так надо!
>Я отвечаю, мы его закачиваем из пенсионного и каждый год будем приводить в соответствие, а смотреть его, там же 600 000 записей

А зачем пользователю видеть сразу 600 000 записей ???

>2 Журнал документов
>тетка говорит все в базе, я пытаюсь оптимизировать решение и торгуюсь, давайте за последний месяц, тетка - нет, а вдруг я за прошлий захочу

А какие проблемы сделать журнал с возможностью выбора периода и перезапросом при его изменении?
15 окт 03, 09:22    [377097]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Ermak
Member

Откуда: Tomsk
Сообщений: 811
>Почему в Вашей реализации CS не видно ни цены, ни остатков???
>>Не в обиду, но похоже что есть большие проблеммы со структурой БД.
Нет, проблемы с sql, причем серъезные... Проблемы с структурой БД, легко правятся грамотным применением sql.

Ну значит к тому же и проблеммы с sql.
15 окт 03, 09:33    [377112]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
viman
Member

Откуда: Тамбов
Сообщений: 1111
>Шаг первый: по начальным (или любым другим) буквам наименования ищем
> товар. Выполняется запрос, который выводит список подходящих товаров,
>но пока не видно ни цены, ни доступного количества.
Вложенный селект и можно смотреть цену сейчас, вчера (если такая информация есть), колво в коробке, цену коробки, массу, ... ЛЮБЫЕ данные

>Шаг третий: клиент говорит, что это дорого. GOTO шаг 1.
набираем несколько букв, выбирается весь подобный друг другу товар, с ценами (несколькими), остатками... с 5000 наименований это работает МГНОВЕННО.

>Или пытаемся зарезервировать 100 единиц, но товара оказывается меньше.
>Чтобы уточнить доступное количество, щелкаем кнопкой еще раз...
Есть понятие событий которое лечит такие проблемы. Из примитивных способов, можно выбрать проверку изменений по таймеру
15 окт 03, 09:52    [377145]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
eddi
Guest
В контексте данного обсуждения можно посмотреть -
"Блеск и нищета клиент-серверных технологий"
http://www.cavo.hut.ru/shine.php3
15 окт 03, 10:05    [377167]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Серега
Member

Откуда:
Сообщений: 887
ИМХО
Отмирание ФС технологий обусловлено не тем, что они плохи, а тем что изменились условия работы с информацией. Копать свой огород лопатой можно, а вот с колхозным полем такой прием крайне неэффективен.
15 окт 03, 10:38    [377233]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
brahew
Member

Откуда: 61;90
Сообщений: 724
2 Zaxx
Я с клиентом-сервером работаю, но и на фоксе писал.
И я понимаю как все это работает, и все написалв пред. сообщ.
15 окт 03, 11:55    [377396]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
q
Guest
а что означает файл сервер (в этом топике)?
файл сервер типа ENCINA? или может просто файловая система?
15 окт 03, 12:09    [377420]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Нда, Ефим Перекладин уж не знаю чего хотел доказать, но облажался своим незнанием на все 100 :)
Это ж надо такое сморозить? Тут не руки кривые - голова, прошу прощения.
Ничего не буду цитировать - до меня все успели :)

Просто ограничусь следующим: полный бред. Если Вы не умеете программировать правильно, то не беритесь, и уж тем более не выдвигайте такие посты в форуме. Это даже не смешно. Я не завидую Вашим заказчикам. :(((

-- Tygra's --
15 окт 03, 12:16    [377440]     Ответить | Цитировать Сообщить модератору
 :)  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
На главной странице надо сделать раздел "Цитата дня". Первая уже есть

автор писал:
...с сервера
нельзя часто запрашивать много информации....


:)
15 окт 03, 12:35    [377496]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Эт точно.
Хорошо подметил. Еще один гвоздь в ..... квалификацию разработчика

-- Tygra's --
15 окт 03, 12:38    [377504]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
brahew
Member

Откуда: 61;90
Сообщений: 724
2 all кто против Ефим, у разработчика руки может и кривые, но признать следует, что ФС позволяет отображать любое количество записей без задержки при работе с дбф файлом напрямую, мимо одбц и прочего, без загрузки на клиента, что при работе со скуль серверами сделать если заказчик рогами в землю упирается и говорит хочу видеть все и сразу 600 000 записей на 166 ММХ и сервере Р2 128 озу, с 10 мб сетью то несколько проблематично, никакие оптимизаторы то не спасут
15 окт 03, 16:32    [378058]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор писал:
у разработчика руки может и кривые, но признать следует, что ФС позволяет отображать любое количество записей без задержки при работе с дбф файлом напрямую, мимо одбц и прочего, без загрузки на клиента, что при работе со скуль серверами сделать если заказчик рогами в землю упирается и говорит хочу видеть все и сразу 600 000 записей на 166 ММХ и сервере Р2 128 озу, с 10 мб сетью то несколько проблематично, никакие оптимизаторы то не спасут


Эээээ, дарагой, да бери хоть 10 миллионов записей из сервера - сетка то одна и та же. Если конечно клиент не помрет. :)

А заказчику сделать как просит - после дня работы будет кричать обратное.

-- Tygra's --
15 окт 03, 16:58    [378097]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
viman
Member

Откуда: Тамбов
Сообщений: 1111
>что ФС позволяет отображать любое количество записей без задержки
600000 МГНОВЕННО не загрузятся даже если у тебя гигабитная сеть и raid0 с 3мя винтами, записи будут подгружатся. Так же работает и CS, при скролинге записи подгружаются, сам сейчас постоянно работаю с табличкой в которой 60000 записей, показывается мгновенно, скролится быстро. Но чтобы быстро что то найти существуют параметры выборки. А если вы попытаетесь чтонть посчитать в этой табличке угадайте FS или CS быстрее с этим справится. Я думаю ответ очевиден...
15 окт 03, 17:09    [378123]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
brahew
Member

Откуда: 61;90
Сообщений: 724
2 viman
clipper & foxpro отображают мгновенно на экран и позволяют бегать по этой сетке без особенных задержек на очень дохлом оборудовании
2 tygra
так это сделать надо, потом переделать, а так как работаю в основном по договору субподряда, вычищать всякие хочу во то время когда я уже забыть о задаче должен, прям таки не супер
16 окт 03, 04:50    [378628]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
viman
Member

Откуда: Тамбов
Сообщений: 1111
>clipper & foxpro отображают мгновенно на экран и позволяют бегать по этой
>сетке без особенных задержек на очень дохлом оборудовании
Для тех кто в танке повторяю третий раз :-) CS точно также бегает без тормозов по большим табличкам. Мое мнение что все ваше стремление защитить FS от нежелания учится новым технологиям и вообще общий консерватизм. Видили таких деятелей уже, мол у нас так все работает. Только вот на нашем предприятии я уже переписал 2 проекта по CS, теперь пользователи бегают и просят написать еще 2, которые существуют в FS. А такие как вы работали у нас до меня, потом начальство наконецто поняло что таких людей не переучить, нет конечно они могут научится чему то новому но им самим это видилите ненужно, ведь FS со всеми задачами справляется... Ну и выгнали их всех нах...
16 окт 03, 08:09    [378686]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
eNose
Member

Откуда:
Сообщений: 183063
brahew писал:
clipper & foxpro отображают мгновенно на экран и позволяют бегать по этой сетке без особенных задержек на очень дохлом оборудовании

Супер!

Для тебя, наверное, будет новость:
кроме select * from table_1 есть и другие способы выборки данных.




eNose
16 окт 03, 08:10    [378687]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить