Древо Жизни
Программа для Windows, Linux и MacOS. До 40 персон бесплатна, неограниченное количество персон при покупке лицензии. Есть поддержка Gedcom
LonerDдитё боярское  из откуда в никуда Сообщений: 738 На сайте с 2013 г. Рейтинг: 771 | Наверх ##
13 июля 15:28 13 июля 17:55 Владимир Иванов написал: [q] каким образом Вы видите выбор в группу необходимых персон ?[/q]
Открываю таблицу Персон (Событий, Документов и т.д.). Зажимаю Ctrl или Shift, выбираю несколько строк. Нажимаю кнопку на панели (пункт в меню, хоткей) "Найти и заменить" - открывается окно, в котором можно выбрать поля, которые нужно обрабатывать. Интерфейс для выбора полей в программе уже реализован, например форма "Настройка отчёта" - "Неотображаемые поля". И рядом два текстовых поля - "Найти" и "Заменить на". Дополнительные галочки "С учётом регистра" и "Использовать регулярные выражения". Если программа заточена на тех, кого kotbasikcom не хочет грубо называть, то можно сделать кнопочки попроще "Найти", "Заменить на", "Заменить весь текст в поле", "Добавить текст в начало/конец поля". Текстовые логи были бы плюсом, но не первоочередным. А вот отмена последнего действия была бы очень полезным плюсом. kotbasikcom написал: [q] сравните вес (объем кода) любого редактора таблиц и ДЖ.[/q]
Последняя версия табличного редактора (xls, xlsx, csv) Spread32 весит 5 Мб. Последняя версия PlanMaker (аналог MS Excell) из пакета SoftMaker FreeOffice весит 30 Мб. Последняя версия ДЖ - около 100 Мб. Какой вывод из этого сравнения вы предлагаете сделать? --- Дневник || Дергунов, Дырдин, Добрынин, Богатырев, Арехов, Берескин, Попов (Липецкий у.) || Нагорный, Нелипа, Вергун, Борисенко (Богодуховский у.), Лябах, Ростовский (Полтавщина) - Константиновка | Громѣка (Гадяч), Бурдѣй (Перелюб) - Вознесенка | | Лайк (2) |
tirael Подмосковье Сообщений: 1138 На сайте с 2023 г. Рейтинг: 4165 | Наверх ##
13 июля 15:48 13 июля 16:12 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: Куда делись эмодзи? :( --- Ищу сведения: Хижниковы,Хижняковы,Хижинковы (ст.Новочеркасская), Бродские (Одесса, Туркестанский край), Коломойцевы,Зоновы (Никополь,СПб,Мск) Погореловы (Воронеж. губ до1925, Крым/Кубань с1925, Ленинград с 60х), Саватеевы/Савватеевы (Владимирская губ, Москва и обл. Кулебякино), Моисеевы (Рязанская г | | Лайк (1) |
kotbasikcom Москва Сообщений: 210 На сайте с 2011 г. Рейтинг: 212 | tirael написал: [q] kotbasikcom написал:
[q] 1. Как я понимаю, логика программы такова. Есть объект - Персона (INDI - индивидуал, с присущими только ему уникальными свойствами) и все остальное (связи, события и т.д.) "крутится вокруг". Если сделать массовую замену, значит признать свойства Персоны не уникальными. А это другая логика и другая программа.[/q]
Нет, не так. Есть такое понятие, как идентификатор и первичный ключ, который является уникальным идентификатором объекта (персона, место, событие)......[/q]
В очередной раз убеждаюсь, что не умею толком объяснять то, что имею ввиду. Я немного знаю, как работать с базой, т.к. в свое время самостоятельно, т. е. без CMS, нацарапывал свой сайт на PHP, делал базу на основе таблиц из ДЖ и админку к сайту. Попробую еще раз объяснить и больше не буду.  Я имел ввиду то, что ДЖ сделана по принципу редактирования одного отдельного объекта с уникальными свойствами (отдельное окно), а не редактирования коллекции таких объектов (таблица). Почему персона это основа - попробуйте на пустой (новой) базе создать событие или место (у них будут ID) без создания персоны и привязки к ней этого события и места и экспортируйте в ГЕДКОМ. LonerD написал: [q] Какой вывод из этого сравнения вы предлагаете сделать?[/q]
Для себя я вывод уже сделал. Программа потяжелеет и не на 5 mb, а больше, станет "задумчивее" и наверняка появятся доп. баги, т.к. перестаивать и построить заново - вещи разные. Теперь, надеюсь, понятно. | | Лайк (3) |
tirael Подмосковье Сообщений: 1138 На сайте с 2023 г. Рейтинг: 4165 | kotbasikcom написал: [q] Я имел ввиду то, что ДЖ сделана по принципу редактирования одного отдельного объекта с уникальными свойствами (отдельное окно), а не редактирования коллекции таких объектов (таблица).[/q]
Окно это лишь графический интерфейс, для ввода и вывода данных в/из таблиц(ы) БД. Объект в программе (например, персона) - это таблица или несколько связанных таблиц в БД. Я базу внутри не видел, но наверняка это сделано по классике примерно так: 1) есть таблицы в БД "Персоны", "Места", "События", ... . В таблице БД "Персоны" есть поля ID_person (первичный ключ), фамилия при рождении, фамилия, имя, отчество, дата рождения, место рождения, дата смерти, место смерти, комментарий и т.д. и т.п. 2) при создании персоны появляется новая строка в таблице "Персоны" с новым уникальным ID_person, который в дальнейшем не меняется. Этот ID_person помогает связать между собой несколько таблиц, содержащих информацию о конкретной персоне. В поля таблицы фамилия при рождении, фамилия, имя, отчество, дата рождения, дата смерти, комментарий вносятся сведения из окна "Персоны", которые свободно могут меняться при жизни БД и которые как раз можно менять предлагаемой автозаменой. В поля место рождения, место смерти, место жительства вносится ссылка на строку таблица "Места" (ID_place), в которой содержатся сведения о месте. В поля родители ссылка на ID_person из таблицы БД "Персоны" или же ссылка на ID события рождение, в котором уже идут ссылки на ID_person родителей. Их тоже можно сделать меняемыми по автозамене, только их нужно будет уже не вводить в текстовое окно, а выбирать конкретные данные из таблицы программы (таблицы БД). Резюме: Первичные ключи нельзя менять - это нарушит целостность базы. Текстовые поля можно менять автозаменой как угодно - они лишь влияют на визуальное представления информации, на целостность БД это никак не повлияет. Ссылки на первичные ключи в других базах данных тоже можно менять автозаменой, но вместо одной ссылки нужно выбрать другую ссылку, а не произвольный текст, тогда целостность тоже не будет нарушена. Все это легко решается разработчиком на этапе создания визуального интерфейса для автозамены. То, что уникально для нас, как для пользователей и генеалогов, для БД лишь поля, которым можно задать совокупность любых значений, например, Иванов Иван Иванович или Петров Петр Петрович, а затем поменять их местами, изменить целиком или частично, хоть руками, хоть по заданному алгоритму. На работе программы это никак не скажется и это самое главное, и поэтому я не разделяю ваше мнение о том, почему автозамены никогда не будет. kotbasikcom написал: [q] Почему персона это основа - попробуйте на пустой (новой) базе создать событие или место (у них будут ID) без создания персоны и привязки к ней этого события и места и экспортируйте в ГЕДКОМ.[/q]
Персона это вообще основа генеалогии. Логично, что в программе и в GEDCOM это будет основной объект. Без человека в генеалогии все остальное не имеет значения. Возможно поэтому в стандарт и не добавили указание на событие без персоны. При этом в БД ДЖ событие вполне себе может быть самостоятельным объектом. --- Ищу сведения: Хижниковы,Хижняковы,Хижинковы (ст.Новочеркасская), Бродские (Одесса, Туркестанский край), Коломойцевы,Зоновы (Никополь,СПб,Мск) Погореловы (Воронеж. губ до1925, Крым/Кубань с1925, Ленинград с 60х), Саватеевы/Савватеевы (Владимирская губ, Москва и обл. Кулебякино), Моисеевы (Рязанская г | | Лайк (1) |
tirael Подмосковье Сообщений: 1138 На сайте с 2023 г. Рейтинг: 4165 | kotbasikcom написал: [q] Программа потяжелеет и не на 5 mb, а больше, станет "задумчивее" и наверняка появятся доп. баги, т.к. перестаивать и построить заново - вещи разные.[/q]
Как вариант это можно реализовать отдельным модулем. Задумчивее, по идее, программа может стать только в момент работы с функционалом массовой замены, в остальное время необязательно подгружать и использовать функционал. Баги, конечно, могут появиться. Но баги постоянно какие-то появляются, когда выходит обновление, да и без него тоже что-то да находят - достаточно посмотреть не список обновлений, где большинство изменений помечено как "Исправлено". Другое дело, что баги в желаемом функционале могут дорого стоить пользователю, поэтому перед выпуском необходимо длительное тестирование с привлечением людей со стороны пользователей. --- Ищу сведения: Хижниковы,Хижняковы,Хижинковы (ст.Новочеркасская), Бродские (Одесса, Туркестанский край), Коломойцевы,Зоновы (Никополь,СПб,Мск) Погореловы (Воронеж. губ до1925, Крым/Кубань с1925, Ленинград с 60х), Саватеевы/Савватеевы (Владимирская губ, Москва и обл. Кулебякино), Моисеевы (Рязанская г | | Лайк (1) |
romanvm Россия, г. Ефремов Сообщений: 5991 На сайте с 2014 г. Рейтинг: 3987 | kotbasikcom написал: [q] свойства Персоны не уникальными[/q]
Свойства в любой БД не должны быть уникальными. Уникальным должен быть ключ объекта. По сути БД это это связи объектов через их ключи. И всё. Написав джойн по ключам, можно вытащить любую информацию. Другой вопрос на сколько этот джойн будет сложным и как быстро БД обработает такой запрос. Но это уже всё зависит от индексов в базе и оптимизации запроса. Персона сама по себе уникальна по ключу. Ключ таблицы (ID) то бишь персоны, а поля имя, отчество, фамилия - это свойства. Вот эти свойства и можно менять. Можно хоть 100500 Ивановых Иван Ивановичей создать в БД и каждый из них будет уникален по своему собственному ключу (ID). --- Вопрошающие, большая просьба - приводите ссылки на документы из общедоступных источников. | | Лайк (2) |
kotbasikcom Москва Сообщений: 210 На сайте с 2011 г. Рейтинг: 212 | romanvm написал: [q] kotbasikcom написал:
[q] свойства Персоны не уникальными
[/q]
Свойства в любой БД не должны быть уникальными. Уникальным должен быть ключ объекта. По сути БД это это связи объектов через их ключи.[/q]
Я писал про Ерёму (ДЖ), а вы про Фому (БД). А вообще сейчас в тренде, вытащить фразу из контекста и перевернуть смысл. | | |
romanvm Россия, г. Ефремов Сообщений: 5991 На сайте с 2014 г. Рейтинг: 3987 | Наверх ##
14 июля 18:34 14 июля 18:35 kotbasikcom написал: [q] Я писал про Ерёму (ДЖ), а вы про Фому (БД). А вообще сейчас в тренде, вытащить фразу из контекста и перевернуть смысл.
[/q]
В основе ДЖ лежит та же самая БД. Условного - персона лежит в одной таблице, события в другой и связка у них идёт по ключам. Вот вам и вся ДЖ. И какой же смысл Я перевернул? Разговор шёл про организацию хранения и обновления информации в ДЖ, читай в БД. --- Вопрошающие, большая просьба - приводите ссылки на документы из общедоступных источников. | | Лайк (2) |
kotbasikcom Москва Сообщений: 210 На сайте с 2011 г. Рейтинг: 212 | Наверх ##
14 июля 19:41 14 июля 19:43 romanvm написал: [q] [/q]
я так [q] Я имел ввиду то, что ДЖ сделана по принципу редактирования одного отдельного объекта с уникальными свойствами (отдельное окно), а не редактирования коллекции таких объектов (таблица)[/q]
Потому и в ДЖ не одна таблица на все. и если вы это понимаете как [q] читай в БД[/q]
то плохой из меня объяснятель и получается в итоге холивар | | |
romanvm Россия, г. Ефремов Сообщений: 5991 На сайте с 2014 г. Рейтинг: 3987 | kotbasikcom написал: [q] Потому и в ДЖ не одна таблица на все. и если вы это понимаете как[/q]
Естественно не одна таблица на всё. Это было бы очень странно, если бы была одна таблица на всё. Теоретически база данных может состоять и из одной таблицы, но как правило состоит из множества таблиц. Информация из которых, повторюсь в который раз, связана ключами. И таким образом можно любую информацию вытащить из БД, если знать структуру таблиц и взаимосвязь по ключам. --- Вопрошающие, большая просьба - приводите ссылки на документы из общедоступных источников. | | Лайк (2) |
|