|
Всегда ли в запросе МАКСИМУМ(Ссылка) вернет последний документ? | ☑ | ||
---|---|---|---|---|
0
ValeriTim
03.03.21
✎
14:48
|
Есть куча сформированных документов, у которых дата (вплоть до секунды) одинакова. Формирую запрос по регистру и хочу получить последний сформированный документ. Так вот вопрос в запросе МАКСИМУМ(ИмяРегистра.Регистратор) всегда будет возвращать последний документ? Как вообще работает МАКСИМУМ(Ссылка) ?
|
|||
189
fisher
05.03.21
✎
13:49
|
(176) 1C не сохраняет миллисекунды в базе данных. Во всяком случае в сиквел нули пишет.
|
|||
190
PR
05.03.21
✎
13:49
|
(177) Граница — это дата и ссылка опять же
|
|||
191
PR
05.03.21
✎
13:50
|
(180) В чем в обратном?
|
|||
192
fisher
05.03.21
✎
13:52
|
(191) При стандартной генерации ссылок платформой обеспечивается их возрастающая последовательность. Банально за счет того, что в них записывается время их генерации.
|
|||
193
PR
05.03.21
✎
13:55
|
(192) О как
А, ты имеешь в виду, что Боря сказал, что возрастающая последовательность не обеспечивается, а на самом деле обеспечивается? Какой коварный тип! |
|||
194
fisher
05.03.21
✎
13:59
|
(193) Как я понимаю, этим сразу два зайца убивается:
1) для базы данных хорошо, когда новые записи пишутся в конец кластерного индекса, а не как бог на душу положит 2) при сортировке по моменту времени в пределах секунды тоже получается логичнее, что позднее созданные документы идут после созданных ранее |
|||
195
PR
05.03.21
✎
14:01
|
(194) + Уникальность, хотя ее можно было и по-другому конечно достичь
+ Движения в регистры ложатся позже и не приходится пересчитывать каждый раз те же актуальные итоги |
|||
196
Serginio1
05.03.21
✎
14:01
|
(192) Ну стандартно документы ставят в конец дня. Возьмется последний сгенеренный, но это не факт, что последний прилетевший из другой системы. Но до этого могли и номер документа поменять. Вообще для большинства документов Номер является основной сортировкой.
Для каких то нет. Для распределенных баз префикы применяют. Если брать индекс по моменту времени это одно, если по другим критериям это другое Нужно определиться, что такое последний документ. |
|||
197
fisher
05.03.21
✎
14:06
|
(195) Про итоги не понял. Актуальные в любом случае будут пересчитываться.
|
|||
198
Dzenn
гуру
05.03.21
✎
14:09
|
(176) А если допустить, что в базе создали 100 000 000 документов "Реализация товаров и услуг", и у всех у них дата "31.12.2020 12:00:00", как отработает момент времени, основанный на миллисекундах?
Мне кажется, там всё-таки не миллисекунды, а какой-то другой механизм. Да тот же инкремент, например. |
|||
199
fisher
05.03.21
✎
14:21
|
(198) Момент времени - это дата + ссылка. Дата с точностью до секунды. Какую пользователь выставил, скажем. А ссылка, с точки зрения порядка - тупо время генерации ссылки (плюс еще части, дополнительно обеспечивающие уникальность ссылки как гуида). Время генерации ссылки - там 60 бит кажись. С точностью до микросекунд и даже долей микросекунд.
|
|||
200
Serg_1960
05.03.21
✎
14:31
|
(193) эээ... все в курсе, что из ссылки можно достать её время создания? Оно не совсем и не всегда соответствует реальному, но для моих целей - и так сойдёт. Я запросом выбрал однотипные документы за прошлый год; отсортировал по GUID(SQL); вычислил и сравнил даты создания. На пару тысяч ссылок всего одно нарушение возрастания последовательности. Как бы Боря - прав... но я не исключаю вероятность проблемы с получением времени сервера в многопользовательском режиме.
|
|||
201
Почему 1С
05.03.21
✎
14:34
|
(199) http://catalog.mista.ru/1c/articles/635159/ вот тут подробно написано, время это один и компонентов, но он не гарантирует возрастание порядка выданых гуид, поэтому опираться на утверджение "А ссылка, с точки зрения порядка - тупо время генерации ссылки " не верно
|
|||
202
fisher
05.03.21
✎
14:37
|
(200) Не совсем понял, с чем ты сравнивал. С ЖР?
(201) Поясни, почему время генерации не гарантирует порядок возрастания. Я, видимо, туплю. Уже несколько раз сказал, что 1С в базе данных часть со временем генерации впереди записывает. То есть сначала будет порядок времени генерации, а все остальное уже влияет на порядок в пределах микросекунды. |
|||
203
Serg_1960
05.03.21
✎
14:44
|
Вопрос о количестве документов в одной микросекунде подобен вопросу "Сколько ангелов поместится на кончике иглы?" ;)
(202) Сортировал GUIDы по возрастанию и проверял на возрастание время создания этих-же GUIDов |
|||
204
Почему 1С
05.03.21
✎
14:44
|
(202) В ссылке (201) отдельным пунктом рассматривается этот вопрос. Грубо говоря что это может работать в 99.9% , но уже не может быть однозначным правилом.
|
|||
205
fisher
05.03.21
✎
14:47
|
Порядок времени генерации гуид в каких-то отдельных случаях может и не совпадать с порядком времени записи в БД.
Можно же заранее получить ссылку нового, например. Но в базе данных все равно же будет порядок возрастания времени генерации гуидов. Исключением будет только нестандартное получение ссылки. На основании "ручного" гуида, например. (204) Я возражал на утверждение "Возрастающая последовательность при их генерации не обеспечивается". Обеспечивается. Но есть еще "ручная" генерация. |
|||
206
Почему 1С
05.03.21
✎
14:57
|
(205) Тут правильнее было написать "Возрастающая последовательность при их генерации не гарантируется"
|
|||
207
NorthWind
05.03.21
✎
14:58
|
(198) если у вас есть настолько бессмысленная и беспощадная автоматическая генерация доков, которая делает такие вещи, то механизм принятия какого-либо решения на основе "выбора последнего документа" в существенной степени вообще теряет смысл для доков, которые таким образом генерируются. Мне так кажется.
|
|||
208
PR
05.03.21
✎
14:58
|
(196) Последний документ — это тот, который поставили самым последним, то есть у него самая последняя дата и самая большая ссылка в секунде этой даты
|
|||
209
PR
05.03.21
✎
14:59
|
(197) А, ну да, в любом случае будут же просто движения нового документа добавляться
|
|||
210
PR
05.03.21
✎
15:00
|
(198) Инкремент, все верно
В ссылке |
|||
211
fisher
05.03.21
✎
15:01
|
(203) Хм... Тогда непонятно, откуда расхождение вылезло. Возможно, ошибка извлечения времени для какого-то краевого случая.
(206) Гарантируется. Просто так как все неявно пытаются привязать время генерации гуидов к чему-то практическому (например ко времени записи в БД), во всех статьях проще бить всех по рукам и говорить "ничего не гарантируется". Потому что эти дебилы-одинэсники не хавают таких тонких разниц. |
|||
212
Половинкин
05.03.21
✎
15:06
|
(205) Не "обеспечивается" же, это просто "сайд эффект". Его можно использовать, но при этом не удивляться, если что-то пойдёт не так...
|
|||
213
fisher
05.03.21
✎
15:08
|
Я соглашусь с такой формулировкой: "Возрастающая хронологическая последовательность записи объектов в БД при генерации их ссылок не гарантируется".
|
|||
214
fisher
05.03.21
✎
15:10
|
А сами-то ссылки генерятся исключительно в хронологической последовательности (по хронологии компа, который их генерит) и хранят в себе это время.
|
|||
215
PR
05.03.21
✎
15:10
|
(212) Эээ... а как его и зачем использовать?
|
|||
216
fisher
05.03.21
✎
15:12
|
(215) Единственное практическое применение, которое я встречал - можно узнать примерное время создания объекта, если ЖР не сохранился.
|
|||
217
Половинкин
05.03.21
✎
15:16
|
(215) Если ты этого не знаешь - значит тебе этого и не нужно.
|
|||
218
PR
05.03.21
✎
15:19
|
(217) Логично
Мне не нужно Даже (216) |
|||
219
vi0
05.03.21
✎
15:35
|
(121) такой способ, в теории, может давать разные результаты при одинаковых данных
|
|||
220
Почему 1С
05.03.21
✎
15:48
|
(214) Этого никто не гарантирует, все обсуждение в этой ветке строится на том, что GUID можно использовать как уникальный идентификатор и только, ни порядка, ни тем более определения времени из него не гарантированы. Сама генерация GUID есть разных версий, в том числе и с помощью криптографических средств. Юзать как лайвхак здесь и сейчас можно, использовать как правило нельзя.
|
|||
221
fisher
05.03.21
✎
16:17
|
(220) Ок. Этого никто не гарантирует. Но в 1С это работает именно так с первой версии и по текущий момент. И я не вижу ни одной причины, почему это может измениться. Потому что причины, почему сделано именно так, вполне очевидны и весьма весомы. На практике от этого толку мало, поэтому с пеной у рта попросту нечего обсуждать. Но факт остается фактом. Хотелось расставить точки над "ё".
|
|||
222
vi0
05.03.21
✎
16:20
|
(194) Читал на партнерском комментарий от фирмы 1с, что это было актуально для автоматических блокировок, когда применяется уровень изоляции сериалайзбл, который, как известно, нередко блокирует больше чему нужно. Соответственно выдаваемые порции рядомстоящих уидов позволяют уменьшить избыточные блокировки между сеансами. Ну и что это стало неактуально с появлением управляемых блокировок.
|
|||
223
fisher
05.03.21
✎
16:25
|
(222) Это не "стало неактуально с появлением управляемых блокировок". Это для управляемых блокировок этот момент стал менее критичным. Две большие разницы.
|
|||
224
vi0
05.03.21
✎
16:27
|
(220) если говорить о ms sql то порядок там можно гарантировать на том основании что ссылка это ГУИД которых имеет тип binary, который sql не запрещает сортировать:
"Columns of type ntext, text, image, geography, geometry, and xml cannot be used in an ORDER BY clause." https://docs.microsoft.com/en-us/sql/t-sql/queries/select-order-by-clause-transact-sql?view=sql-server-ver15 |
|||
225
vi0
05.03.21
✎
16:28
|
(223) ну так написано было, и если нет сериалайзбл то действительно проблема снимается
делали то пачки именно для этой цели |
|||
226
fisher
05.03.21
✎
16:33
|
(225) Не только для этой. Задам вопрос так. Ты считаешь, что изменение алгоритма генерации гуида в очередной версии 1С на полностью рандомный ничего не ухудшит?
|
|||
227
vi0
05.03.21
✎
16:39
|
(226) ну я просто процитировал, если интересно, то могу ссылку дать
а так - надо замеры делать |
|||
228
fisher
05.03.21
✎
16:45
|
(227) Нет. Мне неинтересно. Я ответ знаю. Использование "последовательных гуидов" - стандартный прием для первичных ключей в таблицах СУБД. 1С тут вовсе не изобретатели. Потому что если вставлять "абы куда", то увеличиваются накладные расходы на разделении страниц и растет фрагментация индексов. Плюс опять же "нативная" сортировка в пределах секунды по моменту времени.
|
|||
229
PR
05.03.21
✎
16:54
|
(220) Уже сто раз все объяснили, сто раз давали ссылки на разъяснения от 1С, сто раз взывали к логике и здравому смыслу
Уже вроде даже никто не спорит с тем, что момент времени = дата + ссылка Но нет, все-таки есть еще некоторые упоротые, которые по-прежнему считают, что никакого порядка из ссылки получить и получать нельзя, максимум можно использовать как странный необъяснимый лайфхак А что же вместо этого использовать? Ну конечно же сортировать по номеру документа, самый верный способ |
|||
230
vi0
05.03.21
✎
16:55
|
(228) ну если знаешь, то скажи, примерно на сколько процентов увеличиваются накладные расходы
про сортировку это додумки - можно новому документу установить любой гуид |
|||
231
PR
05.03.21
✎
17:00
|
(230) LOL
Это уже упертая дремучесть какая-то Как ты думаешь, если двум первому документу назначить вручную "большой" гуид, а второму вручную "мальнький" и одну и ту же дату до секунды, то: 1. Сортировка по моменту времени совпадет с сортировкой по дате + ссылка? 2. Движения в СКД по какому-нить регистру остатков, куда эти два документа наделали движений, пойдут в какой последовательности, сначала движения первого, а потом второго или наоборот? |
|||
232
PR
05.03.21
✎
17:02
|
(231) И все-таки еще вопрос:
3. При правильной сортировке (понимай под этим что хочешь, порядок в списке документов, попадание в последовательность, сортировка по моменту времени или что-то еще) сначала пойдет первый документ, а потом второй или наоборот? |
|||
233
vi0
05.03.21
✎
17:10
|
(231) я как бы понимаю что там где сортируется, поэтому не понял наезда про дремучесть
дремучесть в чем? |
|||
234
fisher
05.03.21
✎
17:19
|
(230) > скажи, примерно на сколько процентов увеличиваются накладные расходы
Понятия не имею. Допустим, процент очень небольшой. И? > про сортировку это додумки В смысле додумки? Ты не согласен, что такая сортировка лучше, чем рандомная? |
|||
235
PR
05.03.21
✎
17:21
|
(233) А, я так понимаю, я неправильно понял
Если так, то сорри Я подумал, что ты утверждаешь, что по ссылке сортировать нельзя, потому что в принципе можно же ссылке назначить любой гуид, не обязательно бОльший, чем предыдущие в этой секунде А ты, я так понимаю, про то, что нельзя рассчитывать на то, что каждый новый документ в той же секунде будет обязательно позже имеющихся, при любой ссылке |
|||
236
vi0
05.03.21
✎
17:21
|
(234) смущает слово "допустим")
додумки в том смысле, что любому новому документу можно установить произвольный уид, и уже не будет ожидаемой сортировки и повторю - я передал слова фирмы 1с, больше что то нет желания дискутировать по этому вопросу) |
|||
237
vi0
05.03.21
✎
17:22
|
(235) ну да
|
|||
238
fisher
05.03.21
✎
17:24
|
(236) Ок, взаимно.
|
|||
239
PR
05.03.21
✎
17:28
|
(237) А, ну так это вообще непонятно почему возникшая в этой теме дискуссия
Я про то, что новый документ по дефолту будет с бОльшим гуидом Ветка-то изначально не про это и в принципе вообще неважно, больше будет новый гуид или меньше Ветка про то, что и как использовать для сортировки и максимума и решения (0) А полветки обсуждается именно то, как генерятся ссылки |
|||
240
acht
05.03.21
✎
23:10
|
Три страницы печенкиного самоутвержения какие-то
|
|||
241
Ненавижу 1С
гуру
05.03.21
✎
23:19
|
Опираться на сравнение больше/меньше на гуид так себе идея. Объект вообще может прийти из другой базы.
|
|||
242
PR
05.03.21
✎
23:36
|
(240) Ну, на самом деле можно было закончить на (2), но прибежала орава народу, вчера открывших конфигуратор, и начала спорить про то, что не знает
|
|||
243
PR
05.03.21
✎
23:36
|
Теперь вот еще (241) нихрена не прочитал, но тоже очень хочет что-нибудь сказать
|
|||
244
Cthulhu
06.03.21
✎
03:21
|
сортировка по ссылке = сортировка по моменту создания документа (или что то же самое уид-у).
при этом дату и время документа можно менять. в результате чего сортировка по ссылке станет существенно отличаться от сортировки по дате(+времени) документов. //упп демо укр: ВЫБРАТЬ Док.Ссылка, Док.Номер, Док.Дата ИЗ Документ.ЗаказПоставщику КАК Док УПОРЯДОЧИТЬ ПО Ссылка // результат: // Ссылка Номер Дата // Заказ поставщику НФ000000011 от 01.05.2011 0:00:00 НФ000000011 01.05.2011 0:00:00 // Заказ поставщику ДО000000008 от 06.06.2011 0:00:00 ДО000000008 06.06.2011 0:00:00 // Заказ поставщику НФ000000001 от 04.04.2011 12:00:00 НФ000000001 04.04.2011 12:00:00 // Заказ поставщику НФ000000002 от 05.04.2011 12:00:00 НФ000000002 05.04.2011 12:00:00 |
|||
245
ДенисЧ
06.03.21
✎
05:31
|
(239) "окумент по дефолту будет с бОльшим гуидом"
Ромочка... Сиди в луже и не булькай. Для гуидов операции на больше-меньше - не определены. Если они работают в каких-то случаях - это случайность. И закладываются на это только такие непрофессионалы, как ты. |
|||
246
Почему 1С
06.03.21
✎
07:52
|
(242) На самом деле можно было. Но сравнение что мы открыли недавно конфигуратор и спорим не корректное, подойдет другое у нас есть хотя бы базовые знания в программировании поимо конфигуратора 1С. Ты настолько упертый, что для даже Сергей Нуралиев для тебя не авторитет.
Метод из 2 сработает, но никто не гарантирует что этот метод даст реально последний введенный в базу документ. Тут спор идет о тонком моменте который ты не понимаешь наверно ввиду своей гуманитарной натуры. 1С приняло правило, что для разграничения внутри секунды используется сортировка по ссылке, но так как сам ГУИД имеет природу генератора, а не инкремента, то гарантируется лишь сохранение бинарного порядка гуидов в последующем, сам порядок ничего не значит (кроме свойств бинарной сортировки), если кто то хочет рулить временным порядком 1с предлагает регулировать дату документа, больше никак. Сравнивать на больше меньше по GUID не верно, это как нельзя делить на 0. Вывод тут один, это твои знания на уровне посмотреть как работает в конфигураторе, но даже здесь ты не до конца провел эксперименты отвечая на вопрос, что больше приходная накладная или расходная, ответом та у которой позднее GUID . Последний раз простыню пишу, тема себя уже исчерпала. |
|||
247
Провинциальный 1сник
06.03.21
✎
07:57
|
"Да, очень жаль, что нам так и не удалось послушать начальника транспортного цеха!" (с)
На самом деле, 1с очень не хватает документированного механизма реализации хранения последовательности документов внутри секунды, не завязанного на гуиды, которые в общем случае для упорядочения непригодны.. |
|||
248
vi0
06.03.21
✎
08:15
|
(245) как же не определены, если сама 1с закладывает это в понятие момент времени, что в пределах секунды порядок документов неизменен, и это достигается именно сортировкой по гуиду
|
|||
249
vi0
06.03.21
✎
08:24
|
так то сравнение по гуидам вполне себе возможно технически, хотя бы из логики что сортровка основана на сравнении
ну и на практике это тоже можно использовать, например если нужно делать выборку большого колва документов, но не всю сразу в кусками по Н элементов делаем что то типа такого: СсылкаПредудыщая = Неопределено пока истина цикл Запрос "Выбрать первые 10 Ссылка Из Документ1 УПОРЯЧИТЬ ПО Ссылка ГДЕ Ссылка > &СсылкаПредудыщая" .. СсылкаПредудыщая = Выборка.Ссылка; КонецЦикла |
|||
250
Провинциальный 1сник
06.03.21
✎
08:27
|
(248) Порядок то неизменен. Только вот гарантировать, что порядок гуидов при этом будет совпадать с хронологическим порядком записи объектов, они не берутся. Это лишь предполагается исходя из алгоритма формирования гуидов в 1с, а он также не документирован и вполне может быть изменен.
|
|||
251
vi0
06.03.21
✎
08:28
|
(250) не берутся. но я этого и не писал
|
|||
252
PR
06.03.21
✎
10:41
|
(245) Мне достаточно того, что ты на это закладывается 1С
|
|||
253
PR
06.03.21
✎
10:57
|
(246) >>но никто не гарантирует что этот метод даст реально последний введенный в базу документ
Рукалицо А кто это утверждает? >>1С приняло правило, что для разграничения внутри секунды используется сортировка по ссылке Всё! Мы только про это и говорим Нахрена сюда приплетать сортируемость гуида, дикость этой процедуры или что-то еще? 1С сортирует документы по дате + ссылка А ТС, ну нифига себе, как раз спрашивает, как в 1С получить самый поздний документ для каждой номенклатуры, ну или для чего он там пытается их получить Я уже не знаю, как объяснить такую простую вещь Все время разговор скатывается либо на то, что ссылка на последний введенный документ может быть не максимальной Либо на то, что сравнивать гуиды вообще странно, дико и как-то фу Но вопрос НЕ В ЭТОМ, вопрос в том, как это ПРАВИЛЬНО делать, замечу, делать именно в программе 1С, а не где-то еще Вся ветка напоминает примерно следующее — А как в 1С можно прочитать avi-файл? — Платформой никак, только как двоичные данные, а дальше делай с ними что хочешь — Спасибо, все понятно — Читать avi-файл как двоичные данные? Нахрена? — Никто не читает avi-файлы как двоичные данные, это дико, надо использовать потоковое чтение — Граждане, так вопрос же был про 1С, а не про то, как avi-файлы можно и нужно читать в других языках программирования — Да понятно, что в 1С можно прочитать avi-файл только как двоичные данные, но это неправильно, просто 1С так решила ... — Уже было, что читать avi-файл как двоичные данные — это неправильно? |
|||
254
PR
06.03.21
✎
10:59
|
(250) >>Только вот гарантировать, что порядок гуидов при этом будет совпадать с хронологическим порядком записи объектов, они не берутся
А нахрена им это гарантировать? |
|||
255
PR
06.03.21
✎
11:01
|
(251) Да по ходу где-то неподалеку наркоманскую секту адвентистов хронологической сортировки по гуиду разогнали, они все сюда прибежали
|
|||
256
Половинкин
06.03.21
✎
11:56
|
(253) Рома, есть у тебя особенность - любишь до усрачки спорить на пустом месте. Но, с другой стороны, должен же кто-то на Мисте посетителей развлекать...
|
|||
257
PR
06.03.21
✎
12:02
|
(256) Да в принципе да, можно было остановиться на (2) и проигнорировать дальнейшую бредятину, но вот что-то решил поспорить
|
|||
258
Serginio1
06.03.21
✎
13:34
|
(115)>> То есть если я в номер вместо 0010123 напишу 0000001, то он сразу станет самым первым в этой секунде что ли?
Для кассовых документов номер документа является уникальным в течении года. Что ты хочешь от получения ппоследний по ссылке? Без учета того, что это не внешний гуид сформированный по версии Версии 3 и 5 https://ru.wikipedia.org/wiki/UUID#Версии_3_и_5 Используя максимум(Ссылка) ты получишь последний документ по отсортированный по ссылке. Вопрос что именно тебе нудно? Как я и писал проще использовать Выбрать последние и отсортированные по нескольким полям. Какие это будут поля зависит от того, что тебе нужно. v8: Подзапросы с Выбрать Первые Но если ты используешь пагинатор, то при выводе документов нужно использовать определенную сортировку. Для документов это как правило номер документа, или День документа номер документа. Или ДатаДокумента посекундно и номер документа. Для документа может меняться время очень часто. Ставят в конец или начало дня. Итд Можно делать что угодно, но МАКСИМУМ(Ссылка) вернет последний документ отсортированный по ссылке byte[16] Хотя время документа может быть изменено, GUID может быть получен из внешней системы итд. Но все зависит от того что тебе нужно. |
|||
259
GANR
06.03.21
✎
13:49
|
(0) Профайлер посмотри - увидишь в какой SQL-запрос превращается 1С-ный запрос
|
|||
260
GANR
06.03.21
✎
13:50
|
в (49) вон показывает человек
|
|||
261
PR
06.03.21
✎
16:32
|
(258) Да прочитай уже ветку что ли, уже сто раз сказали, что нужно
|
|||
262
Serginio1
06.03.21
✎
18:43
|
(261) Читать долго. В любом случае правильно использовать выбрать последние по нескольким полям в зависимости от условий. Или ты не согласен?
|
|||
263
PR
06.03.21
✎
19:02
|
(262) Не согласен, но спорить с тобой не буду, раз чукча не читатель, не хочу объяснять каждому отдельно, замумило уже
|
|||
264
Serginio1
06.03.21
✎
19:09
|
(263) Мне интересно твое мнение и твои аргументы. То, что я читал, даже чукче ну ни как не аргумент.
|
|||
265
PR
06.03.21
✎
19:28
|
(264) Мой аргумент очень простой
Сама 1С использует сортировку по дате + ссылка (момент времени — это то же самое и есть) как единственный вариант упорядочивания, когда речь идет о необходимости упорядочить документы Будь то для журнала документов, будь то для последовательностей, будь то для формирования движений по регистрам, будь то для отчетов, где угодно |
|||
266
PR
06.03.21
✎
19:31
|
+(265) Вообще, 1С при необходимости берет и добавляет нужные для упорядочивания реквизиты, например номер строки в регистрах
А тут почему-то решила завязаться на регистратор, хотя можно было бы сделать другой реквизит числового типа |
|||
267
Serginio1
06.03.21
✎
19:48
|
(265) Молодец! И как же противоречит то что я сказал, что нужно использовать Выбрать последние по нескольким полям в зависимости от условий?
В данном случае Дата, ссылка, но может и Дата, уникальное значение в течение дня. Ты же подтверждаешь мои слова. Но почему то ты с моими выводами не согласен! |
|||
268
PR
06.03.21
✎
19:50
|
(267) Никак не противоречит, так тоже можно
Но для ТС в (0) лучше один раз сразу для всех номенклатур посчитать и потом слева присоединить, чем каждый раз выполнять выбрать первые 1 Логично? |
|||
269
PR
06.03.21
✎
19:53
|
(268) Кстати, вот по поводу того, что это будет быстрее, я как рах не уверен, ХЗ, но вообще по логике должно быть быстрее
|
|||
270
Serginio1
06.03.21
✎
20:15
|
(269) Зависит от используемого индекса. Если сортировка использует индекс будет одинаково.
Выбрать первые ты тоже можешь использовать в подзапросах v8: Подзапросы с Выбрать Первые |
|||
271
mikecool
06.03.21
✎
20:32
|
случайно наткнулся: "Это решение отличается от применяемого сейчас сомнительного приема, когда документы внутри одной секунды упорядочиваются по внутреннему идентификатору и таким образом погашаются в случайной последовательности."
https://infostart.ru/1c/articles/262300/ |
|||
272
PR
06.03.21
✎
21:13
|
(271) >>таким образом погашаются в случайной последовательности
>>Неоплаченные долги при распределении оплаты по правилу ФИФО Противоречие и непонимание сути, дальше можно не читать |
|||
273
youalex
06.03.21
✎
23:56
|
(249) >>ГДЕ Ссылка > &СсылкаПредудыщая"
Дин. списки и списки объектов в ОФ вроде бы по такому же принципу выводят данные порциями, типа select top 25 * where _IDRRef > @PrevRef |
|||
274
Cthulhu
07.03.21
✎
01:00
|
(272): ммм... как бы это помягче то сказать.
с самого начала, будучи знакомым со статьями ильдарова с одной стороны - и этим вашим "творчеством" и этим выводом в частности - с другой, почему-то решил, что действительно, вас можно не читать ничего при этом не теряя (в отличие от статей ильдарова). а отдельно повнимательнее перечитав процитированное вами вкупе с вашим "выводом", а также перечитав эту статью ильдарова - понял что это решение верное. |
|||
275
vi0
07.03.21
✎
07:37
|
(271) да, эта случайность может боком выйти
я с чем то подобным сталкивался, когда сверка в двух базах не сходилась по подобной причине |
|||
276
Провинциальный 1сник
07.03.21
✎
07:55
|
Этот вариант сортировки по гуидам в пределах секунды плох ещё и тем, что не дает пользователю возможности явно управлять последовательностью. Потому что гуид документа генерится один раз при записи объекта, а при перепроведении не меняется. И интерфейсных возможностей "подвинуть" документ в последовательности - просто нет. Да и программных, по сути, тоже. Перегенерация гуида для этой цели и перезапись объекта с новым гуидом - это какие-то кривые костыли.
|
|||
277
Провинциальный 1сник
07.03.21
✎
08:18
|
А вот что пишет ИТС по этому вопросу в https://its.1c.ru/db/metod8dev/content/2737/hdoc
"Значение ссылки уникально среди документов всех видов, поэтому порядок следования документов будет детерминирован, даже при просмотре журнала, включающего несколько видов документов или объединения документов разных видов в запросах. Однако следует учитывать, что значение ссылки генерируется системой без какой-либо гарантии получения неубывающей последовательности. То есть взаимное расположение в хронологической последовательности двух документов имеющих одинаковую дату (включая время) не зависит от порядка создания документов или от чего-то другого. Соответственно не существует возможности изменить порядок расположения двух документов в пределах одной секунды. Таким образом, порядок двух документов с одинаковой датой можно считать неопределенным, но система обеспечивает неизменность этого порядка после записи документов." |
|||
278
Провинциальный 1сник
07.03.21
✎
08:28
|
+(277) И вот для решения этой проблемы в 1с придумали очередной костыль в виде "оперативной отметки времени", когда дата документа тупо инкрементируется на секунду (фальсифицируется) для обеспечения уникальности. В гамаке и на лыжах, героически преодолевая созданные ими самими же трудности.
|
|||
279
PR
07.03.21
✎
11:55
|
(278) Что за "оперативная отметка времени"? Ты точно не про семерку?
|
|||
280
acht
07.03.21
✎
13:40
|
(279) Глобальный контекст (Global context)
ПолучитьОперативнуюОтметкуВремени (GetRealTimeTimestamp) Синтаксис: ПолучитьОперативнуюОтметкуВремени() Возвращаемое значение: Тип: Дата. Возвращаемое значение соответствует текущей дате, но будет не меньше, чем последняя оперативная отметка времени, полученная каким-либо пользователем в этом сеансе работы. Если значение соответствующее текущему времени, которое уже выдавалось, то возвращается значение на 1 секунду большее. Таким образом, система обеспечивает выдачу для всех пользователей в ходе сеанса оперативной отметки времени в неубывающей последовательности. В варианте "клиент-сервер" - в качестве исходного текущего времени используется время компьютера, на котором работает сервер 1С:Предприятия. В файловом варианте - в качестве исходного текущего времени используется текущее время компьютера пользователя. Описание: Получает оперативную отметку времени. Доступность: Сервер, толстый клиент, внешнее соединение. Примечание: Получение оперативной отметки времени выполняется также системой автоматически в ходе оперативного проведения документов. Использование в версии: Доступен, начиная с версии 8.0. |
|||
281
acht
07.03.21
✎
13:41
|
1000 рублей занесешь к ДенисЧ
|
|||
282
PR
07.03.21
✎
14:15
|
(280) И что это и нахрена?
|
|||
283
PR
07.03.21
✎
14:17
|
Есть очень простая тема с не очень удачным решением
А вокруг нее зачем-то какие-то кучи всякого мутного дерьма наворотили |
|||
284
PR
07.03.21
✎
14:21
|
(277) А, так это оказывается про вообще другое https://its.1c.ru/db/metod8dev/content/2312/hdoc
Понатащут всякой дряни в ответ на вполне себе конкретный сабж |
|||
285
Провинциальный 1сник
07.03.21
✎
14:49
|
(284) Это прямое следствие того "не очень удачного решения". Если бы был механизм упорядочения, не завязанный на гуиды - не понадобилось бы изобретать "оперативную отметку времени".
|
|||
286
PR
07.03.21
✎
15:07
|
(285) Оперативная отметка времени — это вообще про оперативный режим проведения, причем здесь нахрен упорядочивание документов?
Выдыхай, бобер |
|||
287
Cthulhu
07.03.21
✎
15:47
|
(286): тебе бы выдохнуть лучше, истеричка. перечитай (280) по слогам. а потом по слогам же - читай слово "также". до просветления. если оно случится. и не прерывайся на метание говна и истерики пока не.
|
|||
288
PR
07.03.21
✎
17:15
|
(287) Какие все кругом умные, плюнуть некуда
Давай еще раз, где отметка используется ТАКЖЕ я понял, давай теперь, какое ее основное назначение и какое это отношение имеет к сабжу? |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |