1. 1Счик 29.10.10 17:51 Сейчас в теме

Добавление поля в справочник

Всем привет!

Используется 1С 7.7 релиз 27
Формат DBF
В экспериментальной базе есть только один справочник "Номенклатура" и больше никаких объектов метаданных.
Справочник "Номенклатура" имеет поля:
ЗакупочнаяЦена - Число, 10, 2
ЦенаРеализации - Число, 10, 2
ШтрихКод - Строка, 13, сортировка
Артикул - Строка, 13, сортировка
Вес - Число, 10, 0

В этот справочник добавлено 30000 записей.

Проблема в следующем:

Когда я пытаюсь добавить еще одно поле (например, числовое, длина 1) в справочник с количеством записей ~30000 происходит следующее:

1. Конфигуратор зависает на весьма продолжительное время.
2. Открываю папку NEW_STRU и вижу, что индекс файла, соответствующего моему справочнику растет безбожно. Уверен, что этот неудержимый рост индексного файла является причиной столь долгой реструктуризации. В моем случае уже часа три прошло...

К примеру размер файла DBF справочника до добавления поля равен 6Mb, индексный файл до добавления поля 8Mb, а в папке NEW_STRU индекс уже распух до 800Mb. Особенно хорошо эффект заметен, когда добавляешь поле со включенной галкой "Сортировка". Индекс растет еще больше и достигая размера в 2Gb все прекращается. 1С вываливается с ошибкой записи, т.к. размер индексного файла достиг 2Gb.

Кто может подсказать как принудительно отключить создание индексного файла во время реструктуризации справочника? Или этот глюк 1С как-то лечится?

ЗЫ: проблема эта мне известна давно, но на малых количествах записей незаметна. После реструктуризации стоит сделать переиндексацию базы и размер индексного файла снова становится нормальным.
Ответы
Избранное Подписка Сортировка: Древо
14. vladimir_makarov 106 30.10.10 18:14 Сейчас в теме
(1) Наверное, писали по делу (уважаю всех), но Вы изначально дурь пишете
[FONT=Arial]ЗакупочнаяЦена - Число, 10, 2
ЦенаРеализации - Число, 10, 2
ШтрихКод - Строка, 13, сортировка [/FONT]

НЕТ там таких реквизитов! Это подчинённые! К вопросу о том, что у Вас 30000 элементов... Любой самый задумчивый Celeron (имея 256 ОЗУ) с этим справится МАКСИМУМ за 10 мин. ... Сервер проверьте!!!
30. hogik 01.11.10 01:07 Сейчас в теме
(1) (1Счик)
Тестовую базу получил и протестировал. ;-)
Причину проблемы я "угадал" верно, еще выше по теме форума.
Дело в "неудобных" значениях ключей (8). Мы, в своей конфигурации, с аналогичной проблемой не сталкивались в силу самих значений реквизитов и "балансировки" на грани максимальной длины ключей. Я промоделировал, путем добавления в свою конфигурацию, индексов с сортировкой и отбором аналогичных Вашей структуре и получил тот же результат - очень долго работает и индекс принимающей таблицы разбухает до огромных размеров. Попытка открывать такие таблицы утилитой из СУБД "Advantage 8.1/9.1" вызывает ошибку (см. Приложении #1). Бороться с этой проблемой можно тремя способами:
1) Переходить на другие СУБД. Это самый правильный путь. Но... Мы же понимаем... ;-)
2) Использовать мою разработку "DBEng32 Share". Если это у Вас возможно использовать, то я могу поковыряться с ней и добавить режим отключающий создание индексов для принимающих таблиц и отключить использование транзакций в момент реструктуризации. Транзакции я уже проверил - ускорение, на глаз, раз в 100. Но, индексы, естественно продолжают разбухать. Вопрос отключения создания индексов не такой простой, как это представляется на первый взгляд. Я допускаю, что в алгоритмах реструктуризации имеются потребности использовать таблицы в каталоге NEW_STRU по индексам когда, например изменяется суть связанных таблиц. Надо еще об этом отключении думать. Но шансы на успех - большие.
3) Уменьшать размер ключей. Я провел тесты уменьшая реквизит "Наименование" от 100 символов до 80. Уже при длине реквизита в 90 символов система начинает жить, почти, нормально. А при длине в 80 символов - совсем всё хорошо. Кроме этого мне показалось, что отбор по штрих-коду можно и не включать. Не могу представить задач, где требуется отбор по штрих-коду. И надо всегда следить за длиной ключей, т.е. заглядывать в 1Cv7.DD и считать. Существует формула для расчета максимальной длины ключа при определенном размере блока индексного файла. В случае "движка" от "1С 7.7" размер блока равен 512 байт. Например, в документации к Advantage даётся формула (см. Приложение #2) и эта формула может использоваться и для нашего случая родного "движка". Однако, эта формула имеет ошибку. И мне пришлось "вывести ;-)", немного, другую формулу (см. Приложение #3). Т.е. максимальный приемлемый размер ключа для "движка" "1С 7.7" равен 117 байтам. В Вашей схеме базы данных ключ немного больше.
Приложение #1.
Problem: The current index is unbalanced. This problem is most likely to occur when using very long index keys and new keys are being added to the index. This error could also occur if the index is corrupt.
Solution: Reindex the file. The reindexed file will be built using the minimum number of levels. This will speed up all future operations using the index. If this does not resolve the problem, reindex with a larger page size.
Приложение #2.
The following formulas show the relationship between index key size K and index file page size P.
The minimum required page size for a given key is: P = ( K + 8 ) * 2 + 12
To guarantee at least three keys per page for better balancing: P >= ( K + 8 ) * 3 + 12
For a given page size, the maximum key size supported is: K = (( P - 12 ) / 2 ) - 8
For a given page size, optimal balancing is given by: K <= (( P - 12 ) / 3 ) - 8
Key Size Index File Page Size
1 - 158 512
159 - 329 1024
330 - 670 2048
671 - 1353 4096
1354 - 4082 8192
Приложение #3.
P >= ( K + 8 ) * 4 + 12.
Key Size Index File Page Size
1 - 117 512
118 - 245 1024
246 - 501 2048
502 - 1013 4096
1014 - 2037 8192
АндрейКр; +1 Ответить
2. Altair777 29.10.10 18:00 Сейчас в теме
такие вещи хорошо лечатся переходом на скульную базу
3. 1Счик 29.10.10 18:07 Сейчас в теме
Но ведь это стопудово глюк 1С. Если подумать, то можно поле в DBF файл и с помощью сторонней проги добавить и это не займет столько времени.
4. hogik 29.10.10 18:43 Сейчас в теме
(3)
Это не глюк. А ошибка при проектировании системы. В "1С 7.7" всегда и все таблицы открываются с использованием файла индексов (*.CDX). И даже тогда, когда это не требуется. Думаю, эту "проблему" можно решить в разработке http://infostart.ru/public/16268/
Но, это надо? Ведь изменение структуры делается не каждый день. Да, и на SQL-ную версию имеет смысл перейти при таких размерах таблиц базы данных.
5. 1Счик 29.10.10 19:06 Сейчас в теме
Не глюк?!

Как можно объяснить то, что индекс пухнет в папке NEW_STRU при реструктуризации до 2Gb и пытается еще? В то время, когда файл DBF 6Mb, а индекс до реструктуризации 8Mb. Если Вы внимательно прочитали мое первое сообщение, то поймете, что и после реструктуризации стоит сделать переиндексацию БД - индекс этого справочника возвращается к нормальному размеру!
6. hogik 29.10.10 19:22 Сейчас в теме
(5)
Да. Я прочел все Ваши сообщения данной темы.
И еще "прочел" все способы и методы работы с DBF файлами в 1С 7.7. ;-)
В её кишках - прочел. См. мои разработки.
А по поводу размера индексного файла в 2 гигабайта - это другой глюк, и, думаю, в другом месте. У нас в справочнике товаров - 75000 записей. Изменение структуры делаем не часто, но - делаем. И всегда успешно... Пришлите мне этот файл и *.DD. Гляну. Причина может быть в испорченном файле DBF.
Структура нашего справочника:
#==TABLE no 37 : Справочник Номенклатура
# Name |Descr |Type[A/S/U]|DBTableName|ReUsable
T=SC33 |Справочник Номенклатура |A |SC33 |1
#-----Fields-------
# Name |Descr |Type|Length|Precision
F=ID |ID object |C |9 |0
F=PARENTID |ID parent obj |C |9 |0
F=CODE |object code |C |7 |0
F=DESCR |object description |C |100 |0
F=ISFOLDER |Flag - Is Line - Fol|N |1 |0
F=ISMARK |Flag Object is Marke|C |1 |0
F=VERSTAMP |Version stamp |C |6 |0
F=SP8183 |(P)АвторНачВвода |C |9 |0
F=SP8182 |(P)АвторИзменений |C |9 |0
F=SP7481 |(P)Артикуль |C |20 |0
F=SP74 |(P)БазоваяЕдиницаИзм|C |9 |0
F=SP8803 |(P)ВесЕдиницы |N |11 |3
F=SP689 |(P)ВидТовара |C |9 |0
F=SP7502 |(P)КоэфПодачи |N |10 |4
F=SP7480 |(P)Модель |C |20 |0
F=SP7433 |(P)НомерГТД |C |50 |0
F=SP8025 |(P)НомернойТовар |N |2 |0
F=SP9044 |(P)Секция |N |3 |0
F=SP7482 |(P)СтранаПроизводите|C |30 |0
F=SP7432 |(P)СтранаПроисхожден|C |30 |0
F=SP5712 |(P)ТипТовара |C |9 |0
F=SP7504 |(P)Ценник |C |9 |0
F=SP9181 |(P)ВводБС |N |2 |0
F=SP9318 |(P)ОригНомер |C |20 |0
F=SP9326 |(P)Производство |C |20 |0
F=SP9843 |(P)ФильтрТоваров |N |3 |0
F=SP9908 |(P)НеАктуальный |N |2 |0
F=SP9909 |(P)ФильтрОбщий |N |4 |0
F=SP9925 |(P)ОтборОстатков1 |N |2 |0
F=SP9926 |(P)ОтборОстатков2 |N |2 |0
F=SP9927 |(P)ОтборОстатков3 |N |2 |0
F=SP9928 |(P)ОтборОстатков4 |N |2 |0
F=SP9929 |(P)ОтборОстатков5 |N |2 |0
F=SP9930 |(P)ОтборОстатков6 |N |2 |0
F=SP9931 |(P)ОтборОстатков7 |N |2 |0
F=SP9932 |(P)ОтборОстатков8 |N |2 |0
F=SP9933 |(P)ОтборОстатков9 |N |2 |0
F=SP9939 |(P)ОтборОстатковA |N |2 |0
F=SP9940 |(P)ОтборОстатковB |N |2 |0
F=SP9941 |(P)ОтборОстатковC |N |2 |0
F=SP9942 |(P)ОтборОстатковD |N |2 |0
F=SP9943 |(P)ОтборОстатковE |N |2 |0
F=SP9944 |(P)ОтборОстатковF |N |2 |0
F=SP9945 |(P)ОтборОстатковG |N |2 |0
F=SP9946 |(P)ОтборОстатковH |N |2 |0
F=SP9947 |(P)ОтборОстатковI |N |2 |0
F=SP9948 |(P)ОтборОстатковJ |N |2 |0
F=SP9949 |(P)ОтборОстатковK |N |2 |0
#----Indexes------
# Name |Descr |Unique|Indexed fields |DBName
I=IDD |of ID |0 |ID |IDD
I=PCODE |of PARENT and |0 |PARENTID,ISFOLDER,CODE(UPPER) |PCODE
I=PDESCR |of PARENT and |0 |PARENTID,ISFOLDER,DESCR(UPPER) |PDESCR
I=CODE |of CODE |0 |CODE(UPPER) |CODE
I=DESCR |of DESCR |0 |DESCR(UPPER) |DESCR
I=VI7481 |VI7481 |0 |SP7481(UPPER=128),DESCR(UPPER) |VI7481
I=VIP7481 |VIP7481 |0 |PARENTID,ISFOLDER,SP7481(UPPER=128),DESCR(UPPER) |VIP7481
I=VI7480 |VI7480 |0 |SP7480(UPPER=128) |VI7480
I=VIP7480 |VIP7480 |0 |PARENTID,ISFOLDER,SP7480(UPPER=128) |VIP7480
I=VI9318 |VI9318 |0 |SP9318(UPPER=128) |VI9318
I=VIP9318 |VIP9318 |0 |PARENTID,ISFOLDER,SP9318(UPPER=128) |VIP9318
I=VI9326 |VI9326 |0 |SP9326(UPPER=128),DESCR(UPPER) |VI9326
I=VIP9326 |VIP9326 |0 |PARENTID,ISFOLDER,SP9326(UPPER=128),DESCR(UPPER) |VIP9326
I=VI9843 |VI9843 |0 |SP9843,DESCR(UPPER) |VI9843
I=VIP9843 |VIP9843 |0 |PARENTID,ISFOLDER,SP9843,DESCR(UPPER) |VIP9843
I=VI9908 |VI9908 |0 |SP9908,DESCR(UPPER) |VI9908
I=VIP9908 |VIP9908 |0 |PARENTID,ISFOLDER,SP9908,DESCR(UPPER) |VIP9908
I=VI9909 |VI9909 |0 |SP9909,DESCR(UPPER) |VI9909
I=VIP9909 |VIP9909 |0 |PARENTID,ISFOLDER,SP9909,DESCR(UPPER) |VIP9909
I=VI9925 |VI9925 |0 |SP9925,DESCR(UPPER) |VI9925
I=VIP9925 |VIP9925 |0 |PARENTID,ISFOLDER,SP9925,DESCR(UPPER) |VIP9925
I=VI9926 |VI9926 |0 |SP9926,DESCR(UPPER) |VI9926
I=VIP9926 |VIP9926 |0 |PARENTID,ISFOLDER,SP9926,DESCR(UPPER) |VIP9926
I=VI9927 |VI9927 |0 |SP9927,DESCR(UPPER) |VI9927
I=VIP9927 |VIP9927 |0 |PARENTID,ISFOLDER,SP9927,DESCR(UPPER) |VIP9927
I=VI9928 |VI9928 |0 |SP9928,DESCR(UPPER) |VI9928
I=VIP9928 |VIP9928 |0 |PARENTID,ISFOLDER,SP9928,DESCR(UPPER) |VIP9928
I=VI9929 |VI9929 |0 |SP9929,DESCR(UPPER) |VI9929
I=VIP9929 |VIP9929 |0 |PARENTID,ISFOLDER,SP9929,DESCR(UPPER) |VIP9929
I=VI9930 |VI9930 |0 |SP9930,DESCR(UPPER) |VI9930
I=VIP9930 |VIP9930 |0 |PARENTID,ISFOLDER,SP9930,DESCR(UPPER) |VIP9930
I=VI9931 |VI9931 |0 |SP9931,DESCR(UPPER) |VI9931
I=VIP9931 |VIP9931 |0 |PARENTID,ISFOLDER,SP9931,DESCR(UPPER) |VIP9931
I=VI9932 |VI9932 |0 |SP9932,DESCR(UPPER) |VI9932
I=VIP9932 |VIP9932 |0 |PARENTID,ISFOLDER,SP9932,DESCR(UPPER) |VIP9932
I=VI9933 |VI9933 |0 |SP9933,DESCR(UPPER) |VI9933
I=VIP9933 |VIP9933 |0 |PARENTID,ISFOLDER,SP9933,DESCR(UPPER) |VIP9933
I=VI9939 |VI9939 |0 |SP9939,DESCR(UPPER) |VI9939
I=VIP9939 |VIP9939 |0 |PARENTID,ISFOLDER,SP9939,DESCR(UPPER) |VIP9939
I=VI9940 |VI9940 |0 |SP9940,DESCR(UPPER) |VI9940
I=VIP9940 |VIP9940 |0 |PARENTID,ISFOLDER,SP9940,DESCR(UPPER) |VIP9940
I=VI9941 |VI9941 |0 |SP9941,DESCR(UPPER) |VI9941
I=VIP9941 |VIP9941 |0 |PARENTID,ISFOLDER,SP9941,DESCR(UPPER) |VIP9941
I=VI9942 |VI9942 |0 |SP9942,DESCR(UPPER) |VI9942
I=VIP9942 |VIP9942 |0 |PARENTID,ISFOLDER,SP9942,DESCR(UPPER) |VIP9942
I=VI9943 |VI9943 |0 |SP9943,DESCR(UPPER) |VI9943
I=VIP9943 |VIP9943 |0 |PARENTID,ISFOLDER,SP9943,DESCR(UPPER) |VIP9943
I=VI9944 |VI9944 |0 |SP9944,DESCR(UPPER) |VI9944
I=VIP9944 |VIP9944 |0 |PARENTID,ISFOLDER,SP9944,DESCR(UPPER) |VIP9944
I=VI9945 |VI9945 |0 |SP9945,DESCR(UPPER) |VI9945
I=VIP9945 |VIP9945 |0 |PARENTID,ISFOLDER,SP9945,DESCR(UPPER) |VIP9945
I=VI9946 |VI9946 |0 |SP9946,DESCR(UPPER) |VI9946
I=VIP9946 |VIP9946 |0 |PARENTID,ISFOLDER,SP9946,DESCR(UPPER) |VIP9946
I=VI9947 |VI9947 |0 |SP9947,DESCR(UPPER) |VI9947
I=VIP9947 |VIP9947 |0 |PARENTID,ISFOLDER,SP9947,DESCR(UPPER) |VIP9947
I=VI9948 |VI9948 |0 |SP9948,DESCR(UPPER) |VI9948
I=VIP9948 |VIP9948 |0 |PARENTID,ISFOLDER,SP9948,DESCR(UPPER) |VIP9948
I=VI9949 |VI9949 |0 |SP9949,DESCR(UPPER) |VI9949
I=VIP9949 |VIP9949 |0 |PARENTID,ISFOLDER,SP9949,DESCR(UPPER) |VIP9949
7. 1Счик 29.10.10 19:53 Сейчас в теме
Рад за вас, т.к. для меня проблемно добавить еще одно поле даже при 30000 записей.

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

Могу файл MD прислать или целиком экспериментальную базу.

мой DD гораздо скромнее:

#==TABLE no 8 : Справочник Номенклатура
# Name |Descr |Type[A/S/U]|DBTableName|ReUsable
T=SC12 |Справочник Номенклатура |A |SC12 |1
#-----Fields-------
# Name |Descr |Type|Length|Precision
F=ID |ID object |C |9 |0
F=PARENTID |ID parent obj |C |9 |0
F=CODE |object code |C |5 |0
F=DESCR |object description |C |100 |0
F=ISFOLDER |Flag - Is Line - Fol|N |1 |0
F=ISMARK |Flag Object is Marke|C |1 |0
F=VERSTAMP |Version stamp |C |6 |0
F=SP13 |(P)ЗакупочнаяЦена |N |11 |2
F=SP14 |(P)ЦенаРеализации |N |11 |2
F=SP16 |(P)ШтрихКод |C |13 |0
F=SP17 |(P)Артикул |C |13 |0
F=SP18 |(P)Вес |N |11 |0
#----Indexes------
# Name |Descr |Unique|Indexed fields |DBName
I=IDD |of ID |0 |ID |IDD
I=PCODE |of PARENT and |0 |PARENTID,ISFOLDER,CODE(UPPER) |PCODE
I=PDESCR |of PARENT and |0 |PARENTID,ISFOLDER,DESCR(UPPER) |PDESCR
I=CODE |of CODE |0 |CODE(UPPER) |CODE
I=DESCR |of DESCR |0 |DESCR(UPPER) |DESCR
I=VI16 |VI16 |0 |SP16(UPPER=128),DESCR(UPPER) |VI16
I=VIP16 |VIP16 |0 |PARENTID,ISFOLDER,SP16(UPPER=128),DESCR(UPPER) |VIP16
I=VI17 |VI17 |0 |SP17(UPPER=128),DESCR(UPPER) |VI17
I=VIP17 |VIP17 |0 |PARENTID,ISFOLDER,SP17(UPPER=128),DESCR(UPPER) |VIP17
8. hogik 29.10.10 20:28 Сейчас в теме
(7)
Мне проще будет разбираться имея целиком экспериментальную базу.
Способы получения - напишите в личку.
Но забегая вперед, обобщу "проблему":
1) В 1С 7.7, при изменении структуры БД производится запись в новый DBF в рабочем каталоге. Для этой задачи не требуется создавать, открывать и обновлять CDX. Это, теоретически, можно исправить в моей разработке.
2) При обновлении индексов они всегда разбухают. Это присуще любой СУБД.
3) Индексный файл разбухает сильней, чем больше "неудобных" значений ключа поступает на добавление/изменение записей. Например, исходная таблица просматривается в порядки одного индекса, а ключи другого индекса встают в обратном порядке индекса и имеют много различных значений.
4) Исходя из #3, надо всегда пересоздавать индекс результирующей таблицы. И желательно пересоздать индекс исходной таблицы перед выполнением изменения структуры.
9. jmw 30.10.10 07:47 Сейчас в теме
Можно попытаться сделать так:
- убрать со всех реквизитов галочки Сортировка и Отбор по реквизиту
- сохраниться
- добавить реквизит
- снова сохраниться
- восстановить галочки Сортировка и Отбор по реквизиту
Ещё, чтобы пофигуратор не "зависал" в свойствах ярлыка 1С поставить "Запускать программу в режиме совместимости - Windows 2000". По крайней мере у меня помагает.
Ещё можно загнать всю базу в RAMdrive - если память позваляет!
10. 1Счик 30.10.10 09:27 Сейчас в теме
Jurii,

Спасибо за попытку, но меня другое интересует.

Можно, конечно, снять галочки "сортировка", а потом их поставить...
Но после того, как я их поставлю придется сохранить изменения конфигурации. При этом реструктуризация будет длиться еще дольше. Проверено. И размер индексного файла дорастет до 2Gb со всеми вытекающими...

Танцы с бубном уже все исполнены. Меня не интересуют советы как добавить это несчастное поле. Мне интересно почему так себя ведет 1С? Зачем она создает индексный файл во время реструктуризации файла DBF? Индекс тупо можно было бы создать непосредственно после добавления поля в DBF, а не во время добавления поля. Как победить непомерно растущий индекс во время реструктуризации? Знаю, что штатными средствами - никак.
11. jmw 30.10.10 11:49 Сейчас в теме
(10) Это ты браток не у тех спрашиваешь!
Это нужно у Нургалиевских кодеров спрашивать...
16. hogik 30.10.10 19:42 Сейчас в теме
(10) (1Счик)
"Мне интересно почему..."(с)
На все Ваши вопросы - ответы даны.
Рост до 2 гигабайт - надо смотреть базу.
Я предложил Вам свою помощь.
Где база? ;-)
(14) (vladimir_makarov)
"Вы изначально дурь пишете"(с)
Скажите это себе.
12. 1Счик 30.10.10 11:54 Сейчас в теме
:D

Интересно. Они этот форум читают?
13. jmw 30.10.10 12:16 Сейчас в теме
Сто пудово нет!
Оне там даже про OpenConf, FormEx, Телепат и SciColorer не знают
15. vladimir_makarov 106 30.10.10 18:19 Сейчас в теме
Господа программеры! Что-то я тут свою единомышленницу не вижу: госпожу Уфимскую! Вместе посмеяль бы...
17. 1Счик 30.10.10 19:54 Сейчас в теме
Владимир (hogik),
Спасибо за предложение. Обязательно воспользуюсь. Хочу еще немного "помучиться" :)
Базу выложу. Может быть завтра.
18. 1Счик 30.10.10 20:01 Сейчас в теме
vladimir_makarov,
ну, насчет дури - я попросил бы!

Если не знаете ответа на вопрос, то нечего эфир засорять.
19. Ish_2 1019 30.10.10 21:23 Сейчас в теме
ОФФ. Я извиняюсь. Проходил мимо, дай ,думаю, погляжу что "семерочников" волнует , какие проблемы решают. И ,честно сказать, смахнул слезу...
сколько же лет прошло .. DBF-файл,индекс CDX, медленная работа...
Спасибо автору.
P.S.Владимиру. Про "ошибку проектирования".
Двадцать лет назад В FoxPro 2.0 dbf-таблица автоматически создавалась с индексом CDX. Тогда помнится были обсуждения как обойти создание этого паразитного индекса.
Тогда он назывался "структурным".
Вижу , что и через 20 лет Вечный бой продолжается...
22. hogik 30.10.10 23:59 Сейчас в теме
(19)
Игорь.
А я "проходил мимо" другой темы http://infostart.ru/forum/forum14/topic35991/
И тоже "смахнул слезу" от зависти. О сколько можно написать статей и операторов для решения элементарных задач запросами. Обсудить, подумать, посмешить людей, самому посмеяться... ;-)
Про FoxPro.
Я не писал программы на этой системе. И "не знаю" про проблемы "паразитного индекса". Я, по своей глупости, всегда избегал использовать системы (средства) программирования в которых за мнимым облегчением труда программиста предлагалось "строгать портянки". Т.е. писать (делать) явную халтуру с минимальными затратами мозгов.
Про вечный бой.
Вопрос, обсуждаемый в данной теме, не имеет отношение к "структурным"(с) индексам. В "движке" 1С 7.7 есть возможности не создавать и не использовать индексы для таблиц. Этот "движок" предоставляет гораздо больше возможностей использовать мозги чем в FoxPro. Однако, разработчики, видимо, отучились использовать мозги после длительного использования систем типа "FoxPro".
Про медленную работу.
Скорость работы системы волнует разработчиков, которые занимаются не только теоретическим программирование, но и реальным внедрением и эксплуатацией. И это не зависит от среды программирования. Вы же открыли тему по запросам не просто так. Да? ;-)
23. Ish_2 1019 31.10.10 01:46 Сейчас в теме
(22) Конечно, не просто так. Я хочу набраться опыта и стать настоящим разработчиком .
Вот теперь изучаю рекурсию и, думаю , следующее обсуждение в рубрике "Мы пишем запросы" будет посвящено ей . В этом Миша виноват.
http://www.infostart.ru/public/75878/?PAGEN_1=18#comm396565
24. hogik 31.10.10 02:04 Сейчас в теме
(23)
Да. Я так и понял, что названием следующей статьи в Вашем цикле будет "Рекурсия". Я уже собрался в той теме написать очередную "гнусность", но Вы меня опередили своей "слезой" в этой теме. Пришлось отвечать здесь.
Пишите - дело полезное. Почитаем. Как я уже говорил, что если нет выбора в средствах программирования, то и в этой среде надо уметь делать "Рекурсию". Мне, то, проще писать всякую критику. Я свободен в выборе средств программирования и СУБД. Могу выбирать, могу и не выбирать... ;-)
25. Ish_2 1019 31.10.10 02:21 Сейчас в теме
(24) Нет. Не свободен !
Был бы свободен - давно бы уже утер нос по всем темам "Мы пишем запросы" и не "словесами" , а своими опровергающими обработками на 1с8 - дескать смотрите, ребята как нужно решать задачи ! Пока же только ...соображения... размышлизмы..
рассуждалки.
26. hogik 31.10.10 02:45 Сейчас в теме
(25)
Я не очень понял. "Не свободен" - это обо мне?
Если - да. То какой "утер" от меня может быть.
Т.е. я сажусь на "1с8" и начинаю писать вместе с Вами запросы?
Игорь. Еще раз. Я не пишу запросы. И не потому, что не умею.
А потому, что к нашим задачам запросы это тоже самое, что забивать гвозди фотоаппаратом.
Больше скажу, что реляционное "отображение" нашего объекта автоматизации - это технология 30-и летней давности. И еще больше скажу, что описание нашей предметной области документами с регистрами - это технология 50-и летней давности.
И Вы мне предлагаете сделать выбор в пользу этих древних технологий, снабженных бантиками "внешних форм" взаимодействия с пользователем, и "утирать" нос окружающим?
Я, конечно, свободен в выборе "среды программирования", но не настолько глуп, чтобы вернуться в своё прошлое. Т.е. я не настолько стар, чтобы впадать в детство... ;-)
27. Ish_2 1019 31.10.10 02:58 Сейчас в теме
(26) Ну, да. Я помню : Реляционные базы - каменный век, 1с - отстой....
И предъявить ничего не могу , потому как "стрёмно" писать на 1с ...

Что же остаётся ?
Остаётся помогать лечить DBF-файлы.
Спору нет , дело, конечно, доброе. Только ..."стрёмно" как-то.
28. hogik 31.10.10 03:14 Сейчас в теме
(27)
Игорь.
Ну зачем так примитивно?
Слова типа "отстой" я не употреблял. Про применимость реляционной модели для наших задач - давал Вам ссылку. По поводу предъявить - намекал Вам посмотреть мои разработки или хотя бы спросить меня - "о чем это?". Я восхищаюсь Вашим "конкретизмом" и уважаю его. Но, имеет смысл немного посмотреть "ширее" и "глубжее". ;-)
Начнёте писать статью про "Рекурсию" попробуйте, задачу из ссылки в (22) сообщении, написать рекурсией с применением массива (исходные данные) на абстрактном алгоритмическом языке. Забудьте о запросах на время. А потом представьте, что при обращении к массиву по индексу в этом языке есть возможность написать m[Key+i,j] и получить i-ое значение строки из множества с равными Key. И, думаю, решение этой задачи уложится в 5-10 простых операторов.
P.S. Если я сбивчиво рассказал про массив - извините. Если будет желание разобраться - задавайте вопросы.
P.P.S. С применением моих разработок подобные задачи решаются аналогичным количеством и содержанием операторов.
P.P.P.S. Я помогаю лечить DBF-ы, т.к. меня попросили люди разобраться с другой ошибкой. А эта ошибка, думаю, мне поможет это сделать. Да и, надеюсь, в этой ошибке помогу человеку. А в моей промышленной системе DBF давно не используются и не портятся таблицы БД, т.к. используется клиент-серверный режим.
20. 1Счик 30.10.10 21:44 Сейчас в теме
Ish_2,
:D
Вы уже 20 лет не пользуетесь DBF?
И где же Вы были эти 20 лет?

Если интересно - я расскажу зачем мне все это. Почему я данный проект не перевожу на SQL или на ту же 8-ку.
21. Ish_2 1019 30.10.10 23:01 Сейчас в теме
(20) Конечно, интересно. Почему ?
29. Ish_2 1019 31.10.10 05:14 Сейчас в теме
31. 1Счик 01.11.10 09:56 Сейчас в теме
Владимир, большое спасибо Вам за проделанную работу!

Я пошел по самому простому пути: уменьшил длину наименования до 80-ти знаков. При этом, как Вы и говорили размер индексного перестал расти! Вместо ~1Gb индекс вырос лишь до ~15Mb. Чудо! :)

Отвечая одновременно и Вам, и Ish_2, скажу: перевести этот проект на SQL не могу по простой причине. Есть N-количество торговых точек одной торговой сети. Все они в разной степени удалены от "центра" (разные города). Базы каждой торговой точки никак не связаны между собой. Единственное, что их объединяет - это то, что в каждой из них точная копия конфигурации 1С. Если бы была 100% надежная связь каждой торговой точки с центром... Конечно, тогда можно было бы поставить базу на центральный сервер, а туда SQL, терминальный сервер и т.п. Но в жизни все немного иначе. В каждой торговой точке от одного до четырех компов. Согласитесь, покупать SQL сервер в магазин, где стоит один комп как-то дороговато...
По поводу "невозможности" перехода на 1С8. Представьте, что у Вашего клиента уже X-лет работает N-количество магазинов на 1С7. Причем быстродействие и функционал 1С7 его устраивает. Как его убедить перейти на 1С8? Сказать ему, что у меня индекс при реструктуризации вырос до 1Gb? На это он мне посмеется в лицо и будет прав.

Владимир, по второму пункту: "Использовать мою разработку "DBEng32 Share".
Если уменьшение поля "Наименование" дает такой хороший результат, то зачем заморачиваться? К тому же я с Вами полностью согласен, что при вмешательстве в алгоритмы реструктуризации возможны проблемы со связанными таблицами.

Отбор по штрихкоду иногда нужен. Например, находясь в списке справочника "Номенклатура", можно нажать кнопку "Отбор по значению" и быстро найти нужный товар (когда штрихкод плохо сканируется с помощью сканера штрихкодов). Можно, конечно искать по первым символам, набирая непосредственно в списке, но в сетевой версии иногда притормаживает...

Объясните мне, пожалуйста, из чего складывается K в этой формуле P >= ( K + 8 ) * 4 + 12? Это сумма длин всех индексируемых полей справочника?

Несомненно, именно с этой проблемой для меня все решено. Я заблудился в трех соснах, как говорится. Спасибо Вам, Владимир. Глаза открыли.

Но все-таки остается вопрос: а почему все-таки размер индексного файла при реструктуризации вырастает до ~1Gb, а если эту же базу переиндексировать сразу после реструктуризации, то размер индексного файла приобретает вполне человеческий размер ~8Mb? Почему при реструктуризации и при "обычной" переиндексации получаются такие разные по размерам индексные файлы?
32. hogik 01.11.10 16:58 Сейчас в теме
(31)
1) "из чего складывается K в этой формуле P >= ( K + 8 ) * 4 + 12?"(с)
Сумма длин реквизитов, входящих в индексное выражение.
Например в DD Вашего теста есть текст:
I=VIP16 |VIP16 |0 |PARENTID,ISFOLDER,SP16(UPPER=128),DESCR(UPPER) |VIP16
Мы, выше по тексту, видим и складываем длины реквизитов:
PARENTID 9
DESCR 100
ISFOLDER 1
SP16 13
А "хитрое" выражение "(UPPER=128)" указывает системе переводить значение реквизита в больше буквы и обрезать до 128 символов, если реквизит длиннее 128 символов. Выражение "(UPPER)" - просто переводить в большие буквы.
2) "Отвечая одновременно и Вам, и Ish_2,"(с)
А мне это и так понятно. ;-) Это у Игоря (Ish_2) на все проблемы из "другой" жизни один ответ - "в 8.х всё уже сделано и все проблемы решены". Кроме "Рекурсии" запросами. ;-)
3) "остается вопрос: а почему все-таки размер"
Образно говоря. Очень - образно!
Реиндексация - это сортировка и запись упорядоченного множества в файл. А добавление записи в таблицу и внесение ключа в индекс - это вставка в уже упорядоченное множество и перестройка "указателей" на ключи или "перестановка" ключей.
Но, в случае 1С-а, есть еще одна проблема. В момент вставки ключа в индекс может возникать ошибка в "движке", аналогичная описанию от Advantage. И "движок" возвращает код ошибки в вызывающий модуль. Но этот код не проверяется в вызывающем модуле. Разработчики "1С 7.7", вообще НЕ проверяют коды возвратов после выдачи команд модификации данных БД в "движок". А продолжают работать по, ранее "выбранному", алгоритму невзирая на ошибку. И ошибка (искажение в информации БД) проявляется позже в совсем других местах и совсем неожиданным образом. :-(
33. 1Счик 01.11.10 17:13 Сейчас в теме
Владимир (hogik),
Спасибо за Ваш ответ. Вы мне очень помогли!
34. artbear 04.11.10 12:26 Сейчас в теме
35. mst 19.01.11 09:06 Сейчас в теме
столкнулся с аналогичной проблемой, ну до 2га у меня не дошло, остановилось на 168мб. но долго. а вот после обновления запускаю не переиндексацию, а выгрузку/загрузку данных. что-то она стала мне нравится в последнее время. например, после обрезки базы от старых доков база вырастает в 2 раза. выгрузил/загрузил, опа, уже меньше в 2 раза от старой т.е. в 4 раза от новой... а то ни переиндексации, ни техобслуживание с пакковкой не помогали...
36. Ёпрст 1031 19.01.11 11:43 Сейчас в теме
(0) в разы быстрее добавить поле руками, поправить мд, словарик, и тупо переиндексировать этот файлик.
И пофик там на количество записей и на индексное выражение, и на неправильную работу 1с-ины при реструктуризации.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Консультант-аналитик 1С
Москва
зарплата от 100 000 руб. до 170 000 руб.
Полный день

Программист 1С
Москва
Полный день

Программист 1С
Видное
Полный день

Программист 1С
Москва
зарплата до 120 000 руб.
Полный день