Наверно мой ответ можно было бы разместить под грифом "Оффтоп", но я вам всё же порекомендую обратить внимание на следующий способ: все запросы переадресовываются на "морду" и парсить их уже средствами php. Т.е. в .htaccess только такие правила:
Теперь $uri_parts будет содержать части: array('firms','russia'), которые вы можете самостоятельно анализировать и в зависимости от их значений, выдавать ту или иную информацию.
Таким образом, вы избавляетесь от лишней головной боли, создаваю куча правил.
Это я уже просто скопипастил у ТС Не нужно, конечно
P.S. Кстати, обратил внимание на счетчик цикла: там берется 10 строк. В этом случае, file() пригодиться. Поместили в массив > array_slice() на десять элементов > запись
Давайте по другому, чтоб наверняка. Есть разные инструменты для отладки. Если иcпользуете Chrome, то это "Инструменты разработчика" (Ctrl+Shift+I), но лично мне более удобно отладку делать в FireBug (под FireFox). И в Opera есть аналоги, и других браузерах тоже. Что выберите - дело личное. Но в любом случае, эти отладчики, позволят вам видеть какие данные передаются на сервер, что сервер возвращает на запрос и другую полезную инфу тоже можно там получать, и отслеживать различные процессы.
Кракозябры поправил ;юфофч() === $.ajax(). Про консоль, я думаю, что значете, остался вопрос по поводу селектора и еще один момент - путь к обработчику: не нужно писать полный адрес, достаточно указать от корня сайта "/action.php".
Покажите, как вы формируете ответ в серверной части.
P.S. Только что обратил внимание на этот кусочек кода - $('a .plus'). Такой селектор указывает, что выбрать элементы с классом "plus", которые являются дочерними тэгов <a>. Но для вашего случая, тэг и класс относятся к одному элементу. Поэтому запись должна быть такой:
Что-то я последнюю мысль вашу не особо уловил. Если это вопрос, то да "обязательно в уникальный ключ". PRIMAREY KEY - может быть только один, UNIQUE KEY - может быть множество, плюс ко всему, можно группировать поля таблицы под один уникальный ключ. Схематически так:
То есть пусть переписывает БД пока не устанет? Как я понял.
Второй вариант я привел, как возможный для определенных целей. Если надо просто исключить дублирование данных (одинаковый login, email и т.д.), то первого вполне достаточно.