По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(11) Верно, без реквизитов, без доп. отборов и сортировок, а используется исключительно в экспериментальных целях
Количество элементов (10) подсчитано за 86 741 мсек процедурой:
Тем не менее сути это не меняет
Количество элементов (10) подсчитано за 86 741 мсек процедурой:
Справочник=СоздатьОбъект("Справочник.Новый1");
КоличествоЭлементов=0;
Справочник.ВыбратьЭлементы(0);
Пока Справочник.ПолучитьЭлемент(1)=1 Цикл
КоличествоЭлементов=КоличествоЭлементов+1;
КонецЦикла;
Сообщить(КоличествоЭлементов);
ПоказатьТем не менее сути это не меняет
Это решение
(13) Gkmy, какой сути-то? что перебором, не выполняя никаких действий, можно "пробежать" по справочнику без реквизитов, монопольно за 1,5 минуты? Круто, чо. Только у ТС немного сложнее справочник, + подчиненные ему, + он видимо используется как измерение регистра и/или субконто, в реальной базе с несколькими работающими пользователями.
Это решение
(15) Простой.. сути. Ничто не мешает ТС и прочим разработчикам для DBF-базы загрузить и спользовать , а таким образом получать тоже самое КоличествоЭлементов (13) или производить иные манипуляции, в т. ч. и "пробежать" по справочнику без реквизитов (16) НЕмонопольно, но уже за 119-123 мсек.
Как бы то ни было, возвращаясь к вопросам о производительности (0), использование такого справочника (10) (13) в качестве измерения регистра (15) малозначительно влияет на скорость проведения документа в зависимости от размеров справочника, количества документов и количества подключенных пользователей, а именно при разнице 1 элемент 1 документ и 289 300 элементов 580 400 документов прирост составляет 0-9 мсек, причём используя только штатные методы пере- и проведения.
Как бы то ни было, возвращаясь к вопросам о производительности (0), использование такого справочника (10) (13) в качестве измерения регистра (15) малозначительно влияет на скорость проведения документа в зависимости от размеров справочника, количества документов и количества подключенных пользователей, а именно при разнице 1 элемент 1 документ и 289 300 элементов 580 400 документов прирост составляет 0-9 мсек, причём используя только штатные методы пере- и проведения.
Это решение
(2) O-Planet,
Бред сивой кабылы в ясную лунную ночь ...
В аптечных базах в справочнике товаров десятки тысяч позиций, в справочнике внутренних штрих-кодов - сотни тысяч, в журналах документов (с 2000-2001 годов) сотни тысяч документов, базы ДБФ, работают на всяком компьютерном хламе - никаких проблем со скоростью работы не наблюдается. Что я делаю не так?
Есть типовые ТиС доработанные под торговлю автозапчастями. В справочнике Номенклатура не менее 50000 позиций. Пришлось намного переделать подбор чтобы показ остатков (и показ аналогов и остатков аналогов и еще куча всяких расчетных сложным путем данных из итогов) не тормозил поиск/скроллинг. Все летает. Может, у меня 2 правых руки и одна запасная левая?
Для таких объемов данных 1С не предназначена (по крайней мере, 7.7 и не sql)
Бред сивой кабылы в ясную лунную ночь ...
В аптечных базах в справочнике товаров десятки тысяч позиций, в справочнике внутренних штрих-кодов - сотни тысяч, в журналах документов (с 2000-2001 годов) сотни тысяч документов, базы ДБФ, работают на всяком компьютерном хламе - никаких проблем со скоростью работы не наблюдается. Что я делаю не так?
Есть типовые ТиС доработанные под торговлю автозапчастями. В справочнике Номенклатура не менее 50000 позиций. Пришлось намного переделать подбор чтобы показ остатков (и показ аналогов и остатков аналогов и еще куча всяких расчетных сложным путем данных из итогов) не тормозил поиск/скроллинг. Все летает. Может, у меня 2 правых руки и одна запасная левая?
Это решение
Стоит ли справочник застрахованных лиц делать подчиненным договорам страхования?
Возможно стоит договора страхования переделать в документ.
Снизит ли это производительность?
Производительность чего именно?
По застрахованным будет большое количество информации: к каким больницам прикреплен, когда прикреплен, когда откреплен, набор возможных услуг, обращения, диагнозы, стоимость лечения и пр. Думаю, организовать всю эту инфу в оборотный регистр, и оттуда получать данные (есть другие варианты?) или же организовать подчиненные справочники? Сильно ли скажется это на произоводительности?
Почему в оборотный?
Кроме выше указанных вариантов: подчиненный справочник, оборотный регистр — возможны:
- справочник,
- документ,
- регистр остатков,
- перечисление.
Опять же, производительность чего именно?
Как посоветует организовать БД. Кто-нибудь сталкивался с автоматизацией ДМС?
Сталкивался и автоматизировал отдельные элементы этой непростой на первый взгляд деятельности. Поэтому прежде чем давать практические советы, рекомендую более полно изложить ситуацию, а также задачи возлагаемые на разрабатываемую БД.
Это решение
Согласен, (14) - в теме излишнее. Тем не менее vitn (8), Ta_Da (11) и возможно не только они, не вняли прописным истинам и в сумраке своего неведания настаивают на обратном, чем и порождают излишние высказывания.
Это решение
(18) Gkmy, ну да, ну да. Сначала реализовывать задачу в неподходящей среде, а потом чтобы работало навешивать поверх слабодокументированные и не обновляемые сторонние ВК. Круто, чо. Витайте дальше в сиянии своей мудрости.
P.S. Кошки рулят писал о том, что Вы советы даете автору, который вопрос задал 7 лет назад.
P.S. Кошки рулят писал о том, что Вы советы даете автору, который вопрос задал 7 лет назад.
Это решение
По поводу безграничных возможностей 7.7 и ВК (20) спорить пустое, равно как и сомневаться в возможностях, официальности, поддержке и пр. Однако интересно другое, что например (10,13 и прочие иже с ними) способны предложить в качестве альтернативы? Уж не 8.х ли.. бездарно перенявшую эстафету ;)
Это решение
Вот только подчиненные справочники договоров... Очень плохая идея. Есть конфигурации для страховых компаний ВГДБ: Страхование, если не ошибаюсь. Вот там было сделано таким образом. И сделано очень криво - пересчет элементов при открытии приводил к тому что открываемый элемент сразу помечался как измененный, хотя его только открыли "на посмотреть", и велика вероятность на случайное сохранение этих данных. Тормознутые отчеты и документы... Много неудобных мест (например если договор справочник , то выцепить даты окончания договоров для обзвона клиентов можно только обходом всех элементов) В общем через пару лет очень тормознутая вещь. Так что лучше или писать на другой платформе, или пользоваться более нормальной БД (sql, sqlite), или хотя бы продумывать "на будущее" как будет работать система, а не плодить справочники
Это решение
(21) поотому что рожали на ходу.
Сначала надо сидеть и долго рисовать/кумекать - тогда будет ок. но мы зачастую идем на поводу запросов вышестоящих лиц. надо завтра к утру. вот и рождаются костыли - и ничего плохого в этом нет. никто же не говорил - сделай к утру, но чтобы и через 5 лет вертелось на ура и проблем не было.. ;-0
Сначала надо сидеть и долго рисовать/кумекать - тогда будет ок. но мы зачастую идем на поводу запросов вышестоящих лиц. надо завтра к утру. вот и рождаются костыли - и ничего плохого в этом нет. никто же не говорил - сделай к утру, но чтобы и через 5 лет вертелось на ура и проблем не было.. ;-0
Это решение
(28) Угу, вертится. Только очень медленно и скрипит сильно. Я согласен что бывает когда нужно бывает "вчера". Но ведь потом эту идею начинают тиражировать. Я ведь привер просто первую вспомнившуюся конфигурацию, а с аналогичным костылем , но с логотипом "1С:Совместимо" достаточно изделий.
Это решение
1)если речь все таки идет про 1С платформу, то просто надо делать на 8.2 + СУБД, сам реально пробовал только на MSSQL, таблица в 200 тыс. записей это не проблема для современных СУБД.
2)смысла делать справочник застрахованных лиц подчиненным договорам (ДМС) я не вижу. тем более один застрахованный потом может зарегистрировать другой договор и он будет уже в 2х договорах одновременно...
3)наверное все таки для построения оптимальной структуры БД во многом необходимо исходить из бизнес-процессов нуждающихся в автоматизации и той отчетности которую придется формировать на основании, введенной в базу данных, информации.
2)смысла делать справочник застрахованных лиц подчиненным договорам (ДМС) я не вижу. тем более один застрахованный потом может зарегистрировать другой договор и он будет уже в 2х договорах одновременно...
3)наверное все таки для построения оптимальной структуры БД во многом необходимо исходить из бизнес-процессов нуждающихся в автоматизации и той отчетности которую придется формировать на основании, введенной в базу данных, информации.
Это решение
использование подчиненых справочников очень положительно влияет на производительность. исключает фулсканы по таблицам. В целом построение БД надо основывать на приципах построения любых баз...нормализаци данных для хранения денормализация для создания витрин выборок и тд...
Это решение
(31) Bazh,
Использование подчиненных справочников чаще всего отрицательно сказывается на производительности.
Из-за построения туевой горы лишних индексов.
Положительно сказывается на производительности добавление оптимальных индексов.
Весь плюс подчиненных справочников только в бесплатном интерфейсе.
Использование подчиненных справочников чаще всего отрицательно сказывается на производительности.
Из-за построения туевой горы лишних индексов.
Положительно сказывается на производительности добавление оптимальных индексов.
Весь плюс подчиненных справочников только в бесплатном интерфейсе.
Это решение
(6) Директор PR отдела,
Совершенно согласен у меня сейчас тонны таких справочников, в которые пишется мох и болото. Логируются все изменения, которые делают пользователи. Разные другие логи, огромные таблицы обменов с поставщиками. В одной базе справочник номенклатуры имеет 150000 записей. Про другие справочники связанные с номенклатурой я вообще молчу.
Все пишется, ничего не подтормаживает.
Пишутся все справочники напрямую в SQL базу. Если б писались штатными средствами все не "подтормаживало" бы а стояло колом в дедлоке.
Совершенно согласен у меня сейчас тонны таких справочников, в которые пишется мох и болото. Логируются все изменения, которые делают пользователи. Разные другие логи, огромные таблицы обменов с поставщиками. В одной базе справочник номенклатуры имеет 150000 записей. Про другие справочники связанные с номенклатурой я вообще молчу.
Все пишется, ничего не подтормаживает.
Пишутся все справочники напрямую в SQL базу. Если б писались штатными средствами все не "подтормаживало" бы а стояло колом в дедлоке.
Это решение
В данном контексте использование подчиненных спр будет более эффективно, индекс генерятся сами, причем оптимизированные, по нужным полям. Если городить свои справочники то выборки будут выполнятся по выбору компилятора запроса, щас будет кореляция и прочие неприятности. Хотя я не исключаю что при желании можно сделать чтобы все работало правильно, только это будет больше похоже ни разработку велосипеда. Если мы говорим об 1с как о транзакционке - это вообще не тот инструмент проще писать ее отдельно на 1с "кушать" данные для получения агрегатов и сводов информации
Это решение
(34) Bazh,
Могет быть, могет быть.
Просто рассказываю про свой опыт.
В последнее время практически не использую подчиненных справочников.
Вместо этого по необходимости достраиваю составные индексы.
И индексов меньше и в индексах нет лишних полей и количество необходимых полей ничем не ограничено.
Соответственно и эффективность этих индексов выше.
Могет быть, могет быть.
Просто рассказываю про свой опыт.
В последнее время практически не использую подчиненных справочников.
Вместо этого по необходимости достраиваю составные индексы.
И индексов меньше и в индексах нет лишних полей и количество необходимых полей ничем не ограничено.
Соответственно и эффективность этих индексов выше.
Это решение
Если посмотреть глобально, можно реализация так называемого ОЛАПа в рамках 1с где данные вносимые пользователями попадают в структуры адаптированные на работу с пользователем. Пото данные джобами качую в "витрины" где уже есть денормализация есть куча проблем - но структура заточена на быстрые выборки.
Это решение
Есть задача: разработать базу данных для страховой компании по учету договоров добр. Мед. Страхования. В настоящее время застрахованных лиц 10 тыс. возможно скоро будет 150 – 200 тыс.
Подскажите по производительности:
1. Стоит ли справочник застрахованных лиц делать подчиненным договорам страхования.? Снизит ли это производительность? (в наст. Время я сделал не подчиненный с возможностью отбора)
2. По застрахованным будет большое количество информации: к каким больницам прикреплен, когда прикреплен, когда откреплен, набор возможных услуг, обращения, диагнозы, стоимость лечения и пр. Думаю, организовать всю эту инфу в оборотный регистр, и оттуда получать данные (есть другие варианты?) или же организовать подчиненные справочники? сильно ли скажется это на произоводительности?
3. Как посоветует организовать БД. Кто-нибудь сталкивался с автоматизацией ДМС?
Подскажите по производительности:
1. Стоит ли справочник застрахованных лиц делать подчиненным договорам страхования.? Снизит ли это производительность? (в наст. Время я сделал не подчиненный с возможностью отбора)
2. По застрахованным будет большое количество информации: к каким больницам прикреплен, когда прикреплен, когда откреплен, набор возможных услуг, обращения, диагнозы, стоимость лечения и пр. Думаю, организовать всю эту инфу в оборотный регистр, и оттуда получать данные (есть другие варианты?) или же организовать подчиненные справочники? сильно ли скажется это на произоводительности?
3. Как посоветует организовать БД. Кто-нибудь сталкивался с автоматизацией ДМС?
Не советую делать ЭТО на 1С...
Когда только начинал, делал конфу для центра профпатологии. Для таких объемов данных 1С не предназначена (по крайней мере, 7.7 и не sql) Впрочем, я тогда выкрутился из положения... :)
Когда только начинал, делал конфу для центра профпатологии. Для таких объемов данных 1С не предназначена (по крайней мере, 7.7 и не sql) Впрочем, я тогда выкрутился из положения... :)
Это решение
O-Planet Написал:
-------------------------------------------------------
> Не советую делать ЭТО на 1С...
> Когда только начинал, делал конфу для центра
> профпатологии. Для таких объемов данных 1С не
> предназначена (по крайней мере, 7.7 и не sql)
> Впрочем, я тогда выкрутился из положения...
>
Вот, вот, а кто говорил, что будет смешно?
А что ему даст сиквел при объеме 200 тыс?
А между прочим, товарищ не сказал со скольких раб. мест эту базу будут юзать. Все ли места локальные, или будут удаленные подключения с филлиалов? И вообще база в воздухе не ставится. Это я ктому, что товарищ ни словом не обмолвился о среде и условиях эксплуатации.
Теперь по поводу замечания imsoftware.
У нас на ДБФ 7.7 билд 25 в справочнике товаров более 12.5 тыс позиций + подчиненный справочник серий (сотни тыс позиций). Не скажу, что умерли (захлебнулись), но живем оче-е-е-нь хрыново... Правда, хочу добавить, что скорость определяется не только объемом одного справочника - здесь целый комплекс: железо, к-во активных юзеров, интенсивность товарооборота и еще х**ва куча другого понта. Так что еще раз хочется обратить внимание: задачу надо изначально решать комплексно (чтобы потом не оказалось, что чего-то одного не учли - и финита!).
-------------------------------------------------------
> Не советую делать ЭТО на 1С...
> Когда только начинал, делал конфу для центра
> профпатологии. Для таких объемов данных 1С не
> предназначена (по крайней мере, 7.7 и не sql)
> Впрочем, я тогда выкрутился из положения...
>
Вот, вот, а кто говорил, что будет смешно?
А что ему даст сиквел при объеме 200 тыс?
А между прочим, товарищ не сказал со скольких раб. мест эту базу будут юзать. Все ли места локальные, или будут удаленные подключения с филлиалов? И вообще база в воздухе не ставится. Это я ктому, что товарищ ни словом не обмолвился о среде и условиях эксплуатации.
Теперь по поводу замечания imsoftware.
У нас на ДБФ 7.7 билд 25 в справочнике товаров более 12.5 тыс позиций + подчиненный справочник серий (сотни тыс позиций). Не скажу, что умерли (захлебнулись), но живем оче-е-е-нь хрыново... Правда, хочу добавить, что скорость определяется не только объемом одного справочника - здесь целый комплекс: железо, к-во активных юзеров, интенсивность товарооборота и еще х**ва куча другого понта. Так что еще раз хочется обратить внимание: задачу надо изначально решать комплексно (чтобы потом не оказалось, что чего-то одного не учли - и финита!).
Это решение
В догонку к предыдущему сообщению.
Мне кажется, что при объеме 200 тыс не помогут ни подчиненный, ни оборотные регистры, ни святая вода. Я даже не могу себе представить в кошмарном сне размер оборотного регистра через год. Мы то у себя в начале года базе делаем "обрезание", а здесь это точно не покатит.
Мне кажется, что при объеме 200 тыс не помогут ни подчиненный, ни оборотные регистры, ни святая вода. Я даже не могу себе представить в кошмарном сне размер оборотного регистра через год. Мы то у себя в начале года базе делаем "обрезание", а здесь это точно не покатит.
Это решение
SQL от 200 тыс. не упадёт. Ровные руки, прямые запросы, проведение на SQL и всё будет работать.
+ грамотная структура базы решит скорость. Был у нас справочник на 5.5 млн позиций. В него писались все изменения, которые происходили в базе. Да, при записи притормаживало, но не на столько, чтобы прям "ах, ничё не работает!". В базе 70-80 человек. Проводящих документы порядка 20.
Вопрос с тормозами на формах решить сложнее.
В общем, на 1С сделать можно и будет работать, но проще сделать не на 1С.
+ грамотная структура базы решит скорость. Был у нас справочник на 5.5 млн позиций. В него писались все изменения, которые происходили в базе. Да, при записи притормаживало, но не на столько, чтобы прям "ах, ничё не работает!". В базе 70-80 человек. Проводящих документы порядка 20.
Вопрос с тормозами на формах решить сложнее.
В общем, на 1С сделать можно и будет работать, но проще сделать не на 1С.
Это решение
Внимание! Не забывайте отмечать решение на ваш вопрос, если оно найдено. Это повысит ваш рейтинг на форуме.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот