Старая тема тут:
Померяемся? SELECT Count(*) FROM _1SJOURN 460 000 документов...
Кто еще осталсё на v7?
Чемпионы прошлой:
Итоги?
DenIv - 48 178 881 (700 Gb) O_o

 r2003 - 19'628'937 | 28'744'712
 Soda - 17'668'477 (80 Gb/5лет)
 sapphire - 17'275'751
 SnarkHunter - 10'158'596
 Кириллка - 10'158'596
 Ненавижу 1С - 8'515'946
 Aristo - 6'093'108
 Sadovnikov-5'914'783
 Windrose - 5'170'113
 Phoenix - 4'399'646
 VladZ - 2'300'902
 КонецЦикла - 1'894'403 (+300'000 д/м)
 novichek - 1'877'060
 val -1'510'241
 Джинн - 1'500'000
 DmitrO - 1'483'872
 Mikeware - 1'453'966
 Циник - 1'353'177
 12345 - 1'308'096
 fez - 1'156'648 (dbf)
 Maniac 1'150'314
 1Cко - 1'119'131  
 у лю 427 - 1'100'000
 Иде я - 954'039
 myk0lka - 940'000
 Азат - 939'979
 Ленинград - 900'000
 Chai Nic - 811'201
 РСИ - 661'896
 lustin - 652'248
 Ёпрст2 - 641'594
 fly7 - 614'236
 big - 532'443
 trdm - 460'000
 Программист 484 - 450'000
 Salimbek - 421'386
 milan - 408'486
 dimm7310 - 384'244
 Если - 354'000
 BorisHighLander - 220'489
 bodycom 68'000
 Skom - 39'000
 ВосточныйПарень - 100


Фух*8... в принцыпе ого.

(0) Только что на одинэсии писал :)
Семерка, базе 2 года и 10 месяцев.
Документов 15 698 109.
15 698 109 / 34 (месяца) / 30 (дней в месяце) = 15 390 (доков в день).

Навеяно: v8: Быстродействие при большом документообороте
Были предложены несколько типов мерялок:
1. Общее количество документов:
SELECT Count(*) FROM _1SJOURN
2. Статистика по SQL базе макс/мин/сред документов в месяц:
DECLARE @КоличествоМесяцев Int, @МаксКоличествоВМесяц Int, @МинКоличествоВМесяц Int, @ВсегоДокументов Int

Select
   @КоличествоМесяцев = SUM(Месяц),
   @МаксКоличествоВМесяц = MAX(Количество),
   @МинКоличествоВМесяц = MIN(Количество),
   @ВсегоДокументов = SUM(Количество)
From
(
   Select
       1 Месяц, Count(*) Количество
   From
       _1SJOURN Журнал (NoLock)
   GROUP BY
       Left(Журнал.Date_Time_IDDOC, 6)
) Месяцы

Select
   @ВсегоДокументов ВсегоДокументов,
   @КоличествоМесяцев КоличествоМесяцев,
   @МаксКоличествоВМесяц МаксКоличествоВМесяц,
   @МинКоличествоВМесяц МинКоличествоВМесяц,
   (@ВсегоДокументов / @КоличествоМесяцев) СреднееКоличествоВМесяц
3. Развертка помесячно:
Select
   Left(Месяц, 4) + '.' + Right(Месяц, 2) Период,
   Количество
From
(
   Select
       Left(Журнал.Date_Time_IDDOC, 6) Месяц,
       Count(*) Количество
   From _1SJOURN Журнал (NoLock)
   GROUP BY
       Left(Журнал.Date_Time_IDDOC, 6)
) Документы
ORDER BY
   Месяц

1486634 дбф

Итоги SQL/DBF :
15 698 109 (SQL) Sadovnikov
909 008 (SQL) trdm
1 486 634 (DBF) Ёпрст3

Я скромный...
1 143 372

зы SQL

Упс...
Итоги SQL/DBF :
15 698 109 (SQL) Sadovnikov
1 486 634 (DBF) Ёпрст3
1 143 372 (SQL) ДенисЧ
909 008 (SQL) trdm

(7) Тэкс... Устарела информация... Уже 15 698 438 доков :)

гы оперативка на SQL сервере 2 Гб всего :))))))) при 60 пользователях... Кто так смогет? :)

опять решили меряться? :)
у кого еще 25 сантиметров :)

(8) Ты их специально штампешь, померяться? :-))

(9) Ко мне в личку загляни :) Админы, cцу()kи, половину памяти у сервака выдернули...

