Для подъема больших дампов лучше использовать штатые средства самого 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
