Здравствуйте, Dmitry The Wing, Вы писали:

S>> Почему??? Можешь использовать Tcp/Ip для связи с 1С. У меня ТСД через Wi-Fi работает под определенным юзером.
S>>Многие кстати используют прямую запись и чтение в БД.

DTW>Как-то страшно даже представить ... у 1С есть свой веб-сервер? если нет — то его реализация будет намного геморнее, чем взять тот же апач

Имел ввиду получаешь данные на вэб сервере, а полученные данные записываешь в 1С либо через ВК как клиент Tcp/Ip.
Либо напрямую в файлы. В былое время когда не было терминалов использовал прослойку через DCOM, но TCP/IP мне лично больше нравится.

Здравствуйте, Serginio1, Вы писали:

S>по сравнению с SQL ты можшь прменять более оптимальные алгоритмы группировок и агрегации

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Serginio1, Вы писали:

S>>по сравнению с SQL ты можшь прменять более оптимальные алгоритмы группировок и агрегации
Z>
Поэтому поводу всегда привожу пример найти время нахождение товара за период, не учитывая периоды с нулевыми остатками.
Навигационным способом, складываются время с момента становления остатка больше нуля и при возникновении нулевых остатков, или с конца периода, сгруппированных по дням. По группировкам, при прохождении по таблицам в порядке время возрастания нужен поиск только ID товара, т.к. для него организуется стек, где последнее значение это нужный день, иначе добавляется новое значение.
Итд.

Здравствуйте, Serginio1, Вы писали:

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

Я не понял задачу

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

Поэтому решение тоже не совсем понтяно, можно более детально, со структурой таблиц?

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Serginio1, Вы писали:

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

Z>Я не понял задачу

Найти время нахождения товара в продаже, Например в январе с 1 по 10 , и с 21 по 30, товар был в наличие. За период с января по декабрь.
Этих дней получается 20. Навигационным путем получаем остаток на 1 число, ставим дату начало продажи на 1, если остаток больше 0 и проходим по данным движения данного товара (или группы).
Сравниваем текущий остаток с 0 и ставим дату окончания продажи. При поступлении товара если остаток 0 сравниваем дату с с окончанием продаж, и если они не совпадают вычисляем время нахождения в продаже, добавляем к общему счетчику, ставим дату начала и так до конца.
Нет ни каких группировок по дням. Всё очень компактненько и быстро.

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

Z>Поэтому решение тоже не совсем понтяно, можно более детально, со структурой таблиц?
Просто ты строишь хэш таблицу, с валуе равным стеку состоящего из полей дата, и количество.
Например Группировка продаж по дням (или неделям итд), учитывая индекс выборки. У тебя нет затрат на поиск по дате, так как она либо последняя, либо нужно добавить.

Здравствуйте, Serginio1, Вы писали:

Что мешает применять навигационный доступ на сервере СУБД? Если задача решается им горздо проще?

Здравствуйте, Ziaw, Вы писали:

Да в общем то никто. Тем более, что новые сервера новые возможности.
Мечта программиста хошь применяй навигацию, хошь SQL и все это на сервере без таскания данных туда сюда.
Идеальное размещение для модулей проведения причем в объектном представлении.
Уже мечтаю свалить с 1С, на что то более прогрессивное.
Здесь разговор шел об 1С версии дбф и SQL (там, кстати даже не Sql 2005).
И приведены возможности для дбф даже быстрее чем аналогичный SQL.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Ziaw, Вы писали:

Z>>Здравствуйте, Serginio1, Вы писали:

S>>>по сравнению с SQL ты можшь прменять более оптимальные алгоритмы группировок и агрегации
Z>>
S> Поэтому поводу всегда привожу пример найти время нахождение товара за период, не учитывая периоды с нулевыми остатками.

Извините, я правильно понял задачу — есть таблица (или представление, или запрос), в которой мы имеем название товара, остаток и дату остатка, и по этой таблице (или представлению, или запросу) нам нужно получить сколько дней у нас остаток каждого товара был отличен от нуля? Ну, тогда для оракла, примерно так:

select itemname, sum(days) as days from
(select itemname,
    case
      when itemqty <> 0 then
        lead(changedate, 1, trunc(sysdate)) over (partition by itemname order by changedate) - changedate
      else
        0
    end days
  from test1)
group by itemname;

Подготовка данных для примера:

create table test1 (itemname varchar2(50), itemqty int, changedate date);
insert into test1 (itemname, itemqty, changedate) values ('карандаши', 5, to_date('2009-01-10', 'YYYY-MM-DD'));
insert into test1 (itemname, itemqty, changedate) values ('карандаши', 0, to_date('2009-01-15', 'YYYY-MM-DD'));
insert into test1 (itemname, itemqty, changedate) values ('карандаши', 10, to_date('2009-01-17', 'YYYY-MM-DD'));
insert into test1 (itemname, itemqty, changedate) values ('карандаши', 7, to_date('2009-01-19', 'YYYY-MM-DD'));
insert into test1 (itemname, itemqty, changedate) values ('карандаши', 0, to_date('2009-01-20', 'YYYY-MM-DD'));
insert into test1 (itemname, itemqty, changedate) values ('ручки', 5, to_date('2009-01-5', 'YYYY-MM-DD'));
insert into test1 (itemname, itemqty, changedate) values ('ручки', 10, to_date('2009-01-9', 'YYYY-MM-DD'));
insert into test1 (itemname, itemqty, changedate) values ('ручки', 7, to_date('2009-01-10', 'YYYY-MM-DD'));
insert into test1 (itemname, itemqty, changedate) values ('ручки', 0, to_date('2009-01-15', 'YYYY-MM-DD'));

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

Я правда не помню есть ли подобный функционал в MS SQL, если мы про связку 1С и MS SQL говорим.

Здравствуйте, lazymf, Вы писали:

L>Извините, я правильно понял задачу — есть таблица (или представление, или запрос), в которой мы имеем название товара, остаток и дату остатка, и по этой таблице (или представлению, или запросу) нам нужно получить сколько дней у нас остаток каждого товара был отличен от нуля? Ну, тогда для оракла, примерно так:

не совсем. в 1С есть остатки на период и движение. То есть мы должны вычислять остаток на каждый момент.
Идея хранить остаток на каждое движение плоха т. к. придется пересчитывать все остатки при проведении задним числом (но пересчитыватся остатки по периодам в большинстве случаев месяц).
Причем в течении дня остаток может менятся от 0 и в обратную сторону.
Но суть не в этом, так или иначе речь идет о навигационном подходе, против стандартного SQL

Здравствуйте, DarkMaster, Вы писали:
DTW>>>- локальный сервер Apache + php + FireBird + ajax
T>>Мы делаем на Python + PyQt + FireBird — классно получается.
DM>И сколько времени вы уже делаете? Вопрос обучаемости и 2-х исполнителей у вас не стоит?
Делаем уже больше 2х лет.
Перешли с Delphi + FB.

Сразу наблюдалось ускорение разработки больше чем в 2 раза.
Сйчас написано некоторое количество утилитного кода под наиболее частые задачи, так что скорость ещё возросла в 2-3 раза.

На начало разработки python знал только 1 человек в команде.
Через неделю остальны стали уверенно писать стандартные места.
Через месяц обращений за помощью стало меньше чем было до переода.

П.С. Пока нет времени, но как только появится, мы собираемся выложить свои наработки в свободный доступ.