limych / genibase Goto Github PK

Введены справочники dic_reason2reason и dic_rank2_rank. Первый уже сейчас используется при формализации. Второй - нет.
По званиям надо запланировать переделку таблицы person - чтобы там индексы хранились из dic_rank, а не сами значения

Мысли по-поводу будующего администрирования базы в плане исправления ошибок, обнаруженных посетителями...

Представляется оптимальным такой алгоритм:

1. посетитель обнаружил, что данная конкретная запись содержит ошибку (не совпадает с оригинальным сканом/неправильно формализована и т.п)
2. совершает действие, чтобы отметить эту запись как ошибочную (например, ставит флажок в соответствующем столбце или нажимает на кнопочку)
3. база предлагает ему ввести правильный вариант записи, т.е., если посетитель согласен, ему открывается соответствующая форма, в которой он ДОЛЖЕН заполнить ВСЕ(!!!) поля записи правильно (по-умолчанию, их можно открывать заполненными старым вариантом)

С помощью со стороны посетителя всё.

Далее два режима:

1. работа администратора - отбор записей, предложенных к исправлению, проверка, подтверждение/отклонение исправления
2. автономная(!!!) работа базы данных, которая заключается в том, что база ожидает, пока данную конкретную запись не предложат ИДЕНТИЧНО(!) исправить два (три... как решим) разных(!) посетителя. А как только такие предложения, сохранённые в спец. таблице, появятся - так сразу система их и использует.

Вариант 2, как видно, совсем не противоречит варианту 1. Но добавляет системе некоторую независимость от необходимости действий администратора.

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

Новая, более защищённая от взлома, система работы с СУБД MySQL.

По № списка выдаёт пустой результат. К тому же кол-во возвращённых записей пишет равным 1.

Удалить ненужные таблицы/поля, привести все имена к нормальной форме.

Переименования таблиц базы:

• dic_marital → dic_maritals
• dic_rank2rank → dic_rank2id
• dic_reason → dic_reasons
• dic_reason2reason → dic_reason2id
• dic_region → dic_regions
• dic_religion → dic_religions
• dic_source → dic_sources
• dic_source_type → dic_source_types
• dic_user → dic_users

Переименование/Удаление полей таблиц/вьюшек:

• persons:
  • list_nr → ×
  • list_pg → source_pg
• dic_source:
  • pg_correction → source_pg_corr
• v_persons:
  • source_pg_correction → source_pg_corr
  • list_pg → source_pg

Оптимизация запросов к СУБД с целью максимального ускорения его работы.

Предлагается запретить поисковикам индексацию слишком больших результатов поиска. Тем самым уменьшится нагрузка на базу данных.

Алгоритм вычисления границы — вопрос открытый.

Как вариант, предлагаю запрещать все результаты поиска, в которых в запросе используются метасимволы и в результате найдено более 300 строк.

1. форма для правки данных (edit, которая) сейчас портит сведения из raw по источникам (она всегда его берёт нулём и вычисляет по № страницы, вродебы). Сейчас это неправильно! Новые данные (не из списков, а из Разведчика, например) грузятся в raw с уже заполненным source_id
   edit-форма его затирает
   Это надо не забыть проверить!!!
2. по ней же. Сделать второй режим её работы. Не формализация, а правка. Недоделано

Разметка в соответствии с общепринятыми стандартами.
См. http://schema.org/Person

В идеале (мы же будем к нему стремиться?) - вероисповедания тоже надо иерархическими делать.
Ну, примерно такой же, как и в иерархии по АТД smile.gif - увидеть картину по трём главным вероучениям вцелом, т.е. по христианству, буддизму, исламу.

Система управления сообществом волонтёров для максимально точной ручной оцифровки массивов документов.

Создание алгоритма поиска, нивелирующего возможные ошибки написания/прочтения рукописных и печатных текстов на бумажных носителях.

Онлайн вьюер с возможностью ссылаться на конкретную часть любой страницы.

После заливке всей базы пройтись по всем спискам и посмотреть, какие записи выбиваются по дате из общего фона для каждого списка.

1. это происходит несинхронно с формализацией
   В итоге, счётчик пишет, что всё доступно для поиска, а фамилии не находятся (нет индексов).
   Либо конкретизировать работу счётчика (например, писать "формализовано ХХХ, индексировано YYY"), либо расширять основной запрос (по id) на неиндексированные записи

2. запрос, отбирающий фамилии для индексации работает, как мы ещё раз недавно перепроверили, верно
   Но неверны, по-моему, запросы, отбирающие по этим фамилиям записи для индексации (на delete и insert). Туда ТОЖЕ надо добавить ограничения на даты модификации и смены алгоритма.
   Потому как похоже, что залил я сейчас Георгиевских... Там есть Иванов. Вот индексатор ВСЕХ Ивановых заново перелопачивает!!! А надо - только добавленные записи.
   Залил 5,5 тысяч строк, а 350 тыс. строк индексов уже обновились! %)

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

Важно также заложить автоматическое отключение режима, если он включён слишком долгое время (на случай сбоев с обновлением).

Warning: Invalid argument supplied for foreach() in /home/www/z77591/1914/stat.php on line 109

Кажется затыкается на статистике по вероисповеданиям и семейному положению.

Какая-то проблема на стороне MySQL

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

1) Расширенный поиск, список событий - неверная сортировка строк.
Мне добиться решения не удалось

7) Инструкция для пользвателей:
"В списках можно выбирать по нескольку значений. Для этого кликайте мышью держа зажатой клавишу «Ctrl» («Command» для Mac)."
Предлагаю добавить: "Повторный клик по выбранному значению с зажатой клавишей позволяет отменить выбор".
А то я вот, например, далеко не сразу до этого допёр. :)

15) сообщение "В полях «Страница источника» и «ID записи» можно перечислять по нескольку значений через запятую или пробел." нет «Номер источника»
Извращение, конечно, но можно формировать эту фразу динамически - на основе массива цифровых полей.

16) футер всех страниц - слова о принципах размещения и использования данных базы.
Мне кажется, что "Обратите внимание:" тут не подходит. Надо что-то типа "(Copyright)" - вначале, "(с)" - в конце, или вообще ничего. Вообщем, подумать над этим...

22. additional_info из результатов у нас ушло - надо возвращать (и думать про поиск по нему - как бы не пришлось его в основную таблицу persons для этого добавлять)

1. переделать на обновляемую таблицу, в которую ежесуточно будут заноситься данные за прошедшие сутки
   это избавит от повторных "тяжёлых" запросов - тем более, что анные за прошедший период можно считать статичными
2. добавить столбцы со средними скоростями выполнения запросов
3. саму страницу настроить на работу с представлением (таблица + данные за текущие сутки)

Вообще, по хорошему, надо покопаться в java-скриптах для OLAP-кубов. Ссылки я приводил на форуме. Но при их использовании, возможно, не удасться сохранить единый стиль оформления.

По ходу мысль родилась, не знаю, насколько фантастично ее претворение в жизнь.
Допустим, в одном источнике одни данные про Иванова Ивана Иванович (список №.. - ранен тогда-то), в другом источнике про него же (список №... - убит тогда-то).
Затем в третьем, ином, источнике, что он служил в такой-то роте такого-то полка.
В четвертом, ином, источнике, о нем же информация, что похоронен после боя там-то.

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

Такое слияние возможно, НО ни в коем случае НЕ в автоматическом режиме.
Мы можем на эту возможность ориентироваться на будущее. Например, ввести регистрацию пользователей и исследователям дать возможность самостоятельно ВРУЧНУЮ создавать сводные карточки по интересующим их людям, которые уже показывать (если разрешит исследователь) всем остальным пользователям.

Но всё это — уже серьёзный шаг от просто фактографической базы данных к генеалогической социальной сети.

Сделать второй режим её работы. Не формализация, а правка. Недоделано

НО!… Это надо делать ТОЛЬКО при публикации новой версии, т.к. иначе старая перестанет корректно работать с именами.

Есть сведения о некрополях 1МВ в Европе, где данные о похороненых указаны латиницей.
Часть, теоретически, можно транслитерировать, но, наверное, не стоит (?)
Часть - точно не поддаётся этой операции

В связи с этим продумать вопрос о хранении и поиске такого типа ФИО:

• опциональный режим ввода фамилии на транслите (т.к. не ясно, ищут русскую или английскую её весию)
• построение ключей(!!!) - фонетического и графологического

Был 10 пункт в мелких багах первоначально. По поводу отсутствия указания на некоторых участников.

Позже было предложение формировать эту страницу на основе справочника dic_user.

Сейчас справочник модифицирован. На его основе создано представление v_user.

Надо подумать/договориться по-поводу расшифровки типов ролей (степени участия в проекте). Я сейчас сделал во вьюшке так же, как и в текущем варианте страницы. Плюс добавил категорию помошников.
Возможно, типизацию надо будет расширить.

когда нажимаешь кнопку "Поиск", внешне ничего не происходит, и поначалу реакция поисковой системы непонятна.
Можно ли поставить какой-нибудь индикатор того, что "процесс пошел"?

Неплохо было бы сделать в рамках сайта такую страницу.
Можно даже некоторые новости добавлять не неё в автоматическом режиме - например, "За такие-то сутки изменилось кол-во доступных для поиска записей"

А рассылка - просто удобно следить за проектом, кому интересно. Заодно нам доп. статистика о постоянных пользователях.

форма для правки данных (edit, которая) сейчас портит сведения из raw по источникам (она всегда его берёт нулём и вычисляет по № страницы, вродебы). Сейчас это неправильно! Новые данные (не из списков, а из Разведчика, например) грузятся в raw с уже заполненным source_id
edit-форма его затирает
Это надо не забыть проверить!!!

Введены справочники dic_reason2reason и dic_rank2_rank. Первый уже сейчас используется при формализации. Второй - нет.
По званиям надо запланировать переделку таблицы person - чтобы там индексы хранились из dic_rank, а не сами значения

Кроме того переименовать таблицы в dic_reason2id и dic_rank2id, соответственно (для лучшего понимания их назначения).

Больше всего сейчас проблем с расширенным поиском.

Скрипт инсталляции чистой системы с базой. Как минимум для целей автоматического тестирования кода.

А также функция, распознающая необходимые структурные изменения в схеме таблиц, и применяющая к базе только их.

Перед этим необходимо сделать механизм хранения опций системы.

Одновременно перевод системы на английский язык.

Переход на систему хранения информации, когда отдельно хранятся данные о персоне и о событиях, происходивших с какими-либо персонами из базы. И обе эти части базы взаимосвязаны между собой ссылками M:N.

Формируем набор правил (строго только на реальных примерах):

• «ьш» = «ьм» = «ын» (Ольшанец/Ольманец/Олынанец)
• «ев» = «оз» (Морев/Мороз)
• «Н» = «И» (Новиков/Ио…)
• «а» = «е» (Сатанин/Сетенин)
• «п» = «м» = «н» (Храпов/Храмов; Шурамов/Шуранов)