о размерах базы

Форум Программирование Общие вопросы программирования (Dev)

Платформа 1С v7.7

1. pisarevEV 8 13.03.15 09:06 Сейчас в теме

приветствую! просто из спортивного интереса хочу спросить: каков макс.размер (в архиве) БД ТиС DBF с которыми вы сталкивались. Я больше чем 1,1Гб сам не видел...

По теме из базы знаний

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. Ёпрст 1063 13.03.15 09:12 Сейчас в теме

21 ГБ в дбф (это *.dbf в каталоге базы), 70 активных пользователей.

5. dicwork 13.03.15 10:02 Сейчас в теме

(2) Ёпрст,
Бедный 1SJOURN :-)

3. Ёпрст 1063 13.03.15 09:18 Сейчас в теме

если быть точнее, 21,3 ГБ (22 938 139 863 байт)

4. varelchik 13.03.15 09:48 Сейчас в теме

(3)ЖЕСТЬ!

6. Ёпрст 1063 13.03.15 10:07 Сейчас в теме

(4) всё летает
(5) почему бедный ?

7. dicwork 13.03.15 10:22 Сейчас в теме

(6) Ёпрст,
Ну у нас в SQL базе днем около 50 пользователей (конфигурация бухгалтерия для Украины с дописанным самими производственным учетом и зарплатой) при массовом переформировании документов для выдачи заданий рабочим очень часто выводится сообщение "блокировка таблицы журналов".

9. Ёпрст 1063 13.03.15 12:14 Сейчас в теме

(7) у нас, практически нет блокировок, даже при массовом перепроведением доков одним из пользователей, обработкой, например. Которые в полный рост это используют.

И да, размер базы вообще не показатель.. ничего.

10. Gkmy 28 15.03.15 03:26 Сейчас в теме

(9) Да ладно!? Винчестеров 10Гб разве не застал? ;)

15. alexdm 18.03.15 00:04 Сейчас в теме

(9) Ёпрст,

И да, размер базы вообще не показатель.. ничего.

Угу, общий размер базы - не показатель, это точно. У меня тут у одних из новых в ПУБе регистр ПЗ разросся до ~2Гб (общий размер базы ~8Гб) - и, в итоге, возникли грабли, пока перевел временно на скуль, щас сворачиваю...

16. Frogger1971 18.03.15 00:05 Сейчас в теме

(15) alexdm, 120 - это много? две базы в этих размерах - тупят нещадно на 20-ти пользователях!
на 2003 + SQL2000

17. alexdm 18.03.15 00:09 Сейчас в теме

(16) Frogger1971, 120 - это что ? Размер dbf-файлов, или все вместе с индексами и ExtForms ? К тому же летает база или нет сильно зависит от конфы.

14. Frogger1971 17.03.15 23:17 Сейчас в теме

(6) Ёпрст,

всё летает

а в чем у вас заключается "лёт"?
и хотелось бы уточнить версию ОС, разрядность, процы и память

18. alexdm 18.03.15 00:23 Сейчас в теме

(14) Frogger1971, Я еще вам скажу - для 7.7 процы, память и прочее имеют некоторое значение на компе пользователя, да, но платформе уже 15 лет, поэтому все новые фишки ей скорее во вред, чем на пользу. На сервере - максимально быстрые диски, и все, в случае обычного мелкомягкого сервера. А, например, на том же самом Новелле у меня вполне себе неплохо работают 20 юзеров в бухгалтерии 7.7 и особо не жалуются. Но Новелл нужно уметь готовить...

19. Frogger1971 18.03.15 00:27 Сейчас в теме

(18) alexdm, это на Сиквелле, если вы считаете, что 120Гб на дбф - без извратов, то это один большой изврат

22. Ёпрст 1063 18.03.15 09:19 Сейчас в теме

(14) время проведения любого документа - измеряется в мс.
Конфа на основе комплексной, 2 плана счетов, введен упр. учет во все регистры.
Проц, так себе 24 ядра, оперативы не помню, гигов 64 что ле (лень смотреть)
Раньше был 10 рейд на sas дисках, щас воткнули ssd, в зеркале.
Конфу пришлось резать, ибо упёрлись в 2 гига на регистре, 1.8 еще более менее терпимо было, но 1.9 уже всё.
Время на переиндексацию -20 минут

26. varelchik 18.03.15 13:06 Сейчас в теме

(22) Не хило живем.
Нам бы такой сервант.

28. alexdm 18.03.15 20:06 Сейчас в теме

(26) varelchik, Ну а что вы удивляетесь, большому кораблю - большую торпеду, в смысле, что организация, судя по всему, немаленькая, поэтому и сервант соответствующий. У одних моих тоже подобная техника есть, УПП на 150 юзеров и ЗУП на 50 крутятся...

47. akita 23.03.15 17:30 Сейчас в теме

(28) alexdm, как-то слабо представляется такое сочетание: "большой корабль", дорогущий "сервант", 70 (активных!) пользователей и база на dbf... налицо как минимум неэффективное использование железа...

49. Frogger1971 23.03.15 23:03 Сейчас в теме

(47) akita, изначально "ущербность" в том, чтобы технологии 1996-1999 годов (по заставке 1С:7.7) "использовать" на железе минимум 2010 и рассказывать как оно прикольно работает....
если брать в чистом виде, то на 2000-ом Сиквелле, с его 4-мя сервис-паками или ограничением на размер dbf-файла, нормально база работать не может

56. alexdm 24.03.15 11:21 Сейчас в теме

