Быстрый поиск комбинации строк в массиве

← →
MsGuns © (2015-05-25 12:49) [40]

>Павел Калугин © (25.05.15 07:51) [35]
>Я бы рекомендовал добавить три поля в которых держать отдельно фамилию имя и отчество в верхнем регистре и очищенных от "мусора". Мусором кроме Е признал бы И Й пробелы, дефисы запятые и т. д.
Это позволило бы эффективнее искать, к примеру, по имени и фамилии без отчества

Невнимательно читаешь. Юра в самом начале сказал, что база - чужая.
Кроме того, тебе, как опытному разработчику, нельзя не знать, что недостаточно просто "исправить" ошибки в базе РАЗОВО, надо еще менять бизнес-правила и, соответственно, политику пользовательских приложений, через которые в базу добавляется информация. А это уже совсем иная "опера".

← →
MsGuns © (2015-05-25 12:53) [41]

Немного из личного опыта. Когда-то пришлось делать системку, где была база населения. На момент, когда я приступил к работе, в имеющейся БД было порядка 2 млн. записей. База была на фоксе. Я ее перетаскивал в Paradox.
Жутчайшие тормоза при работе прекратились лишь тогда, когда я ввел доп.поле-ключ - инициалы.

← →
Ega23 © (2015-05-25 13:06) [42]

> База была на фоксе. Я ее перетаскивал в Paradox.

Вот на этом месте завис. Даже не знаю, что сказать.

← →
кгшзх © (2015-05-25 13:07) [43]

так это поди было еще при андропове

← →
Ega23 © (2015-05-25 13:13) [44]

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

← →
junglecat © (2015-05-25 13:26) [45]

были времена, когда и фокс и парадокс считались прогрессивными субд. Ну типа как сейчас DB2

← →
Юрий Зотов © (2015-05-25 13:36) [46]

> Дмитрий С © (25.05.15 11:10) [38]

> завести поле с хешем фамилии и имени в таблице и индексировать его.

Дык... а я что сделал?

← →
Ega23 © (2015-05-25 14:03) [47]

> фокс и парадокс считались прогрессивными субд

ИМХО, фокс всегда был "прогрессивнее" парадокса.

← →
Павел Калугин © (2015-05-25 15:51) [48]

Юрий Cергеич, один вариант привел - нет отчетсва.
Второй - когда имя и фамилию перепутали полями или при вводе данных или при поиске. По отдельным полям такое можно выловить "комбинацией"
from t_Pers as t
where ((t.fio = @fio) or (t.name = @fio) )and ((t.name = @name)or (t.fio = @name))
Если поле одно то придется уже по подстроке сравнивать, что опять же будет очень долго.

Ну и правильно напомнили, обвесить придется табличку триггером, который это поле/поля заполняет. Иначе вся прелесть пропадет.

← →
MsGuns © (2015-05-25 17:25) [49]

>ИМХО, фокс всегда был "прогрессивнее" парадокса.

Посмеялсо :)

← →
Юрий Зотов © (2015-05-26 00:40) [50]

Блин. Рано радовался. Отменили доп. поле и индекс по нему. Аргумент один - не нравится. И все аргументы "за" перед ним бессильны.

Бред какой-то.

← →
Ega23 © (2015-05-26 01:11) [51]

> Отменили доп. поле и индекс по нему. Аргумент один - не
> нравится.

Сделай доп.таблицу "один к одному", уже в ней - это самое поле. Может так "понравится".

← →
Jeer © (2015-05-26 01:26) [52]

>Юрий Зотов

"Да пни ты их по яйцам" (С)

← →
Юрий Зотов © (2015-05-26 01:42) [53]

> Ega23 © (26.05.15 01:11) [51]

Настаивают вот на чем - засосать всю таблицу (где миллион записей) в память и делать поиск на клиенте. То есть, как раз то, что я обозначил в сабже. Объясняю - не хватит памяти. Не верят. Ок, прямо на глазах внедряю засос всей таблицы в код и запускаю. Получаю, естественно, Out of memory. Убедились. Но говорят - тогда грузи эту таблицу кусками. Объясняю - скорость упадет на порядок - то есть придем к тем же 50 минутам, что и сейчас (в лучшем случае). Снова не верят. Я офигеваю, дорогая редакция. Вместо того, чтобы использовать простое, документированное, гарантированно работающее решение и уже отлаженный код, предлагают изобрести велосипед с квадратными колесами, а код поломать и отлаживать его по новой.

Блин, и че я переживаю? Забить болт и делать, как просят. Я предупредил, что из этого получится? Предупредил. Ну и получайте, что хотели. Только претензии потом сами себе предъявляйте.

← →
Сергей Суровцев © (2015-05-26 01:44) [54]

>Юрий Зотов © (26.05.15 00:40) [50]
>Блин. Рано радовался. Отменили доп. поле и индекс по нему. Аргумент один - не нравится. И все аргументы "за" перед ним бессильны.

Жестко 2 варианта:
1) есть поле и 5 минут
2) нет поля и 50 минут.

"7 целых шапок из овцы не выкроишь никак" (с)

← →
Jeer © (2015-05-26 01:49) [55]

>Настаивают вот на чем

Я давно выбрал вариант, что настаиваю я - профи в том, в чем и сомнений нет.

← →
Юрий Зотов © (2015-05-26 01:52) [56]

> Сергей Суровцев © (26.05.15 01:44) [54]

Один спец считает, что 7 шапок из овцы - запросто. И даже решил показать, как это делается, написал код. Получил, естественно, все то же out of memory. После чего сказал, что это мой код глючит.

← →
Сергей Суровцев © (2015-05-26 01:57) [57]

А если разделить задачу? Сначала выборка по фамилии, а уже из этого набора поиск по имени и отчеству?

← →
Сергей Суровцев © (2015-05-26 02:00) [58]

>Юрий Зотов © (26.05.15 01:52) [56]
>Один спец считает, что 7 шапок из овцы - запросто. И даже решил показать, как это делается, написал код.

Наблюдал таких. Сначала громко орут и матерят Билли, Win, язык прог. А потом тихо бормочут под нос "как же это я это пропустил..."

← →
Юрий Зотов © (2015-05-26 02:09) [59]

> Сергей Суровцев © (26.05.15 01:57) [57]

Так суть проблемы не в этом. Главный вопрос - где искать, на сервере или на клиенте. Если на сервере (как сейчас и как нормальные люди делают) - то да, либо поле есть (и тогда 5 минут), либо поля нет (и тогда 50 минут). А если на клиенте, то идет нехватка памяти и чтобы ее избежать нужен какой извращенный алгоритм. Чесать левое ухо правой рукой через голову (а точнее - через другое место). Причем совсем не факт, что этот алгоритм даст выигрыш в скорости. Скорее всего, не даст и все потуги окажутся напрасными.

← →
Сергей Суровцев © (2015-05-26 02:16) [60]

>Юрий Зотов ©
>Записей в массиве порядка миллиона.

Если я правильно понял, то миллион это ВСЕ фамилии. Если вытащить на клиента 1 фамилию, то выборка будет порядка на 2-3 меньше. А уже ее копать до совпадения массивом. Тогда лишнее поле в базе не понадобится. Основной отсев на сервере, добить на клиенте.

← →
Германн © (2015-05-26 02:48) [61]

Удалено модератором

← →
Kerk © (2015-05-26 02:54) [62]

Сгенерировал хэш-таблицу с миллионом записей (всякий мусор вместо фамилий/имен/отчеств). Сделал к ней 10000 обращений. Выполняется быстрее, чем за секунду. Без каких-то оптимизаций, просто в лоб решение.

Так что если действительно проблемы с памятью (правда, трудно такое представить), нужно сокращать выборку насколько можно.

Сделать select по фамилии, например, как предыдущий оратор советует, а потом уже хэш-таблицу. Или даже по первой букве фамилии. Если база данных захвачена павианами, то это скорее всего единственный вариант.

← →
Kerk © (2015-05-26 02:59) [63]

Проблемы с памятью могут еще быть вызваны ее фрагментацией. Можно в эту сторону покопать. Потому что чисто по объему миллион коротких строчек - это вообще ни о чем.

← →
Павел Калугин © (2015-05-26 07:22) [64]

