iBase.ru Forum

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

Как принято поступать в таких случаях, ткните ...

поставить генератор в первом филиале на 10000
во втором на 20000
в третьем на 30000
и т д.
если справочник предпологает быстрый рост то по 10000000 разницу ставь.

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

Про репликацию на FB/IB какие-нибудь статьи читал?
По поводу несовпадения данных - у тебя должна быть процедура разруливания таких "дубликатов". Автоматическая или пользовательская - твоё решение.

Attid писал(а):поставить генератор в первом филиале на 10000
во втором на 20000
в третьем на 30000
и т д.
если справочник предпологает быстрый рост то по 10000000 разницу ставь.

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

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

Во-первых, в центре можно предусмотреть очень и очень многое, гораздо больше, чем кажется на первый взгляд. География как раз - запросто. Три девочки с шустрыми пальчиками набивают за неделю-другую справочник практически любого объёма, главное чтоб инфа была доступна. Информация, имеющая чёткую привязку к филиалу, данные о его собственной деятельности, обычно хранится в таблицах с двухсегментным ключом ИД_филиала, ИД_записи. Что, кроме простоты хранения, очень удобно и для всяческой обработки в центре. Самая проблемная часть - организации, с которыми контактируют, филиалы по ним могут пересекаться довольно часто. Тут могут быть две политики - идентификация и унифицирование с участием человека в центре и присвоением нового ID в центре (по-любому), дальше дорога раздвояется, либо рассылка нового ID с апдейтом ключей в филиалах (сложно, ненадёжно и противоестественно), либо ведение в центре таблицы соответствия m:n ID_в_центре, ID_в_филиалеN и проведение репликаций с её использованием.

2Merlin
спасибо за ответы.

примерно понятно, но в последнем посте ... это слишком для моего случая.

объясню на примере, может я не совсем коректно задал вопрос, думал из типичной задачи найду решение своей.

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

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

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

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

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

korotkov писал(а): имеется программа коллекционирования объявлений привязанных к районам города (в лучшем случае, а если страны). существуют девочки с быстрыми пальчиками которые берут из разных печатных источников и набирают объявления в свои "локальные базы", девочки могут находится где угодно с ними может не быть оперативной связи и пр., работают удаленно Один из справочников в базе - районы, улицы города. Каждая из них может интерпретировать район по своему, кто называет как во дворе, а кто как и административное деление происходит, кто пишет с ошибками, а кто ...

Собсно я про девочек из личного опыта в сходной задаче. Именно так подошли к решению вопроса ещё в 92-м году, года делали базу и задачу для агентства торговли недвижимостью "Реклама-Шанс" в Питере. Цена вопроса вколачивания полного справочника со свежайшей книжки и упреждающего добавления-распространения по мере строительства мизерна по сравнению с зарплатой программиста, реализующего и поддерживающего сложную схему, не говоря уж о потерях всвязи с невольными или злоумышленными искажениями. И объявления регистрируются не как бог на душу положит, а как правильно. А то один приятель из Великого Новгорода сказывал, что в базе, если мне не изменят склероз, налоговой, обнаружил 68 вариантов написания названия улицы "Комсомольская". Цена такой информации близка к 0.

... вот, есть еще ягоды в ягодицах, а то думал уже совсем все забыл

спасибо!

КЛАДР, конечно, та еще бяка, но полнее ее, базы по географическим названиям нет.