Нужно сохранять в базе 2 больших числовых двумерных массива (до 1000х1000 целых положительных чисел).
Конфа УТ10.3.

Где и как оптимальнее его хранить чтобы потом получать быстро?

Кроме массивов еще нужно хранить пронумерованный список складов, связанный с этими массивами.
Куда его лучше сохранить?

Массивы можно засунуть в ХранилищеЗначения, но список туда нежелательно так как ссылки на справочник складов.

А почему список со ссылками нежелательно? Типовое версионирование - объекты со ссылочными данными хранятся и ничего. Правда сказать, есть недостаток - не поддерживается контроль ссылочной целостности.

(0) регистры сведений

(2)+1

(1) да в этом то и проблема, лучше нечто с контролем
к примеру регистр сведений

Ну вот, ты сам и ответил на свой вопрос :)

(2) в смысле хранить значения из массивов в записях регистров? или что то другое?

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

Ну и ветки пошли.
Скоро будет "Нужно хранить в базе английское наименование контрагента, как это лучше сделать?".

+(7)Если связь складов с массивами один к одному, то можно вообще не заморачиваться и сделать хранилище в справочнике Склады

(8) подожди. щас будет JSON в дотнете.

(10) Ой, как страшно. А что там такого? То, что JSON что ли? И что такое в дотнете?

(8) И? Нормальный вопрос, имхо. В реквизите или в регистре хранить - нормальный вопрос, если автор сомневается и есть неозвученные ещё нюансы.

(12) Эсники не знают, что есть "массив" :)))))))))))))))))

(13)"Есть" - это в каком смысле?
"Существует","Что это такое" или гастрономическом?:-)

(14) "Есть" (гастрономия) - как. А тут - есть и есть. :))

Азъ есмь

(15)Берешь 16 пироженых, делаешь из них массив(2,8), получаешь торт и ешь:-)

(17) 2,8 не хочу... Хочу - 4,4 :)))))))))
И одной!!!!!

(18)Хочешь стать колобком и укатиться в дальние страны?:-)

(19) Нет. Мишкой и в берлогу - до весны. :)

(7) не, немного не то
2 массива они связаны со всеми складами из списка (это матрицы из алгоритма Флойда)
Размеры массивов это количество складов (поэтому и нужно пронумеровать склады)

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

Пока думаю хранилищезначениф в константы. И список складов тоже туда (в виде ТЗ или СЗ) чтобы лишнего не изобретать

(8) "а самые умные пойдут грузить чугуний"©

(21) нифига у вас складов

(23) ыыы, просто в реальности оказалось что маршруты между складами они по дням недели разные

(24)+ к примеру в Пн есть А>Б, а во Вт нету )) есть только А>В

(21) А чего ты поскромничал? Так и написал - графы...
Первая сотка - была бы срач неимоверный :))))))))

А выводить как будешь?

(26) вот для выводить как раз только найденные маршруты
т.е. две процедуры:

1. Долго считает все маршруты и записывает в 2 массива в базу, используя нумерованный список складов, тоже в базу нуна сохранить

2. Мгновенно получает нужный маршрут используя список складов и 2 массива из базы

(27) Логично....
Только - а как дни недели хранить собираешься?

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

и между ними и "строится граф"
Склад 1(1=Пн) -> Склад 2(3=Ср)
Склад 2(1=Пн) -> Склад 1 (2=Вт)

(29) так может этот двумерный массив идет с фиксированным числом колонок? хотя, городить произвольно колонки в регистре не комильфо. Ну тогда только справочник, у которого каждый элемент - строка из матрицы, а каждая строка в табчасти - значение колонки из матрицы.

(29) в любом случае, в табличном виде, на уровне хранения данных в базе, окажется на каждое значение массива одна запись в таблицах.
Если поле ссылки на склад можно сопоставить со строкой массива тогда ссылка на склад один раз в реквизите элемента Если ссылка на склад идет с номером колонки (при фиксированном количестве колонок по строкам в двумерном массиве, тогда можно соответствие со ссылкой на склады хранить в отдельном списке где-то еще.

(30) склад добавили/убрали или просто маршруты на другой день недели перенесли отправку и "список вершин" меняется, нужно снова пересчитывать

нумерованный список складов это реально таблица вида:
№, Склад, ДеньНедели
1, Склад1, 1
2, Склад1, 2
...
7, Склад1, 7
8, Склад2, 1
...

(31) Эээ так блин в этом то и вопрос ))