(47) akita, Да почему бы и нет ? База там ТиС, которая сама по себе достаточно неплохо написанная конфигурация, плюс если прямые руки и все допилено для организации - нафига изобретать велосипед ? Ради красивых картинок в 8-ке ? А скуль на 7.7 в чистом виде без оптимизации - это только как средство обойти предел по размеру файла, dbf быстрее.

P.S. У нас тут работают в регионе пара достаточно крупных сетей магазинов - так у них 7.7, и ничо, не жалуются...

58. akita 24.03.15 12:17 Сейчас в теме

(56) alexdm, Почему бы и нет? То есть почему бы не использовать средства неэффективно? Я не говорю про "неэффективность" 77, я говорю о том что не стоит софтверные проблемы решать целиком за счет железа)) Логичнее выглядит цепочка dbf(smallServ)-sql(smallServ)-sql(bigServ)-sql(biggestServ), чем dbf(smallServ)-dbf(bigServ)-dbf(biggestServ), так как второй вариант часто выливается в dbf(smallServ)-dbf(veryveryverybigServ). И с точки зрения обслуживающего персонала казалось бы всё отлично: пользователи не жалуются, система не тормозит, деньги в серв конечно вбуханы немалые, но они же типа не мои))) А то, что конфа могла "также летать" и на серве за "в2разаменьшие" деньги, то это типа "Запас карман не ломит"?

З.Ы. И нет, dbf не быстрее

59. vasyak319 150 24.03.15 14:42 Сейчас в теме

(58) akita, это вы к тому, что за сервер платить надо, а вот работа программистов, полирующих базу до состояния, при котором она и на слабом сервере работает, достаётся совершенно бесплатно?

60. _Z1 38 24.03.15 14:46 Сейчас в теме

(59) Все важно.
важно и железо
и труд программистов
и еще важно правильно настроить железо и поддерживать его в хорошем состоянии.
просто от особенностей у кого-то какая-то часть может преобладать над другими.

61. akita 25.03.15 11:16 Сейчас в теме

(59) vasyak319, это я к тому, что 200 руб в железку + 0 руб программистам обычно менее эффективно чем 100 руб в железку + 100 руб программистам))). А дорогущий серв с базой на dbf это как раз 200 руб в железку и 0 программистам.

62. vasyak319 150 25.03.15 11:26 Сейчас в теме

(61) akita, пардоньте, невнимательно прочёл форум. "дорогущий серв с базой на dbf" это по-моему не 0 программистам, это программисты за что-то жестоко мстят.

63. akita 25.03.15 13:26 Сейчас в теме

(62) vasyak319, или там НЕТ программистов, что в общем-то сразу всё объяснило :о)

64. alexdm 27.03.15 22:44 Сейчас в теме

(58) akita,

З.Ы. И нет, dbf не быстрее

Позволю себе с Вами не согласиться, т.к. весь 15-летний опыт говорит об обратном. SQL в 7.7 - это костыль, который приставили для решения проблемы роста размеров файлов. В типовых конфигурациях от него больше зла, чем пользы, хотя, конечно, никто не отменяет удобство бекапа "на лету" средствами самого скуля, отсутствия необходимости реиндексации при некорректном завершении работы и так далее. Но - скорость работы в чистом DBF при наличии хорошего сервера с быстрой дисковой подсистемой накроет с запасом аналогичный вариант в SQL для большинства ТИПОВЫХ конфигураций, это проверено неоднократно, особенно проявляется на ЗиК и ПУБ. Да, если бы типовые были написаны хотя бы даже с использованием тех же примитивных, по сути, семерочных запросов, то результат, возможно, был бы иным (сам удивился, лет 10 назад, что простой перебор документов работал на SQL раз в 20 медленнее, чем простейший запрос с выборкой), но мы имеем то, что имеем.

65. _Z1 38 28.03.15 08:07 Сейчас в теме

(64) sql это просто sql .
Dbf это просто dbf
Если говорить об 1c как о клиете баз то фактически
1Cdbf и 1csql это два разых клиента скрытых под одной оберткой языка 1c
Многие не понимают что это фактически два разных языка
Которые внешне выглядят одинаково

Как бы нигде не утверждается что обертка для 1csql сделана оптимально
И когда делался 1csql исходили из принципа совместимости языка 1c
С тем что уже бвло написано

Но если самому оптимизирозать конфигурации то 1cdbf никогда не обгонит
По скорости и по производительности 1csql

66. alexdm 28.03.15 11:22 Сейчас в теме

(65) _Z1,

Но если самому оптимизирозать конфигурации то 1cdbf никогда не обгонит
По скорости и по производительности 1csql

С этим никто и не спорит, я речь веду ИСКЛЮЧИТЕЛЬНО о типовых конфигурациях, которые под SQL никогда специально не затачивались.

68. Ёпрст 1063 30.03.15 10:10 Сейчас в теме

(65) Обгонит и еще как.. Прямые запросы в дбф работают не хуже, чем в sql
^))

69. _Z1 38 30.03.15 10:38 Сейчас в теме

(68) Я знаю что у тебя сасая лучшая самописная 1с dbf бза.
но все равно не может dbf тяжвться с sql.
даже если и будешь влазить по размерам базы ну ника не потянет dbf 200-250 пользователей.
т.е. для dbf баз потолок масштабирования где-то 100 пользователей

71. Ёпрст 1063 30.03.15 11:10 Сейчас в теме

(69) у нас больше 70 не было, за это не скажу.
(70) 70 активных юзверей на дбф, это много или мало ?

