Petro123ГУИД человека не несёт никакой смысловой нагрузки - заменить на счётчик.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

А как объединять базы тогда?
Вообще и в талице состояния идентификатор нужно делать тоже ГУИД, но тогда нужна еще отметка "Текущее"..

Должна быть возможность объединять все данные на уровне учреждения и всех учреждений..

Как поведет себя база с большим объемом данных (милионы) при использовании ГУИД в качестве идентификатора во всех трех таблицах ?

Сергей СергеевичНормализации данных нет вообще имхо.... структуру БД надо перестраивать...

А конкретно?

Petro123 SchwanДолжна быть возможность объединять все данные на уровне учреждения и всех учреждений..

Как поведет себя база с большим объемом данных (милионы) при использовании ГУИД в качестве идентификатора во всех трех таблицах ?
Не изобретай велосипед.
Вопрос объединения БД (репликация) при совпадении кодов товара обмусолен в форуме MS SQL Server тысячу и один раз.

ГУИД здесь не поможет и СУБД с ним работает медленнее.
С таким-же успехом (если боятся совпадения счётчика) можно добавлять БД№1 в БД№2 не заполняя счётчик в целевой БД (он сам заполнится).

А вот как ты будешь искать 2-х Ивановых в БД№1 и в БД№2 если базы заполнялись разрозненно это твои проблемы (проектирования).

Есть БД1, есть БД2 - производиться выгрузка данных в какой либо формат, затем данные загружаются в БД3.. (Никакой сети нет!). Если получилось 2 Ивановых, то (если это один и тот же человек), то приводим его к одному (ХП например).. Это если есть ГУИД.. А если нет? Тогда мне непонятно как сохранять связь между данными.. Просветите.. :)

adv Schwan Сергей СергеевичНормализации данных нет вообще имхо.... структуру БД надо перестраивать...

А конкретно?например1: человек сменил фамилию (ИО).

например2: одно посещение по нескольким причинам; по одной причине несколько результатов.

например3: у человека несколько статусов.

1) Да если человек сменил фамилию, то мы теряем информацию о том какая фамилия у него раньше была.. но нам это не важно, гораздо важнее, что мы знаем, что это тот же самый человек..

2) Таблицу посещений давайте трогать не будем пока - поля которые я прописал в ней условные, я лишь пытался показать связь между таблицами..

3) ДА учеловека несколько статусов: эта таблица используется для того чтобы хранить информацию о них - т.е. знать какой статус был у человека при каждом конкретном посещении. Но мы должны естественно знать текущий (последний) статус (либо максимальный код, либо если код ГУИД, то тогда нужна отметка что статус текущий (логическое поле)..

Мне важно принципиальное построение БД для такой задачи: т.к. объемы данных будут довольно большие и использоваться будет много лет..

adv1. весело будет искать по фамилии, например, посещения товарища. Или вы по ид искать будете:)?

2. не трогаем по просьбе трудящихся.

3.
>т.е. знать какой статус был у человека при каждом конкретном посещении
при конкретном посещении, например, два статуса - что делаем?

1) Запрос типа:
SELECT ПОСЕЩЕНИЯ.*
FROM (ПОСЕЩЕНИЯ LEFT JOIN СОСТОЯНИЯ ON ИД_ПОСЕЩЕНИЯ.ИД_СОСТОЯНИЯ=СОСТОЯНИЯ.ИД_СОСТОЯНИЯ) LEFT JOIN ЛЮДИ ON (СОСТОЯНИЯ.ИД_ЧЕЛОВЕКА=ЛЮДИ.ИД_ЧЕЛОВЕКА)
WHERE ЛЮДИ.ФАМИЛИЯ LIKE "ПЕТРОВ%"

Должен вывести посещения всех Петровых и Петровских.. Или Вы имеете ввиду что эти запросы будут "тяжелые"?

2) Как может быть два статуса при одном посещении: в таблице ПОСЕЩЕНИЯ только один код статуса.. Т.е. связь один ко многим (Один статус - много посещений). Если статус изменился создаем новый на основе данных предыдущего.. Не может же быть у человека два паспорта одновременно?

Petro123Аффтар! У вас репликация? Или вы это слово не знаете? Если знаете то по какому типу?
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Да с репликациями не фонтан.. :)
Подскажите тогда как реплицировать БД на двух компьютерах с MSDE и без сети?

aagПроблема идентификации физлиц уже обсуждались, можете поискать.
Конкретно, Dik76 к сожалению прав - универсального 100%-го решения нет.
Есть решения с большей или меньшей надежностью - сравнение по ФИО + дата рождения + ИНН + паспорт. Дополнительно - здесь уже кто-то предложил интересный вариант - сравнений цифр в адресе (кроме индекса). Для сравнения ФИО можно попробовать нечеткий поиск - дабы ловить ФИО, набитые с ошибками.
Полной гарантии эти способы не дадут, но... приблизят.


Nobody faults but mine... (LZ)

Для набивки имен и отчеств используются справочники.. Для идентификации человека несколько параметров Ф.И.О.+Дата рождения+место рождения, можно использовать СНИЛС и т.д.
Весь вопрос теперь в другом: какую структуру БД создать чтобы была возможность объединения данных?