Можно было бы пойти по простому пути и сделать репликацию, но задача несколько иная.

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

К примеру, во второстепенной базе №1 и №2 были добавлены свои клиенты, по ним созданы заказы и т.д.
В 00:00 происходит отправка в центральную базу (думаю сделать скрипт синхронизации PHP и повесить на крон) со второстепенных баз всех изменений за день.
Затем в 01:00 со всех второстепенных баз делается запрос в центральную на обновление таблицы клиентов, и они получают в ответ все изменения (добавления/редактирования/удаления).

Но тут у меня возникает вопрос, как быть с primary key, что бы избежать дублей при получении данных со второстепенных баз?
Сделать составной primary из BaseID (код второстепенной базы) + TableID (обычный AI key)?

UPD.
Отдельная проблема возникает с пониманием синхронизации со второстепенной базы таблиц пересечений (т.е. где хранятся связи таблиц, к примеру структура таблицы Order: ClientID, ProductID), как быть с ней? Вешать OrderID + BaseID на такую таблицу, которые до этого по сути вообще были не нужны?

UPD.
Синхронизацию думал делать "INSERT ... ON DUBLICATE UPDATE" по запросу "SELECT * WHERE ChangeStamp > ДатаПоследнейСинхронизации", поле ChangeStamp во всех таблицах timestamp update on change

Arm79,
Спасибо, почитал про GUID, возникло несколько вопросов:
1) В MySQL реализация поля только через CHAR(30)?
2) Можно ли сделать autoincrement без передачи GUID со стороны клиента?
3) Насколько понял, существует проблема с кластеризацией индексов, и соответственно со временем операций?

biwed.ru,

Вы меня извините, но больше смахивает на рекламу вашего проекта, чем совет по существу.

Arm79,

Благодарю за информацию.
Не смог там найти ответ на вопрос по поводу возможности autoincrement GUID, нельзя ли, к примеру, установить для поля значение по умолчанию UUID()?
Или перед INSERT обязательно нужно будет выполнить SELECT UUID()?

И еще вопрос по типу данных, использовать все же нужно VARCHAR(38) 16 байт?
varchar для PK и для индексов ведь не самое лучшее решение?

Arm79,

Как-то у меня с триггерами не заладилось, первое знакомство с ними приводили к тому, что внесение данных в базу занимало очень много ресурсов и практически вешало железо, да и навешивать триггеры на n-нное количество таблиц - долгая процедура, когда можно в одном месте кода просто добавить (ID, ...) VALUES (UUID(), ...)

Тут другой момент возникает, как относитесь к такой информации по индексам:
binary(16) как guid

И еще вот нашел про UUID_SHORT(), но еще не понял, за счет чего он формируется.

Да что ж тут нельзя свои сообщения то редактировать?
Вот про http://dev.mysql.com/doc/refman/5.1/en/miscellaneous-functions.html#function_uuid-short

m1andry,

А вот про производительность :

I’ve created MyISAM tables containing just integer auto_increment primary key and containing char(36) value and used for UUID primary key and when I populated it with 268.435.456 rows (large enough for that 512M box to be disk bound). For auto_increment key load process took 1 hour 50 minutes giving load speed of 40305 rows/sec. For UUID process took over 12 hours and is still going. From MySQL status I can see it is loading about 200 rows/sec and the it is still slowing down a bit as key file growths. So in this little case we have about 200 times performance difference which is worth to consider

Arm79не 100%. реплика может хранить те же права доступа

Как это организовать?
Просто пока склоняюсь все же к GUID, так как это практически не приведет к перестройке структуры базы данных и кода, просто заменить текущие поля ID INT на CHAR(30) и сделать "SET ID=UUID()", но не понимаю, как сделать разграничение доступа по базам без введения дополнительной колонки BaseID, а если ее уже и вводить, то спокойно можно уже и составной ключ делать.

Arm79Вы на примере поясните, в чем видите сложность...

Ну к примеру, с локальной базы №1 заливаются данные в центральную, как пользователям группы №1 с правами доступа к локальной базе №1 ограничить данные к данным из локальной базы №2?
Нужно ведь поле, по которому можно будет идентифицировать, из какой базы зашли данные в центральную?
Или можно как-то воспользоваться только GUID?

Arm79m1andryиз какой базы зашли данные в центральную
1) а почему ваши пользователи работают с центральной вместо своей локальной реплики?
2) и почему вообще надо что-то ограничивать?

1) Пользователи каждый работает в своей локальной базе.
Раз в сутки данные с локальной отправляются в центральную.
2) Нужно понимать, с какой базы зашла информация, как по GUID можно определить отправителя информации (№ локальной базы) в центральную базу?

Arm79Зачем? Если требуется знать, в центральной БД нужно поле ReplicaID. Вы пока не обосновали, зачем вам...

Для разграничения прав пользователей.
Пользователи локальной базы №1 не должны видеть данные локальной базы №2, при этом у всех одна общая база, которая синхронизируется через центральную.
Вот и я о том же, обязательно нужно поле ReplicaID, обойтись только GUID для идентификации, откуда зашло, нельзя?

Arm79,

Да, двухсторонняя. Из центральной в локальные возвращаются обновленные общие справочники.

Кроме того, некоторым пользователям нужно давать доступ не только к своей локальной, но и к примеру соседним базам.
На простом примере из другой теоретической области это выглядит так: каждое территориальное подразделение видит только свою локальную базу, в рамках одной территориальной единицы (города/области) региональные директора видят информацию по всем своим территориальным подразделениям, в рамках всех территориальных подразделений генеральный директор видит всю информацию. Так же в подчинении генерального директора могут быть зам. директора по нескольким регионам.
В виде схему можно выразить следующим образом:

.........................Генеральный директор.......................
......................./.................|.................\..................
..................Зам1...............Зам2...............Зам3...........
.............../....|....\........../....|....\.........../....|....\.......
...........РД1..РД2..РД3...РД4..РД5..РД6...РД7..РД8..РД8..
......../...|...\...........
.......П1..П2..П3.......

Где РД - региональный директор
П - подразделения

И подразделение П1 не должно видеть данные, введенные П2, а региональный директор 1 не должен видеть данные региона №2.
Т.е. нужно разграничить права доступа по ID локальной базы, но как его вшить в UUID?
Нашел, что вроде как UUID_SHORT() формируется на основе id_server + time_serber + autoincrement, но не могу понять, где настраивать id_server и как будет меняться от этого UUID_SHORT().

Arm79m1andryUUID_SHORT()
не стоит использовать...

код подразделения нужно вводить... как минимум в центральную БД

Тоже сомневаюсь насчет него, так как неясна природа создания этого "случайно уникального" числа, но подкупает то, что тип поля INT, т.е. не прийдется перелопачивать весь код для внесения изменений с работой по ID типа String.
А как по-вашему мнению, почему UUID_SHORT() не стоит использовать?

m1andry... не прийдется перелопачивать весь код для внесения изменений с работой по ID типа String.

У меня плейсхолдеры на ID везде ?i, но это то, что на поверхности. Пока не до конца осознаю, во что еще может вылиться смена первичного ключа на String.

Arm79не стоит использовать...

Вот кстати еще один повод для сомнений.

Никак не пойму, отчего в MySQL столько мелочей-недоработок?
Почему нет возможности стандартными средствами хранить дерево в таблицах, а нужно мудрить костыли с Nested Tree?
Почему до 5.5 только на одно поле Timestamp можно было вешать CURRENT_TIMESTAMP?
Почему не оптимизирована работа с UUID (хранение, индексация, кластеризация и т.д.)?
Но это так, крик души)

Кстати, не посоветуете какой-нибудь простенький класс для работы с Nested Tree? Может сталкивались.

А вот кстати по поводу кластеризации, оказывается в UUID_SHORT можно настраивать порядок формирования значения , т.е. что бы сначала шел timestamp вместо server_id, ну и наоборот.
Скажите пожалуйста, где выставляется этот самый server_id?

javajdbcЕсли нужны какие-то тонко-настроеные права
доступа, то имеет смысл создать отдельную колонку
created_by или,например source_db_id.
Вычислять на лету источник из ГУИД , я думаю, будет
небыстро (по сравнению с отдельной
проиндексированой колонкой)

Подскажете, какое Ваше мнение насчет UUID() в качестве PK?
Все-таки CHAR(30), насколько удачно применять строчный первичный ключ?
Не будет заметной потери в производительности, если есть куча JOIN ON ID=parentID?
И также куча таблиц-связок одна-ко-многим (ID1, ID2), опять же, занимаемое место, или можно пренебречь?

Arm79m1andryПочему не оптимизирована работа с UUID (хранение, индексация, кластеризация и т.д.)?
Почему не оптимизирована? Вы с чем сравниваете то?

Сравниваю с обычным INT, или ошибаюсь? INT PK при AI пишется в индексе в конец, так как ID идет по возрастающей, а вот что будет с UUID, который постоянно генерируется с бухты-барахты?

Как вообще реализуется в крупных проектах PK? INT или делают и UUID?