При записи в "ХранилищеЗначения" каким образом будет сериализован Массив[N][N] числовой?

(32) Каждый склад везде участвует?

(34) если есть маршруты, склад может участвовать от 0 до 7 раз

(35)+ чтобы массивы были поменьше полное умножение не делаю, только смотря какие склады отправления и склады назначения

если Склад(Пн) нигде не учавствует то и вершины Склад(1) нет

(33) Если число полей в одну запись регистра сведений можно поставить фиксировано, то будет удобней в РС сделать.

Если бы было переменное количество значимых значений по строкам массива, то лучше в справочник с переменным числом строк в ТЧ каждого элемента.

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

(36) Ну, куда ты лезешь - поперед батьки? :) Только хотела сказать...

Таблицу маршрутов покажи (как в (32)).

(37) интересная идея, можно технически взять и массив поделить на число складов и их в ТЧ каждого склада

но не хочу таким извратом заниматься это сложность еще вырастает (потеря быстродействия) а из удобства только хранение в базе

(36) тогда Я бы такое делал на справочнике с ТЧ

(38) Не могу, оно платное ))

(40) проблема что алгоритм (http://catalog.mista.ru/public/442306/) только с двумерными массивами работает
и так начальное преобразование проблеммное еще и усложнять?

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

Кстати, может оказаться, что числовые значения окажутся каждый раз только расчетными от изменившихся оперативных состояний складов, а не фиксируемыми. Фиксация, с потерей времени на запись, потребуется только для записи вершин (или узлов, как ты там их у себя называешь, не знаю)

(43) что быстрее

запросом данные в Массив 1000х1000 (10 тысяч записей) прочитать из чего то?

или просто из хранилища восстановить?

(44) наверное, могу ошибаться, хранилище значений умеет работать с полями произвольного размера.
Т.е. для этого объекта нужен доступ к чему-то в СУБД с блоб-полями, которые считываются сразу большими блоками. Затем уже в оперативной памяти разбираются как нужно.

(45) Вот в этом собственно и вопрос :)

Может быстрее будет не массив в хранилище засовывать а каким то иным образом?

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

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

(47) вот из-за этого у нас с NS и вышел спор,
я утверждал что никакой теоретический алгоритм без напильника низзя напрямую в реальности использовать

если бы преобразовать эти 2 массива
(1-й по сути длина минимального пути между вершинами АхБ, берется как в таблице умножения, 2-й номер предыдущей вершины этого пути) в "готовые маршруты"

то их уже можно было бы как угодно хранить в базе и как угодно получать

но это преобразование для такой реальной (с учетом что периодичности маршрутов по времени) тучи складов-вершин слегка затратно

(48) да тоже дежавю, но не на типовую а на ветку тут

Так сколько складов то в реальности?

(51) тестовые данные 64 склада, 440 маршрутов
при умножении на 7(дней в неделе) выходит расчет для ~400 вершин с 440 ребрами

(52) и чо надо вычислить?

(44) Что то у тебя со счетом 1000х1000 будет мульён.
Прочитать из таблицы будет быстрее, но вот запись будет значительно дольше

(52)+ код на 1С считает все минимальные по длине существующие маршруты примерно 5-10 минут, потом получение любого маршрута мгновенно

только осложняется что нужно брать 7 маршрутов и выбрать из них реальный ))
Допустим сегодня Чт, 4 день тогда считаем/ищем 7 маршрутов (по кол-ву возможных дней в неделе окончания):

1. Склад 1(4) - Склад 2(1)
2. Склад 1(4) - Склад 2(2)
...
7. Склад 1(4) - Склад 2(7)

(54) Все работает, сча тестю с ХранилищемЗначения, если что то не так буду думать уже

(54) блин и правда мульён... совсем старею уже в уме умножать разучился ((

(55) Ты конечно извращенец такие алгоритмы на 1С считать.

(58) это не я извращенец ))

но если подскажете быстрый способ передачи таких данных из 1С куда то и назад буду благодарен и даже ВК наваяю

(59) Передавай  safeArray. В .Net он определится как массив.

(0) Жениться тебе надобно, и все пройдет.