1. 814632
2. 814632    68    47581    1    11979
3. 2007.12    11691
2008.01    30676
2008.02    34777
2008.03    38338
2008.04    43892
2008.05    40822
2008.06    42628
2008.07    47581
2008.08    42670
2008.09    41295
2008.10    41823
2008.11    35354
2008.12    41164
2009.01    27863
2009.02    25419
2009.03    28816
2009.04    31505
2009.05    29345
2009.06    32669
2009.07    33623
2009.08    32803
2009.09    37155
2009.10    37868

(12) Если бы... Пользователи стараются...

(12) А у меня вот так скромненько.
http://unnstudioreport.googlecode.com/files/taskMangr.PNG
Скоро будем новый сервак брать, старого явно нехватает на 60 юзверей...

прошлогодняя необрезатая SQL
6 382 001
за этот год SQL
2 164 383

(15) как-то совсем грустненько...

(16) А зачем резали?

Упс...
Итоги SQL/DBF :
15 698 109 (SQL) Sadovnikov
6 382 001 (SQL) dk
1 486 634 (DBF) Ёпрст3
1 143 372 (SQL) ДенисЧ
909 008 (SQL) trdm
814 632 (SQL) leshikkam (макс. доков в месяц: 47581)

тормоза'с )
она еще и распределенная 8 баз, на складах серваки слабые, не выдерживали

не правильный тест...
надо SELECT Count(*) FROM  DT#### + SELECT Count(*) FROM _1SJOURN

ЗЫ у меня 687692

а количество строк не считали ? (и связей)

хехе...

(21) А зачем ты к количеству строк в документах прибавляешь количество документов?
И как быть, если: Метаданные.Документ() = 117  ?

(24) чтобы безтабличные не пропали

(25) Это как??? :)

ну, если нет табл. части то и DT не будет, а документ есть
хотя конечно тоже не очень корректно

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

(27) Дык в любом случае документ будет в _1SJOURN.
(28) Так все равно - складывать-то зачем? Может, 2 отдельные циферьки?

(21) Эта ветка будет жить по неправильному тесту. Вот такие мы плохие :)

Может так форматирование пойдет:
Если Версия = "v7" Тогда
Итоги SQL/DBF :
15 698 109 (SQL) Sadovnikov
6 382 001 (SQL) dk
1 486 634 (DBF) Ёпрст3
1 143 372 (SQL) ДенисЧ
909 008 (SQL) trdm
814 632 (SQL) leshikkam (макс. доков в месяц: 47581)
КонецЕсли;

блин.

теги [1С_] и внутри [/1С_]
_ убрать

(28) По одному виду документов:

Select
   (Select Count(*) FROM докЗаявкаНаСкладТЧ) СтрокВ_ТЧ1,
   (Select Count(*) FROM СводнаяДоп..ЗаявкаНаСкладСтроки (NoLock)) СтрокВ_ТЧ2,
   (Select Count(*) FROM СводнаяДоп..ЗаявкаНаСклад_СоставНаборов (NoLock)) СтрокВ_ТЧ3

СтрокВ_ТЧ1    СтрокВ_ТЧ2    СтрокВ_ТЧ3
22416259    23054794    2434088

(0) 823 646
SQL

(+35) Это ЦБ в распределенке

в семерках 2 387 023/2 306 923

(37) Дык это ж всего 1,0347 будет :)

(38) Зато какой! :-)

sql
3075230

Итоги SQL/DBF :

15 698 109 (SQL) Sadovnikov
6 382 001 (SQL) dk
3 075 230 (SQL) trad
2 387 023 (SQL) Mikeware
1 486 634 (DBF) Ёпрст3
1 143 372 (SQL) ДенисЧ
909 008 (SQL) trdm
823 646 (SQL) also
814 632 (SQL) leshikkam (макс. доков в месяц: 47581)


1 161 141 sql 7.7
в следующем году переход на 8.1

1 814 341 sql 7.7
маловато на фоне остальных

626 201

мдя... не густо, думал больше будет

семерка отстой

(45) :)))))
База для ОТП не получается?

select count(*) from _1sjourn

2 371 968

(46)получается, но для этого приходится программировать.

(48) Ты до програмирования опустился???
Марш в восмерку - там всё мышой делается!!!

На 28.10.2009г. 1 458 842 SQL
18 гигов после Шринка. Последняя обрезка 11 месяцев назад.

Интересно, до триллиона можно количество доков довести? )

(51)
Нет. Только до 0x7FFFFFFF, так как 7ка для ид-дока унутре юзает long.

А кто из списка не планирует переход на 8.1/8.2  в ближайшие полгода ?

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

у мну по сабжу 1SJOURN = 111428... маленький я...

(53) голосУвалКу добавил, если чего....

уже год как "переходим", очередная дата Ч - 01/01/2010 ))

(49)вот именно, восьмерка наше все.

240879045 sql

1С 6.0

1SBCONS - 135 097
1SBDOC  -  31 415
1SBOPER -  49 911

