Видимо теперь я вас совершенно не понимаю. Примитивный пример: у нас есть таблица users, и есть 100 таблиц которые связаны с таблицей users по первичному ключу. После "синхронизации" что бы избежать коллизии у половины строк из users назначаются новые первичные ключи. Теперь, что бы ссылочная целостность сохранилась, надо так же обновить индексы у 100 зависимых таблиц... 


Потому что вместо одного insert select используется 10 селектов и 100 апдейтов.


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



Что за ерунда? Как по вашему будет работать резервный сервер, если у него данные месячной давности?

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

Да хоть раз в год пусть происходит. объект должен однозначно идентифицироваться всего 1м ключем одинаковым для всех серверов (пусть даже и составным)

и? не совпадает? другой вопрос, что в запросах в пределах одного сервера не обязательно использовать длинный идентификатор, уникальный во всей системе. а можно использовать "локально уникальный" автоинкремент. разве нет?

во-первых, селекты не нужны. в апдейтах вполне можно использовать несколько таблиц, объединенных через join. потому вместо вставки в N таблиц, мне надо сделать вставку в N таблиц и обновление в M из N, в которых есть данные о связях. Учитывая количество таблиц равное 30, это большая проблема. ога 
при репликации раз в минуту - насчет нагрузки был бы дикий аргумент. а так, даже не знаю, как реагировать 
вот с 

я согласен. только вот в моем представлении сие действо(синхронизация) происходила бы дважды в сутки. как часто по-твоему это должно быть сделано(не важно - по какой схеме)?

естественно. хотя мог бы, если бы добавил идентификатор, уникальный для всех "наших" товаров. как предлагает Fortop.

в моем варианте так и происходит - поле guid это "где-то сохраненные ключи внешних сущностей"

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

ну, что за горячие финские парни! неужто я так раздражаю своей упрямостью/ограниченностью/непониманием(нужное подчеркнуть)?

Нет, не мог бы, т.к. id в яндекс маркете - это загран паспорт, а id у нас - это наш российский паспорт, который генерируется по своим законам, и которые яндексу не подвластны. 

А вот если бы все интернет магазины, участвующие в программе яндекса, были разработаны самим яндексом, то тогда он бы так и сделал.

Вот еще один наглядный пример. Бывало ли у вас когда-нибудь, что находишь в поисковике статью, кликаешь по ссылке, а попадаешь на уже на другую? Вроде заходили по уникальному идентификатору статьи... а оказывается он уникальный только до следующей синхронизации.


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

И опять же. У яндекс маркета это вынужденная мера, т.к. данные к ним приходят из-вне от 3d-paty магазинов, и уверен это доставило им не мало хлопот при разработке. Вы же добровольно вешаете себе эту петлю на шею.


Вы считаете, что несколько раз в минуту забирать (я подчеркиваю, просто забирать без какой-либо обработки данных) лог транзакций в пару десятков киллобайт - это сколько-нибудь большая нагрузка для сервера? И это хуже чем лочить на N-ое время все таблицы и перелопачивать половину базы при ручном слиянии?


Синхронизация и репликация - это разные вещи. replication



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



Ну вы же сами согласились с тем, что сервер с данными месячной "свежести" никому не нужен 

почему? где я о подобном говорил? людям, как и системе синхронизации, давать работать с длинным и поистине уникальным идентификатором. внутренние запросы могут строится по более "скоростной" схеме. впрочем, ты прав: изначально про проблемы людей я не думал.

дошли до споров о терминах. о"кей. как тогда под "тиражирование" попадает репликация слиянием(merge replication)?

Добавлено через 4 минуты и 8 секунд

как пример. на данном форуме вот так выглядит ссылка на раздел: http://forum.vingrad.ru/forum/PHP-forum.html
в БД ведь не "PHP-forum" выступает первичным ключом, а какой-нибудь id, равный 125487. правда? и ничего. два уникальных идентификатора: людям/поисковикам и "для внутренней кухни"

