|
СрезПоследних ИЛИ ПолучитьПоследнее ? | ☑ | ||
---|---|---|---|---|
0
Kain_wrath
28.05.15
✎
15:39
|
Что лучше использовать?
|
|||
1
Heckfy
28.05.15
✎
15:40
|
А не монописуально?
|
|||
2
Shurjk2
28.05.15
✎
15:43
|
(0) Смотря для чего.
|
|||
3
LordCMEPTb
28.05.15
✎
15:44
|
голосовалки не хватает..
|
|||
4
D_E_S_131
28.05.15
✎
15:45
|
Согласен с (2).
|
|||
5
anatoly
28.05.15
✎
15:52
|
первое возвращает ТЗ - второе структуру.
|
|||
6
Kain_wrath
28.05.15
✎
15:57
|
(2) я знаю что срез последних вернет мне одну строку стоит ли в этом случае использовать получить последнее? Или лучше шаманить с таблицей значений?
|
|||
7
pavig
28.05.15
✎
16:14
|
(0)
Только явные запросы. Объектная модель - от лукавого. |
|||
8
DS
28.05.15
✎
16:21
|
(7) Только прямые запросы. Запросы 1с - от лукавого.
|
|||
9
Ненавижу 1С
гуру
28.05.15
✎
16:26
|
(8) добавьте дополнительное поле, заполняйте его через триггер, остально от лукавого:
http://naf2000.blogspot.ru/2013/09/1-8_11.html |
|||
10
vicof
28.05.15
✎
16:35
|
(9) Только Excel, остальное от лукавого
|
|||
11
palpetrovich
28.05.15
✎
16:41
|
(9) курто, чё
|
|||
12
Ненавижу 1С
гуру
28.05.15
✎
16:48
|
(10) только счеты, остальное от лукавого
|
|||
13
Heckfy
28.05.15
✎
16:48
|
Да чё там, только вычисления в столбик.
|
|||
14
fisher
28.05.15
✎
16:55
|
Не, ну вот реально. Вообще не вижу смысла в объектной модели для получения данных, если только это не динамическая выборка.
|
|||
15
fisher
28.05.15
✎
16:56
|
Завтра понадобится какие-нить сопутствующие данные выбрать, и что? Придется плодить обращения к БД или переписывать на тот же запрос. Лучше уж сразу, чтобы два раза не вставать.
|
|||
16
pavig
28.05.15
✎
17:00
|
(14)
Динамическая выборка - это как? |
|||
17
DS
28.05.15
✎
17:02
|
(15) А если завтра не понадобится?
Зачем два раза вставать? А если сразу писать тот же запрос, а завтра понадобится, это как-то облегчит работу? |
|||
18
fisher
28.05.15
✎
17:06
|
(16) Объектная выборка справочников и документов получает данные из БД по принципу динамического списка - порционно. Может быть удобно для обработки очень больших объемов.
(17) А если не понадобится, то как минимум не надо запоминать лишние методы. Если понадобится - конечно облегчит. Получить доп.реквизит через точку или соединение воткнуть всяко быстрее, чем с нуля этот же запрос рисовать. Да и вообще объектная модель очень редко когда сейчас оптимальна даже на старте. Во всех алгоритмах пытаешься за один-два запроса все нужные данные вытащить, чтобы минимизировать обращения к БД. Объекты тут в пролете. |
|||
19
DS
28.05.15
✎
17:12
|
(18) Есть ситуации, когда целесообразно одно, есть - когда целесообразно другое. Поэтому, не вижу смысла фантазировать.
|
|||
20
fisher
28.05.15
✎
17:17
|
(19) Какая в опу фантазия? Суровая практика жизни.
Придумай мне хоть один случай когда объектный доступ будет целесообразнее. Если крупно повезет в эксплуатационном цикле - то он будет просто не хуже запроса. Поэтому не надо ля-ля. |
|||
21
Demetres
28.05.15
✎
17:18
|
(7)(8)(10) еретики, только береста!
|
|||
22
Demetres
28.05.15
✎
17:20
|
СрезПоследних победил!!!
|
|||
23
H A D G E H O G s
28.05.15
✎
17:23
|
(9) Спасибо. Иногда и от тебя можно услышать что-то полезное.
|
|||
24
fisher
28.05.15
✎
17:31
|
(23) Сомнительная польза.
10-15%, хотя время выполнение тестов подозрительно мало (для тестов). Фиг его знает, чего на более крупных выборках покажет. |
|||
25
H A D G E H O G s
28.05.15
✎
17:33
|
(24) А мы проверим. Есть у меня такой РС, идеально подходящий для этого.
|
|||
26
vicof
28.05.15
✎
17:33
|
(21) Каменные таблички, остальное от лукавого
|
|||
27
fisher
28.05.15
✎
17:33
|
(25) Отлично. Пост по итогам будет?
|
|||
28
H A D G E H O G s
28.05.15
✎
17:35
|
угу
|
|||
29
pavig
28.05.15
✎
17:47
|
(18)
"Объектная выборка справочников и документов получает данные из БД по принципу динамического списка - порционно. Может быть удобно для обработки очень больших объемов." А выборка из результата запроса разве не так работает? Она тоже не вся получается, а порционально. Вот только результат, скорее всего, хранится на сервере приложений. С объектной моделью, скорее всего, тоже именно так и происходит. И ничем выборка по объектной модели не отличается. |
|||
30
H A D G E H O G s
28.05.15
✎
17:48
|
(29) Отличается.
|
|||
31
pavig
28.05.15
✎
17:50
|
(30)
Чет не верю я тебе. |
|||
32
H A D G E H O G s
28.05.15
✎
17:51
|
(31) Я - вру?
|
|||
33
pavig
28.05.15
✎
17:54
|
(32)
Откуда мне знать? А может и не врешь, а ошибаешься? |
|||
34
H A D G E H O G s
28.05.15
✎
17:56
|
(33) Я почти не ошибаюсь. Счет идет на единицы за 7 лет.
|
|||
35
fisher
28.05.15
✎
18:00
|
(28) Только того этого. С блокировками возможны вопросы. Надеюсь, у тебя туда конкурентно не фигачат в больших объемах.
(31) Зря не веришь. |
|||
36
pavig
28.05.15
✎
18:01
|
(34)
Тем не менее, вероятность есть. |
|||
37
H A D G E H O G s
28.05.15
✎
18:02
|
(35) РС пишется раз в полгода, читается при каждом проведении.
|
|||
38
H A D G E H O G s
29.05.15
✎
12:40
|
Афтор статьи (9) ниасилил ее до конца.
Все не так однозначно :-) |
|||
39
H A D G E H O G s
29.05.15
✎
12:41
|
Дополнительный индекс там не нужен, он никак не исползоваться не будет.
ииии, не факт, что будет быстрее... |
|||
40
H A D G E H O G s
29.05.15
✎
12:43
|
Вся проблема в строчке
И &Дата МЕЖДУ ЦеныНоменклатуры.Период И ЦеныНоменклатуры.ПериодОкончания которая мутируется в строчку ЦеныНоменклатуры.Период <= &Дата И ЦеныНоменклатуры.ПериодОкончания >= &Дата именно оператор <= вызывает то, что сначало будет индексный поиск по полю Период и остаточный скан по ПериодОкончания. Фсе. Это катастрофа :-) |
|||
41
H A D G E H O G s
29.05.15
✎
12:45
|
Если вы делаете именно Срез, без отборов по измерениям - то выгода будет, если у вас немного отбором по измерениям - то выгода сомнительна, она будет из за отсутствия Сортировки, которая возникает там неявно.
Если у вас отборы почти по всем измерениям - будет проигрыш, так как эти отборы попадут в остаточный индексный скан. |
|||
42
H A D G E H O G s
29.05.15
✎
12:46
|
Я, кстати, делаю именно Срез, поэтому мне - годно!
|
|||
43
H A D G E H O G s
29.05.15
✎
13:00
|
Прошу прощения.
В типовом Срезе отбор по измерениям (даже без пропусков) также попадает в остаточный индексный скан. Да, метод Ненавижу выигрывает всегда. Просто ему не надо добавлять индекс на ресурс. |
|||
44
rozer76
29.05.15
✎
13:55
|
итс:
Особенности методов менеджера регистра сведений У объекта РегистрСведенийМенеджер имеется набор методов для доступа к данным регистра сведений. Методы СрезПервых() и СрезПоследних() позволяют найти наиболее ранние и наиболее поздние записи по всем комбинациям измерений. При этом может быть установлен отбор записей. Методы возвращают таблицу значений, содержащую строки соответствующие найденным записям. По своему действию эти методы аналогичны виртуальным таблицам СрезПервых и СрезПоследних. Их единственное преимущество перед использованием запроса - краткость записи. Методы Получить(), ПолучитьПервое() и ПолучитьПоследнее() отличаются тем, что предназначены для получения только значений ресурсов. Методы возвращают структуру, содержащую элементы, соответствующие ресурсам регистра. Основным отличием описанных методов является то, что методы Получить(), ПолучитьПервое() и ПолучитьПоследнее() выдают значения одной записи, а методы СрезПервых() и СрезПоследних() позволяют получить несколько записей. В методах Получить(), ПолучитьПервое() и ПолучитьПоследнее() структура возвращается в любом случае. То есть если в регистре нет записей с указанными значениями отбора, то будет возвращена структура, содержащая значения ресурсов по умолчанию. Таким образом, методы Получить(), ПолучитьПервое() и ПолучитьПоследнее() целесообразно использовать в тех случаях, когда, с точки зрения прикладной задачи, нужны данные одной записи, и значение по умолчанию вполне может быть использовано как не установленное значение для этой комбинации измерений, то есть соответствовать отсутствию записи. Например, если хранятся цены товаров, то получение цены 0 (ноль) вполне может отвечать логике использования не установленной цены. В этом случае удобно использовать эти методы и не анализировать в модуле имеется ли запись в регистре или нет. Однако если наличие или отсутствие записей с указанной комбинацией измерений существенно, то нужно использовать запрос или методы СрезПервых() и СрезПоследних() для периодических регистров сведений. С точки зрения производительности, методы СрезПервых() и СрезПоследних() оптимизированы именно для получения данных одной записи. Разумеется, в конкретных ситуациях (в зависимости от структуры измерений, варианта хранения базы данных и т.д.) соотношение может быть различным. |
|||
45
Serginio1
29.05.15
✎
14:02
|
(43) А ты план запроса смотрел? Помоему и в том и в другом случае будет поиск по Периоду на меньше или равно
|
|||
46
GROOVY
29.05.15
✎
14:04
|
(45) +100
|
|||
47
H A D G E H O G s
29.05.15
✎
14:06
|
(45) Да, именно я его и смотрел
|
|||
48
H A D G E H O G s
29.05.15
✎
14:07
|
И как фраза в (45) противоречит предыдущим моим фразам?
|
|||
49
GANR
29.05.15
✎
14:07
|
(0) Прямой SQL-запрос - не потратится время на преобразование 1С-запроса к запросу MS SQL ))).
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |