Форум программы Древо Жизни
Слияние и удаление дублирующих персон
Модераторы: Genery, Elena Polyanskikh
- hippocamus
- Сообщения: 1045
- Зарегистрирован: 09 дек 2009 16:28
- Откуда: Рыбинск, Ярославская обл.
- Контактная информация:
Re: Слияние и удаление дублирующих персон
Дата сортируется как раз очень удобно. Я пользуюсь полем sortdate2, в котором 12.?.1875 будет представлено строкой 187599121.
Если нужно найти все события июня 1937 года - пишем Select * from Dates where sortdate2 like '193706__1';
Хотя, насколько я понимаю, лучше пользоваться свойством Filter с установленным Filtered - средства самой БД. SQL-запросы с объединением 3 таблиц работают минут по 5 у меня, я от этой затеи отказался.
o22, для SQL можно не указывать индексы, но я так подозреваю - он в программе не используется. В Dates и в Events нет ни одного индекса, кроме первичного. А не помешали бы. Но использовать их смогут только утилиты, программе они не станут известны.
По вопросу, что я ещё делал - ещё я делал выведение перечня событий и персон по заданному месту. Но с появлением версии 4.4 это уже не нужно. Делал утилиту для правки и удаления стандартных событий. Но это дело сомнительное, не знаю, к чему может привести.
Если нужно найти все события июня 1937 года - пишем Select * from Dates where sortdate2 like '193706__1';
Хотя, насколько я понимаю, лучше пользоваться свойством Filter с установленным Filtered - средства самой БД. SQL-запросы с объединением 3 таблиц работают минут по 5 у меня, я от этой затеи отказался.
o22, для SQL можно не указывать индексы, но я так подозреваю - он в программе не используется. В Dates и в Events нет ни одного индекса, кроме первичного. А не помешали бы. Но использовать их смогут только утилиты, программе они не станут известны.
По вопросу, что я ещё делал - ещё я делал выведение перечня событий и персон по заданному месту. Но с появлением версии 4.4 это уже не нужно. Делал утилиту для правки и удаления стандартных событий. Но это дело сомнительное, не знаю, к чему может привести.
Скачать Информер (для Древа Жизни 4.х). Установить.
Заменить экзешник на вот этот: https://yadi.sk/d/v49r7N46tdixe
Запустить от администратора. Указать путь к базе. Отключить автообновление.
Будет последняя версия 2.43. Рабочая )
Заменить экзешник на вот этот: https://yadi.sk/d/v49r7N46tdixe
Запустить от администратора. Указать путь к базе. Отключить автообновление.
Будет последняя версия 2.43. Рабочая )
Re: Слияние и удаление дублирующих персон
А если точная дата не известна? А она в большинстве случаев - не известна.vbob писал(а):наверное потому-что не использую "около", "между", только точная дата, "до" и "после".
Хотя я по дате тоже тормозов не наблюдаю, правда у меня база не большая 2300 персон. Высказал чисто теоретическое предположение
Это понятно, я имел в виду сортировку по полю, которое содержит не конкретную дату, а ее варианты. И здесь со всякими Между, После и До одним полем не обойдешься.hippocamus писал(а):Если нужно найти все события июня 1937 года - пишем...
А ведь у Автора они работают быстро. И объединяется там около 10-ка таблиц, я так подозреваю.hippocamus писал(а):SQL-запросы с объединением 3 таблиц работают минут по 5 у меня, я от этой затеи отказался.
Тут еще зависит не только от структуры таблиц (удачной или не удачной), а и от умения составить удачный запрос. И тот же первичный ключ в таком деле - лучший способ сделать такой запрос быстрым.
Разве индексы в запросе в данном движке нужно указывать явно? Разве сам движок не станет использовать индекс по полю, если это поле присутствует в "order by", например?hippocamus писал(а): для SQL можно не указывать индексы, но я так подозреваю - он в программе не используется. В Dates и в Events нет ни одного индекса, кроме первичного. А не помешали бы. Но использовать их смогут только утилиты, программе они не станут известны.
Не думаю, что используемая в программе БД, такая тупая, что не сумеет этого сделать сама.
Ладно, кончаем оффтопить.
Но на вопрос о круговой диаграмме Вы так и не ответили.
Или у Автора есть планы на эту задачу? Дмитрий, что скажете?
Сайт программ GedcomReport, DrevoReport http://go.inf.ua
Исследования: Васильковський, Киевский, Звенигородский уезды Киевской губернии
Нежинский уезд Черниговской губернии
Исследования: Васильковський, Киевский, Звенигородский уезды Киевской губернии
Нежинский уезд Черниговской губернии
- hippocamus
- Сообщения: 1045
- Зарегистрирован: 09 дек 2009 16:28
- Откуда: Рыбинск, Ярославская обл.
- Контактная информация:
Re: Слияние и удаление дублирующих персон
Да нет, пока не собираюсь. Я как-то с графикой не дружу особо, да и не нравятся мне эти диаграммы. Вон, у меня phpGedView их строит отлично, они какие-то ненаглядные, да и только по возрастающей. Было бы у меня поколений 15 в базе - тогда может и оценил бы, а так только 9, и только в некоторых ветках.
Скачать Информер (для Древа Жизни 4.х). Установить.
Заменить экзешник на вот этот: https://yadi.sk/d/v49r7N46tdixe
Запустить от администратора. Указать путь к базе. Отключить автообновление.
Будет последняя версия 2.43. Рабочая )
Заменить экзешник на вот этот: https://yadi.sk/d/v49r7N46tdixe
Запустить от администратора. Указать путь к базе. Отключить автообновление.
Будет последняя версия 2.43. Рабочая )
Re: Слияние и удаление дублирующих персон
если точная дата неизвестна, то смысла нет придумывать около или между…o22 писал(а):А если точная дата не известна? А она в большинстве случаев - не известна.vbob писал(а):наверное потому-что не использую "около", "между", только точная дата, "до" и "после".
Хотя я по дате тоже тормозов не наблюдаю, правда у меня база не большая 2300 персон.
пишу год, если не уверен то "до" или "после".
для дальнейшего анализа не вижу особой разницы: умер после 1812 или между 1812 и 1845, всё равно работа ручная
Re: Слияние и удаление дублирующих персон
Не соглашусь категорически.vbob писал(а):если точная дата неизвестна, то смысла нет придумывать около или между…
И тому есть много причин.
Во-первых, банальные тезки, один из которых жил в 18 веке, а другой - в 19-м
Если даты (даже приблизительной) нет, то попасть так сразу на нужного "Ивана Сидорова" не получится. Не секрет, что наши предки не отличались разнообразием имен, а фамилии в силу родственных связей, тоже в дереве присутствуют не в большом разнообразии. Если есть хотя-бы приблизительная дата, то определить есть ли такая персону в дереве и какая по ней информация - проще именно сопоставив дату.
Вторая причина более важна. Особенно для дат рождений и браков.
Когда пытаешься выстроить цепочку событий, то период, в который точно попадает дата, очень в этом помогает. Например, если ищешь брак и известна дата рождения ребенка, то ставишь второй датой (До) именно дату рождения этого ребенка (минус пол-года). Если позже найти дату рождения более раннего ребенка, то дата "До" брака сдвигается. Датой "От" в данном случае может быть дата рождения супруга, к который прибавлено 15 лет от рождения невесты или 17 - жениха.
Со временем рамки предполагаемого брака могут сузится до Между 1835 и 1837, что, согласитесь, несет больше информации, чем пустая дата (ведь "нет смысла придумывать"?) или приблизительная.
И когда ищешь такой брак, уже знаешь за какой период нужно брать дела.
Еще одна причина - когда идешь в архив, то фильтруешь в программе все события по дате того периода, за которые планируешь брать дела, и получаешь готовый список того, на что обратить внимание при поиске.
И это далеко не все. Те, у кого база за большой период времени могут привести Вам еще массу примеров, где серьезный подход к датам со временем позволяет сделать поиск достаточно эффективным.
Сайт программ GedcomReport, DrevoReport http://go.inf.ua
Исследования: Васильковський, Киевский, Звенигородский уезды Киевской губернии
Нежинский уезд Черниговской губернии
Исследования: Васильковський, Киевский, Звенигородский уезды Киевской губернии
Нежинский уезд Черниговской губернии
Re: Слияние и удаление дублирующих персон
немножко отвлеклись от темы. то что Вы написали - это всё понятно и отчасти верно.o22 писал(а): И когда ищешь такой брак, уже знаешь за какой период нужно брать дела.
только дата дате рознь - по разным истоникам они могут разниться очень сильно, и в ранних метриках куча ошибок, описок, путаницы, не говоря об исповедных ведомостях. сам занимаюсь бесфамильными крестьянами, и бывают случаи что даже по записи в метрической книге невозможно определить, у кого родился ребёнок, или чья вдова умерла
Re: Слияние и удаление дублирующих персон
Согласен про кучу ошибок. Но ошибки чаще всего в возрасте. А вот что касается исповедок, то можно ориентироваться на события. Если в ней, например, написано, что некому Ивану в 1840 году 1 год от роду, то со 100% уверенностью можно утверждать, что этот Иван родился не позже, чем в 1840 году, так как он уже есть на белом свете в принципе. А если некая Мария в том же 1840 году вдова, то с большой долей вероятности можно утверждать, что ее муж Василий умер до 1840 года. А если при этом в 1838 году он был жив (и тут не важно, что ему возраст могли наврать на десяток лет), то можно утверждать, что умер Василий "Между 1838 и 1840". И если в 1845 у Марии уже новый муж Федор, то наверняка этот брак состоялся "Между 1840 и 1845".o22 писал(а):и в ранних метриках куча ошибок, описок, путаницы, не говоря об исповедных ведомостях
Не нужно дальше объяснять, что если в этом промежутке времени у Федора и Марии обнаружится рождение ребенка, то диапазон, в котором нужно искать брак, сузится и будет, например, уже "Между 1840 и 1843".
Как раз вот в таких случаях даты и выстраиваются и "Между" весьма в этом помогает.
А если сослаться на большое количество ошибок и на даты "забить" вообще, то вряд-ли в этом отношении далеко сдвинешься. Тем более на бесфамильных.
Сайт программ GedcomReport, DrevoReport http://go.inf.ua
Исследования: Васильковський, Киевский, Звенигородский уезды Киевской губернии
Нежинский уезд Черниговской губернии
Исследования: Васильковський, Киевский, Звенигородский уезды Киевской губернии
Нежинский уезд Черниговской губернии
Re: Слияние и удаление дублирующих персон
это очевидные вещи, никто-ж и не спорит, пишите даты как Вам удобноo22 писал(а):Согласен про кучу ошибок. Но ошибки чаще всего в возрасте. А вот что касается исповедок, то можно ориентироваться на события. Если в ней, например, написано, что некому Ивану в 1840 году 1 год от роду, то со 100% уверенностью можно утверждать, что этот Иван родился не позже, чем в 1840 году, так как он уже есть на белом свете в принципе. А если некая Мария в том же 1840 году вдова, то с большой долей вероятности можно утверждать, что ее муж Василий умер до 1840 года.o22 писал(а):и в ранних метриках куча ошибок, описок, путаницы, не говоря об исповедных ведомостях
по моему селу и приходу в метриках каждая 10 запись содержит ошибки, и не только в датах, появляются неизвестные люди, некоторые рождаются дважды с интервалом в 3-4 месяца, умершие женятся или выходят замуж и мн. пр.
а между тем, задача по теме решается одним оператором (***):
select Event
replace all Id with New_Id where Id=Old_Id (***)
select Person
delete record
refresh
Re: Слияние и удаление дублирующих персон
Если это для Вас очевидные вещи, то вдвойне не понятны Ваши утверждения :vbob писал(а):это очевидные вещи, никто-ж и не спорит, пишите даты как Вам удобно
vbob писал(а):не использую "около", "между", только точная дата, "до" и "после"
Смысл есть и очень большой. И чем больше путаницы в датах, тем он больше.vbob писал(а):если точная дата неизвестна, то смысла нет придумывать около или между…
Сайт программ GedcomReport, DrevoReport http://go.inf.ua
Исследования: Васильковський, Киевский, Звенигородский уезды Киевской губернии
Нежинский уезд Черниговской губернии
Исследования: Васильковський, Киевский, Звенигородский уезды Киевской губернии
Нежинский уезд Черниговской губернии
Re: Слияние и удаление дублирующих персон
ОК. Объясняю Вам еще раз:o22 писал(а): Если это для Вас очевидные вещи, то вдвойне не понятны Ваши утверждения :vbob писал(а):не использую "около", "между", только точная дата, "до" и "после"
1) я лично не использую такие составные конструкции, т.к. заметил, что программа не всегда корректно с ними работает, + на больших объёмах сортировка очень медленная по таким датам
2) нет необходимости досконально высчитывать по каждой персоне диапазон дат и заказывать нужные метрики - это уже всё в прошлом… потом окажется что даты посчитали ошибочно, а так скорее всего и будет, и надо заказывать другие метрики, следом отыщутся новые родственные фамилии и эти же метрики будете заказывать по 2-3 разу.
Давайтье не забалтывать основную тему, я действительно не понимаю чего сложного в слиянии дублей, и почему Дмитрий уже несколько раз отвечал что пока это невозможно?
Re: Слияние и удаление дублирующих персон
Одна из последних обсуждаемых тем на форуме была про слияние деревьев, где упоминалось в том числе про образование дублей. Они и без слияний деревьев образуются, так что дублями приходится заниматься часто (пишу здесь подробно, чтобы не было недопонимания).
Эту важную задачу нужно разбить на две подзадачи.
Первая - найти пары и решить, кого на кого заменять. По моему мнению, эта подзадача не автоматизируется. Конечно, бывают случаи, когда дубли очевидны, но часто дублирующиеся персоны отличаются по разным параметрам. Бывает, что не совпадает буквально ничего - имя или отчество, фамилия или все вместе могут быть разными. Возраст может значительно отличаться (до 5 лет часто, но и 10 лет не редкость). Многие не представляют, какое невероятное количество ошибок встречается в исторических документах. Я бы мог привести примеры удивительных дублей, но формат форума не позволяет. Те, кто давно и много работает с генеалогической информацией, подтвердят, что об автоматической замене можно не думать. Нереально сегодня. В лучшем случае - формировать список потенциальных "жертв" (на удаление).
Но вот мы определились с заменой - выбрана персона, которую нужно заменить на другую. Как я делаю? Я встаю на потенциально лишнего человека, открываю его карточку событий и последовательно во всех событиях заменяю этого человека на другого. Далее сохраняю карточку и удаляю эту персону (с ним уже не связано никаких событий). Часто далее приходится повторять эту работу с некоторыми детьми и женами (при переносе событий могут образоваться новые дубли).
То есть на этапе редактирования остается чисто механическая работа, которую мог бы выполнять компьютер.
Мне кажется, не так трудно добавить одну команду в список персон, например, "Заменить на...", которая бы выполняла перенос событий от одного человека к другому (есть некоторые тонкости, например, уточнение дат у рождения и смерти, но они решаемые). Таким образом, мы бы имели не утилиту, которая бы "перемалывала" правых и неправых и в результате создавала бы еще больше проблем, а аккуратную локальную замену небольшой порции данных.
Наличие такой функции в ДЖ помогло бы сократить рутинную работу, которой остается в программе еще неоправданно много.
Было бы хорошо при этом иметь возможность отката, но это проблема для всех операций в ДЖ (не могу объяснить, почему такая важная функция проигнорирована).
Эту важную задачу нужно разбить на две подзадачи.
Первая - найти пары и решить, кого на кого заменять. По моему мнению, эта подзадача не автоматизируется. Конечно, бывают случаи, когда дубли очевидны, но часто дублирующиеся персоны отличаются по разным параметрам. Бывает, что не совпадает буквально ничего - имя или отчество, фамилия или все вместе могут быть разными. Возраст может значительно отличаться (до 5 лет часто, но и 10 лет не редкость). Многие не представляют, какое невероятное количество ошибок встречается в исторических документах. Я бы мог привести примеры удивительных дублей, но формат форума не позволяет. Те, кто давно и много работает с генеалогической информацией, подтвердят, что об автоматической замене можно не думать. Нереально сегодня. В лучшем случае - формировать список потенциальных "жертв" (на удаление).
Но вот мы определились с заменой - выбрана персона, которую нужно заменить на другую. Как я делаю? Я встаю на потенциально лишнего человека, открываю его карточку событий и последовательно во всех событиях заменяю этого человека на другого. Далее сохраняю карточку и удаляю эту персону (с ним уже не связано никаких событий). Часто далее приходится повторять эту работу с некоторыми детьми и женами (при переносе событий могут образоваться новые дубли).
То есть на этапе редактирования остается чисто механическая работа, которую мог бы выполнять компьютер.
Мне кажется, не так трудно добавить одну команду в список персон, например, "Заменить на...", которая бы выполняла перенос событий от одного человека к другому (есть некоторые тонкости, например, уточнение дат у рождения и смерти, но они решаемые). Таким образом, мы бы имели не утилиту, которая бы "перемалывала" правых и неправых и в результате создавала бы еще больше проблем, а аккуратную локальную замену небольшой порции данных.
Наличие такой функции в ДЖ помогло бы сократить рутинную работу, которой остается в программе еще неоправданно много.
Было бы хорошо при этом иметь возможность отката, но это проблема для всех операций в ДЖ (не могу объяснить, почему такая важная функция проигнорирована).
Приглашаю в гости на opalex.info
- Genery
- Site Admin
- Сообщения: 3372
- Зарегистрирован: 23 янв 2005 06:17
- Откуда: Новосибирск
- Контактная информация:
Re: Слияние и удаление дублирующих персон
В планах есть. Возможно, сделаем это в рамках процедуры удаления персоны: или просто удалить, как сейчас, или заменить на выбранную. Но тут не всё так просто, будут возникать дубли событий, документов и т.п., т.е. для каждого связанного объекта нужна возможность выбора, оставить его или удалить, а для этого нужно видеть и все связанные объекты выбранной персоны.
Дмитрий Киркинский, Genery Software
Кто сейчас на конференции
Сейчас этот форум просматривают: Google [Bot] и 7 гостей