Оптимизация взаимодействия с БД

[carrotoff]

Имитация сложных реляционных отношений в ОО может оказаться непосильным трудом / запутать.

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

Предполагает специфическую структуру базы данных, обязывает к специфическому подходу к построению запросов

Скажите это тем, кто использует рельсы или джангу. Зато (назовем все это ORM) на себя берет из коробки львиную долю модельной логики, и не нужно париться о безопасности запросов.

гугл предложил достаточно много полноценных ORM, с has_many из коробки и прочим.

для php уже придумано не хуже чем на ROR. Гуглите Yii ActiveRecord, Kohana ORM, symfony2 doctrine.

Сами используем для Python Джангу и для php Yii. Это очень хорошие штуки.

[bifidokk]

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

ORM - это уже претензия на архитектуру.

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

Зато (назовем все это ORM) на себя берет из коробки львиную долю модельной логики, и не нужно париться о безопасности запросов.

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

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

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

[carrotoff]

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

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

[ZicoRio]

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

[Psycho Tiger]

Но на практике выяснилось, что за несколько десятилетий существования, стандарт так полностью не реализовал практически никто.

Насколько мне известно, наоборот: стандарт реализовали все, только каждый накидал сверху ещё разных "киллерфич".

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

Ок. А чем по твоему занимается ORM? =)

Но с точки зрения ОП, PDO полезен в первую очередь тем, что предлагает механизм для подстановки значений в запросы (не нужно изобретать механизмы защиты от сиквел-инйекций)

Кстати, этим тоже занимается ORM. Я об этом писал.

а так же убирает необходимость самому перерабатывать полученные данные в нужные типы / делает эту процедуру более универсальной.

И об этом. Это диалог со мной или просто? Это всё делает как раз ORM.

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

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

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

[wvxvw]

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

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

[Psycho Tiger]

Используя ПДО вы можете вообще объекты не создавать, если ван не нравится.

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

ПДО ничем таким не занимается, он только обеспечивает совместимость / устраняет наиболее часто встречающиеся неудобства.

С моей стороны речь про то, что ORM тоже обеспечивает совместимость и тоже устраняет неудобства.

[wvxvw]

Сообщение от Psycho Tiger

хорошей практикой является их как раз создавать.

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

[Psycho Tiger]

Например, в базе у вас хранится несколько миллионов молекул белков (расписаных как последовательности аминокислот), заводить на каждый белок по классу?

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

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

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

[wvxvw]

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