(0) Что это за инфа, которую нужно хранить в 1С?

+62 Продолжу свою мысль.  Допустим, у нас есть некая совокупность данных с определенной структурой. Вспоминаем, как называется "совокупность данных, хранимых в соответствии со схемой данных..."...  База данных!!! :)  Вот и храни во внешней базе данных! Нужно подцепить к 1С - используй внешний источники.  Какой "пихать  н е в п и х у е м о е"?

* опечатка: "Какой смысл..." далее по тексту

(0) В регистре, только в виде одномерного варианта :)

(61) Кандидаток из Москвы пока не рассматриваю :)

(62) вот такая инфа https://ru.wikipedia.org/wiki/Алгоритм_Флойда_%E2%80%94_Уоршелла

(65) и в константе оно хорошо хранится точнее в 3-х константах разных

ЗЫ когда уже 1С придумает "группы для констант", а то только формы и наборы мало помогают

60+ Кстати десериализация массива очень быстра и компактна

var res = new int[20, 20];

            for (int i = 0; i < res.GetLength(0); i++)
                for (int j = 0; j < res.GetLength(1); j++)
                    res[i, j] = i + 20 + j;

            var stream = new MemoryStream();

            var bf = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
            bf.Serialize(stream, res);

            textBox.AppendText(stream.Length.ToString() + Environment.NewLine);

Общий размер байт 1638
20*20*4=1600 и плюс информация о размере массива типе еще 38 байт

(69) а терь плиз повторить тест с 1000х1000 ))

(70)+ и в 1С ))

(70) 4000038

71 Ну в 1С то есть COMSafeArray это и сам сможешь

60+ В Net COMSafeArray  сразу приводится к двумерному массиву. При передаче в 1С он будет как COMSafeArray

(74) а в linux?

(75) В линкус можешь сереиализовать в CSV или JSON.

(76) Да можно

Интересно ограничения на практике на длину передаваемых строковых параметров какие будут

Кстати ЗаписатьJSON(<ЗаписьJSON>, <Значение>, <НастройкиСериализации>, <ИмяФункцииПреобразования>, <МодульФункцииПреобразования>, <ДополнительныеПараметрыФункцииПреобразования>)
Параметры:

<ЗаписьJSON> (обязательный)

Тип: ЗаписьJSON.
Объект, через который осуществляется запись JSON. Поток JSON должен быть подготовлен для записи значения.
<Значение> (обязательный)

Тип: Произвольный.
Объект записи JSON. Меняет состояние потока записи.
Представляет собой значение произвольного типа.
В формате JSON допускается записывать только значения следующих типов:
Строка,
Число,
Булево,
Дата (преобразованная в строку),
Массив,
ФиксированныйМассив,
Структура,
ФиксированнаяСтруктура,
Соответствие,
ФиксированноеСоответствие.
Ключ соответствия (или фиксированного соответствия) должен иметь тип Строка. В противном случае, будет вызвано исключение.
Если будет передано значение, отличное от перечисленных, оно должно быть преобразвоано с помощью функции преобразования.
При попытке записать значение недопустимого типа будет вызвано исключение.
<НастройкиСериализации> (необязательный)

(77) Ограничение только на память

Двумерный массив по сути то одномерный

Или массив массивов

Бугага!!!
мои предсказания в (10) сбылись :)

(82) http://www.anekdot.ru/id/674409/

хотя это http://www.anekdot.ru/id/-9946592/ мне больше нравится :)

(0) Сколько MS SQL Enterp дает полей в таблице по max ?

82 Ну нужно же направить на путь истинный. А то считать матрицы в 1С как то не кошерно. здесь лучше всего подходит С++ с SIMD вычислениями

+(84) т.е. 1000 строк на 1000 столбцов и ... select * from

(84) https://technet.microsoft.com/ru-ru/library/ms143432(v=sql.110).aspx

(85) да я бы проще сделал: сляпал бы по бырому ВК с алгоритмом Дейкстры. выгрузил бы таблицу с ребрами в текст. там будет меньше мегабайта. Расчет магшрута занимал бы полсекунды вместе с загрузкой таблицы. Два часа работы.

85+ http://rsdn.ru/forum/flame.comp/6070881

(88) Я алгоритм Дейкстры знаю, а вот в алгоритм Флойда Уоршелла не вникал.
А так полностью согласен.

(90) я и алгоритм Дейкстры не знаю, но могу скопипастить в интернете. :)

(86) для хранения в sql двумерного массива нужна таблица только из 3 колонок:
Стр,Кол,Знач
первичный ключ (Стр,Кол) - для получения элемента и выборки строки массива
и доп индекс (Кол,Стр) - для получения выборки колонки массива

(92)+ все это отлично ложится в регистр сведений

(91) Он очень понятный. А насчет (10) Поверь, я долго держался. Но считать такие вещи на 1С это извращение.

(92) спасибо тебе, что ты есть.

(92) Это вертикаль .(86) - горизонт

(94) Но я то предложил бинарную сериализацию в 69

(95) звучит почти как: Слава тебе, Господи!

(96) что? какая вертикаль? какой горизонт?
Стр,Кол,Знач - тут и вертикаль и горизонт

(99) Ну это .... прямая .

(99)+ знать о макс количество колонок (Q) в таблице нужно только тогда, когда нужно организовать N-мерный массив, с N близким к Q

(100)
Инд1,Знач - это линия
Инд1,Инд2,Знач - это плоскость, двумерный массив
Инд1,Инд2,Инд3,Знач - это куб
и т.д.
Инд1,..,ИндN,Знач - это N-мерный массив

(101) Скуль знает ...

(69) А вытягивать ты будешь, в циклах?
Я так то рассматривал вариант получение информации под средством запросов :)

(99) Зачем вообще знать количество колонок?
Кто сказал, что в таблица должна быть размера массива?
Какая СУБД такое может предоставить, когда Сегодня там 100, а завтра 10000 элементов?
Человек не сойдет с ума, внося 1000 колонок в одну таблицу? :)

+(105) К чему такое расточительное хранение информации? :)

(105) ладно вам. ну ляпнул человек неподумавши.

(105) эти вопросы ко мне?
я не говорю про 1000 колонок в одной таблице
я говорю что двумерный массив размещается в трех колонка одной таблицы

+(107) хотя 1000 столбцов это додуматься надо :)

(107) кто ляпнул не подумавши?
озвучь мой ляп

(88) если бы

просто между складами ездиют не каждый день а по дням недели
день пропустили значит что?

или ищем обходной маршрут в тот же день или нужно ожидание в каком то складе

(110) да не ты

(108) Не, не вам, у вас так как должно быть :)

(111) и что это меняет? поставь в массиве Infinity, если не работает.

(114) а каким значком в 1С можно заменить "8" на боку то?

+(114) да и вабще, у тебя 64 склада. даже в 1с считать будет быстро, без ВК можно обойтись. Только алгоритм Дейкстры нужно набивать в 1с (если его нету ещё)

(116) 64(склада) * 7(дней в неделе) = ?
вообще то

(115) зачем тебе значки? буквами напиши или цифрами.

(117) ну это ты так решил. может же быть и по другому.

(117) они у тебя по нескольку дней ездят? типа дальнобойщики?

Блин как в 1С получить разницу в днях между 2 днями недели по нормальному течению?

1(Пн) - 4(Чт) = 3 дня разницы
4(Чт) - 1(Пн) = 4 дня
5(Пт) - 1(Пн) = 3 дня

(121)+ в смысле переход Вс-Пн когда с 7 дня на 1 день по кругу это учитывать?

(120) они заразы до 14 дней ездят

(119) по другому уже Флойд работать не будет )) и нужен волновой или еще что

(124) а я не знаю чем тебе Флойд поможет.
Рёбра у тебя в часах пути или в километрах?

(121) Так правильно?

Если ТекДеньКуда>=ТекДеньОткуда Тогда
   ДлинаВДнях = ТекДеньКуда - ТекДеньОткуда;
Иначе
   ДлинаВДнях = (7 - ТекДеньОткуда) + ТекДеньКуда;
КонецЕсли;

(125) ребра в СрокТранзита или СрокТранзита + 1 день иногда

(127) в днях чтоли

(128) угу

(129) так они у тебя комивояжеры

интересная фигня получается. таблицу дашь поглядеть?

(130) еще те млин вояжеры

(131) потом как сдам выложу с демо данными своими придумаю

(132) ну ладна. парься сам тогда. займусь чем нибудь другим.