73. vasyak319 150 30.03.15 12:02 Сейчас в теме

(71) Ёпрст, это много. И то, что у вас это работало, не говорит о том, что dbf это хорошо, даже если не брать такие приколы dbf, как "Что-то мне не понравилось, как меня выключили прошлый раз. Давайте запустим меня монопольно и переиндексируем." и невозможность онлайн-бэкапа.

67. Gkmy 28 28.03.15 23:39 Сейчас в теме

Кстати, о костылях (64). 8-ка с её языком запросов:

Процедура ЗапросВсехСтрокСоЗначениямиВсехСтолбцовТаблицы()
    Запрос = Новый Запрос(
        "
        | ВЫБРАТЬ
        |   *
        | ИЗ
        |   Справочник.Номенклатура
        |"
    );
 
    Результат = Запрос.Выполнить();
    ОткрытьЗначение(Результат.Выгрузить(ОбходРезультатаЗапроса.Прямой));
КонецПроцедуры

Показать

Только как ни крути, а 8-ка продолжает традицию использование костылей. И хотя они всё больше похожи на:

RS=СоздатьОбъект("ODBCRecordset");
RS.УстБД1С();
ТекстЗапроса="
|SELECT
|    Спр.Code as Код,
|    Спр.Descr as Наименование
|FROM
|    sc433 as Спр";
ТЗ=RS.ВыполнитьИнструкцию(ТекстЗапроса);
ТЗ.ВыбратьСтроку();

Показать

Желающие делать 1С++ для 8-ки найдутся навряд ли.

76. AlexO 135 30.03.15 16:38 Сейчас в теме

(67) Gkmy,

Желающие делать 1С++ для 8-ки найдутся навряд ли.

А ничего так, что платформа закрыта наглухо? В отличие от 7.7, где еще можно было покопаться и что-то доделать.

74. akita 30.03.15 16:32 Сейчас в теме

(64) alexdm,

Позволю себе с Вами не согласиться, т.к. весь 15-летний опыт говорит об обратном. SQL в 7.7 - это костыль, который приставили для решения проблемы роста размеров файлов.

Вы можете не соглашаться, но от этого dbf не станет быстрее sql, чему я, кстати, может быть был бы и рад :о)
В середине девяностых на бухии 6.0 с 10 мегабитной сеткой на коаксиале на полудуплексе еще было интересно ставить эксперименты "аля кто кого заборет, дбф или сиквел". Но те времена давно прошли...

75. AlexO 135 30.03.15 16:36 Сейчас в теме

(74) akita,

но от этого dbf не станет быстрее sql,

DBF принципиально быстрее SQL на выборках и поиске. Но проще в администрировании (т.е. более "примитивен"), и менее отказоустойчив.
(73) vasyak319,

не говорит о том, что dbf это хорошо

Для 1С - это "отлично". Это, на чем надо было делать 8-ку. Это именно тот простой и "быстрый" формат, где 1С ничего особо делать не надо было, чтобы достигнуть результатов - к чему она и стремилась всегда.

77. alexdm 30.03.15 17:12 Сейчас в теме

(74) akita,

Вы можете не соглашаться, но от этого dbf не станет быстрее sql

Это вы моим клиентам расскажите, у которых на SQL форма ввода пенсионного стажа в ЗиКе открывается 10 минут на скуле и 10 секунд в dbf на одном и том же железе. Да и вообще примеров масса - SQL надежнее, отказоустойчивее, но никак не быстрее. Это 1С в свое время лапшу любил на уши вешать, как SQL заточен под большие предприятия и как он быстр...

78. _Z1 38 30.03.15 17:18 Сейчас в теме

(77) Если сам расчет в 1с sql версии безобразно реализован
из этого не следует вывод что сам sql плохой и что sql медленный

80. AlexO 135 30.03.15 17:43 Сейчас в теме

(78) _Z1,

из этого не следует вывод что сам sql плохой и что sql медленный

Вам еще раз говорят - SQL медленнее на примитивных операциях выборки.
Потому что.
Потому что - другая структура, потому что - DBF более "нормализован", потому что...

81. _Z1 38 30.03.15 20:41 Сейчас в теме

(80) Ты сам то понял что написал.
Нормализована по каким-то правилам может быть какая-то логическая схема.

как бы наоборот при хорошем запросе sql обгонит dbf за счет гораздо лучшего
оптимизатора запросов.

Как бы исторически сначала была 1c dbf.
потом появилась 1с sql, причем пошли по пути наибольшей совместимости
с тем что уже было естественно за счет качествва.
т.е. в стандартной реализации 1с sql сделан через промежуточную таблицу (ТЗ куда дергаем по одной записи),
что на самом деле не нужно.

Эврика.
Я понял почему мы не понимаем друг друга
потому что Вы говорите ( и мыслите в терминах )
стандарного 1с sql

я же пишу о
1с sql плюс 1с++

Так что скорее всего мы оба правы.

тогда мое утверждение превращается в :

1с sql и 1с++ при правильном его использование намного быстрее
чем любой другой вариант 1с sql стандартный или любой 1с dbf

82. AlexO 135 31.03.15 09:48 Сейчас в теме

(81) _Z1,

1с sql и 1с++

А тут и спорить нечего. Собственно, 1С++ для этого и писался - "ускорить и углубить" базы на SQL. Суть - возможность писать те самые "черные" запросы.
Но это, опять же - "любительские" доработки.
А по 1С в общем - остаюсь при мнении: 1с надо было развиваться на основе DBF - все уже есть, быстро, недорого, и практически никаких усилий от них: используй готовое, с 40-ка летним опытом.