отмечусь

Конечно-же.

Итоги SQL/DBF :
хм?
240 879 045 sql  los_hooliganos


15 698 109 (SQL) Sadovnikov
6 382 001 (SQL) dk
3 075 230 (SQL) trad
2 387 023 (SQL) Mikeware
2 371 968 (SQL) Скользящий
1 814 341 (SQL) rs_trade
1 486 634 (DBF) Ёпрст3
1 458 842 (SQL) NS
1 161 141 (SQL) Смотрящий от 1С
1 143 372 (SQL) ДенисЧ
909 008 (SQL) trdm
823 646 (SQL) also
814 632 (SQL) leshikkam (макс. доков в месяц: 47581)
626 201 (???) Попытка1С
111 428 Злопчинский

[/1С_]

240 миллионов? о_О Это точно количество документов, а не элементов справочника? )

а где v 6.0 ?

(65) ну дык выложи результат запроса "SELECT Count(*) FROM _1SJOURN"
включу :))))))))

2515336
SQL
01/01/2010 уже скоро, а напильником еще работать и работать ))

Ждем кто первый сотенку достигент

миллионов документов

(69) см (59) ))

ну тогда миллиард

Интересно сколько из этой статистики наших клиентов?:)
А вообщем то из относительно последних проектов расчет зп на 55 0000 сотрудников в одной бд(да и юрлице).

(72) Чисто для статистики - к МуМу не обращался, время проведекния РН точкой актуальности миллисекунды, задним числом до 2 секунд (конец месяца), всё штатное (никаких 1С++, прямых запрсов), переписанное.

1100 (в среднем) РН в день.

Занимаемся моделированием нагрузки. Вообщем к примеру 1000 РН в день ни о чем не говорит. Ситуация может отличаться на порядок в зависимости от сложности проверок, состава номенклатуры и ее разряженности(наличия дефицитных товаров, часто продаваемых),количества связанных проводок(бухия, финансы) и т.д и т.п.

Бывает специфика когда небольшие информационные потоки но при этом одна и та же номенклатура встречается с вероятностью 0.3 в каждом документе.

мое ИМХО - выше - словоблудие. Какие проводки во фронт-базе?
Кроме контроля остатков (в некоторых случаях и партий/сроков), шахматок предыдущих заказов/отгрузок, и новых позиций (в том числе и с измененными ценами и т.д.) - ничего в заявке быть не может. Реализация делает много движений, но конечно-же никаких проводок.

номенклатурник конечно-же десятки тысяч позиций. средний заказ - десятки позиций. Вероятность 0.3? Вы кому писали?

То 77. Мое ИМХО - выше- поверхностный однобокий взгляд.  Я не говорю  о том как сделать идеальную систему.(разумеется аналитические и оперативные проводки нежелательно смешивать в одну). Я говорю о том что есть на практике. А на практике руководители хотят ЕРП систему в которой в онлайне в одной транзакции обрабатываются все информационные потоки. И оперативные(чистая продажа) и финансовые и для аналитиков в ряде случаев. Пример УПП, и в дальнейшем выделение в УПП специального режима для проводения только опертивной(отгруззка товара) части и последующим провдением партий и .т.п.

То 78. Вот только не надо принимать жесткую позицию. Я могу показать примеры из жизни, благо их уже очень много. Поэтому что бы не сесть в лужу не советую сразу же начинать кидаться какашками.;)
В одной из компаний например номенклатура "тара" присутствовала с вероятностью 0.9 в каждом документе и проверка остатков по ней была всегда необходима. Я думал ты знаешь определение вероятности? Берем общее количество документов и берем конкретную позицию номенклатуры, считаем в скольких документах она присутсвует и делим на общее количество документов.

В данном случае кол. строк не важно потому как блокировки будут накладываться по всей табличной части. И важно пересечение множеств номенклатуры.

Мое мнение видимо просто несовпадает с другими.
Не нагрузит систему формирование проводок. Но они не для фронта. А вот разделение фронта и Бэка - я считаю в случае крупных клиентов обязательно.
Причем во фронте может быть некоторое количество достаточно мощных управленческих отчетов, но фискальному учету там точно (ИМХО) делать нечего.

(81) Ваша система не стоит, поэтому блокировка стандартная - практически на всё.
Очень оптимизированы модули, и поэтому несмотря на очень напрженную работу проведение не тормозит.

То 82. Так я про что, просто ситуации и требования очень отличаются. Насчет отделения фронта и бэка - так в теории это конечно архиважно. А вот на практике нарушается повсеместно.
То Модератор. И кстати в (80) я не голосовал,.... либо это произошло случайно.

481681 дбф 7.7

501899

select count(*) from Журнал
942012

Это дбф на моей старой работе, до сих пор периодически поддерживаю, обрезана с 01.01.2007

Во:

55683

и во:

294924!

558143
SQL
Ибо некуй.

1'928'624
База с 01.01.02 по 01.04.09   SQL
1 апреля 2009 я ее обрезал по 01.01.06. Слишком много старых клиентов болталось. А клиентов порядка 10000. На сегодняшний момент документов 960'000
эта база никогда не тормозиля и по моим оценкам без труда потянет 10 млн документов. Только где нам взять еще 90 тыс клиентов?
 На 8-ку уже два года поглядываем, закупили то, что необходимо, пренесли данные. Но уж больно тормознутая. Обрабатывать ее кувалдой настроения нет. Вот если фирма будет дальше развиваться в сторону открытя региональных заводов, тогда может и перейдем.

База на данный момент 8 Gb, до обрезания была 15 Gb. Активных пользователей порядка 10, одновременнно работающих пользователей до 30.

(0) а в чем прикол?
документы же не сами по себе , они еще кучу проводок делают
вот тут бы и меряться вам

(92) А если там только опер.учет?

Кстати почему не приведены запросы для 8ки? Они тоже наверное хотели бы померяться.

(93) Дык пусть и нарисуют запросы. Делов-то.

(94) А что, разве "в восьмерке это не реализовано"©? :-)

(94) Скажи в какой системной таблице храняться имена таблиц?
Я нарисую.

Журналы документов.
_DocumentJournal<n> - таблица журнала документов, создается для каждого журнала документов.
Только что-то в 8,2 я такой таблицы не вижу(

(96) Приколист...

(96) Моцарт?

100. (93) тогда уж все таблицы вытаскивать. "за ушко , да на солнышко"

select count(*) from _1SJourn

1103799

При переходе на 8 придется всё переписывать, а мы не готовы

(0)Предвижу запуск коллайдера и в планировании что-то куда-то переходить отпадает само собой *CRAZY*

меня забыли

Итоги SQL/DBF :
хм?
240 879 045 sql  los_hooliganos

 
15 698 109 (SQL) Sadovnikov
6 382 001 (SQL) dk
3 075 230 (SQL) trad
2 515 336 (SQL) Serjio  
2 387 023 (SQL) Mikeware
2 371 968 (SQL) Скользящий
1 928 624 (SQL) ProxyInspector
1 814 341 (SQL) rs_trade
1 486 634 (DBF) Ёпрст3
1 458 842 (SQL) NS
1 161 141 (SQL) Смотрящий от 1С
1 143 372 (SQL) ДенисЧ
1 103 799 (SQL) noxxx
942 012 (DBF) orefkov  
909 008 (SQL) trdm
823 646 (SQL) also
814 632 (SQL) leshikkam (макс. доков в месяц: 47581)
626 201 (???) Попытка1С
558 143 (SQL) Если
501 899 dimm7310
481 681 (DBF) YHVVH
294 924 Оболтус
111 428 Злопчинский


[/1С_]

Для ДБФ - мгновенное получение количества записей 1C++
Процедура КолЗаписейТаблицы()
   ИмяТаблицы="1SJourn";
   
   ОлеДБ = СоздатьОбъект("OLEDBData");
   Рез=ОлеДБ.Соединение("
   |Provider=VFPOLEDB.1;  
   |Null = Yes;
   |Exclusive = No;
   |SourceType = DBF;
   |Data Source=" + КаталогИБ() + ";
   |Mode=ReadWrite;
   |Extended Properties="""";
   |User ID="""";
   |Password="""";
   |Mask Password=False;
   |Collating Sequence=MACHINE;
   |TABLEVALIDATE =0;
   |DSN=""""");
    ОлеДБКоманда = ОлеДБ.СоздатьКоманду();
    ОлеДБКоманда.Выполнить("Exec('PUBLIC  NCount')");
    ОлеДБКоманда.Выполнить("Exec('USE "+ИмяТаблицы+" in 0')");
    ОлеДБКоманда.Выполнить("Exec('NCount=RecCount()  ')");
    ТЗ = ОлеДБКоманда.ВыполнитьИнструкцию("=NCount");
    NCount=ТЗ.ПолучитьЗначение(1,"return_value");
    Сообщить("Количество записей "+NCount);
КонецПроцедуры

у меня 401 465

Ладно чуть позже напишу для 8ки. Сейчас сильно занят))

(106) "240 879 045 sql  los_hooliganos " - ты лучше вот это прокомментируй.

Я пока на v7.7 остаюсь. Работаем с 2005г. Объем DBF 3.5Г Всего 506800 документов и все пока хорошо. Переходить будем, но тока на sql.

(107) телепатирую: это объем базы :-)

