САЙТ и ФОРУМ: вопросы по БД наших проектов, замечания и предложения

[Канадец]

А что с БД? Скоро ли будет доступна?

Пока ничего не меняется, просто повторю:

конкретных планов нет. Судьба самой БД под вопросом.

"Судьба самой БД под вопросом."? Почему? Можно ли помочь чем-то? Неужели только по техническим причинам?

[oztech]

Канадец, а Вы эту тему почитали? Был ответ, выделенный жирным красным шрифтом:

ПОИСК ПО БД "АРХИВНЫЕ ССЫЛКИ" НЕ РАБОТАЕТ. ВОССТАНОВЛЕНИЕ ДОСТУПА К БД "АРХИВНЫЕ ССЫЛКИ" НЕ ВХОДИТ СЕЙЧАС В ЧИСЛО ПРИОРИТЕТНЫХ ЗАДАЧ.

Был ответ, наводящий на мысль, что сама концепция БД морально устарела, требуется освежение идеи. Можете что-то предложить? Как наполнять БД, как поддерживать ее актуальность? Скорей всего, технические проблемы преодолимы, а вот организационные - в тумане.

[Канадец]

Канадец, а Вы эту тему почитали? Был ответ, выделенный жирным красным шрифтом:

ПОИСК ПО БД "АРХИВНЫЕ ССЫЛКИ" НЕ РАБОТАЕТ. ВОССТАНОВЛЕНИЕ ДОСТУПА К БД "АРХИВНЫЕ ССЫЛКИ" НЕ ВХОДИТ СЕЙЧАС В ЧИСЛО ПРИОРИТЕТНЫХ ЗАДАЧ.

Был ответ, наводящий на мысль, что сама концепция БД морально устарела, требуется освежение идеи. Можете что-то предложить? Как наполнять БД, как поддерживать ее актуальность? Скорей всего, технические проблемы преодолимы, а вот организационные - в тумане.

Не понятно, зачем выкидывать старое, но работающее, пока нет другого получше? Где логика? Вы вот туалетной бумагой пользуетесь, а в Японии уже есть электронные унитазы с фонтанчиком. Между прочим, вся концепция этого сайта давно устарела и хромает, но вы же сайт не закрываете, и правильно делаете.

[oztech]

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

[oztech]

Между прочим, вся концепция этого сайта давно устарела и хромает

Не согласен. По-моему, пока концептуально мы вполне конкурентоспособны. Мы точно не идеальны, но, скажем, как все устроено на ФБ или ВК, так, лично меня просто удручает. Но если есть предложения что-то у нас улучшить, то это всегда интересно.

[Канадец]

Между прочим, вся концепция этого сайта давно устарела и хромает

Не согласен. По-моему, пока концептуально мы вполне конкурентоспособны. Мы точно не идеальны, но, скажем, как все устроено на ФБ или ВК, так, лично меня просто удручает. Но если есть предложения что-то у нас улучшить, то это всегда интересно.

Т.е. вы считаете, что с сайтом все ок, а БД морально устарела. А что, БД - это не часть сайта? Короче, я понимаю финансовые проблемы, даже технические. Но закрывать фичер только потому, что он "устарел" - это новость. Можно спросить, а как вы планируете решать проблему?

[oztech]

Т.е. вы считаете, что с сайтом все ок, а БД морально устарела. А что, БД - это не часть сайта?

Нет, я вовсе не так считаю. С сайтом далеко не все ок, но сайт и БД - в разных категориях. БД - лишь один из проектов, который вели энтузиасты. Раньше могли им заниматься - теперь не могут или не хотят. Значит, на это есть какие-то личные причины, их может быть гораздо больше, чем финансовые и технические проблемы. Никто ничего не закрывал, знамя выпало из рук и некому его подхватить. Есть желающие профессионалы в области создания БД? Они готовы прийти и сделать все заново или по старым лекалам, но с учетом нынешних реалий? Вот им бы можно было задать Ваш вопрос

а как вы планируете решать проблему?

У нас на форуме все по Жванецкому: "Кофе в постель я могу и сам себе подать. Но придётся встать, одеться, приготовить, раздеться, лечь и выпить."

[Канадец]

Т.е. вы считаете, что с сайтом все ок, а БД морально устарела. А что, БД - это не часть сайта?

Нет, я вовсе не так считаю. С сайтом далеко не все ок, но сайт и БД - в разных категориях. БД - лишь один из проектов, который вели энтузиасты. Раньше могли им заниматься - теперь не могут или не хотят. Значит, на это есть какие-то личные причины, их может быть гораздо больше, чем финансовые и технические проблемы. Никто ничего не закрывал, знамя выпало из рук и некому его подхватить. Есть желающие профессионалы в области создания БД? Они готовы прийти и сделать все заново или по старым лекалам, но с учетом нынешних реалий? Вот им бы можно было задать Ваш вопрос

а как вы планируете решать проблему?

У нас на форуме все по Жванецкому: "Кофе в постель я могу и сам себе подать. Но придётся встать, одеться, приготовить, раздеться, лечь и выпить."

Устарело-не устарело здесь не при чем. Техническая причина. Теперь все понятно. Впрочем, так я и думал. Если бы вы так сразу и ответили, я бы не засорял эфир. К сожалению, я в web-DB не специалист.

[dimaioffe]

Есть желающие профессионалы в области создания БД? Они готовы прийти и сделать все заново или по старым лекалам, но с учетом нынешних реалий? Вот им бы можно было задать Ваш вопрос

Я могу посмотреть и помочь с БД. Не знаю, какие нынешние реалии требуется учесть, но время и желание помочь сейчас есть.

[oztech]

dimaioffe, спасибо за отклик. Работа над восстановлением БД еще не началась, но уже попала в очередь. Оказывается, прежде чем заняться базой, нужно решить более важные задачи экзистенциального характера, в целом по форуму. Новая команда админов сейчас этим и занята, и пока первоочередные задачи по обновлению движка не будут выполнены, серьезно заниматься базой бессмысленно.

[Лея]

dimaioffe, спасибо за отклик. Работа над восстановлением БД еще не началась, но уже попала в очередь. Оказывается, прежде чем заняться базой, нужно решить более важные задачи экзистенциального характера, в целом по форуму. Новая команда админов сейчас этим и занята, и пока первоочередные задачи по обновлению движка не будут выполнены, серьезно заниматься базой бессмысленно.

Мне кажется, можно просто сделать БД платной по подписке - тогда можно элементарно найти специалистов, которые все починят и запустят.

[dimaioffe]

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

Ок. Если нужна будет помощь -- обращайтесь. Я не то чтобы какой-то гуру MySQL, но есть опыт разработки высоконагруженных систем, с использованием MySQL в частности.

[aklos]

Ок. Если нужна будет помощь -- обращайтесь. Я не то чтобы какой-то гуру MySQL, но есть опыт разработки высоконагруженных систем, с использованием MySQL в частности.

Ничего технического в детсадовской проблеме соединения пары табличек нет. Скорее всего они продали данные другой поисковой системе типа hryc.by и теперь кормят нас экзистенциальными сказками.

[oztech]

Скорее всего они продали данные

Ну, конечно, тут же все такие.

[Helen V.]

Скорее всего они продали данные другой поисковой системе типа hryc.by

типа hryc.by - самостоятельный проект, делающийся силами одного программиста из Беларуси, на основе описей и газет из открытого доступа.

[oztech]

Начиналось все так:

Сочинили и мы свою базу по архивам Беларуси

Дальше последовало пояснение от создателей БД:

Принцип наполнения прост - куда едем, какие дела и описи смотрим, оттуда информацию и берем. И, соответственно, добавляем. Поэтому то-сё имеется из Минска, из Гомеля, из Витебска, из Бреста, из Вильнюса...

И появилась ветка, которая вышла за рамки исходной темы и больше подходит в тему вопросов по нашим проектам, в т.ч. нашим БД. Ее начало - в следующем абзаце:


По этому же принципу и наша БД пополнялась, и принцип этот постепенно ее превратил в чемодан без ручки, что стало особенно понятно, когда потребовался ремонт. Но это уже другая история, а не камень в огород "сочинителей" новой базы.

[Tatik]

По этому же принципу и наша БД пополнялась, и принцип этот постепенно ее превратил в чемодан без ручки, что стало особенно понятно, когда потребовался ремонт. Но это уже другая история, а не камень в огород "сочинителей" новой базы.

Поясните, пожалуйста, чем этот принцип плох для "нашей БД" ? sql на то и sql, что запросами можно любую инфу вытащить, пересобрать в другие таблицы, поменять "принцип" и тп.

[oztech]

чем этот принцип плох для "нашей БД" ? sql

Татьяна Tatik, Вы меня на минное поле толкаете. Без помощи Гугла мне даже до сути Вашего вопроса не добраться. Вот прочитал пояснение:

SQL (Structured Query Language) — это стандартный язык запросов для управления и работы с реляционными базами данных.