Добавлено через 7 минут и 32 секунды
наверное, уперся я в свой вариант исключительно оттого, что он "свой" и предполагает внесенния минимум изменений в существующий код.
пришла пора много думать и беспристрастно сравнивать   
спасибо за внимание.

Ок, проехали. Я вас не правильно понял. Вероятно, яндекс пользуется подобной схемой.


Я всего-лишь хотел подчеркнуть смысл слова "репликация" и то, что в данном случае она ничего не стоит.


Это совершенно разные вещи. Данный short name - это уникальный индекс (а может даже и не уникальный), предназначенный специально для людского фактора, вывод на экран, формирования красивых ссылок и не для чего более. К тому же количество форумов ограничено, по этому short name не предоставляет никаких дополнительных затрат.

Все же первичные ключи, я уверен, здесь уникальны (как это про guid-ы говорится) во времени и пространстве.

И обрати внимание, что для топиков доступ уже по id http://forum.vingrad.ru/forum/topic-222972/anchor-entry1600986/30.html

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

конечно, обратил.
Но "PHP-forum" однозначно резолвится и никто от этого не страдает. правда? 
вообще говоря, нашел ещё один штук возможности дампить без привязки к автоинкременту: можно сделать неполный дамп и только на основании уникального идентификатора вытянуть все связанные объекты. т.е. такой себе объектный бекап в отличие от низкоуровневого "все подряд" лога изменений. 
но, правда, это уже никак не связано с созданием резерва-зеркала...

А теперь вопрос: стоит ли всё это создания сайта-зеркала?   
Большинство хороших хостеров гарантируют uptime около 99,9% и резервируют данные

Синхронизация?  


PHP-forum - это не первичный ключ, это индекс. Я тоже не знаком с движком форума, но уверен на ~100%, что первичные ключи в нем нигде не перегенерируются.

Не понимаю, откуда у всех PHP программистов такая любовь к велосипедам?

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

с точки зрения человека - это первичный ключ.

а сколько у форума независимых на уровне данных(в смысле - нет общего сервера БД или файлсервера) зеркал?   

откуда у всех РНР-программистов такая тяга к глобальным обобщениям?   

Первое не убедительно, ИМХО, проще сменить хостинг на нормальный. А вот вторая часть заинтересовала   

А имеет ли право на жизнь вариант с третей базой, в которую будут заноситься данные и с первой и со второй? Добавил новость на одном сайте - данные занеслись в первую базу и третью. Занёс данныне со второго сайта - обновилась вторая база и, опять же, третья. А потом на каждом из сайтов сверять свою базу с третей и делать импорт недостающих данных.

Плюс такого способа - можно делать n зеркал, и простота реализации.

Это сообщение отредактировал(а) HackMan - 4.8.2008, 23:04

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


Сколько зеркал не знаю, но у него как миниму еще 2 проекта использующего базу с юзерами.


Не знаю, я на C# программирую 


Это и называется репликация баз данных, о которой я твержу уже 3ию страницу, с одним отличием - никакого импорта недостающих данных делать не надо и при этом с увеличением производительности.

sTa1kEr, оу, сорри. Прочитал сначала первую страницу, остальное сразу не осилил  
Потом написал пост и стал читать дальше   

А вот импорт данных делать на тот случай, если ляжет master-сервер. Хотя, если ведущий сервер ляжет, можно на сайтах написать что-то вроде "Извините, в данный момент сайт недоступен по техническим причинам". Такое же не каждый день будет случаться, и пережить можно?

Добавлено @ 23:25

А вот про коллизии - можно реализовать структуру как на Вики - хранить историю изменений.

Это сообщение отредактировал(а) HackMan - 4.8.2008, 23:26

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

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

блоги и vingrad.ru? а они разве не на одном хостинге(т.е. просто работают с одной БД общего пользования)?

Ты однака не человека - ты программиста 


У тебя они генерируются дважды!!!!
1й раз при вставке на один сервер, второй раз при синхронизации.....
И сколько серверов мы будем использовать, столько раз будет происходить перегенерация ключа у конкретного объекта...