(109) В "бозонах хикса"? :)

и меня посчитайте :)
3 487 560

т.к. r2003 занят, я за него скажу - 26 697 942

(All) Интересно вот, а какой максимальный объем БД для 7.7 вы наблюдали. Ну и дбф/скл соответственно

Теперь и для 8ки))

SET NOCOUNT ON

declare @counter numeric, @tablename nvarchar(128)
declare cur cursor
for select name from [ИмяБазыДанных]..sysobjects where name like '%_DocumentJournal%'
exec('if exists(select * from [ИмяБазыДанных]..sysobjects where id = object_id(''[ИмяБазыДанных]..countertable''))
    drop table countertable')
exec('create table countertable (CT int)')
open cur
fetch next from cur
into @tablename
while @@fetch_status = 0
begin
exec('insert into countertable (CT) select count(*) from '+@tablename)
fetch next from cur
into @tablename
end
SET NOCOUNT OFF
select sum(ct) as QuantityDocs from countertable
exec('if exists(select * from [ИмяБазыДанных]..sysobjects where id = object_id(''[ИмяБазыДанных]..countertable''))
    drop table countertable')
close cur
deallocate cur

то (114) а разве в документ может входить только в один журнал ?
код неверный.

1 758 328 Доков за примерочно 6 лет, база sql

Пока останемся на семерке

(112) А можно чуть подробнее про эту базу?

(118) а что интересует?

(115) Ну злодей)))

SET NOCOUNT ON

declare @counter numeric, @tablename nvarchar(128)
declare cur cursor
for select name from [ИмяБазыДанных]..sysobjects where name like '_Document[0-9]%' and  name not like '%_VT%'
exec('if exists(select * from [ИмяБазыДанных]..sysobjects where id = object_id(''[ИмяБазыДанных]..countertable''))
   drop table countertable')
exec('create table countertable (CT int)')

open cur

fetch next from cur

into @tablename
while @@fetch_status = 0
begin

exec('insert into countertable (CT) select count(*) from '+@tablename)
fetch next from cur
into @tablename
end
SET NOCOUNT OFF
select sum(ct) as QuantityDocs from countertable
exec('if exists(select * from [ИмяБазыДанных]..sysobjects where id = object_id(''[ИмяБазыДанных]..countertable''))
   drop table countertable')

close cur
deallocate cur

(109) Ну я думаю все поняли что это шутка)

(119) Что это за база? На чем сделана? Документы - многострочные или нет? С какой скоростью отчеты работают?

(122) 7.7, sql2008, торговля, документы многострочные, отчеты работают всяко :) все зависит от прямых рук при написании запросов.

(123) За какой срок введено такое количество доков? И сколько в среднем пользователей работает?

(123) Ну не знаю. Мне лично кое-какие механизмы не нравятся

(125) Вспоминаем старое доброе слово "Рефакторинг" и кладем палец на кнопку Delete :)

(126) Не о том речь.

(127) Поясни?

(128) Семерку можно оптимизировать в хвост и в красную армию без особо сильных извратов. Да, без 1С++ не обойтись, но при таком подходе и встроенных средств вполне хватает.

(123) 2,5 года, 250-300 прямых пользователей плюс еще порядка 150-200 коннектов из сторонних систем

(129) А как это коррелирует с (126) и ответом на него в (127) ?
(130) Ага, пасиб.

(129) Без всяких 1С++ можно оптимизировать.

(132) Соглашусь, что 1с 77 можно хорошо оптимизировать без 1с++. У нас штатно 1С++ не используется. Хотя быстро обрезать базу удалось только с помощью 1с++.

(133) Без 1С++ хорошо нельзя...

+(134) существенного прироста не будет...

(135) они наверное с помощью ado

(136) RiK_SQL помнишь?

(137) Что значит помню?
Активно пользую.

(138) Я к тому, что не только при пощи ADO и 1С++ можно запросы к скулю делать :)
Кстати, а что именно из нее юзаешь? Просто интересно.

(139) работу с экселем.)

(134) Я писал - РН штатными средствами проводится быстрее секунды. Возможно штатно я быстрее не сдалаю, возможно прямые запросы еще ускорят, но зачем?

я проснулсё!
Итоги SQL/DBF :