Всю таблицу на клиента тащить смысла нет достаточно Id и фио. Но я подозреваю что там не миллион записей, а восемьдесят миллионов ;) потому 3*255*80000000 на какого клиента не хватит если не писать это порциями в файл ну и так долее. По сути реализовать локальную СУБД ради одного запроса.
Канал связи клиент-сервер безразмерный и моментальный изобрели уже?

Юрий Сергеич а проверь ка сколько на сервере будет идти инсерт во временную индексированную таблицу этих полей Id и очищенное фио.
Попутно глянь насколько производительность сервера просядет.
Любые телодвижения с клиентом априори будут медленнее.
Выдернуть 80 кусков на 80 клиентов во каждом осуществить поиск и потом результат обработать к выдаче врятли получиться. И не быстрее так уж точно.

← →
Юрий Зотов © (2015-05-26 08:35) [65]

Любые изменения структуры БД (в том числе, создание таблиц, пусть даже и временных) - табу.

← →
Павел Калугин © (2015-05-26 09:19) [66]

Юрий Сергеевич, а хранимых процедур в DB2 разве нетути?
Временная таблица "живет" только на время сессии, как переменная. (ну или переменная табличного типа, если такая есть)
Так что "табу" на это не распространяется ну никак...

← →
Юрий Зотов © (2015-05-26 09:40) [67]

> Павел Калугин © (26.05.15 09:19) [66]

Я в курсе. Но все равно низзя. Считай, что доступен только DML.

← →
D.N. Polezhaev © (2015-05-26 09:41) [68]

А какие проблемы с памятью? Миллион фамилий по 12 букв в unicode это 22МБ данных. Ну с именами отчествами меньше , но всяко меньше 100МБ.

Не понимаю как у профи хватает нервов с идиотами работать )

> хранимых процедур в DB2 разве нетути?

В DB2 - есть. А в базе- нет. Почему - не знаю. Нет - и все. Запрещены.

Удалено модератором

> D.N. Polezhaev © (26.05.15 09:41) [68]

> А какие проблемы с памятью?

Да пустяк - при выполнении SELECT где-то в недрах сервера приложений возникает исключение Out of memory.
:o)

> Юрий Зотов © (26.05.15 00:40) [50]
> Блин. Рано радовался. Отменили доп. поле и индекс по нему. Аргумент один - не нравится. И все аргументы "за" перед ним бессильны.
>
> Бред какой-то.
"родной" конторой повеяло... с таким "убойным" аргументом. ничего не докажешь (у меня не получалось).

> Блин, и че я переживаю? Забить болт и делать, как просят. Я предупредил, что из этого получится? Предупредил. Ну и получайте, что хотели. Только претензии потом сами себе предъявляйте.
а вот тут нет, претензии будут только к тебе, как к исполнителю... я как то пробовал, доходило, прямой письменный приказ выбить с а ля "делать ТАК", ничем не помог, в итоге "мы имели ввиду так, но чтобы правильно работало" (т.е. с неправильной логикой/действиями по ней, но с правильным результатом) и "если не знаешь как правильно спроси у кого нибудь".

лучше вообще не делать. ИМХО. типа "либо делаю по своему, либо кто нибудь другой, ну вот хотя бы тот кто за это решение".

> Да пустяк - при выполнении SELECT где-то в недрах сервера
> приложений возникает исключение Out of memory

Почему бы причину не выяснить?

Тогда я вообще не понимаю.

По условиям задачи в памяти лежат два списка, их нужно соединить по условию равенства.

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

Значит на клиенте задачу решить нельзя из-за не возможности получить сырые данные.

На бд задачу тоже нельзя решить поскольку не дают оптимизировать бд.

Ну и что теперь - всем спасибо все свободны, ветка какая то ни о чем...

> Kerk © (26.05.15 11:31) [73]

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

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

Допустим, каким-то волшебным способом мы это сделали. Тогда задача сводится к быстрому поиску ФИО. Быстрее, чем это сделал бы сервер БД.

Сабж об этом.

я тут вот что хочу сказать. Я не верю в 50 минут тупо в лоб без индексирования фулл-сканом на миллионе записей. Даже с upper и replace.
Такие дела.

> Тогда я вообще не понимаю.
но чтоб к утру было сделано!

стандартная ситуация. :)

Быстрый поиск комбинации строк в массиве Найти похожие ветки