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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да хоть в ста местах. На то она и структуированная база

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

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