Имеется справочник граждан, числом записей около миллиона в файле dbf, да еще в кодировке DOS-866.
Думаю, значения не имеет, что за БД используется.
Проблема, собственно, как поступить с таким объемом данных.
По этому поводу у меня есть несколько вариантов решения, но каждый имеет свои недостатки и, как мне кажется, серьезные.
1. Однажды загрузить этот справочник в БД и потом проводить его актуализацию. Т.е. добавлять и удалять записи. Проблема в том, что записи не имеют уникального идентификатора, а построить таковой даже по нескольким полям (минимум 8 значимых полей) - этот вариант меня пугает.
2. Создать отдельную БД для этого справочника, на отдельной машине каждый месяц загружать в него информацию заново, а потом просто подменять на сервере. Этот вариант мне кажется сомнительным.
3. Так и юзать этот dbf, но
Доступ к нему по сети не проверялся и представляется затруднительным, но вполне может быть, что я ошибаюсь.

Каждый месяц кидать его на машины клиента. В принципе возможно, механизм обновления клиентов через xcopy уже реализован, так что особых проблем с этим, думаю, не будет.
Общий недостаток такого подхода - дополнительный движок БД специально для dbf, не хотелось бы из-за этого утяжелять клиента и вбухивать дополнительные деньги.

Отказаться от этого справочника невозможно. А процентов 90 из него - бесполезный балласт. Избавиться от "мусора" невозможно по двум причинам:
1. Нет-нет да и потребуется что-то из этих 90 процентов.
2. Невозможно отобрать только нужные записи, т.к. не за что "зацепиться".

Naf,

В том-то и дело, смотри пункт номер 1.

Роман Дынник,

Firebird.

Naf,

1. В том и смех, что эта таблица ни с чем не связана, из нее будут браться только Ф.И.О., д.р., кое-что еще. В принципе, особой нужды в такой таблице как-будто бы и нет, просто из нее приходится иногда брать недостающие данные, проверять сроки и т.п. Все только для того, чтобы не напартачить с ручным вводом и не пропустить лишних людей иначе будет потеря в деньгах.
2. Вот кстати насчет подгрузки я и размышлял. Т.к. нет уникального поля, то его можно создать. Сделать это, я прикинул, можно по 8 полям (собрать их в одно поле). Т.е. создаю и там по такому "ключу", потом сравниваю талицы. Те записи, которых нет в dbf, будут удалены из БД. А недостающие будут подгружены в БД из dbf. В таком случае просто избегаю возни с редактированием записей. Надеюсь, не очень путано получилось. Просто добавляю недостающие и удаляю лишние. Как-то так.

UPD Но получится очень громоздко.

egorych,

Фамилия, Имя, Отчество, д.р., номер страхового полиса, номер договора, соц. группа, страховая компания.
Можно и не объединять. В принципе, на суть не влияет, как делать, просто это важные поля, поэтому их надо учесть.
Просто мне показалось, чем сравнивать каждое поле, проще собрать их в одно и уже через in делать выборку.

Naf,
И номер договора и номер полиса еще как изменны!
Для примера. Месяц назад человек не работал, у него был один номер страховки, номер договора, страховая компания, соцгруппа (безработный). Теперь он устроился на работу, сменилась компания, договор, номер страховки, соцгруппа и т.д. Так чем сравнивать каждое из этих полей, проще сразу удалить эту запись из БД и заменить новыми данными, благо не критично.
Казалось бы, номер страховки - уникальный номер, но фишка в том, что в они могут совпадать в разных компаниях, более того даже в одной компании могу совпадать номера страховок. Поэтому необходимо учитывать еще и номер договора (почти наверняка будет отличаться) и т.д. Для крайнего случая можно еще серию страхового полиса "посчитать".

Роман ДынникEvgen2009Firebird.
Давно не смотрел что нового есть в FB.
В любом случае лучше взять любое ETL средство, например, MSSQL DTS/Integration Services
Сделайте DTS пакет по загрузке данных из dbf в FB и job для запуска пакета по расписанию.
DTS будет довольно простым (сделаете минут за 10).

Спасибо за информацию к размышлению!

Cane Cat Fisher
А если нет уникального ключа, как вообще можно говорить об обновлении? Например, был ИВАНОВА МАРФА ВАСИЛЬЕВНА 12345 - 100, в обновлении приехало ПЕТРОВА МАРФА ВАСИЛЬЕВНА 12345 - 999. Как понять, это новый человек приехал, или Иванова замуж вышла и в связи с этим страховую компанию поменяла? А может, просто эти данные были неправильно внесены, и теперь должны быть исправлены?

Так и ладно! Тогда это будут два разных человека.

Для ясности картины скажу, что помимо этого имеется справочник посетителей, связанный с журналом посещений.
Имеем: дбф-файл, подготовленный для перекачки в БД (Спр_Д), под этим же именем (Спр_Д) он будет значится в БД. Имеются справочник Посетителей (Спр_П), журнал Регистрации (Журн_Р).

Пример.
Имеется у нас Иванов Иван Иванович, 01.06.1956 г.р. (это в Спр_П)
У него были посещения (занесены в Журн_Р):
1. 03.07.2008, Иванов Иван Иванович, 01.06.1956 г., Полис: № 000415, дог. 0030
2. 12.09.2008, Иванов Иван Иванович, 01.06.1956 г., Полис: № 333333, дог. 999
При каждом посещении в Журн_Р, подставляются данные из Спр_Д, актуальные на момент посещения.

Если же окажется, что Иванов Иван Иванович стал Ивановым Петром Петровичем, так и будет добавлен в Спр_П новый посетитель с этим именем, ну и т.д.

Надеюсь, не сильно запутал.

Klickа может там у вас ИНН есть? он вроде как более уникален
Нету. Более уникален СНИЛС, но тут тоже есть варианты.

Не дописал.

Вот этот справочник Спр_Д мне и нужно каким-то образом к БД цеплять.

Кифирчиккак утверждал тот чел, комбинация уникальная для каждого человека в РФ
- Все лгут! (с)сами_знаете_кто

Хе-хе! Нарочно посмотрел "иванп1958", найдено три человека: две женщины, один мужчина.
Вот иванп03091974 - это уже комбинация, но тоже 100% гарантии не дает, так что для ключика маловато будет.

Cane Cat FisherА если человек сменил фамилию, то как узнать, что тот посетитель со старой фамилией, и этот с новой - одно и то же лицо?

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

Но все-таки вернусь к сабжу, вот схема .
Мне нужно каким-то образом грузить данные из "А" в "Б" или придумать что-то еще, варианты, опять же, в сабже.
Опять же повторюсь. Справочник "Б" - что-то вроде словаря, посмотрел, как будет правильно, скопировал, закрыл. Все.

egorychсправочник "А", тот, который dbf, после загрузки, будет изменяться? или залили и забыли про него?
что мешает сделать структуру справочника "Б" такой-же, как и в "А", добавить столбец ID и не заморачиваться больше на этой теме? тем более, что справочник этот будет использоваться в качестве словаря, имхо
Не очень понял, что подразумевается под "справочник "А", тот, который dbf, после загрузки, будет изменяться". Раз в месяц этот справочник "А" присылается к нам готовым, сами мы в него ничего не вносим.
Старая версия программы писана на Фоксе под ДОС, там этот файл ежемесячно просто заменяется новым. А так как в новой версии предполагается использовать FB, то и думаем, как это дело провернуть.
Так и задумано, что справочник "Б" - точная копия "А". Залить в БД (или не залить?), проиндексировать и дальше селектом его, селектом.

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