Слияние и удаление дублирующих персон

[Mich Glitch]

Вообще, конечно, слияние и удаление дублирующих персон под четвёртой версией - это ужас. И совсем не тихий.
Обозначу задачу.
Есть к примеру два Ивана Петровича. Один без указанных родителей. По другому же полная информация. В результате проверки выясняется, что речь идёт об одной и той же персоне.
Казалось бы, чего проще:
- подцепить обоих Иванов Петровичей к одним и тем же родителям;
- на одного из них перекинуть жён и детей;
- ненужный дубль уничтожить.

Однако на каждом из этапов не самый медленный компьютер подвисает минут на пять. В базе сейчас 39591 человек. Такое ощущение, что меняются Ай-Ди по всем персонам. То есть, производится полный обсчёт-пересчёт всей базы.

Учитывая, что у меня процентов около 10 - дубли, сей факт навевает тоску смертную.

Может как-то алгоритм добавления родителей и удаления персон можно оптимизировать?

[vbob]

Может как-то алгоритм добавления родителей и удаления персон можно оптимизировать?

Уже не раз отмечали, что скорость работы ДЖ напрямую зависит от кол-ва персон - чего не должно быть для грамотно построенной Базы данных.

Я не представляю, как вы со своими ~40 тыс. справляетесь, у меня на 7 тыс. порой тормоза на простейших операциях, например при смене названия населенного пункта - и время отклика прямо пропорционально кол-ву персон по данному НП - от 1 секунды до 2 минут.

[hippocamus]

4000 дублей???
Не представляю, как такое вообще могло получиться.

[Mich Glitch]

4000 дублей???
Не представляю, как такое вообще могло получиться.

Да, оно и понятно.
Как движется Ваша работа по составлению библейской генеалогии? Рискну предположить, что никак.
А вот если бы Вы имели опыт работы с архивными документами, особенно со сплошь бесфамильными крестьянами России 17-19 веков и с весьма приблизительными написаниями дат, мест, имён, то очень скоро бы поняли, что дублирующие персоны - это нечто неизбежное.

[Mich Glitch]

vbob,
Я уже оставил минимум полей в таблице.
Убрал сортировки (особенно по датам).
Выставил наивысший приоритет для программы и закрыл все прочие.
Но, увы...

[vbob]

vbob,
Я уже оставил минимум полей в таблице.
Убрал сортировки (особенно по датам).
Выставил наивысший приоритет для программы и закрыл все прочие.
Но, увы...

Это как мёртвому припарки…

Вот Вы выше отметили, "Такое ощущение, что меняются Ай-Ди по всем персонам. " - так оно и есть!

Думаю, что структура БД не оптимизирована на большой объём, т.к. у подавляющего большинства пользователей не более 1 тыс, где тормоза незаметны.

Что делать? - смириться, либо переходить на другую платформу. Автор не будет ради нескольких пользователей что-то кардинально менять, как мне видится.

[hippocamus]

У меня чуть менее 2000. Ничего, живу. Написал только пару утилит для оптимизации.

[o22]

Написал только пару утилит для оптимизации.

Имеется в виду оптимизация для быстродействия работы базы?
Или просто автоматизация не реализованных в программе функций (типа, расставить род группе товарищей)?

[Mich Glitch]

Чем хороша четвёртая версия против третьей?
Сортировка гораздо быстрее (исключая, конечно, даты).

Чем хуже?
Значительно замедлилось редактирование персон.

Моё предложение - иметь возможность выбора двух опций:
а) Работа с уже существующей базой (сортировки, просмотр, отчёты, статистика и пр.)
б) Редактирование базы (добавление, удаление, слияние персон и пр.)

[vbob]

У меня чуть менее 2000. Ничего, живу. Написал только пару утилит для оптимизации.

так помогите Михаулу, напишите утилиту по теме, думаю многие будут благодарны

[hippocamus]

Нет, быстродействие я не трогал. Ускорить можно добавлением дополнительных индексов в таблицы, и разделением таблицы Values на несколько более мелких. Ну, может, ещё какую оптимизацию можно было бы провести. Но нет смысла добавлять в базу эти индексы, если программа с ними всё равно не работает, и скорее всего их затрёт при сохранении.
С датами проблема в том, что они в строковом виде хранятся, да ещё постоянный анализ на юлианские даты.
А с расстановкой рода - да, сделал.

[hippocamus]

Моё предложение - иметь возможность выбора двух опций:
а) Работа с уже существующей базой (сортировки, просмотр, отчёты, статистика и пр.)
б) Редактирование базы (добавление, удаление, слияние персон и пр.)

База данных и так в любой момент времени работает в одном из режимов:
- SetKey (навигация)
- Edit
- Insert
(ну и Restructure, хотя вряд ли он используется при работе программы).
Само редактирование и вставка происходят быстро, независимо от размера базы. А вот навигация страдает. Но дело в том, что перед тем, как выдать данные для изменения, как и для просмотра - программа собирает и объединяет множество полей из полутора десятков таблиц, поэтому и редактирование замедляется. И чем больше полей персоны или события заполнено, чем больше создано дополнительных полей - тем медленнее будет работа.

[vbob]

И чем больше полей персоны или события заполнено, чем больше создано дополнительных полей - тем медленнее будет работа.

здесь (в ДЖ) скорость напрямумю зависит от кол-во записей

прав был учитель информатики, что грамотно созданная структура БД - 95% успеха!

Ну не должна БД с 10 тыс. записей тормозить на современных компах, у нас такие базы были в 1987 году на СМ-1600 и всё летало...

[o22]

Но нет смысла добавлять в базу эти индексы, если программа с ними всё равно не работает, и скорее всего их затрёт при сохранении.

Что значит "не работает"? Разве abs-у нужно указывать индексы явно в запросе? Он не использует их самостоятельно в случае, если в запросе присутствует проиндексированное поле?
И уж явно он их не станет затирать. Это же не clarion, у которого структура хранилась в исполняемом модуле. Хотя я с данной БД не очень хорошо знаком.
А с датами сортировка понятно почему медленная. Это издержки записи даты, как Между, Около, После, До, Или, записи как полной даты, так и только года. Все эти ньюансы нужно учитывать.
Что Вы сделали кроме подстановки рода? Речь ведь шла не об одной утилите?
Нет желания построить отчеты? Тот же FanChart (круговую диаграмму)? Может потом Автор ее и встроил-бы в основной модуль.

[vbob]

А с датами сортировка понятно почему медленная. Это издержки записи даты, как Между, Около, После, До, Или, записи как полной даты, так и только года. Все эти ньюансы нужно учитывать.

а вот сортировка на моём массиве достаточно быстрая, по текстовым полям - мгновенная, по дате - секунды 2, наверное потому-что не использую "около", "между", только точная дата, "до" и "после".

также мгновенный поиск по первым буквам имени или фамилии, т.е. может ДЖ быстро работь и на больших объёмах, - где нет "косяков"?