Web-based программы

Еще есть немаловажный параметр memory_limit (какой лимит памяти выделен одному процессу скрипта)
Смотреть там же - Администрирование - Информация PHP
И если этот лимит превышен - то скрипт так же прерывает свою работу

Я проверял на базе Генеалогия европейской знати - 33 тыс особ
Проверял связи между двумя произвольными особами около 300 лет разницы
Значения параметра memory_limit 256М не хватило :(
При поднятии лимита до 512М - запрос со скрипом отработал....

Попробуйте с хостером решить вопрос об увеличении memory_limit
Хотя конечно такие огромные значения это слишком "жирно" если речь не идет о выделенно сервере.

Отдельное Вам спасибо за то что нашли метод для стресс-теста Все остальные тесты что я мог придумать по построению отчетов и графиков - просто пыль по сравнению с такой задачей

Yulita написал:

[q]

Странно только, что прямые-то графики он нормально обрабатывает

[/q]

Под разные задачи скрипт потребляет разные ресурсы.
Что бы нарисовать один прямой график - скрипт обрабатывает значительно меньший объем данных, для обработки запроса по нескольким веткам родства - нужно значительно больше исходных данных и как следствие значительно больше памяти, я так даже подозреваю что именно для этого запроса лимит памяти должен быть даже больше чем указанный рекомендуемый при установке. К тому же тут нет четкой зависимости, многое зависит от разветвленности и пересечений родственных связей.
Это пожалуй самый "прожерливый" запрос. Скажем для формирования интерактивного дерева - скрипт использует только те данные, которые нужны для того участка дерева, который помещается на экран. С этим связано, замеченое многими уже, притормаживание при передвигании дерева (идет подгрузка дополнительных данных для отрисовки другого участка дерева).

frato написал:

[q]

Если существует более простой способ устранения нестыковки - буду благодарен, если подскажете.

[/q]

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

[q]

1 PLAC
2 FORM City, County, State/Province, Country

[/q]

И судя по всему, скрипт отсортировал данные именно по этому принципу.
И наверное не правильно будет такое переворачивание... логика скрипта от этого не изменится, он будет продолжать понимать именно такой порядок данных при вводе новых записей City, County, State/Province, Country

Наверняка в админке есть установки по этому поводу, наверное нужно копать где то в эту сторону: Google Maps™-Дополнительно и там в самом низу уровни

И\или стоит поиграться с редактированием этого порядка в гед файле до импорта

[q]

1 PLAC
2 FORM City, County, State/Province, Country

[/q]

Стоит с этим разобраться подробнее...

Для чистоты эксперимента - не забывать чистить кеш:
Администрирование - Очистить директорию данных - выделить чекбокс "cache" - нажать кнопку "удалить"

Возвращаясь к таблицам, в них гораздо быстрее вводится информация из объёмных документов, например, из различных списков людей, чем через генеалогическую программу с последующим формированием гедком-файла.

frato написал:

[q]

yvb написал:

[q]

Есть ли возможность в подобных программах объединения разных древ в одно? В Webtrees я такого не нашёл. Может не так искал?

[/q]

Администрирование->Семейные деревья->Слияние записей

[/q]

Тут Администрирование->Семейные деревья->Слияние записей - речь именно о слиянии записей, а не всей базы. То есть можно конечно всю базу так пройти - но это не удобно и долго. Webtrees действительно не умеет полностью объединять две базы сходу. Webtrees все таки больше позиционируется как программа для одновременной совместной работы и для наглядного предоставления информации. Но это умеют другие программы или специальные отдельные утилиты, например http://www.genmerge.com ( есть как платные так и бесплатные). С одной стороны жаль что нет такого функционала в Webtrees, а с другой - может и хорошо что не перегружена лишними задачами. Главное что стандарт GEDCOM это поддерживает. В любом случае плюс стандартизированных программ на лицо - не важно в какой программе вы работаете, не важно где - результат работы всегда можно сохранить, перенести, объединить и т.д.. (речь конечно о стандартизированных программах).


yvb написал:

[q]

Возвращаясь к таблицам, в них гораздо быстрее вводится информация из объёмных документов, например, из различных списков людей, чем через генеалогическую программу с последующим формированием гедком-файла.

[/q]

Правильнее будет сказать - Вам так удобнее и возможно быстрее.
Мне например - наоборот. В программу я не ввожу повторяющие записи из списка (не ввожу и не копирую, каждое наименование вводится всего один раз). А это значительно быстрее с учетом большого количества повторяющихся фамилий, географических мест, наименований архивов и т.д..
Причем после ввода в таблицу, данные то еще требуют определенной обработки (или речь идет о вводе данных исключительно ради ввода данных? Без всякого дальнейшего использования введенной информации?) В программе - после ввода исходных данных - сразу же имеем конечный результат - в виде различных и многочисленных справочников, графиков, карт, отчетов и т.д..
Тут не о чем спорить - Вам нравится заполнять таблицы - заполняйте на здоровье, но в мире есть много людей которые давно поняли, что если нужно выкопать большой котлован - удобнее использовать экскаватор (специализированную машину), но если очень хочется и очень нравится - то можно покопать и простой лопатой. Так же и специализированным ПО, можно его использовать для более эффективной работы, а можно и на бумаге вообще вести свою базу. Раз спрос есть на это ПО - значит оно кому то нужно, и за платные версии программ люди платят деньги не за нелюбовь к таблицам, а за более эффективную работу.