Ликбез по СУБД

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

Да сама с удовольствием поговорю про базы данных! Там я же про это и разговаривала и сама же себе рот заткнула

На самом деле, было бы забавно где нибудь найти (думаю. что она обязательно есть) или создать (если нет) программу "Деревья"... Это была бы такая программа, которая как раз и ориентирована на построение разнообразных дерев. Они же бывают не только генеалогические, но и деревья целей, например, или каких-нибудь иерархических или даже причинно-следственных связей... Даже административно территориальное деление можно, при желании, изобразить в виде древа (очень даже удобно было бы). Ну и одновременно, она была бы базой данных, поскольку все связанные объекты имеют какие-то свойства, которые тоже неплохо было бы туда засунуть...
Тогда бы в идеальной базе для нашего сайта строились разные деревья, почти все, какие можно только выдумать

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

Людмила, сначала - ремарка:
в СУБД считается "хорошим тоном" иметь в каждой таблице поле [id], в которое заносится (обычно - автоматически) УНИКАЛЬНЫЙ "идентификатор" (как правило - целое число) того "объекта", которой "описывается" каждой конкретной строкой (= записью) этой таблицы ...

(((Если подходить формально - можно считать, что это уникальное значение "идентифицирует" САМУ эту строку, а вопрос: "описывается" ли строкой некий "объект", - вынести за скобки ... но это уже как бы - философские дебри ;-) )))
________________________________________________

Так вот, если среди таблиц нашей СУБД есть хотя бы одна таблица Т, имеющая структуру (=набор полей):
[Тип_Связи], [id_одного_объекта], [id_второго_объекта], ...
(ну и, навеное, - в соответствии с "правилами хорошего тона", о которых я говорил выше, - должно быть и поле [id], - для хранения идентификатора самой записи в этой таблице!)

- тогда, при желании, мы можем в этой СУБД хранить описание ЛЮБОГО графа, в том числе - структуру ЛЮБОГО генеалогического дерева!
___________________________________

Выглядеть это может ПРИБЛИЗИТЕЛЬНО так:
1-я запись: 1, 101,102
2-я запись: 2, 101,103
3-я запись: 2, 102,103
4-я запись: 1, 103,104
5-я запись: 2, 103,105
6-я запись: 2, 104,105
...

- где 1 означает "тип связи - супружество";
2 означает "тип связи - родительство";
101 - идентификатор Бабушки;
102 - идентификатор Дедушки;
103 - идентификатор Папы;
104 - идентификатор Мамы;
105 - идентификатор Дочки;
...

- как Вам нравится такое "изображение"?

Понятно, что "исчерпывающе-полное хранение информации" и "удобочитаемое отображение информации" - это далеко не одно и то же!

Иван

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

Хотя можно раздробить их на месяцы, но это уж чересчур.

Вопрос: может ли этот уникальный идентификатор быть не целым числом, а чем то типа L237-479, то есть может ли задаваться непростой, а иерархический способ нумерации? Или эта иерархичнсоть должна обязательно отражаться дополнительной клеткой с указанием связи (например, для населенного пункта волость, уезд, губерния и т.д.)?
(Разумеется, при внесении информации иерархическая принадлежность должна указываться, это понятно)

ИМХО, то что Вы описываете - возможно, но ... как бы ... это "плохой стиль" ...
______________________

К идентификатору есть ОСНОВНОЕ требование - УНИКАЛЬНОСТЬ. А также - есть ОБЩЕЕ требование к "системе" - технологичность ...
Так вот, попытки "запихнуть" внутрь идентификаторов какую-то СОДЕРЖАТЕЛЬНУЮ информацию, - это плохо, потому что - не технологично.
____________________________

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

Например, - таблица Справочник фамилий. Поля:
[id_фамилии], [фамилия].

Таблица Справочник губерний. Поля:
[id_губернии], [название губерний].

Таблица Справочник городов. Поля:
[id_города], [название города], [id_губернии].

Соответственно, таблица, описывающая людей, будет иметь такие поля:
[id], [id_фамилии], [Имя], [id_города] ... и много других полей ...
________________________________

Но это-то как раз все - в рамках СУБД - очень просто решается ... То, что писал про "изображение" графов, - нАмного (а может - нЕмного ;-) ) сложнее ...

Иван

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

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

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

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

Хотя, может, и есть

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

Ну так вот. Если этот кто-то хочет получать отчет одновременно из двух баз, то есть желает знать, были ли несколько персон одновременно в этом городе в какой-то период, что они там делали и что при этом происходило в городе, как ему лучше было бы поступить: объединить обе базы в одну или устроить какую-то схему отправления согласованного запроса в две базы одновременно? Или просто не мудрить, и отправлять отдельные запросы и объединять их вручную?
Конкретизирую другую часть вопроса - про быстродейсттвие. Если бы государство захотело объединить базы данных ЗАГС, медицинского страхования, социального страхования и пенсионного фонда, не удалять умерших (то есть постепенно строилась бы генеалогическая составляющая) и еще добавить туда отпечатки пальцев, нашелся бы для этого подходящий компьютер? То есть позволяет ли сейчас развитие компьютерных технологий создавать такие огромные базы данных? И сколько велся бы поиск, если бы, допустим, по отпечаткам пальцев надо было получить на одного человека полное досье из всей совокупности объединенных баз?

Про две базы: Лучше было бы иметь одну единую базу, тогда запросы бы можно было оптимизировать более качественно
Про быстродействие: Объединенные базы не проблема, такие компьютеры есть, тем более, что запросы в основном все-таки на текстовую информацию, а отпечатки пальцев, насколько я знаю, тоже как-то кодируются, то есть по ним легко составить индекс, так что при нормальных индексах, даже для всего населения земли проблемы бы не было

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

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

Поздравляю со старым новым годом!

Как сказал один человек, "у нас и старый год, и новый год, и старый новый год... лишь бы не работать!"

И в чём-то он прав.

Во-первых, хотелось бы отметить сразу одну деталь.
Когда мы говорим о генеалогии, то мы, по сути, говорим не о "деревьях", а о "паутине". Это разные вещи.

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

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

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

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

Людмила! Как Вы справедливо заметили, программа, реализующая построение "паутинки" (а Вас интересует именно она, т.к. "древо" - это частный случай паутинки, не являющийся универсальным, так вот, эта программа может быть универсальной.

В принципе, ей безразлично, с каким контентом (набором данных) работать и что это будет: люди, горы или самолёты. Она просто строит "паутину" и указывает связи между узлами этой "паутины".

Метод, предложенный Вами для обеспечения иерархии, несостоятелен по нескольким причинам, хотя он и используется в некоторых промышленных системах стоимостью в десятки тысяч долларов.
Одна из причин заключается в том, что Вы не сможете эффективно и средствами DBMS произвести выборку данных. Например, Вы не сможете узнать, сколько человек с фамилией N* проживало в городе N* в X* году.

Кроме того, чтобы использовать иерархическую структуру данных, гораздо проще и эффективнее воспользоваться штатными средствами DBMS (например, композитные индексы).

Проблема, связанная с медленной работой сайта, связанного с DB МГТС, заключается, по всей вероятности, в недостаточной производительности сервера, неэффективных запросах или неподходящей DBMS или...

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

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

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

Что же касаемо времени ответа на запрос, то нормально, если оно не превышает времени, необходимого на загрузку страницы (если мы говорим о web-системе) + 5 - 10 секунд.

Собственно, при достаточниых аппаратных ресурсах (мощность сервера) любая DBMS выполняет запросы достаточно быстро. Гораздо больше времени тратится на обработку данных.

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

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

Это так, галопом по Европам (по Вашим постингам в этой теме).

С уважением,
Александр.

Вы очень хорошо мне ответили, но не на все

То есть я поняла, одна база лучше, чем три.
Дело в том, что, исходя из многочисленных и не относящихся к СУБД соображений мне удобнее делать три отдельных базы, а потом их объединять. Так вот это возможно или до такой степени трудно, что, можно считать, и невозможно?
Если возможно, то необходимо ли определять сразу, какая структура у результирующей базы и, исходя из этого, придумывать структуру трех первоначальных баз? Или можно просто делать три базы как в голову взбредет (повторяющиеся элементы будут во всех трех), а потом их все равно можно объединить?
А про паутину мне понравилось.

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