Древо Жизни

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

tirael написал:

[q]
kotbasikcom написал:
[q]

1. Как я понимаю, логика программы такова. Есть объект - Персона (INDI - индивидуал, с присущими только ему уникальными свойствами) и все остальное (связи, события и т.д.) "крутится вокруг". Если сделать массовую замену, значит признать свойства Персоны не уникальными. А это другая логика и другая программа.
[/q]

Нет, не так. Есть такое понятие, как идентификатор и первичный ключ, который является уникальным идентификатором объекта (персона, место, событие)......
[/q]

В очередной раз убеждаюсь, что не умею толком объяснять то, что имею ввиду. Я немного знаю, как работать с базой, т.к. в свое время самостоятельно, т. е. без CMS, нацарапывал свой сайт на PHP, делал базу на основе таблиц из ДЖ и админку к сайту.
Попробую еще раз объяснить и больше не буду.

Я имел ввиду то, что ДЖ сделана по принципу редактирования одного отдельного объекта с уникальными свойствами (отдельное окно), а не редактирования коллекции таких объектов (таблица). Почему персона это основа - попробуйте на пустой (новой) базе создать событие или место (у них будут ID) без создания персоны и привязки к ней этого события и места и экспортируйте в ГЕДКОМ.

LonerD написал:

[q]
Какой вывод из этого сравнения вы предлагаете сделать?
[/q]

Для себя я вывод уже сделал. Программа потяжелеет и не на 5 mb, а больше, станет "задумчивее" и наверняка появятся доп. баги, т.к. перестаивать и построить заново - вещи разные.
Теперь, надеюсь, понятно.

kotbasikcom написал:

[q]
Я имел ввиду то, что ДЖ сделана по принципу редактирования одного отдельного объекта с уникальными свойствами (отдельное окно), а не редактирования коллекции таких объектов (таблица).
[/q]

Окно это лишь графический интерфейс, для ввода и вывода данных в/из таблиц(ы) БД. Объект в программе (например, персона) - это таблица или несколько связанных таблиц в БД. Я базу внутри не видел, но наверняка это сделано по классике примерно так:

1) есть таблицы в БД "Персоны", "Места", "События", ... .
В таблице БД "Персоны" есть поля ID_person (первичный ключ), фамилия при рождении, фамилия, имя, отчество, дата рождения, место рождения, дата смерти, место смерти, комментарий и т.д. и т.п.
2) при создании персоны появляется новая строка в таблице "Персоны" с новым уникальным ID_person, который в дальнейшем не меняется. Этот ID_person помогает связать между собой несколько таблиц, содержащих информацию о конкретной персоне. В поля таблицы фамилия при рождении, фамилия, имя, отчество, дата рождения, дата смерти, комментарий вносятся сведения из окна "Персоны", которые свободно могут меняться при жизни БД и которые как раз можно менять предлагаемой автозаменой. В поля место рождения, место смерти, место жительства вносится ссылка на строку таблица "Места" (ID_place), в которой содержатся сведения о месте. В поля родители ссылка на ID_person из таблицы БД "Персоны" или же ссылка на ID события рождение, в котором уже идут ссылки на ID_person родителей. Их тоже можно сделать меняемыми по автозамене, только их нужно будет уже не вводить в текстовое окно, а выбирать конкретные данные из таблицы программы (таблицы БД).

Резюме: Первичные ключи нельзя менять - это нарушит целостность базы. Текстовые поля можно менять автозаменой как угодно - они лишь влияют на визуальное представления информации, на целостность БД это никак не повлияет. Ссылки на первичные ключи в других базах данных тоже можно менять автозаменой, но вместо одной ссылки нужно выбрать другую ссылку, а не произвольный текст, тогда целостность тоже не будет нарушена. Все это легко решается разработчиком на этапе создания визуального интерфейса для автозамены. То, что уникально для нас, как для пользователей и генеалогов, для БД лишь поля, которым можно задать совокупность любых значений, например, Иванов Иван Иванович или Петров Петр Петрович, а затем поменять их местами, изменить целиком или частично, хоть руками, хоть по заданному алгоритму. На работе программы это никак не скажется и это самое главное, и поэтому я не разделяю ваше мнение о том, почему автозамены никогда не будет.

kotbasikcom написал:

[q]
Почему персона это основа - попробуйте на пустой (новой) базе создать событие или место (у них будут ID) без создания персоны и привязки к ней этого события и места и экспортируйте в ГЕДКОМ.
[/q]

Персона это вообще основа генеалогии. Логично, что в программе и в GEDCOM это будет основной объект. Без человека в генеалогии все остальное не имеет значения. Возможно поэтому в стандарт и не добавили указание на событие без персоны. При этом в БД ДЖ событие вполне себе может быть самостоятельным объектом.

kotbasikcom написал:

[q]
Программа потяжелеет и не на 5 mb, а больше, станет "задумчивее" и наверняка появятся доп. баги, т.к. перестаивать и построить заново - вещи разные.
[/q]

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

kotbasikcom написал:

[q]
свойства Персоны не уникальными
[/q]

Свойства в любой БД не должны быть уникальными. Уникальным должен быть ключ объекта. По сути БД это это связи объектов через их ключи. И всё. Написав джойн по ключам, можно вытащить любую информацию. Другой вопрос на сколько этот джойн будет сложным и как быстро БД обработает такой запрос. Но это уже всё зависит от индексов в базе и оптимизации запроса.
Персона сама по себе уникальна по ключу. Ключ таблицы (ID) то бишь персоны, а поля имя, отчество, фамилия - это свойства. Вот эти свойства и можно менять. Можно хоть 100500 Ивановых Иван Ивановичей создать в БД и каждый из них будет уникален по своему собственному ключу (ID).

