Древо Жизни

Наташа СМ написал:

[q]

Если такой функции нет, может стоит её рассмотреть для будущих обновлений?

[/q]

Моя копеечка.
Никаких массовых замен, по-моему, в программе быть не должно и, предполагаю, не будет.
1. Как я понимаю, логика программы такова. Есть объект - Персона (INDI - индивидуал, с присущими только ему уникальными свойствами) и все остальное (связи, события и т.д.) "крутится вокруг". Если сделать массовую замену, значит признать свойства Персоны не уникальными. А это другая логика и другая программа.
2. Замена чего-то в таблице и тем более в базе - это не замена слова в текстовом файле. Это намного сложнее и не ограничивается добавлением чекбоксов или кнопок. И даже "волшебные кнопки" <button type="рыбка золотая">ЗАМЕНИТЬ ВСЁ</button> или <button type="щука емелина">ЗАМЕНИТЬ ОТМЕЧЕННОЕ</button> не помогут Чтобы было понятно о чем я, сравните вес (объем кода) любого редактора таблиц и ДЖ.
3. Программа "заточена" и на пользователей, мягко выражаясь "не очень умеющих работать на компе", грубо говоря - не скажу. И если добавить еще сложности, то .....
Как то так.

king написал:

[q]

Разработчик пока ничего на этот счёт не ответил. a_003.gif

[/q]

он в принципе ничего на пожелания не отвечает)


kotbasikcom написал:

[q]

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

[/q]

Нет, не так. Есть такое понятие, как идентификатор и первичный ключ, который является уникальным идентификатором объекта (персона, место, событие). Например, id события, id персоны, id места. Как правило вы их не видите изнутри программы. У объекта есть какие-то характеристики (свойства), такие, как фамилия, имя, отчество, дата рождения, .... Есть связи, например, участники события, место события и т.п. Первичные ключи менять нельзя, они служат ссылками/связями между объектами. И разработчик программно не реализует такие изменения. Связи менять можно, но нужно знать ID или также дать ссылку на кого-то (выбрать конкретного персонажа или место из списка). Тут в разумных пределах разработчик может сделать механизм автозамены (например, для указания места, рода, пола). А характеристики/свойства пожалуйста меняйте сколько влезет, это повлияет только на визуализацию, но никак не затронет первичные ключи и связи на их основе. Если вы руками сделаете замену поля "Фамилия" у персон, то вы поменяете свойства объектов "Персона" с определенными id. При этом связи этих персон с событиями, местами и т.п. останутся. Тоже самое будет, если вы автозаменой поменяете у них фамилию на любую(ые), какую сочтете нужными.


kotbasikcom написал:

[q]

2. Замена чего-то в таблице и тем более в базе - это не замена слова в текстовом файле. Это намного сложнее и не ограничивается добавлением чекбоксов или кнопок. И даже "волшебные кнопки" <button type="рыбка золотая">ЗАМЕНИТЬ ВСЁ</button> или <button type="щука емелина">ЗАМЕНИТЬ ОТМЕЧЕННОЕ</button> не помогут

[/q]

Да, в БД разработчик будет программно менять определенные поля и только те, которые менять можно.

kotbasikcom написал:

[q]

3. Программа "заточена" и на пользователей, мягко выражаясь "не очень умеющих работать на компе", грубо говоря - не скажу. 101.gif И если добавить еще сложности, то ..... a_003.gif

[/q]

Если так рассуждать, то в нее не нужно было добавлять фильтры :Р потому как кто-то не может, не умеет, ему это не нужно.

PS: Куда делись эмодзи? :(

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]

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

[/q]

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

kotbasikcom написал:

[q]

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

[/q]

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