admak

Для подъема больших дампов лучше использовать штатые средства самого mysql, из командной строки.

Дампы я поднимаю так:

zcat backup.sql.gz |/usr/bin/mysql -uroot -p -D mydb
или
pigz -dc backup.sql.gz |/usr/bin/mysql -uroot -p -D mydb

Для винды попробуйте распаковывать дамп в STOUT при помощи 7zip, если не ошибаюсь ключик -so

Дампер хороший(лучше многих), сам использую. Но на больших дампах - ой...

Про "очень корректно" - я бы убрал слово "очень". При подъеме некоторых баз с миксом разных кодировок внутри случается эпик фейл.

упс, опоздал с советом, но хорошо, что все получилось. :)

Про требования этого фрихостинга читайте внимательно: каждые 30 дней нужно заходить в их панель управления.

Пропустили... - хостинг прощай. Мелочь, а не приятно.

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

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

Преемущество этого вида дерева:

- быстрые выборки

- любой уровень вложености

- легко модифицировать дерево (удаление/вставка/перемещение ветвей)

Недостаток:

- необходимость запуска ребилда при модификации дерева.

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

Тоже два запроса:

1. select left_key, right_key from table where id='$target'

2. select .... where left_key <= $left_key and right_key >= $right_key order by left_key asc // получить всех родителей для элемента

Можно поробовать объединить эти два запроса в один, тогда будет "пакетный" режим.

не скажу, почитать про него нужно

н-да, хорошую идею всегда можно угробить - статья и реализация жесть...

В статье предлагают такую структуру данных:

CREATE my_tree (

	id INT(10) NOT NULL AUTO_INCREMENT,

	name VARCHAR(150) NOT NULL,

	left_key INT(10) NOT NULL DEFAULT 0,

	right_key INT(10) NOT NULL DEFAULT 0,

	level INT(10) NOT NULL DEFAULT 0,

PRIMARY KEY id,

INDEX left_key (left_key, right_key, level)

)

1. parent - не хранится, при малейшем сбое/глюке - дерево посыпится. Операции вставки/удаления/перемещения - "высший" и бесполезный пилотаж. Вся мольба на поля left_key и right_key... Бред.

2. level - бесполезное поле, т.к. выборка может идти не от корня. Удобнее формировать его на лету, это не ресурсоемкая операция.

Более удобная и надежная такая структура данных:

CREATE my_tree (

	id INT(10) NOT NULL AUTO_INCREMENT,

	name VARCHAR(150) NOT NULL,

	left_key INT(10) NOT NULL DEFAULT 0,

	right_key INT(10) NOT NULL DEFAULT 0,

	parent INT(10) NOT NULL DEFAULT 0,

PRIMARY KEY id,

INDEX left_key (left_key)

)

В этой структуре значимые поля: id и parent.

left_key и right_key - просто "технические" поля, они заполняются при ребилде дерева. Удобно перед ребилдом их вообще обнулять, чтобы автоматом находить и исправлять возможные "потерянные" ветки.

Все операции по модификации дерева сводятся к изменению одного поля - parent.

Добавление/перемещение/массовая вставка - баналоно просто, ставим нужный parent и все.

Удаление всей ветки - легко, удаляем строки - это все.

После модификации дерева - запускаем ребилд, который заполняет поля left_key и right_key. Эти поля нужны для очень быстрого чтения любого куска дерева.

Сам процесс получения всего дерева или любого куска дерева сводится к двум sql запросам, упрощенно:

1. select left_key, right_key from table where id='$id' // получаем left_key и right_key нужного(корневого) элемента.

(выборка быстрая, т.к. идет по примари или уникальному ключу)

2. select .... where left_key between $left_key and $right_key order by left_key asc // получаем само дерево или нужную ветвь

(выборка быстрая, т.к. идет по индексу left_key)

Все, дерево у нас уже есть. На пхп один раз(один цикл) пробегаемся по нему - заполняем level и children.

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

А варезник - это ДЛЕ. (чаще всего)

Если в веб интерфейсе редактирование идет через textarea, то может помочь плагин к файрфоксу It's All Text! - он вызывает внешний редактор для редактирования содержимого textarea. При сохранении, во внешнем редакторе (Ctrl+S), отредактированое содержимое возвращается назад в поле textarea.

Спасибо за топик, пойду смотреть dokuwiki.

Я ответил только на:

:)

Ставьте реальные цели. (с) старая социальная реклама.

В исходном посте: 100 городов... по 10 последних новостей для каждого города. 100*10=1000 новостей на одной странице. Интересно их кто-нибудь будет читать? :)

Следующий пост: where `id`=1000 order by `ido` DESC limit 5

Итого 5000 новостей на одной странице... километровые портянки в дорвеях нервно курят в сторонке. 😂

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

Получить 10 последних новостей одним запросом будет проблематично. Пытаться испольховать финты типа where ... ido>=max(ido)-5 (при условии, что ido последовательно и непрерывно в пределах одного id) - может вылезти боком при удалении новостей, да и придеться делать лишние телодвижения пля поддержки последовательной и непрерывной нумерации, по затратам - оно того не стоит.

Рабочие варианты: кеширование, как у Вас, последних новостей в отдельной таблице или кеширование уже результирующего html блока.

select * where `id`=1 order by `ido` DESC limit 5

union all

select * where `id`=2 order by `ido` DESC limit 5

union all

....

select * where `id`=1000 order by `ido` DESC limit 5