26 697 942 (SQL) r2003
15 698 109 (SQL) Sadovnikov
6 382 001 (SQL) dk
3 487 560 (хз) SlavaR
3 075 230 (SQL) trad
2 515 336 (SQL) Serjio
2 387 023 (SQL) Mikeware
2 371 968 (SQL) Скользящий
1 928 624 (SQL) ProxyInspector
1 814 341 (SQL) rs_trade
1 758 328 (SQL) Жеглофф
1 486 634 (DBF) Ёпрст3
1 458 842 (SQL) NS
1 161 141 (SQL) Смотрящий от 1С
1 143 372 (SQL) ДенисЧ
1 103 799 (SQL) noxxx
942 012 (DBF) orefkov
909 008 (SQL) trdm
823 646 (SQL) also
814 632 (SQL) leshikkam (макс. доков в месяц: 47581)
626 201 (???) Попытка1С
558 143 (SQL) Если
506 800 (DBF) cyberandr
501 899 (???) dimm7310
481 681 (дбф) YHVVH
294 924  (DBF) Оболтус
111 428 Злопчинский


[/1С_]

так и не понял, восьмерочники собираются меряться?

(143) Они нервно курят в сторонке :)

(143)
Из списка в (0) вычеркиваешь (142) получаешь восьмерочников

(144) посмотрим)
создал тему)

trdm у меня SQL елси что

1831029   (sql)  Пока тянет, собираемся резать, т.к. постоянно приходится дописывать-переписывать конфу...

Короче - ну его нафиг снеговика с его запросами к железу...

(147) Ок, не проблема :)

(150) У мя тоже SQL :)

17'428'058 | dbf

(152) гонишь или пустая база?

(153)??? почто пустая?

(152) Извини, но почему-то слабо верится...

аааа туплю... пятницоЖ на дворе... %)))
132'022 | 17'428'058(байт)

:)))))))))))))))

Запрос №1:
98413125
размер в ГБ - 53,13ГБ
Запрос №2:
Всего    мес.   Макс. в мес.    среднее в мес.
98413125 107    3518039           919748    
Запрос №3:
Период  Кол-во
1999.01    4
2000.01    4
2001.05    3
2001.06    7
2001.10    2
2001.12    2
2002.01    5
2003.01    502954
2003.12    37
2004.01    25
2004.02    14
2004.03    29
2004.04    27
2004.05    60
2004.06    38
2004.07    42
2004.08    42
2004.09    74
2004.10    2185
2004.11    144
2004.12    2438
2005.01    729
2005.02    3436
2005.03    4455
2005.04    5447
2005.05    5805
2005.06    8752
2005.07    13920
2005.08    15572
2005.09    18650
2005.10    21116
2005.11    22906
2005.12    48740
2006.01    690947
2006.02    763806
2006.03    968125
2006.04    953440
2006.05    1045636
2006.06    1092840
2006.07    1077188
2006.08    1145399
2006.09    1059007
2006.10    1129174
2006.11    1260744
2006.12    1372689
2007.01    1239176
2007.02    1340489
2007.03    1506371
2007.04    1355652
2007.05    1652800
2007.06    1762770
2007.07    1979570
2007.08    2175613
2007.09    1975926
2007.10    2417906
2007.11    2456834
2007.12    2522643
2008.01    2241776
2008.02    2676702
2008.03    2815924
2008.04    3137622
2008.05    3033540
2008.06    3100221
2008.07    3518039
2008.08    3169015
2008.09    3134090
2008.10    3084962
2008.11    2563255
2008.12    3087220
2009.01    2344481
2009.02    2638735
2009.03    2876117
2009.04    2852886
2009.05    2593867
2009.06    2791210
2009.07    2952980
2009.08    2704814
2009.09    2654728
2009.10    2639168
2009.11    179188
2009.12    31
2010.02    3
2010.03    2
2010.05    1
2010.09    1
2010.11    3
2014.01    48
2015.03    1
2015.10    2
2017.01    1
2017.03    1
2017.10    30
2017.12    3
2018.01    15
2019.02    1
2019.06    1
2020.02    1
2020.03    20
2020.04    1
2021.11    2
2024.07    1
2034.12    1
2037.02    1
2060.04    1
2070.11    1
2089.03    1
2112.01    2
Всего строк :   Размер ГБ
3 480 370 171    1 537,14

короче за год база выросла в 2-а раза :) 1,5 ТБ

Переходим на SAP :(

(158) ПОнравилось: 2112.01    2

сам в шоке :)

(158) будет еще прикольекй если эти доки проведены.

(all) нашел у себя аналогичный опрос (winter) за 2003 год.
Если интересно могу сюда выложить

(164) Давай :)

ПолуOFF:Максимальное количество документов в день (Winter) Winter
17.04.2003 - 14:44 Пhосто интересно стало, наваял простой запросец :
select count(*), SUBSTRING(DATE_TIME_IDDOC,1,8)
from _1sjourn group by SUBSTRING(DATE_TIME_IDDOC,1,8)
order by count(*)
---------------------------------
Результат ...
......................
1236 20030416
1242 20030304
1250 20020705
1254 20020312
1255 20030403
1260 20030312
1267 20020627
1273 20020425
1279 20030401
1283 20030408
1317 20030410
1394 20030415
(1268 row(s) affected)
--------------------------
Базе 4-тый год, размер сейчас 18 гиг.
Может кто повторит и кинет в ветку информацию ?  
ДубовыйГай
1 - 17.04.2003 - 14:47 Само по себе кол-во доков в день ни о чем не говорит. Может они все пустые
и/или непроведенные? :)

