Ликбез по СУБД - Генеалогический форум ВГД. Тема №1569

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

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

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

Торопиться надо медленно

. Да кроме того, практическую работу я веду постоянно, пополняя сайт

Вот если получится то, чего мне сейчас пробуют сделать, это будет классно

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

Буду предаваться мыслительному разгулу! И задавать вопросы глупые

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

Людмила!

Забивать самим населённые пункты, области и проч. России - неблагодарное дело

По этой причине лучше взять классификатор, который использует, например, госпочта, и базироваться на нём. А вот все старые варианты (губернии, уезды и проч.) нужно будет забивать самим. И это лучше сделать централизованно, в одном месте.

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

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

Но, в любом случае, для той системы, о которой идёт речь, этот вариант (с несколькими DB), на мой взгляд, неэффективен.

Если Вы изначально вводите одинаковую информацию, но с разными идентификаторами в разных DB, то проблема её консолидации будет более существенна, чем создание самой DB как таковой.

Поэтому идти таким путём крайне не рекомендую.

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

Я еще не всю информацию по населенным пунктам собрала, которая мне для начала нужна

Главное, вы скажите, то, что я сейчас написала по пунктам, "технологично" или нет?

Говоря о "трёх местах", Вы явно преследуете какие-то свои цели, которые лично мне не совсем понятны.
Вы планируете собирать информацию во Владивостоке, Новосибирске и Калининграде? :-)

Никаких диапазонов задавать не нужно. Для этого существует сдандартный инструментарий DBMS.
Нужно просто отслеживать, чтобы у города "Москва" в Новосибирской, Калининградской и Владивостокской базе был один и тот же уникальный код.

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

И о какой "пересекающейся информации" идёт речь, так же не совсем понятно.

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

То есть повторяю, чтоб понятно было. Три места - это три компьютера. Пересекающаяся информация - это наименования населенных пунктов (которые притом меняются во времени).
Я очень стараюсь все понятно объяснить, но у меня как-то не очень получается

Возможно, я гений

(Вовсе у меня нет мании величия, это у меня такое своеобразное чувство юмора).

Я хотел бы подключиться к обсуждению ваших проблем, но мне они не совсем понятны. Работать в своей базе с присоединенными другими базами- это тривиальная ситуация и без проблем. Вы хотите сделать три НОВЫЕ базы (пусть в разных местах) , или использовать уже готовые базы (скажем базу населенных пунктов)?
Делать новые базы - надо тщательно продумать их структуру. Если использовать готовые базы, то разрабатывать надо только структуру своей базы, которая будет связана с другими. Но структура готовых баз должна быть полностью известна.
- Всегда лучше делать несколько разных баз (по разным темам), чем городить одну большую все обединяющую.!!
Это одна из аксиом!
- Уникальные Ключевые поля должны быть в любой таблице для любой базы данных. (и никаких проблем с пересечениями индексов). Это тоже аксиома! Кстати никаких "диапазонов" для ключевых индексов быть не должно.
И о какой "пересекающейся информации" идёт речь, пока действительно не совсем понятно.

Людмила!

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

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

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

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

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

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

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