ThunderCat

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

1) читать про join
2) читать про индексы тут, тут и тут.
3) составить запрос и прогнать его через explain.
4) Настроить индексы...
5) Profit

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

Если данных не много и вы заранее знаете какие данные вам нужны для селекта просто получите их в json и используйте когда нужно. Если же данных много и они заранее не известны - запрашивайте их с сервера Аяксом. Можно даже в виде готового хтмл для селекта.

1) путь куда загружаете существует?
2) проверьте путь, не факт что вы его правильно указали( у вас путь читается от папки текущего скрипта, лучше использовать $_SERVER['DOCUMENT_ROOT'] и путь от него)
3) Права на папку куда пишете какие?
4) Ерор репортинг включите, отладка требует уровня E_ALL

Только UPDATE должен применяться

почему бы и нет?

update `users` 
set id = 42
where username = 'Duglas Adams'

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

Во первых:
$("#form").submit(function(e) {
e.preventDefault();
$.ajax({ ...
иначе форма будет пытаться засубмититься через раз( ретурн фалс не всегда срабатывает).

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

В третьих так же неплохо проверить что данные попадают в нужный скрипт, а то у вас довольно фривольно указан адрес куда аякс должен стучаться. Скорее всего скрипт тупо не понимает адрес который прописан, указывать нужно от корня сайта, например "/addguestbook.php"

всё будет в порядке Ровно до того времени пока вы не перейдете на зимнее или летнее время, и вот тут, в зависимости от того в какой стране прописана временная зона, спокойно может возникнуть разница в 1 час. опять же Это только в том случае если используется синтаксис mysql для вставки текущей даты, например функция now.

Элементарно, Ватсон. Поле текста новости - ckeditor? Если нет - ставим, и подключаем картинки из локальных папок.

`dialog_id` int(16) NOT NULL, - 16 отображаемых знаков - тут вроде не должно быть так, там может быть максимум (11) при int, и емнип в любом случае размер отводимой памяти будет 4 байта. Если вы планируете хранить более 4 миллиардов записей используйте bigint.

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

Можно выбрать так:

SELECT id, `product`.title, `product`.typeID, `type`.title, 
type`.typeID  type_typeID, type`.title  type_ttitle
FROM `product` 
LEFT JOIN `type` 
on `product`.typeID=`type`.typeID 
where `product`.typeID=1

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

Я бы не стал заморачиваться с поиском лучшего решения на пустом месте, если бы лучшая бд существовала, остальные бы умерли в неизвестности. В вашем случае я бы использовал MySQL, как минимум на начальном этапе, и вот почему:
1) Это бесплатно
2) Мускуль - хороший добротный середнячек своего класса, то есть он умеет почти все и при этом сильно не проседает по производительности.
3) На него ОГРОМНОЕ количество доков и юзеркейсов, а так же туториалов и советов по оптимизации в конкретную задачу.
4) При смене бд(если таковая понадобится) вам, скорее всего, придется только поменять драйвер бд(при условии грамотной архитектуры) и аккуратно перенести дамп базы.
5) Про MSSQL - до недавнего времени в ней не было нативной поддержки UTF-8, вместо нее была(и есть еще вроде) своя UCS, которая мультибайт, но какой-то свой(как всегда у мс), в свое время в угоду "скорости" ставили сервак с мсскулем, в итоге практически никакого прироста не получили, зато получили гемор с переводом кодировок.
6) Если проект реально нуждается в разрывном бд на пределе современных возможностей - смотрите в сторону инмемори бд, например тарантул или что-то носкюельное, типа редис и иже с ним.

Это что за архитектура такая???
В таблице ремонта у вас должно храниться только ид техники, НИЧЕГО ДРУГОГО из таблицы техники в таблицу ремонта попасть не должно (дата и прочие атрибуты относящиеся конкретно к ремонту еще добавляются), при выборке делается объединение таблиц по ид с выводом техники которая в ремонте. И запросы с какими то извращениями тоже не нужны.
У вас должен быть какой то фронт же? На нем выбираете галочками что отправить в ремонт, валуе галочек у вас будет ид техники. На бэкенде получаете массив идентификаторов. перебираете и запихиваете каждую запись в таблицу. Профит.

Like не работает

в каком смысле не работает? У вас не работает или выключена(как?) возможность использования?

1) * parent_id
2) нестед сидс проще реализовать на клиенте

Так а вопрос то в чем?
1)Не хватает ресурсов - покупаем мощности сервера,
2) не хватает данных - запрашиваем чаще,
3) опять не хватает мощности - см. п. 1.

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