pvase
2 - 17.04.2003 - 14:47 Повторять не буду могу сказать на словах, примерно 2 000 в день.

МоральныйУродец
3 - 17.04.2003 - 14:49 (1) Угу, прикалываемся мы в 1С - понаделаем пустых и непроведенных доков, а нам за это начальство денег платит ! =о))))
К слову сказать, есть доки с кол-вом строк до 2-х тысяч.
А справочник товаров около миллиона позиций.

Гоша
4 - 17.04.2003 - 14:50 около 3000 штук
Размер 12 гиг
(0) Ну как скорость работы с такой базой. Я уже подумываю варианты урезания.

ДубовыйГай
5 - 17.04.2003 - 14:52 3 Ребят ,а вы гиде работаете?

BigHarry
6 - 17.04.2003 - 14:52 Да уж...
Наверно - перепроведение документов или удаление меченных в такой базе лучше не затевать...

Searcher
7 - 17.04.2003 - 14:53 1194 20020531
1278 20020628
1360 20021230
1373 20020731
1425 20020930
1491 20021130
2057 20021031
2963 20030228
3118 20030131
3656 20030331
(928 row(s) affected)

pvase
8 - 17.04.2003 - 14:53 (3) Я тут со справочником в 10 000 элементов боюсь в нем что-то исправлять (чревато часовыми пересчотами), а представляю что будет с миллионом.

ну
9 - 17.04.2003 - 14:53 Повторил:
16353 20021228
16368 20021229
16916 20021231
16921 20030214
16927 20030222
17057 20021230
17072 20030306
18142 20030308
20280 20030307

Searcher
10 - 17.04.2003 - 14:55 (9) РАГ?

МоральныйУродец
11 - 17.04.2003 - 15:02 (4) Транзакции достали, а так всроде ничего
(5) Работаем это..... на работе ... вот =о)
(6) Про удаление меченых лучше забыть =о) Перепроводяться ночью.
(8) Если надо исправлять какой-то реквизит, то обновление - ночью.
А так уже не вводим реквизиты непосредственно в справочник "Товары" - тока в подчиненные.
(9) УРБД ? Скока ж у тебя центральная база весит ?

у меня тоже не плохо
12 - 17.04.2003 - 15:06 10302 20020531
10890 20021101
12470 20021230
12566 20020731
18774 20021031
19663 20020930
20201 20021130
25563 20030131
30251 20030331
30627 20021231
32466 20030228

ДубовыйГай
13 - 17.04.2003 - 15:08 11
А вообще ,это нормально что в спр-ке 1000000 позиций?
Может быть это связоно с ош-ми проектирования? Зачем такой огромный спр-к?
Предположим юзер что-то найти захочет-это сколько займет?

Очкарик
14 - 17.04.2003 - 15:11 У меня скромно...
20030218 323
20021225 333
20021226 338
20030227 376
20030220 383
20030303 391
20030304 537
 
Winter
15 - 17.04.2003 - 15:14 Ещё информация ...:
-----------------------
select count(*) from sc33
           
-----------
1002863
(1 row(s) affected)

неважно отпетый индеец
16 - 17.04.2003 - 15:15 13-й а если нам например в ИБ нужно пообъектоно учитывать количество атомов во вселенной, что делать, и расчитывать износ для них?

МоральныйУродец
17 - 17.04.2003 - 15:16 (12) Блин, скока же у тебя база ? И что за доки в таком колве ?
(13) А знаешь ли ты, друг, из скольки деталей состоит хороший автомобиль ?
А сто видов хороших автомобилей ? А тысяча ? =о)
А поиск - секунда-две, есть такая весч как прямые запросы к базе, знаешь ли .... Поиск по коду, естественно ....

МоральныйУродец
18 - 17.04.2003 - 15:20 +15. Для особо одаренных, поясню - это и есть как раз справочник "Товары"
=о)))

еще вот так не плохо
19 - 17.04.2003 - 15:20 SELECT LEFT(dbo._1SENTRY.DATE_TIME_DOCID, 6) as Period, COUNT(dbo._1SENTRY.DATE_TIME_DOCID) as Entry
FROM dbo._1SENTRY (NOLOCK)
GROUP BY LEFT(dbo._1SENTRY.DATE_TIME_DOCID, 6)
ORDER BY LEFT(dbo._1SENTRY.DATE_TIME_DOCID, 6)
-------------------------------
200207 279786
200208 332328
200209 403982
200210 483661
200211 543172
200212 839855
200301 632386
200302 618355
200303 693385

