зачем вы подсовываете человеку ORM, если ему нужно просто разбить запрос? задан вопрос по одному sql запросу, а тут уже ORM в предложениях.

и не стоит юзать ее для простых задач. только хуже сделаете.

зато придется долго париться с производительностью.

по теме (хотя уже выше отписались)
1. вам же не нужно показывать все 2500 строк. делайте лимит в запросе по количеству показанного и отдавайте только то, что нужно юзеру. например, по 50 строк.

2. откажитесь от xml. посмотрите хотя бы в сторону json

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

PDO - уровень абстракции базы данных. Тут тоже сложная история, т.как исторически задумывалось, что ODBC должно хватить всем, а на более высоком уровне все DBMS будут поддерживать стандары SQL. Но на практике выяснилось, что за несколько десятилетий существования, стандарт так полностью не реализовал практически никто.
Так вот PDO это прослойка, которая помогает учесть несовпадения между диалектами SQL, и при этом создает более общие абстракции. Например, в MySQL есть limit ключевое слово, а в MSSQL его нет, зато есть top для тех же целей. Используя PDO вам не нужно будет переписывать значительную часть кода с одного диалекта SQL на другой, т.как это будет сделано автоматически.
Но с точки зрения ОП, PDO полезен в первую очередь тем, что предлагает механизм для подстановки значений в запросы (не нужно изобретать механизмы защиты от сиквел-инйекций), а так же убирает необходимость самому перерабатывать полученные данные в нужные типы / делает эту процедуру более универсальной. В менее тривиальных ситуациях, он может помочь организовать транзакции / выборки в которых есть несколько результатов одновременно.

Что до ORM, есть задачи где объектный подход ничего хорошего не сулит. Например, обработка статистических данных, таких как, моделирование моллекул белков / извлечение информации из текста на есстесственном языке. Т.е. ситуации, когда таблицы не хранят в себе состояние, которое можно представить как объект, а наборы отношений, которые лучше представляются типами данных типа графов.

Очень походит на разговор глухого со слепым.
Пока автор топика не разберется как взаимодействовать с БД (PHP, а потом уже mysqli или PDO)
и что это такое на ощупь, данная дискуссия останется в статусе прикола.

Насколько мне известно, наоборот: стандарт реализовали все, только каждый накидал сверху ещё разных "киллерфич".
Ок. А чем по твоему занимается ORM? =)
Кстати, этим тоже занимается ORM. Я об этом писал.
И об этом. Это диалог со мной или просто? Это всё делает как раз ORM.

Сравнивать ODBS и ORM вообще не стоит. ODBC – драйвер, который умеет делать разные операции с таблицами. ORM уже работает с отношениями. Это абстракция выше. Вероятно, что многие реализации ORM являются надстройками над ODBC.

Раз такая пьянка, то я посмотрел что есть PDO и оказалось, что это обёртка над ODBC (или выглядит так, как обёртка). И честное слово, у меня нету идей по которым ты рекоммендуешь его как альтернативу ОРМу. Да, они делают похожие вещи – только ORM навяжет делать красиво и отDRYено.

Тут звучал такой аргумент, что мол, это медленно. Вообще, стоило подумать о производительности выбирая PHP, но речь сейчас не об этом.
Если этот проект мелкий, то зачем тратить время и силы на "ручную" поддержку фич, которые уже есть? Мелкие проекты априори не хайлоад, а красивый код и быстрая разработка всегда актуальны.
Хайлоад же проекты обязаны горизонтально масштабироваться. Это, конечно, вообще другая тема, но я предвижу боль шардинга без ORM. А с ним можно просто сказать моделькам, где они хранятся.

Что мало где / почти нигде не реализовано в полном объеме из стандарта:
- домейны.
- триггеры.
Частично это есть, местами даже почти все есть, но как правило все-таки не все. Триггеры особенно в контексте виртуальных таблиц - это очень заморочливая сама по себе вещь, с которой так просто не разобраться. MySQL в этом плане самый простой и наивный, мало чего умеет, и может иногда гадость сделать. Postgres - ближе всего к стандарту, наверное.
ОРМ - это связывание таблиц с объектами в прикладной программе. Для этих целей придуман специальный вид UML, который позволяет выяснить отношения между таблицами, такие как наследование / компизиция, и перевести это в описания классов программы, которая работает с базой данных.
ПДО ничем таким не занимается, он только обеспечивает совместимость / устраняет наиболее часто встречающиеся неудобства.

Использовать ПДО - ничуть не сложнее / не накладнее, чем использование библиотек привязаных к конкретной базе данных. Это вас ни к чему на уровне проектирования программы не обязывает. Используя ПДО вы можете вообще объекты не создавать, если ван не нравится.
Не нужно сначала разбираться с mysql_* группой функций, а потом переходить на использовние ПДО - ничего хорошего вы из mysql_* не почерпнете / ничего не потеряете если будете всегда использовать ПДО.

Именно. Это и есть ключевой момент: хорошей практикой является их как раз создавать. Лучше – модели, на крайняк – VO. Реальные запросы оборачивать в другие методы (скоупы) для последующего реиспользования. Создавать виртуальные атрибуты, калькулировать нужные значения. Список плюсов у создания модели гораздо больше, чем у не создания :)
С моей стороны речь про то, что ORM тоже обеспечивает совместимость и тоже устраняет неудобства.

С чего бы это? А если в языке их нет? Или, если это совсем плохо подходит к задаче? Например, в базе у вас хранится несколько миллионов молекул белков (расписаных как последовательности аминокислот), заводить на каждый белок по классу? Может еще наследовать их как-то? :) Есть много задачь, где обьекты не особо в тему...
Опять же, используете вы ПДО или нет - использовать или не использовать объекты - сугобо лично ваше дело. ПДО нет дела до того, что вы будете делать дальше с данными.
ОРМ - это привязка объектов к таблицам (отношениям). Это не техническое действие, а теоретическое, как, например, умножение. Продолжая аналогию с умножением: ПДО - это конвенция о том, какой последовательностью битовых операций на процессорах архитектуры x86-64 выполнять умножение, в какие регистры помещать множители, а в какой результат и т.д.
Можно ли использовать ПДО для реализации ОРМ? - да.
Можно ли использовать ОРМ для реализации ПДО? - нет.
Может ли существовать ОРМ без ПДО? - да.
Может ли существовать ПДО без ОРМ? - да.

А как они в базе представлены? Отображение запись в БД <-> объект в языке можно сделать всегда.

Я уже хорошо понял, чем ПДО от ОРМа отличается, не стоит повторять. Но вот примеры... Часто ли приходится на пхп решать задачи о белках или задачи, в которых полученные с таблиц данные противопоказано вязать с моделями? :)

Да, ОРМ вполне себе может быть без адаптеров к базам данных. Но мне доводилось использовать только те, которые были с ним.

Можно, но иногда бессмысленно: зачем вам миллион разных уникальных объектов-синглотонов?
Представлены? Ну, я видел разные варианты, более специализорованое ПО использует не реляционные базы, а графовые. Но можно и просто создать таблицу с несколько тысяч колонок и считать колонки порядковыми номерами аминокислот.
На ПХП - ну бывает на самом деле, в лаборатории, где работала моя знакомая большей частью использовали Перл и Питон, но ПХП от них в этом смысле не сильно отличается. У Питона просто гораздо лучше с математикой, поэтому он предпочтительнее, но если бы, например, драйвер для какой-то базы был только для ПХП, то и его бы использовали.