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

Если у тебя система это 1 сервер, то ты можешь смотреть с его точки зрения.

Но в данном конкретном случае у тебя получается так:

Жило было фото на имя Ивана Петровича Козлова, 
и тут сделали его копию и переложили из левого кармана в правый... И вуаля! Теперь у нас фото Иннокентия Абрамовича Шмыги.

Тебе не кажется это странным? 

война аналогий? пожалуйста. контент же остается прежним, потому тут скорее уместно сравнение: если на бумаге "кодак", то это фото Ивана Петровича Козлова. А если напечатать на другой бумаге, то это . Так у тебя получается?   

Ну вот ты сам все и объяснил 
Тогда ответь, почему одно и тоже изображение, но на разной фотобумаге - у тебя считается разным человеком? (имеет разный ID)

guid(т.е. уникальный в масштабах всей системы) - одинаковый. а то, что id разный - так и бумага разная... 

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


А вот для разной бумаги можно уже и генерировать разные индексы id, short_name-ы, etc сколько влезет и что бы удобнее получать информацию, и для синхронизации, и просто от нечего делать.

Это сообщение отредактировал(а) sTa1kEr - 5.8.2008, 17:57

Только мы от него отказались раньше

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

skyboy, скажи, а у сайта динамика большая? Если нет, то можно еще один вариант использовать...

Верно, так как при использовании стандартного механизма репликаций этой проблемы просто нет - можно спокойно использовать int.

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

skyboy, ну тут смысл вообще какой. Начиналось все с того, что я долго думал, как снизить нагрузку на сервер практически до нуля (до уровня обработки статических страниц). Динамика помимо того что генерирует страницу сохраняет ее копию в качестве статической html. При обращении к движку он делает проверку, мол а надо ли страницу генерировать? (ответ на "надо ли" может зависеть от многих факторов, не суть в этом), если надо - генерируем, если нет, тупо через readfile отдаем пользователю уже готовый html. Процесс - псевдо-кэширование.

Додумался я в свое время до частичной генерации, например для форумов. Сейчас уже, конечно и не вспомню (сразу) всех нюансов.

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

P.S. я надеюсь ты продумал ситуацию, когда у тебя первый сервак отказал, второй работает, обновляет СВОЮ базу, а потом, когда заработает первый ты должен уже его синхронизировать со вторым...

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

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