В этом объяснении мне тоже не все понятно, но я точно не имел в виду ничего, что касается управления и работы с БД, Напротив, мне даже очень понравилось, как быстро все летает на выдаче из новой БД. На мой непрофессиональный взгляд слабое звено - это принципы пополнения любых подобных БД. Скажем, при создании АИС отдельного архива понятны и ближайшие цели, и перспективы. Но совсем другое дело - выборка по заданной тематике из множества хранилищ. Контент собирается как коллекция, с миру по нитке. А название обещает нечто большее, чем то, что есть на самом деле. Массив данных по Белоруссии - это же айсберг. "Надводная" часть - доступное он-лайн, а "подводная" - это то, к чему не подобраться без визита в архив. А было ли сразу понятно, с каким контентом работает новая БД, пока не были обнародованы "принципы наполнения"? Или взять нашу БД с нескромным названием "Архивные ссылки". Появляются новые БД, но насколько отличаются массивы исходных данных, которые они охватывают? Насколько допустимо дублирование? Как поддерживается актуальность БД? Если базы обрабатывают только отдельные коллекции, то можно ли наладить межбазовые связи? Перечень "хотелок" пользователей БД можно продолжить, наверное это будет полезным для программистов, ведь, постановка задачи - важный этап любого проекта. Пытались ли создатели новой базы задавать себе вышеупомянутые вопросы? Нашли ли какие-то решения? Что думают о стратегии создания генеалогических БД? Т.е. новая БД - это шаг вперед или на месте? Есть ли тут новые идеи, которые можно использовать при восстановлении нашей БД? Примерно это я и имел в виду в своей реплике.

[Tatik]

Ой, я так широко не мыслила вообще.
Наша БД была очень полезна, пока не испортился к ней доступ. Отдельно рыдаю о "Каменном архиве".

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

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

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

Массивы исходных данных известны создателю. В теории он обычно и предоставляет пользователю возможность запросов типа "покажи все фонды из архива НИАБ, внесенные в БД", "покажи все описи из архива LVIA", "покажи все материалы, относящиеся к периоду гггг-гггг, имеющие в заголовке слово "еврей", добавленные в БД после 01.01.2026". Виды таких запросов и разнообразие фильтров - добрая воля создателя БД, и если мы его знаем, всегда можем попросить добавить какой-то вдруг нужный нам запрос. Но "теоретические" запросы типа "а все ли описи данного фонда внесены в базу данных?" требуют при создании БД еще полей в таблице фондов, типа "общее число описей в фонде". Они могут быть создателем и не предусмотрены, так как не очень-то на практике и нужны.

[oztech]

Массивы исходных данных известны создателю. В теории он обычно и предоставляет пользователю возможность запросов типа "покажи все фонды из архива НИАБ, внесенные в БД", "покажи все описи из архива LVIA", "покажи все материалы, относящиеся к периоду гггг-гггг, имеющие в заголовке слово "еврей", добавленные в БД после 01.01.2026". Виды таких запросов и разнообразие фильтров - добрая воля создателя БД, и если мы его знаем, всегда можем попросить добавить какой-то вдруг нужный нам запрос. Но "теоретические" запросы типа "а все ли описи данного фонда внесены в базу данных?" требуют при создании БД еще полей в таблице фондов, типа "общее число описей в фонде". Они могут быть создателем и не предусмотрены, так как не очень-то на практике и нужны.

Если не ошибаюсь, как раз в нашей БД создатели старались всячески исключить полные ответы на подобные запросы, причем это обосновывалось необходимостью защиты интеллектуальной собственности. Представление об объеме проиндексированной и включенной в нашу БД информации можно было получить из отдельной закрытой темы Наша БАЗА ДАННЫХ - что нового. Мне кажется это неправильным, но у разработчиков свое представление о самозащите. Вот на сайте Яндекс Архива открываешь вкладку какого-либо фонда и видишь в отдельном окошке справочку: распознано - число дел, число листов, доля распознанных дел. Последние числа, конечно, лукавые, поскольку качество распознавания еще далековато от идеала, но когда речь идет об описях, как в нашей базе, проблема распознавания отсутствует, а пример ЯА мне кажется достойным подражания.
Ну, и не могу согласиться с пренебрежением к оценкам обработанных массивов данных. Что значит, что эти оценки на практике не нужны? В них, действительно нет конкретных ответов по фамилиям, именам, датам и прочим сведениям, ради которых мы обращаемся к архивам, но они, ведь, характеризуют достоверность ответов. Любая информация без оценки ее достоверности мало чего стоит. Сейчас, когда расцветает ИИ, это особенно чувствуется.