Распределённые приложения

[Greek9000]

Данная тема может быть отнесена практически к любой ветке форума, поэтому открою её в самой популярной. Думаю, что так будет правильней.

Вкратце, вопрос такой: как правильно разрабатываются распределённые приложения в условиях автономной работы клиентов.

Возьмём, к примеру, фирму - пусть это будет мебельная контора - у которой есть сайт, общий учёт и несколько складов. Склады либо без интернета совсем, или с "тоненьким" интернетом в лучшем случае.
Задача: написать рабочее место работника склада и программу общего учёта, которая сводит данные со складов в одну кучу и часть информации отображает на сайте (актуальность не обязана быть наивысшей). Получение данных со складов происходит раз в неделю, на съёмных носителях.

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

Очень буду благодарен за любые советы, кто и как решает подобные задачи?

[D-mon]

1. Судя по моему опыту справочники менятся не будут.
2. Ты должен загнать пользователя в узкие рамки по введению информации.
3. Одинаковых даных у тебя никогда не будет, так как ты можешь отталкиватся от пользователя который ввёл данную инфу.
4. Сливать базы в одну не представляет сложностей, так как в общей базе для каждой записи будет ключ.
5. "с учётом коллизий ключевых полей в таблицах с разных складов" - ключевое поле склада уже не будет ключевым в общей базе, оно будет информационным (возможно вторичним ключем) в главной базе.

Как то так...

[Greek9000]

Сообщение от D-mon

1. Судя по моему опыту справочники менятся не будут.
2. Ты должен загнать пользователя в узкие рамки по введению информации.
3. Одинаковых даных у тебя никогда не будет, так как ты можешь отталкиватся от пользователя который ввёл данную инфу.
4. Сливать базы в одну не представляет сложностей, так как в общей базе для каждой записи будет ключ.
5. "с учётом коллизий ключевых полей в таблицах с разных складов" - ключевое поле склада уже не будет ключевым в общей базе, оно будет информационным (возможно вторичным ключом) в главной базе.

Как то так...

1. Предположим, что на склады А и Б в период между обновлениями поступают материалы М1 и М2. Предположим, что справочники материалов до поступления были одинаковыми. Но на складе А внесли сначала M1, потом М2, а на складе Б - наоборот. И создали продукцию с использованием этих материалов. В итоге имеем одни и те же материалы с разными индексами.
2. Если загнать юзера в рамки, то что бы создать новый элемент в справочнике придётся делать это в главной базе и развозить по складам, а до этого времени работа на складе встанет.
3. Тут всё портят внешние ключи. Предположим, в главную базу добавляются изделия из складской базы. Что бы их добавить надо сперва добавить нужные материалы. Если материалы дублируются - как в п.2, то индексы сместятся. Надо предпринимать какие-то действия что бы индексы не сдвинулись.
4. см. п.3
5. "неключёвость" бывшего ключевого поля не решает проблемы обновления при наличии ссылочной целостности.

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

Т.о. загон юзера в рамки - это решение. Но что делать, если всё таки не удастся забить все справочники в полном объёме? (такое вполне вероятно)