romanvm написал:

[q]
kotbasikcom написал:
[q]

свойства Персоны не уникальными
[/q]

Свойства в любой БД не должны быть уникальными. Уникальным должен быть ключ объекта. По сути БД это это связи объектов через их ключи.
[/q]

Я писал про Ерёму (ДЖ), а вы про Фому (БД).
А вообще сейчас в тренде, вытащить фразу из контекста и перевернуть смысл.

kotbasikcom написал:

[q]

Я писал про Ерёму (ДЖ), а вы про Фому (БД).
А вообще сейчас в тренде, вытащить фразу из контекста и перевернуть смысл.
[/q]

В основе ДЖ лежит та же самая БД. Условного - персона лежит в одной таблице, события в другой и связка у них идёт по ключам. Вот вам и вся ДЖ.
И какой же смысл Я перевернул? Разговор шёл про организацию хранения и обновления информации в ДЖ, читай в БД.

romanvm написал:

[q]
[/q]

я так

[q]
Я имел ввиду то, что ДЖ сделана по принципу редактирования одного отдельного объекта с уникальными свойствами (отдельное окно), а не редактирования коллекции таких объектов (таблица)
[/q]

Потому и в ДЖ не одна таблица на все.
и если вы это понимаете как

[q]
читай в БД
[/q]

то плохой из меня объяснятель и получается в итоге холивар

kotbasikcom написал:

[q]
Потому и в ДЖ не одна таблица на все.
и если вы это понимаете как
[/q]

Естественно не одна таблица на всё. Это было бы очень странно, если бы была одна таблица на всё. Теоретически база данных может состоять и из одной таблицы, но как правило состоит из множества таблиц. Информация из которых, повторюсь в который раз, связана ключами. И таким образом можно любую информацию вытащить из БД, если знать структуру таблиц и взаимосвязь по ключам.

в каких генеалогических программах есть массовая замена значений

Быстрый ответ Алисы AI

Содержимое ответа
Я проверила: ни в одной из популярных генеалогических программ нет встроенной функции массовой замены значений «из коробки» (вроде «Найти и заменить всё» в текстовом редакторе). И это не случайность — дело в самой логике таких приложений.
forum.vgd.ru
В генеалогии данные устроены особым образом: у каждой персоны есть уникальный идентификатор (ID), и все связи (кто кому кем приходится, какие события с кем связаны) строятся именно на этих ID. Если разрешить массовую замену (например, поменять фамилию у всех Ивановых на Сидоровых), это сломает внутренние ссылки в базе — цепочки связей разорвутся, и дерево «поедет». Поэтому разработчики сознательно не добавляют такие инструменты: безопаснее запретить потенциально разрушительные операции.
forum.vgd.ru
Что тогда делать?
На практике пользователи решают эту задачу вручную или с помощью скриптов.
Поиск и замена в текстовых полях. Можно пройтись по всем записям (например, по столбцу «Фамилия») и заменить нужные значения вручную.
Массовые операции через экспорт/импорт. Если данных много, можно экспортировать дерево в CSV, отредактировать файл вне программы (заменить нужные значения), а затем импортировать обратно.
Скрипты. Некоторые пользователи пишут небольшие скрипты или используют инструменты вроде Python, чтобы автоматизировать поиск и замену по сложным правилам (например, заменить все отчества вида «Иванович» на пустое значение).

forum.vgd.ru
Какие программы стоит иметь в виду
Я подобрала несколько вариантов, где эта тема всплывает в обсуждениях, но важно понимать: даже там функционал ограничен.
«Древо Жизни». В обсуждениях на форумах пользователи честно отмечают: специальной кнопки «Заменить всё» нет, и для сложных сценариев (массовая замена в связях) инструмент не заточен.
forum.vgd.ru
Gramps. Это open-source проект, и в нём тоже нет готовой массовой замены. Однако сообщество активно пишет расширения и скрипты (например, для замены мест проживания или родов), так что функционал можно расширить под свои задачи.
pedsovet.org
Familio. В этом онлайн-сервисе фокус другой: там есть «История изменений», которая позволяет откатывать правки, но не выполнять массовую замену в один клик.
familio.org
Вывод
Если вам критически важна функция массовой замены, при выборе программы советую сразу проверить, есть ли у неё активное сообщество разработчиков, которые пишут плагины или скрипты для таких задач. А пока — готовьте данные к редактированию вручную или через экспорт, это надёжнее.
forum.vgd.ru

kotbasikcom написал:

[q]
Если разрешить массовую замену (например, поменять фамилию у всех Ивановых на Сидоровых), это сломает внутренние ссылки в базе — цепочки связей разорвутся, и дерево «поедет
[/q]

Ерунда написана.

kotbasikcom написал:

[q]
Я проверила: ни в одной из популярных генеалогических программ нет встроенной функции массовой замены значений «из коробки»
[/q]

Это ни о чем не говорит. Это как если какого-то функционала нигде нет, то и реализовывать его нигде не надо. А как же тогда развивать продукт?

Программа для Windows, Linux и MacOS. До 40 персон бесплатна, неограниченное количество персон при покупке лицензии. Есть поддержка Gedcom