Народ.

Нужна помощь сообщества.

Ситуация следующая... Клиент просит разработать для него небольшую конфигурацию.
Требования: Нужна некоторая таблица, в которой будет ряд реквизитов, в частности 50 реквизитов (Тип значения Строка) (возможно будет и дальнейшее расширение).
В эти строковые реквизиты возможен ввод значений типа: 12 (одно число) или 14,11 (два числа) или 8.2, 12, 17 (три числа) или 5,7,13,14 (четыре числа) или X (одна буква).
Записей в такой таблице может быть до 50 млн.

Дожна быть какая-то форма поиска сходимости, в которой вносят таких 50 реквизитов и система выдает наиболее схожие варианты из таблицы данных. При этом сходимость нужно определять по каждому полю в отдельности.
Пример:
Есть строка для поиска в определенной ячейки - 12,14
Если мы находим ячейку с наполнением 12,14 (полное соответвие заданому условию) - то это Полное соответвие
Если мы находим ячеку в наполнением 12,17 или 9,14 (совпадает только часть) - то это Неполное соответствие
Если мы не находим ничего - то это Полное несоответвие

Далее нужно отобрать наиболее сходие строки таблицы исходя из результата отбора всех 50 значений строки.

Прошу помощи в формирование алгоритма поиска исходя из 50 млн строк.
Как Вам кажется реально ли такой отбор сформировать запросом?
И еще... если есть у кого-нибудь схожие наработки и вы сможете со мной ими поделиться, то буду весьма благодарен.

Народ.

Кто-нибудь может помочь... хотя бы советом

Один сборный реквизит и пллнотекстовый поиск.

А вообще задача непонятна, возможшо можно придумать простой алгоритм

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

(0) регистры правил

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

>50 полей
>50 табличных частей

Сегодня на балу монстров аукцион - кто больше, господа?

кто предложит за этот хлам 50 баз данных?

Забей на 1С, напиши базу на монге с интерфейсом на рельсах каких-нибудь

Спасибо всем, кто откликнулся.
(8) к сожалению или радости, нужна реализация именно на 1С. Будет все организовано на 1С 8.3 + БСП + доработанный функционал

(4) можно раскрыть тему более подробнее про регистры правил

(2)(3) имеется ли примеры реализации?

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

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

(11) если ты расскажешь, как в 1С в реквизите эффективно хранить кортеж, то алгоритм придумать несложно

(12) что подразумевается под определением "как в 1с реквизите эффективно хранить кортеж"... не совсем понял фразу

(13) набор чисел и есть кортеж

Анализ данных тебе в помощь

(15) не подскажите, каким образом к решению задач можно привлечь анализ данных.

(14) не могли бы вы уточнить каким образом Вы можете решить данную задачу иных системам (каков общий алгоритм работы)?

(7)Похоже про недавнюю тему..пятсот реквизитов;)

1.для сравнения значений А и Б введем операцию сравнения, как написано в условии:
Если А и Б разного типа, тогда 0;
Если А и Б разной длины, тогда 0;
Если А и Б совпадают полностью, тогда 2,
если ... частично, тогда 1,
иначе 0

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

3.полученные веса упорядочиваем, собственно, это и будет результат

(15)А сам пытался открыть дерево анализа данных?У меня оно сразу схлопывается.

(0)А заказчик сказал?зачем ему это надо?Может задача построенна неправильно.Да и 50 реквизитов многовато для одного строкового типа,может не надо такую таблицу,тем более пишешь,что может быть дальнейшее расширение.Судя по всему вхождений может быть много.Огласите весь список,гражданин начальник.

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

Ну например в полнотекстовом поиске есть метод
ПорогНечеткости (FuzzinessThreshold)
Использование:

Чтение и запись.
Описание:

Тип: Число.
Содержит порог поиска в процентах от длины слова.
0 - обычный поиск. Если не 0, то к каждому слову поискового запроса применяется нечеткий поиск с порогом в процентах от длины слова.
Например, длина слова 5, свойство равно 50 (%) - тогда порог равен 2 - т.е. 2 буквы в слове могут отличаться.

(21)Да и не метод а свойство.А вообще автор попал,потому,что не очень понимает задачу.

50 реквизитов*50 млн*sizeof("XX.XXXX")*4= приблизительно 70Гб

Отдельные значения: Очевидно, совпадения существуют редко начиная с 3-х цифр. Все эти строки помещаются в отдельный индекс. Индекс, 3 и 4 цифры. Все различные комбинации 3-х и 4-х цифр, условно, отбрасывая дроби, одним хэшем. Это немного одно поле 4 символа длиной. Дроби можно пройти линейно.

Остальное, - решение поиска 1 и двух определённых цифр в каждом из столбцов. Ничего общего с анализом данных.

В задаче пропущено самое главное: поиск пересечений, т.е. соответствие строк, а не ячеек строк.

И вообще, 70Гб, - столько оперативной памяти поставить можно. http://www.ixbt.com/news/hard/index.shtml?15/34/23

И каждый Божий рабочий день начинается с 5 минут закачивания БД в оперативную память. Скорость же чтения сейчас до 18Гбайт в секунду.

Т.е. вопрос не по теме.

(20)(23) Общая задача такова:
Имеется генетический анализатор ДНК, который возвращает текстовый файл на 51 поле (описание ДНК):
1-ое поле - это номер образца
2-50 поля - это некоторые числовые/буквенные значения (как ранее обозначал для одного поля может быть разный вариант записи - одно число, два числа, три числа, четыре числа или одна буква)

База данных подразумевает наличие n-го количества кандидатов с указанными ДНК.

Необходимо к полученному анализу найти наиболее схожие строки ИБ.

Соответственно, нужно сравнивать значение поля 1 анализа с полем 1 ИБ, поле 2 с полем 2 и т.д. но самое главное это сравнить строки в целом. Наиболее подходящие строки необходимо вывести в отчет.

Думаю теперь задача стала более ясна...

Коллеги, есть еще идеи?

Поля состоящие которые могут состоять из 3 чисел всегда из 3 состоят, или могут внезапно стать состоящими из 2?

(26) SETI )))

определяешь вес строки суммой весов полей и сортируешь таблицу по весам строки.
пример:

Критерии поиска
поле1(число) 12,15 поле2(Текст) "Б", Поле3(число) 13,19, ...

Определяем вес строки в таблице
данныеполястроки1(число)
12,14 сравниваем с критерием, вес получаем 0,5
данныеполястроки2(текст)
"В" сравниваем с критерием, вес получаем 0
данныеполястроки3(число)
13,19 сравниваем с критерием, вес получаем 1
Вес строки получаем 0,5+0+1=1,5

Вроде понятно выразился.

Делай Американским путём: сервер под это (или рабочая станция с 128Гб оперативной памяти) и моментальный поиск через оперативную память.

* Там ведь достаточно будет прохэшировать по первым наиболее вероятно заполненным столбцам. В итоге поиск будет по 5% базы. Летать будет.

(9) http://wiki.kint.ru/index.php/Общие_сведения_о_регистрах_правил_(УАУ)
http://wiki.kint.ru/index.php/Общие_сведения_о_регистрах_правил_(УАУ)
http://wiki.kint.ru/index.php/Регистры_правил._Общие_принципы
http://www.33lab.ru/regpr.html

http://web.archive.org/web/20060224054632/http://www.itland.ru/lib/index.php?id=48
http://web.archive.org/web/20050505221428/http://itland.ru/lib/index.php?id=247

50 кластеров серверов ни кто так и не предложил. Эх вы...

(0) В одной табличной части есть ограничение на количество записей. Более 99999 не запишешь. Проверь.

(0)
1. Хранишь все строками, как и хотел.
2. При поиске разбиваешь строку на подстроки по числам.
3. Делаешь счетчик совпадений, начинаешь цикл по каждому искомому.
3.5 Делаешь еще один цикл по колонкам ТЧ.
4. ЗАПРОСОМ В ЦИКЛЕ В ЦИКЛЕ ПО УСЛОВИЮ ПОДОБНО отбираешь ячейки с вхождениями каждого числа.
5. Чем больше у строки\ячейки совпадений - тем выше ее рейтинг.

Да, перед этим стоит купить серверный массив, как писал(33). Недавно Близзард продавал старые от WOW, могут потянуть. =)

А серьезно - реально подумай над реализацией не на 1С, 1С-ку как интерфейс прелипить.

Я думаю что в таблице 50 млн записей будет в далеком будущем. Даже если предположить что будет база ДНК населения Казахстана, то население на тек. момент составляет 17 млн.

>> (26) к полученному анализу найти наиболее схожие строки
т.е. тебе надо "написать" обычный grep.

1. хранить образцы в файлах.
2. хранить результаты в файлах.
3. использовать grep для поиска результатов по образцам.

Поскольку речь зашла об идентификации ДНК, то прочитать вначале здесь ( http://www.k-press.ru/bh/2003/2/perepechina/perepechina.asp ) во что вляпываешься, и насколько серьезные последствия будут иметь неточности.
А неточности точно будут, судя по уровню заданных вопросов и выбранному "инструменту".

Вообще эта область называется ДНК-дактилоскопия. Известно, как минимум, 4 метода анализа результат по образцам, основанных на природной компоновке азотистых оснований. Во всех случаях применяется довольно мощный статистический аппарат и простым grep`ом тут не обойтись.

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

(0) Я бы смотрел в сторону баз данных.

И ещё подсказка: посмотрите на реализацию условия "все записи в базе данных", особенно его нечёткой версии, в 1С или в другой СУБД.

Например, Деревья Баркхарда-Келлера.

если чего то 50 миллионов, то это уже не 1с

кроме денег

(27) одно поле может иметь переменную длину т.е. возможны варианты, с одним значением или с двумя или с тремя

зачем делать 50 реквизитов?
Можно сделать справочник, табличную часть с двумя реквизитами. Имя, Значение.
Потом запросом отбирать по таблице справочника, по имени. Полученный результат запроса анализировать. Результат анализа результата запроса сохранить в регистр сведений, чтобы при повторном анализе использовать готовый результат анализа...

(44) Я бы раскладывал такой множественный вариант в три разные записи с одним вариантом в каждой.

А если из строки "5,7,13,14" захотят найти 7,14 че покажет поиск ?
А если строка 5,107,13,149" и захотят найти те же "7,14" ?

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

Я бы хранил в таб части, а не в отдельных полях.
И каждое значение полей хранил бы в одном спр-е (скажем спр ЗначениеПолей).

Напр: вводишь в поле "5,7,13,14", код ищет в спр ЗначениеПолей. Если нету такого значения, добавляет новую запись.
Поле "Значение" = "5,7,13,14"
поле Мин = 5
Поле Макс = 14.

Судя по тому, что ТС обратился не Мисту, а не к литературе по теме сравнения ДНК; а также по требованию заказчика "нужна реализация именно на 1С", делаю вывод, что бюджет на столь серьезную задачу нулевой, или близкий к нему. Что неизбежно ведет к провалу.

Поэтому мой совет: отказаться, пока не поздно.

(49) *на* Мисту

(49) тему сравнения ДНК изучал по заметкам в инете... доступа к специализированной литературе к сожалению нет... думал, что может кто-нибудь уже сталкивался с подобными алгоритмами ... быть может не на 1С, а в иных системах

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

(52) Категорически плюсую