|
MySQL.RU - Webboard
 Вернуться
 Объединение БД (Waytac) 03/03/2005 - 11:25:53
 Re: Централизованная репликация БД (Валентин) 03/03/2005 - 13:20:09
Re: Централизованная репликация БД (Евгений) 03/03/2005 - 14:02:02
Re: Централизованная репликация БД (Waytac) 03/03/2005 - 14:04:25
Re: Централизованная репликация БД (Валентин) 03/03/2005 - 16:34:46
Re: Централизованная репликация БД (Евгений) 03/03/2005 - 17:23:51
Re: Централизованная репликация БД (Waytac) 03/03/2005 - 17:46:50
Re: Централизованная репликация БД (Валентин) 03/03/2005 - 17:59:45
Re: Централизованная репликация БД (Валентин) 03/03/2005 - 18:05:25
Re: primary key (Dinky) 03/03/2005 - 18:32:43
Re: primary key (Alec) 03/03/2005 - 20:13:58
Re: primary key (Евгений) 03/03/2005 - 22:48:05
Re: primary key (Waytac) 04/03/2005 - 09:24:45
Re: Выбор (Валентин) 04/03/2005 - 10:25:09
Re: Выбор (Валентин) 04/03/2005 - 10:47:05
Re: Выбор (Евгений) 04/03/2005 - 12:15:58
Re: классическое решение по mysql-ски :) (Dinky) 04/03/2005 - 20:02:09
Re: классическое решение по mysql-ски :) (Waytac) 05/03/2005 - 14:25:51
Re: Продолжение :) (Валентин) 05/03/2005 - 15:43:28
Re: Продолжение :) (Waytac) 10/03/2005 - 12:57:22
> Original message text:
> From: Waytac - 03/03/2005 - 11:25:53
> Subject:Объединение БД
> -----------------
> Организация имеет иерархическую структуру до 4-х уровней:
> ООО -> Филиал ООО -> Отделение филиала -> Участок отделения
>
> Во всех подразделениях независимо от уровня иерархии будет использоваться одна программа с БД на MySQL.
> Нужно будет иметь возможность объединять БД различных подразделений в одну БД путем импорта/экспорта.
>
> Как я предполагаю, будут два вида таблиц: общие и собственные. Первые - общие справочники для всей организации (с ними понятно, они общие и не экспорту, не импорту не подлежат), вторые - имеющие данные для конкретного подразделения. Как лучше поступить с ними?
> Конкретный пример:
> Есть таблица клиентов. У каждого клиента в БД есть свой ID (int unsigned auto_increment not null primary key) по которому работают все связи. При объединении будут дубли. Вводить дополнительное ключевое поле не хочется, т.к. хочется использовать правила целостности ссылок (foreign key integrity rules).
>
> Для всех подразделений хочется использовать только одну версию программ (т.е. не писать разные версии для разных подразделений).
>
> Если у кого были подобные задачи, то большая просьба поделится опытом.
>
> Если вопрос не в тему конференции, то просьба сильно не бить, а послать в более нужное место. :)
>
>
From: Валентин - 05/03/2005 - 15:43:28
Subject:Продолжение :)
-----------------
Давно подобных дисскусий не было. В общем все мы коммерческие писатели и полностью спланированную систему репликации я тебе предоставить не могу.
Единственное, что могу сказать, что система работает на практике в сети магазинов в качестве системы управления ассортиментом. Написана она на Delphi+MySQL под моим руководством.
Еще раз повторю: смысл централизованной репликации в правилах репликации, а не в багах реализации.
Могу помочь с формированием правил поведения записей в сети, а реализацию делай сам.
Насчет триггеров http://dev.mysql.com/doc/mysql/en/triggers.html
Они не то что есть, они уже могут работать, правда ограниченно.
Сейчас готовится на сборку версия 5.0.3, она скорее всего уже будет достаточна стабильна для начала разработки.
Но выбор 4.1.10 будет тоже хорошим.
Если репликация планируется изначально, то необходимо ее делать максимально простой по правилам и реализации и крайне функциональной.
Например сейчас система показала очень высокую отказоустойчивость по передаче данных, хотя я уже от нее отдалился, но результаты остались четкие и стабильные.
1) Необходимо теоретически на бумаге перечислить правила репликации, не боясь реализации и никуда не привязываясь.
2) После этого продумать реализацию для справочников, т.к. это самый узкий момент.
3) Репликация документов самое простое и объемное задание.
4) Продумать инструменты управления репликацией. Необходимо обеспечить максимальную гибкость и мониторинг событий.
5) При написании выводить все на максимальную динамику, т.е. инструмент нужно делать максимально простой и не зависящих от данных, т.е. он должен манипулировать данными и правилами, а не сам содержать все правила, это будет ошибочным, т.к. при запуске в промышленную эксплуатацию и развитии необходимо будет необднократно корректировать правила.
мыло visor123@ukr.net
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
20712
|
|
