Новости
Документация
Download
Webboard
Поиск
FAQ/ЧаВо
Обратная связь




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: Waytac - 05/03/2005 - 14:25:51
Subject:классическое решение по mysql-ски :)
-----------------
To: (Валентин) 04/03/2005 - 10:25:09
"Ты хочешь, чтобы мы выбрали за тебя вариант реализации??? "
Нет, меня интересует мнение других по возможным вариантам реализиции. Желательно мнение тех, кто применял их на практике.
А конкретный вариант я выберу сам.

"1) Работает ли уже система без репликации? "
Нет. Есть старая файл-серверная программа на DBF.
Но нужно писать новую под MySQL. Выбор сервера изменению не подлежит.

"2) Кто-нибудь предствалял себе время реализации?"
Примерно полгода.
" это о "пожалеть, что нету триггеров". В 5.0.х триггера есть, но 5.0.2. постоянно падает, это исправлено в 5.0.3."
Вроде там реализованы хранимые процедуры, а не триггеры. Их вобще не планировалось делать.
Если я не прав, то поправте.

"Кстати я видел реализацию, в которой понятия владелец и создатель разнесены !!! работает такая модель плохо"
Можно поподробней? (можно в мыло)

To: (Евгений) 04/03/2005 - 12:15:58
Наверно ваш вариант будет предпочтительней. Т.к. основной его недостаток в части ограничения диапозонов можно преодалеть используя тип BIGINT.
Да и как заметил Валентин, проще работать с FOREING KEY. Плюс сервер на ID из другой БД будет ругаться.

To: (Dinky) 04/03/2005 - 20:02:09
Ваше предложение на счет разных таблиц не подойдет. Кол-во подразделений заранее не известно, да и зачем кучу таблиц плодить?

Уточню задачу.
Предполагается не обмен одной-двумя таблицами, а полное слияние баз нескольких подразделений, в т.ч. вышестоящего. Таблиц для обмена будет много, поэтому хочется спланировать БД сразу с учетом такой перспективы.
К примеру: Берем несколько баз, объединяем соответствующие таблицы (кроме общих справочников конечно) и работаем с общей базой. Сама программа при этом, одинаковая для всех подразделений.

"p.s. а вообще, нравятся мне такие дискуссии - спрашивающий сам толком не знает чего хочет, а все дружно ему что-то советуют :))"
Не знаю, но Валентин и Евгений дали вполне нужные и конкретные советы. Или Вы Сфинксом работаете ;)

--


[Это сообщение - спам!]

Последние сообщения из форума

Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL, версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
 Имя:
 E-mail:
 Тема:
 Текст:
Код подтверждения отправки: Code
20712



РЕКЛАМА НА САЙТЕ
  Создание сайтов | |