84. akita 31.03.15 09:51 Сейчас в теме

(82) AlexO,

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

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

86. AlexO 135 31.03.15 09:56 Сейчас в теме

(84) akita,

В многопользовательтских - это даже теоретически невозможно.

Возможно. И масса баз на DBF (как в 1С, так и не в 1С - на той же Дельфи) работают многопользовательски.
Главное - правильно разрулить чтение-запись таблиц.
Ведь что есть "регистры" 1С? Суть - это попытка "обегчить и убыстрить" доступ и выборку данных из обычных реляционных таблиц. Идея - замечательная, реализация - лучше не говорить о реализации чего-либо у 1С. Это нетактичный вопрос )
А конкретно в DBF - управление "блокировками" и ускорение чтения-записи достигается путем правильного планирования структуры, количества самих таблиц, и разбивкой данных на более мелкие таблицы.

87. akita 31.03.15 13:41 Сейчас в теме

(86) AlexO,

[IS-QUOTE] Ввод сведений о стаже в ЗиК на SQL

Открытие отчета - зависит от количества обрабатываемых данных: чем их больше, тем больше время выполнения запроса. [/IS-QUOTE]

Посмотрите внимательнее о каком отчете идёт речь, сразу станет всё понятно, если "вы в теме".

И масса баз на DBF (как в 1С, так и не в 1С - на той же Дельфи) работают многопользовательски.

Дельфи + dbf - только в случае портирования досовских "фокспрошных" или "клипперовских" программ ( в конце 90ых-начале "нулевых" это было очень востребованное занятие). Как основная СУБД при разработке многопользовательского проекта? Упаси боже. dBase изначально однопользовательская СУБД. Потом были попытки "приобщиться к многопользовательности". Но не получилось. Потом появился FoxBASE, тоже на dbf. Там всё было много лучше с этим делом, поэтому его и купила Microsoft. И как думаете, в каком продукте воплотились все многопользовательские наработки dBase и FoxBASE????

88. AlexO 135 31.03.15 16:06 Сейчас в теме

(87) akita,

Дельфи + dbf - только в случае портирования досовских

Отнюдь, для небольших приложений это была очень удачная связка.

Как основная СУБД при разработке многопользовательского проекта?

Если проект уровня 1С - то к уровню "Дельфи + dbf" нужно еще стремиться и стремиться, и лучшего не придумать.

dBase изначально однопользовательская СУБД.

ДОС с поддержкой сети - многопользовательская или однопользовательская? Заметьте, мы не про "многозадачность".

Потом появился FoxBASE, тоже на dbf.

Это и есть DBF с чуть расширенным заголовком файла.
И, кстати, весьма удачный в плане масштабируемости, легкости обработки, и скорости. "Потому что DBF" в основе.

Там всё было много лучше с этим делом, поэтому его и купила Microsoft

Вот как раз у MS был свой клон DBF (именно клон, а не расширение) - MDF. И свой продукт - Access. А Фокс - был конкурент. Последнее звено понятно?

И как думаете, в каком продукте воплотились все многопользовательские наработки dBase и FoxBASE????

Если вы про "воплотились в SQL", то вас можно отослать только читать википедию: что такое dBase, SQL, T-SQL, MS SQL, PL SQL и прочие интересные названия.

89. akita 31.03.15 17:30 Сейчас в теме

(88) AlexO,

Зачем мне читать wiki, если большая часть перечисленного прошла "у меня на глазах". А вот для вас, пожалуй, процитирую

xBase — собирательное название семейства dBase-подобных языков программирования и программных продуктов, являющихся производными РСУБД dBase, с расширенной по отношению к ней функциональностью. Были предназначены для разработки баз данных в архитектуре файл-сервер, сначала в однопользовательском режиме, затем со слабой поддержкой многопользовательского под управлением DOS, без поддержки ссылочной целостности.
Первая версия оригинального dBase была разработана в начале 1980-х годов компанией Ashton-Tate. Затем, в середине 1980-х возникли новые, близкие по совместимости по коду и открытому[источник не указан 1995 дней] формату файлов данных DBF (но не по формату хранения мемо-полей) продукты Clipper. После этого появляется собственно сам термин xBase, означающий «подобный dBase».
В 1984 году фирмой Fox Software был разработан продукт FoxBASE отличавшийся значительно большей скоростью обработки данных в сравнении с конкурентами. Позже компания Fox Software (разработчик Foxbase) выпустила продукт FoxPro v1.0, чуть позже v2.0, продукт отличался высокой скоростью обработки информации, использовались SQL и прорывная технология Rushmore, объектное программирование. Microsoft купила Fox Software вместе с его технологиями. Позже, Microsoft переносит современные технологии реализованные в FoxPro в свои продукты MS SQL Server и MS Access.

Складывается впечатление, что Вы не совсем (или совсем не) понимаете термин "многопользовательская СУБД" и не отличаете слабую поддержку многопользовательского режима от, например, полной поддержки такового. Вы программировали базы данных на FoxPro, Клиппере на dbf, dbf и paradox на Delphi в многопользовательских режимах или просто теоретизируете?

113. AlexO 135 31.03.15 23:27 Сейчас в теме

(89) akita, не знаю, что там у вас на глазах, но если вы цитировали статью - значит, её писали вы или такой же, как вы.
Осторожно, английский:
"In spite of growing pressure to evolve, in the early 1990s xBase products constituted the leading database platform for implementing business applications."
http://en.wikipedia.org/wiki/DBase
Это значит, что СУБД dBase - был лидер СУБД, в котором работали и как один, так и множество пользователей.
Что вы путаете многозадачность и многопользовательность - ваши проблемы. Доступ к одному файлу, разруливаемый сейчас на SQL - прекрасно обходился в dBase разбивкой на множество файлов.
Так что по вашим глазам просто потоптались.

114. AlexO 135 31.03.15 23:37 Сейчас в теме

(89) akita,

Позже, Microsoft переносит современные технологии реализованные в FoxPro в свои продукты MS SQL Server и MS Access.

Это только вы могли написать. FoxPro еще худо-бедно потомок dBase, в Access Майкрософт уже максимально ушли от него, и с большой натяжкой точнее будет, что современный SQL - на наработках (а не технологиях) Access выстроен. А на самом деле - это итог развития T-SQL и разработок Sybase. Это что касается MS SQL.
А сам SQL ANSI развивался параллельно с dBase и конкурировал с ним, сначала был трансформирован MS в T-SQL (с чего и начался сам MS SQL, собственно), а потом появились и СУБД SQL.
И, кстати, не MS является инициатором разработок СУБД SQL, а Oracle. И, собственно, это и видно по гигантскому разрыву в производительности "двух SQL".
Ну, а вы можете и дальше считать, что DBF и SQl - это одно и то же. Вам - не возбраняется.

115. akita 01.04.15 10:26 Сейчас в теме

(114) AlexO,

Это только вы могли написать.
Ну, а вы можете и дальше считать, что DBF и SQl - это одно и то же. Вам - не возбраняется.

Не несите чепухи, это была цитата из wiki
https://ru.wikipedia.org/wiki/XBase

Где я писал что dbf и sql это одно и то же?
Я уже понял, что программированием баз данных вы никогда не занимались, поэтому дальнейшее Ваше теоретизирование по этому вопросу считаю бесполезной тратой времени.

91. alexdm 31.03.15 19:52 Сейчас в теме

(78) _Z1, Да причем тут расчет - тупая выборка из справочника большого объема тормозит, вот в чем дело...

92. _Z1 38 31.03.15 20:15 Сейчас в теме

(91) Приведите здесь текст запроса который тормозит.
Если по каждой строке считаь остатки да еще не совсем оптимальнвм способом - конечно будет тормозить.Более определенно что у Вас не так сказать затруднительно.

93. alexdm 31.03.15 20:53 Сейчас в теме

(92) _Z1, Там нет запроса - там просто выборка из справочника средствами встроенного языка с отбором по владельцу, код что для дбф, что для скуля идентичный, справочник достаточно некислого размера (грубо 60 записей на человека в год x 11 лет x в среднем 600 человек = порядка 400000 записей) - думаю, что смысла приводить эту простейшую конструкцию нет никакого. Никаких остатков там не считается, там считать нечего, хранится период, код позиции списка и особых условий труда, все это выводится в таблицу в режиме ввода данных...

94. _Z1 38 31.03.15 21:09 Сейчас в теме

(93) так приведи текст запроса.
Если переписать через 1с++ и с типизацией то и получишь скорость.
Сейчас же скорее всего из sql дергается все построчно скидывается в промежуточный
dbf и потом тебе отображается.
Как бы мы о разном. Ты говоришь как все плохо сделано в sql и dbf быстрее.
я говорю что можно переделать в 1с sql и тогда точно будет быстрее работать.
Как бы мы о разном говорим.

96. alexdm 31.03.15 21:34 Сейчас в теме

(94) _Z1, (94) _Z1, Да что ты прицепился к 1с++ - я же уже написал чуть выше, что пробовал сделать то же самое через него - ясен пень, это быстрее. Речь идето том, что в СТАНДАРТНОЙ реализации типовых конфигураций (а на них работает большинство пользователей) этой оптимизации под скуль нет и в помине, все пишется универсально, как для скуля, так и для дбф, пожтому на ТИПОВЫХ априори скуль медленнее в большинстве случаев.

97. _Z1 38 31.03.15 21:42 Сейчас в теме

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

а на них работает большинство пользователей

не факт кто работал только на типовых давно уже на v8

99. alexdm 31.03.15 21:53 Сейчас в теме

(97) _Z1,

не факт кто работал только на типовых давно уже на v8

Если бы все так было просто - если изменений в типовой немного, то да, давно у меня уже на 8, а вот у одних оставшихся - в типовой 7.7 переделано было овердохрена, только в ЗУП 3.0 наконец появилось то, что нужно, но она пока еще сырая донельзя. К тому же, я с трудом себе представляю самописную "зарплату" в случае более-менее крупного предприятия.

95. _Z1 38 31.03.15 21:25 Сейчас в теме

(93) Смысл приводить есть.
В качестве упражнения проследи какие команды идут на sql сервер ( тогда сам все и поймешь)для кода :

Спр1 = СоздатьОбъект("ПодчиненныйСправочник);
Спр1.ИспользоватьВладельца(ГлЭлемент);
Спр1.ВыбратьЭлементы();
Пока Спр1.ПолучитьЭлемент() = 1 Цикл
КонецЦикла;

этот простенький код для твоего прмера генерирует 400000 sql запросов
хотя достаточно одного.

Если у тебя используется такая конструкция то даже переписав ее даже
через Запрос = СоздатьОбъект("Запрос"); получишь значительный выигрыш по скорости.

Еще раз в одном языке 1с 77 по сути спрятаны два различных языка
один язык 1с ddbf
другой язык 1c sql.

т.е каждый оператор языка 1с по разному транслируется на эти языки имееет разную производительность и.т.д
но так как сам язык 1с предприятия 77 достаточно простой то можно понять
что делает каждый оператор для каждого из этих языков.
и тогда ты будешь по разному писать если пишеьб на 1с dbf
или на 1c sql

PS
есть еще и третий язык
1c sql плюс 1с++
я просто по умолчанию оперирую только им и мне уже трудно оперировать ограничниями предыдущих языков ( хотя писал,пишу на всех трех )

79. AlexO 135 30.03.15 17:42 Сейчас в теме

(77) alexdm,

как SQL заточен под большие предприятия и как он быстр...

Это у них птомственное - "1С заточен под большие предприятия и как он быстр..."
1С, кроме ля-ля и поделок-концепций, ничего так и не предоставила за 20 лет на рынке.

83. akita 31.03.15 09:48 Сейчас в теме

(77) alexdm,

Это вы моим клиентам расскажите, у которых на SQL форма ввода пенсионного стажа в ЗиКе открывается 10 минут на скуле и 10 секунд в dbf на одном и том же железе.

Ввод сведений о стаже в ЗиК на SQL открывается меньше секунды (специально только что проверил)... Клиент всегда выбирает сам: ждать ли ему 10 сек на dbf или один раз пригласить специалиста настроить SQL сервер и ждать всего 1 сек)))

85. AlexO 135 31.03.15 09:52 Сейчас в теме

(83) akita,

Ввод сведений о стаже в ЗиК на SQL

Открытие отчета - зависит от количества обрабатываемых данных: чем их больше, тем больше время выполнения запроса.
Это как в 8-ке: московские одноэсники кричат о "миллионах строк регистров" у них "в базах" и "превосходной производительности 1С", когда на самом деле - у них одновременно обрабатываются 100-200 тыс строк максимум, а остальные "миллионы" - просто лежат мертвым грузом "до востребования".
Ну то есть люди даже не знают, с чем работают на самом деле.

90. alexdm 31.03.15 19:49 Сейчас в теме

(83) akita, Угу, особенно когда базе 11 лет и у 90% сотрудников по полтора десятка записей о стаже в квартал, а все это хранится, как известно, в служебном справочнике. А уж как настроить SQL - это я как-то в курсе. Смеха ради пробовал переписать на 1С++ тогда да, даже быстрее дбф, что, в принципе, вполне прогнозируемо. Если бы это было одним узким местом, можно бы было это так и оставить, но, по уму, там надо как минимум процентов 30 кода переписывать, так что уж лучше уйдем на 8-ку со следующего года, тем более, что в 3.0 появились почти все плюшки, которые доделывал а 7.7 для этого клиента.

116. akita 01.04.15 12:06 Сейчас в теме

(90) alexdm,

Угу, особенно когда базе 11 лет и у 90% сотрудников по полтора десятка записей о стаже в квартал, а все это хранится, как известно, в служебном справочнике.

Уже больше из спортивного интереса уточню для себя: мы говорим о форме ввода стажа, которая вызывается из сотра по кнопке "Ввод данных"?
Может мы о разных формах говорим или у Вашего клиента какая-то самописная форма для этого? Просто именно у этой формы от срока жизни базы мало что зависит. С 2010 года справочник новый, и с 2014 новый... Может мы о каких-то разных формах и справочниках говорим? У меня есть база 14 летняя, с вредным производством, и невыходов и людей полно, у особо одаренных по 25-30 строк в квартал набегает, но никаких проблем с открытием и заполнением никогда не возникало...

119. alexdm 01.04.15 16:19 Сейчас в теме

(116) akita,

Уже больше из спортивного интереса уточню для себя: мы говорим о форме ввода стажа, которая вызывается из сотра по кнопке "Ввод данных"?

Да, именно она. Кстати, с размерами несколько погорячился, там, действительно, несколько справочников для разных лет, сейчас посмотрел - в общем-то, чуть больше 5000 записей с 2014 года, на дбф - ~10 секунд, на SQL - порядка 3 минут, если брать с 2010 года - то ~5 минут, железо сейчас строит получше, раньше было тормознее...

120. alexdm 03.04.15 22:08 Сейчас в теме

(116) akita, Уже для себя, опять-таки "из спортивного интереса" - загрузил сегодня для теста базу еще одних клиентов (медики, там тоже хватает данных о стаже) в скуль,все настройки типа отключения Named pipes, включения AWE и прочего идентичны, потестил - получил примерно сопоставимые результаты с предыдущими, хотя уже и на своем "железе", которое оставляет желать много лучшего, но уж какое есть.

27. alexdm 18.03.15 20:04 Сейчас в теме

(22) Ёпрст,

Раньше был 10 рейд на sas дисках, щас воткнули ssd, в зеркале

SSD это вообще наше все, у меня ЗиК у клиентов тормозил на 2хSCSI-320 в зеркале нещадно, пришлось даже переводить расчетчика в терминал, сейчас бухию перевел на 3.0, поставил 2 SSD в зеркале, теперь и ЗиК вполне приемлемо работает по сети...

35. Frogger1971 21.03.15 01:01 Сейчас в теме

(27) alexdm, прёт такие фразы

2хSCSI-320 в зеркале нещадно, пришлось даже переводить расчетчика в терминал

вам никто не говорил, что уже много лет существуют другие интерфейсы для подключения жестких дисков? ключевое слово - "много"

