На сайте ВГД собираются люди, увлеченные генеалогией, историей, геральдикой и т.д. Здесь вы найдете собеседников, экспертов, умелых помощников в поисках предков и родственников. Вам подскажут где искать документы о павших в боях и пропавших без вести, в какой архив обратиться при исследовании родословной своей семьи, помогут определить по старой фотографии принадлежность к воинским частям, ведомствам и чину. ВГД - поиск людей в прошлом, настоящем и будущем!
Перед тем, как ставить оценку, ознакомьтесь с главной страницей рейтинга архивов, чтобы понять оцениваемые критерии. Оценка 1 - очень плохо, 10 - очень хорошо;
1) Да, обход ограничения на 9995 в случае очень распространённой фамилии возможен только через доп. поля. Но обходить я его предлагаю именно в специфике обсуждаемой программы - т.е. по краям и областям и другим типам АТД: - делаем выборку по фамилии, если < 10000, то сразу переходим к анализу мест; - если > 10000, то делаем выборку по областям и краям (тут неплохо бы заранее иметь этот список, ну или шерстить названия АТД по буквам); - если даже по области > 10000, то либо а) говорим пользователю "Извини, но с такой распространённостью смысл использования данной программы пропадает!", либо б) принимаем, что в этой области заданных фамилий > 10000 и переходим к анализу, либо в) углубляемся до уровня районов и т.д. А делать обязательным ввод имен и дат - это не для этой задачи... Мы же не конкретного человека ищем, а ареалы распространённости СПИСКА фамилий (тут я задумалься про ЕДИНИЧНУЮ фамилию... надо? нет?).
2) исходя из варианта по п.1, общее кол-во записей вряд ли будет больше 10000 умножить на сотню АТД - это максимум около миллиона на каждую фамилию :( Т.е., либо каждую фамилию на отдельную страницу экселя, либо что-то кроме него. Access - из той же среды, с ним через эксель можно работать в крайнем случае. DBase - . Можно ещё MySQL рассмотреть, как вариант (компактно, бесплатно и т.д.). Опять же, нам для данной задачи не надо сохранять ДЛЯ ПОЛЬЗОВАТЕЛЯ выборку всех записей. Нам надо их ВРЕМЕННО сохранить для последующего анализа (да хоть в массиве в оперативке), проанализировать, а только потом выдать пользователю те из них, которые удовлетворяют условиям задачи - т.е. записи о людях с фамилиями, одновременно встречающимися в одной и той же местности. А их то уж точно не миллион будет
P.S.: если публиковать программу через Я.Диск (там можно сделать публичную ссылку как на конкретный файл, так и на папку), то счётчик у тебя будет
Москва Сообщений: 717 На сайте с 2005 г. Рейтинг: 846
Наверх##19 августа 2014 16:4319 августа 2014 16:44
a-KaDeMi-k Денис.. Пункт 1 не пройдет.. Вернее по ДопПолям можно выгрузить ФИО, но не по АдмТер Делению.. Вот по этой ветке Районы я выкладывал наименования РАЙОНОВ из ОБД.. Написание - много вариантов, сокращения - какие хочешь.. единственное, что в АТД есть твердого для зацепки- это наименования РВК, и Областей.... НО. .Наименование то РВК наименованием,а есть еще РВК|ГВК|РеспВК|ГРВК|ВК|ОВК|ОРВК|ОГВК
Как быть? У меня только один вариант решения - Фамилия + ГодРождения. Вот статистика по двум Фамилиям - Иванов и Поляков - в принципе все реально ..
Но опять же вопросы. .а есть Фамилии без Года Рождения. Есть фамилии искаженные, значит надо вводить маски поиска (*).. А это уже все, результаты будут нечеткими.. Это я вопросы накидываю по памяти, по тому, что сохранилось в голове при поисках.. А ели сесть за анализ ОБД - там все окажется хуже..
А нечёткий поиск по фамилии в данной задаче не нужен. Ну, не попадут в статистическую обработку процентов 5-10 носителей (с ошибками ввода), ну и не особо страшно это. Самое большее что из-за этого может произойти, по моему, так это поменяются в результате найденные местности (с максимальным кол-вом одновременно встречающихся фамилий) местами.
Из-за того, что есть уверенность в однотипном написании только названий областей, предлагаю (для пробы) на них и остановиться. Т.е. выводить в результате работы программы именно их, не углубляясь. Надо бы как-нибудь, вообще, сначала проверить, рабочая это идея или нет. А то вот обсуждаем тут, а она, как окажется, того не стоит
P.S.: в прошлом сообщении описался, конечно - не MySQL, а SQLite
Ребята, я тут подумал Дело не в том, что НЕЛЬЗЯ написать программу, или сложно.. Дело в том, что программа будет отдавать НЕПОЛНЫЙ результат.. а это значит - НЕТ результата.. Если человек ищет своего предка, пропавшего без вести, задает фамилию, год рождения, место рождения.. Вот пример.. наугад, Псковская область... Бежаинский р-н, Бежанинский р-н, Бежаницкий р-н, Бежаницуий р-н, Бежанский р-н Это реальные фрагменты адресов из ОБД.. Человек НЕ ЗНАЕТ как пишется в документах его район.. Он введет так, как он знает.. а результат не будет, т.к. или оператор ошибся при вводе (Бежаницуий р-н), или писарь в штабе неразборчиво вписал адрес в донесение.
Просто ввести фамилию и получить 10000 записей.. и что дальше? Просматривать глазами? Эт я говорю про поиск ОБД, штатный..
Мой поиск+выгрузка - повторение алгоритма работы ОБД, он чудес не делает.. А поисковику, если какие то записи выпали из запроса -значит ЗАПРОС не состоялся..
НО.. опять же, нет безвыходных ситуаций. Давайте я все таки сделаю такую прогу.. ФИО, адрес рождения.. все поля будут обязательны к заполнению, поле АДРЕС допускать будет знак * (звездочку)..т.е. Беж* - включает различные окончания слова..
Хотя я пока подожду. .подумаю.. надо поэкспериментировать на ОБД-Мемориал, в HTML варианте.. там выдается количество записей в запросе. .видно сразу -что и как
именно это и хотелось бы.В моем случае, такая же ситуация. усть-кубенский,усть-кубинский,усть-кубанский,Усть Кубенский и т.д. А сколько еще без указания района-область и деревня или только область.
А если писарь написал (В)ежаинский вместо (Б). Писари со временем слепнут оптихоньку, а значит при поиске (выборке) Фамилии (и не только) следует прописать автоматическую замену (подбор) всех вариантов "ПОХОЖИХ" букв:
АБВГДЖЗИЙКЛМНОПРСТУФХЦЧШЩЬЪЭЮЯ
А-Л-Н-П-Ц Б-В-О-З-Р Г-Т Д--Ц-Ш-Щ И-Й-Н-П (такойже вариант попробовать и с маленькими буквами). Разумеется, что похожесть букв следует рассматривать для прописных, а не печатных.
Ну, вобщем, сто-то в этом роде. Да, это увеличит массив информации, но уже на 99% (а не 70) даст результат. Хотя, абсолютного ничего не бывает.
P.S. Даже пишущий здесь на форуме - допускает ошибки (имеющий возможность их исправить). Что происходит с текстом написанном химически карандашом на коленке под дождем?
--- "След на песке может быть вечным, если он остался в памяти..."
С *ORION* Прописные, заглавные в ОБД не различаются.. это уже отпадает.. А вот .. с перебором ПЕРВЫХ букв.. Это уже ближе к искусственному разуму.. Надо создать инструмент, который будет давать результат, а пользователь должен САМ перебирать варианты.
Другое дело, что Пользователь не всегда владеет "искусством" поиска Вот почему я до сих пор и не создал такую программу.. все зыбко, нет четкости.. и повторюсь - если нет 100% го результат - значит нет НИКАКОГО результата..
Spirtovich Вот я и не знаю как соблюсти баланс, между алгоритмом поиска, и мастерством поиска Пользователя? Что бы машина запрашивала ОБД и выдавала то, что запросил Пользователь.. Не знаю. .а пока не знаю - не делаю..
надо? нет?).
. Можно ещё MySQL рассмотреть, как вариант (компактно, бесплатно и т.д.).