21 - 17.04.2003 - 15:23 опять у кого @ длиннее
МоральныйУродец
22 - 17.04.2003 - 15:24 (20) LOL !!!!!!!!!! =0))))
А запчасти такие машины юзают ? Или нет ? Ты оправдываешь свой ник !

Winter
23 - 17.04.2003 - 15:26 (19) Тут ты скромней ..... :0(
.............
200205 162625
200206 162460
200207 175467
200208 173057
200209 163350
200210 193481
200211 166008
200212 161198
200301 187795
200302 199250
200303 198040
200304 229835
(17 row(s) affected)
-----------------------
:0)

Winter
24 - 17.04.2003 - 15:28 (+23) В смысле мы скромней ...:0)

to 19
25 - 17.04.2003 - 15:29 сколько весит таблица _1SBKTTL? Если не секрет.

МоральныйУродец
26 - 17.04.2003 - 15:30 (21) Не тока @, но и #, а также & =о)))))

почто 3Гб
27 - 17.04.2003 - 15:33 вести _1SBKTTL, но она далеко не самая большая

ДубовыйГай
28 - 17.04.2003 - 15:33 А поиск - секунда-две, есть такая весч как прямые запросы к базе, знаешь ли .... Поиск по коду, естественно .... В прямых запросах поиск мона делать по любому полю ,не только код,знаешь ли...
21
угу.

www.perlscript.ru
29 - 17.04.2003 - 15:34 У меня скромненько:
======================
SELECT TOP 10 COUNT(*), SUBSTRING(DATE_TIME_IDDOC, 1, 8)
FROM _1SJOURN
GROUP BY SUBSTRING(DATE_TIME_IDDOC, 1, 8)
ORDER BY COUNT(*) DESC
====================
 238 20030307
 140 20030414
 129 20030306
 128 20030226
 126 20021223
 117 20030122
 111 20030312
 110 20030331
 109 20030108
 109 20030326

ДубовыйГай
30 - 17.04.2003 - 15:36 20+ А знаешь ли ты, друг, из скольки деталей состоит хороший автомобиль ? Плохой юзает ровно столько же. Даже больше.

МоральныйУродец
31 - 17.04.2003 - 15:38 (30) Плохих не юзаем =о))))

МоральныйУродец
31 - 17.04.2003 - 15:38 (30) Плохих не юзаем =о))))

Z1
32 - 17.04.2003 - 15:42 1371 20030401
1376 20030120
1380 20030410
1396 20030331
1415 20030414
1468 20021001
1538 20020930
1607 20021209
2575 20021216
4965 20010101

jurmike
33 - 17.04.2003 - 15:44 Не бейте тока ногами сильно за мой ламерский вопрос:
я так понял у вас базы скуельные, и вы к ним со скуельных терминалов запросы строите?

007
34 - 17.04.2003 - 15:46 1435 20020307
1168 20020306
1145 20020305
950 20020330
872 20020302
849 20020323
844 20020304
780 20020406
740 20020416
734 20020420
----------------
733 20020413
734 20020420
740 20020416
780 20020406
844 20020304
849 20020323
872 20020302
950 20020330
1145 20020305
1168 20020306
1435 20020307
.
(602 row(s) affected)

007
35 - 17.04.2003 - 15:48 (33) "C:\Program Files\Microsoft SQL Server\80\Tools\Binn\isqlw.exe" для начала.

Winter
36 - 17.04.2003 - 15:51 (35)Зря ты так парня обидел, лично у меня продвинутый "СИКУЕЛЬНЫЙ" терминал.

ДубовыйГай
37 - 17.04.2003 - 15:53 35
отстой для ламеров. SQL Nav рулит.

jurmike
38 - 17.04.2003 - 16:02 У меня стояла клиентская часть СКЛ Серванта, но я на новую машину переехал:))) Ветка интересная, я и не думал, что 1с такими объемами данных может ворочать, все пугают только, что есть определенный предел, после которого производительности пипец, а какой из себя этот самый предел никто не знает:)))

МоральныйУродец
39 - 17.04.2003 - 16:04 (38) Вот и стараемся мы тут определить размер этого самого пипеца =о)

...
40 - 17.04.2003 - 16:04 (38) "Чтобы узнать пределы возможного, нужно выйти из этого предела в невозможное" (С) Энштейн

Z1
41 - 17.04.2003 - 16:05 (38) предел только из-за блокировок.
Все Остальное можно руками исправить.

(0) У меня скромненько, 571320 в одной базе и 400255 в другой

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