и как вы в одном компе со Скази вставили SSD?

38. alexdm 21.03.15 01:28 Сейчас в теме

(35) Frogger1971,

вам никто не говорил, что уже много лет существуют другие интерфейсы для подключения жестких дисков? ключевое слово - "много"

Ключевое слово здесь - "сервер куплен в 2008 году", правда, я этого не написал, тогда SAS еще был экзотикой, к тому же, SCSI-320 диски на 10к, которые там стоят на контроллере Adaptec PCI-64, порвут в тряпки по скорости почти любой нынешний SATA (есть, правда, WD Raptor SATA-III на 10к у одних моих клиентов, но сравнить производительность не получится у меня при всем желании, да и результат вполне прогнозируем).

и как вы в одном компе со Скази вставили SSD?

Ну это уже совсем элементарно - сейчас на любой современной материнке есть порты SATA-III, причем с возможностью сделать аппаратный RAID - подключай и юзай, я, правда, в этот аппарат сунул отдельный SATA-контроллер, т.к. на матери был только SATA-II, для SSD не гуд - не пойму, в чем проблема-то заключается ? Судя по вашей логике, если в комп воткнуть скази, то другие винты там жить не смогут априори, так что ли ?

39. Frogger1971 21.03.15 01:58 Сейчас в теме

(38) alexdm, ключевой вопрос вообще-то, если есть Скази, то разъемов под САТА, САТА-новая галактика )))), ССД - априори быть не может! )))))
определим понятия - SCSI, SAS, SATA - я правильно понял? ой, добавлю еще Fiber Channel

42. alexdm 22.03.15 18:48 Сейчас в теме

(39) Frogger1971,

если есть Скази, то разъемов под САТА, САТА-новая галактика )))), ССД - априори быть не может! )))))

Да что вы говорите ? Вы, извиняюсь, скази-то сами вживую видели ? Повторюсь, в моем случае SATA был даже на плате, причем с аппаратным RAID, но старый, поэтому вкорячил внешний SATA-III контроллер, SCSI-320 -на PCI-64 внешнем контроллере Adaptec (кто в курсе,тот знает - дорогая и качественная железка) - в 2008 году вполне себе еще можно было купить обычный SCSI, в брендовых серверах (у моих DEPO) - так вообще в полный рост, хотя они уже отмирали, да.
P.S. - Вы немного почитайте, если сами в живую не видели, прежде чем писать заведомую херь, оно иногда полезно.

43. Frogger1971 22.03.15 21:59 Сейчас в теме

(42) alexdm, будем говорить, что последний скази я видел на брендовом серваке выпущенном в 2007-ом году, тогда уже в полный рост применялись САСы и Скази был решением купить "недорогой" сервак (потому что никто не хотел их покупать)

45. alexdm 23.03.15 08:57 Сейчас в теме

(43) Frogger1971,

будем говорить, что последний скази я видел на брендовом серваке выпущенном в 2007-ом году

А SATA-I появились где-то так году в 2003-2004-м, SATA-II ненамного позже, где-то в 2005-м, какие еще вопросы про новые галактики ? К тому же, понятие "внешний контроллер" до вас, похоже, вообще не доходит, так что не поленитесь, подтяните все-таки матчасть...

33. Frogger1971 21.03.15 00:55 Сейчас в теме

(22) Ёпрст, ключевое слово для твоей базе - SSD - при оптимизированной конфе - не 15-20, а часто и все 60-80 процентов ускорения..
а, еще, если перед єтим написать "свёрстку" не нужного - то, согласен должна "летать"

36. alexdm 21.03.15 01:05 Сейчас в теме

(33) Frogger1971,

Ёпрст, ключевое слово для твоей базе - SSD - при оптимизированной конфе - не 15-20, а часто и все 60-80 процентов ускорения..

Ну дык о чем и речь... Я тут уже писал как-то, что нещадно тормозившая ЗиК получила новую жизнь на SSD.

а, еще, если перед єтим написать "свёрстку" не нужного - то, согласен должна "летать"

Если речь идет о Бух 7.7, то там и писать ничего не надо особенно - штатный wrap.ert вполне адекватен.

46. Ёпрст 1063 23.03.15 13:39 Сейчас в теме

(33)

Ёпрст, ключевое слово для твоей базе - SSD - при оптимизированной конфе

НЕТ. Летало всё и до перехода на ssd.
SSD- это просто выеб..он и проверка новых технологий, не более.

50. Frogger1971 23.03.15 23:05 Сейчас в теме

(46) Ёпрст, вопрос в том, что подразумевается под "летает" - обрезки баз делаете регулярно? dll-ок сторнних (1c++, turbobl, formex, romix) сколько используется?

53. Ёпрст 1063 24.03.15 10:57 Сейчас в теме

(50) см (22).
Всё работает и ДО оптимизации на прямые запросы.

55. vasyak319 150 24.03.15 11:16 Сейчас в теме

(50) Frogger1971, тщательное проектирование и разработка руками, растущими из плеч, позволяет творить чудеса. В 2007 году на одном большом-пребольшом заводе видел БД (производственный учёт и торговля, проприетарная) на 7.7, в которой одновременно работало 350-500 пользователей. Никаких тормозов, никаких нетиповых приблуд, типа 1С++

37. Frogger1971 21.03.15 01:08 Сейчас в теме

(22) Ёпрст, вы у нас большой спец

Проц, так себе 24 ядра, оперативы не помню, гигов 64 что ле (лень смотреть)

как-то тяжело сходяться цифры - 24 ядра и всего 64-ре оперативы.....
....сервер 96 Гб - 18 потоков, двухюнитовый, 18-ть САСов....
если у вас есть 24 ядра, то дайте, пожалуйста ТаскМенеджера картинку загрузки этих потоков....

11. antares2010 17.03.15 14:04 Сейчас в теме

(3) Ёпрст,
Как вам это удалось? Насколько мне известно ограничение платформы - 2Гб на dbf файл.

12. varelchik 17.03.15 14:09 Сейчас в теме

(11) а вы что думаете у него 10 файлов?

8. klinik 13.03.15 10:30 Сейчас в теме

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

13. varelchik 17.03.15 14:10 Сейчас в теме

ну и вообще для SQL формата то и вообще ограничения лишь на размеры винтов.

20. alexdm 18.03.15 00:33 Сейчас в теме

Здесь речь идет о DBF, SQL - это отдельная песня, размер вашей базы в сиквеле вообще ни о чем не говорит, в DBF ваша база будет на порядок меньше, это если вообще загрузится.
Да, и какая у Вас конфа ?

21. antares2010 18.03.15 09:12 Сейчас в теме

Есть ли рецепт по увеличению порога в 2гб на Dbf файл?

23. Ёпрст 1063 18.03.15 09:20 Сейчас в теме

(21) есть.
Либо переход на адвантадже, либо скуль, либо свёртка

29. vasyak319 150 18.03.15 20:23 Сейчас в теме

(21) antares2010, нужна сущая мелочь - придумать, как запихнуть в знаковую 32-битную переменную число больше 2^31.

24. FractonKireyev 18.03.15 09:27 Сейчас в теме

На моей практике больше 10 ГБ на базу начинает тормозить. Это было на разных клиентах.

25. Ёпрст 1063 18.03.15 09:30 Сейчас в теме

Сервак на 2003, среднее количество доков в день ~2000

30. CheBurator 3119 18.03.15 21:30 Сейчас в теме

6гб дбф, десяток активных пользователей. Вообщем ничего не тормозит, сервер нормальный настоящий (как не тормозило на серваке в виде пня4 с 2Гб оперативы). Пока склад не перевели на отдельную ВМС - в базе одноврменно сидело свыше 30 юзверей (с 10 активных, до 15 ТСД, несколько неактивных бухов) - точно также ничего не тормозило.
Самый большой файл - документ.ЗаявкиПокупателей - подбирается под полтора гига уже. А вообще около 4 файдлов да.т практически 40=50% размера базы

32. alexdm 18.03.15 23:49 Сейчас в теме

(30) CheBurator, Не озвучена конфа, операционка сервера, и тип дисков... Например, моей самописке на 7.7 для склада с десятком документов и тремя регистрами вообще ничего не страшно, на третьем пне работать будет... :)))

40. CheBurator 3119 21.03.15 04:25 Сейчас в теме

(32) Внимание, озвучиваю: ТиС 9.2, оперативы вроде сейчас стоит 32, диски сказевые, в зеракло три рейда - один под систему, второй под базы, тритй файлопомойка, осб - винсервер2003 (все это же крутилось года четыре на пне-4 с 2-гигами). Сейчас тут же крутится скуль с семерочной базой и клиенты 8-ки с кластером, сама восьмерочная база на скуле в другоймашине

34. Frogger1971 21.03.15 00:59 Сейчас в теме

(30) CheBurator, в клюшках размер базы не определяющая состовляющая - априори, есть ограничени дбф, даже со всеми извратами...
просто нормальный программер думает головой, что дальше или вариант "свёрстки" базы, всё чаще и чаще или перехода на снеговика
...ну, в лучшем случае, разделения задач и использование УРБД... хотя при 30-ти пользователях - это смешно

41. CheBurator 3119 21.03.15 04:27 Сейчас в теме

(34) я тебе так скажу - когдла вертелось на серваке 30-35 юзверей суммарно в двух базах (торг и бух на клюшках) - удвоить это количество без существенных затруднений - вообще было бы без проблем. Даже оптимизировать бы ничего не стал.

31. CheBurator 3119 18.03.15 21:33 Сейчас в теме

Транзакции иногда бывают, но редко и нечувствительно. Никаких оптимизаций и выкрутас не проводилось.

44. pisarevEV 8 23.03.15 06:17 Сейчас в теме

позволю себе вопрос: можно НЕ создавая новый объект метаданных (например ЗаявкаПокупателя_Новая) "переключить" запись текущих документов (ЗаявкаПокупателя) в ДРУГИЕ таблицы dbf (когда размер "старых" станет близким к критичному)?

48. Gkmy 28 23.03.15 18:41 Сейчас в теме

[quote]
позволю себе вопрос: можно НЕ создавая новый объект метаданных (например ЗаявкаПокупателя_Новая) "переключить" запись текущих документов (ЗаявкаПокупателя) в ДРУГИЕ таблицы dbf (когда размер "старых" станет близким к критичному)?
[/quote]

(44) предположу, что простым переключением вопроса в полной мере не решить.

51. pisarevEV 8 24.03.15 07:26 Сейчас в теме

(48) Gkmy, это понятно, просто предположил что возможно есть такой "вариант решения"))

52. _Z1 38 24.03.15 08:56 Сейчас в теме

(44) Так делать ни вкоем случае нельзя.
нарушаете первую нормальную форму. Одно поле - одна сущность.

Как бы или режте базу или переходите на sql

Оставьте свое сообщение

E-mail: