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

И связи перенумеруются!
Всего не учтешь, так что начинайте практическую работу

Насчет уникальных номеров:
1.Вариант: В каждой базе свой диапазон (особенно для числовых)
2 Вариант: В каждой базе свой префикс (Для текстовых)
Второй вариант успешно используется в распределенных базах 1С

Пожалуй, да...
Такое рассуждение мне, кажется понятно (не уверена).
Может ли порядок действий быть таким:
1) создать окончательную структуру базы,
2) в трех местах, задав для уникальных номеров свой диапазон или свой префикс, вводить непересекающуюся информацию.
3) свести вместе все эти три части, номера не повторяются.
4) ввести пересекающуюся информацию, показывающую связи между этими тремя частями.
Ну и для тех, кто спешит, говорю сразу, что завтра я все это не сделаю Я еще не всю информацию по населенным пунктам собрала, которая мне для начала нужна
Главное, вы скажите, то, что я сейчас написала по пунктам, "технологично" или нет?

Три места - это не три города, а три компьютера и три исполнителя.
Делать буду так же как и сейчас - постепенно. У меня есть раздел "Поиск по городам", там населенные пункты России, указанные в почтовых справочниках, уже есть, просто далеко не во всех населенных пунктах есть почтовые отделения. Это раздел надо мне довести до определенного состояния. Часть, касающаяся городов будет, как минимум, включать в себя изменение административно-территориального деления, а кроме того еще некоторые типовые события, я писала раньше - эпидемии, народные волнения и т.п. То есть это сама по себе база - по истории городов. Ее сделает отдельный исполнитель.
Другая часть - это люди, которые и составляют основную часть сайта. Они родились, женились и умирали в определенных населенных пунктах, но кроме того про них есть и другая информация - годы жизни, родственные связи и краткая информация об их деятельности. Эту информацию без названий городов, внесет другой исполнитель. При сведении этих баз вместе появятся связки между людьми и населенными пунктами. Если сразу вводить населенные пункты, то они же автоматически пронумеруются другими номерами, о чем я и говорю. Поэтому, наверно, второму исполнителю их вводить не надо.
Третья часть - хронология, касающаяся не отдельных городов, а всей России. Она нужна для того, чтобы выдавать историческую справку о том, что вообще в России происходило, например, в момент брака кого-нибудь. Сейчас информация для этого на сайте есть только по 19 веку, но, на самом деле, это самый легкий раздел, хронологичесикх справочников много. Ну и ей должен заниматься отдельный исполнитель тоже.
А потом эти три базы сводятся и получается нечто единое и монументальное.
Поскольку так получилось, что мы начали с  построения генеалогической паутины, вся остальная база должна будет делаться уже с учетом сделанного в первую очередь и на ее основе, с теми уникальными номерами людей, которые при создании этой паутины образуются. Так что на самом деле у базы будет четыре части. Если, конечно, эта паутина получится
То есть повторяю, чтоб понятно было. Три места - это три компьютера. Пересекающаяся информация - это наименования населенных пунктов (которые притом меняются во времени).
Я очень стараюсь все понятно объяснить, но у меня как-то не очень получается Возможно, я гений (Вовсе у меня нет мании величия, это у меня такое своеобразное чувство юмора).

Людмила!

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

Если Вы знакомы с работой DBMS (database management systems, системы управления базами данных), то знаете, что все они оринтированы в той или иной степени на многопользовательскую среду.

Например, если говорить о продуктах Microsoft (MS SQL Server) или Oracle (Oracle 8i), то это серьёзные решения, ориентированные на работу в многопользовательских средах.

К чему я веду: физически у Вас может быть один сервер, на котором установлена DBMS. При этом DBMS может поддерживать несколько баз данных (на одном сервере). И с каждой базой данных может работать несколько (десятков, сотен) пользователей.

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

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

В том числе, это:
1. Обеспечение целостности данных;
2. Если не будет доступна какая-либо одна из баз данных, Вы не сможете работать вообще;
3. Обеспечение синхронизации данных из трёх баз разной структуры в одну базу для web-сайта,
и так далее.