Новости
Документация
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 - 04/03/2005 - 09:24:45
Subject:primary key
-----------------
Т.о. на счет сабжа пока два варианта:
Вариант 1. "Каждому подразделению выделяется свой диапазон ID (достаточно большой естественно, можно воспользоваться BIGINT).
Диапазон выбирается так, что бы в ID объектов содержался некий уникальный код подразделения.
Например, если есть два подразделения c кодами 10 и 20, тогда ID объектов для каждого подразделения будут примерно такими
для 10
100001, 100002, 100003 .... 104568, 104569 ...
для 20
200001, 200002, 200003 .... 204568, 204569 ... "
Для каждого подразделения указать соответствующее значение AUTO_INCREMENT:
для 10 CREATE TABLE `MegaTable` (...) AUTO_INCREMENT=100000
для 20 CREATE TABLE `MegaTable` (...) AUTO_INCREMENT=200000

Вариант 2. В реплицируемых таблицах иметь два поля:
ID_AUTO int unsigned auto_increment not null primary key,
ID char ,
где ID = (код_подразделения) * 1000000 + ID_AUTO
Т.о. получаем уникальный автонумеруемый ключ в масштабах организации.

-----
Минусы и плюсы:

Вариант 1.
Плюсы:
1. Для ключа нужно одно поле.
2. Автоинкремент обеспечивается средствами сервера - минимум программирования.
Минусы:
1. Нужно следить за диапозонами.
2. Усложняется инсталяция базы для нового подразделения.

Вариант 2.
Плюсы:
1. Не нужно следить за ID_AUTO.
2. Можно использовать символьный ключ (кстати, как с производительностью в этом случае?).
3. Нет ограничений на диапозон.
Минусы:
1. Два поля для работы ключа, причем одно только для генерации.
2. Дополнительное программирование для поля ID (вот тут и пожалеешь, что триггеров нет :( ).
-----

Какие будут предложения?
Уточню: FOREIGN KEY - обязательно будет использоваться; тип таблиц - InnoDB.



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

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

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



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