|
|
|||||
Регистрация: Jan 2011
Сообщений: 200
|
зачем вы подсовываете человеку ORM, если ему нужно просто разбить запрос? задан вопрос по одному sql запросу, а тут уже ORM в предложениях.
Цитата:
Цитата:
по теме (хотя уже выше отписались) 1. вам же не нужно показывать все 2500 строк. делайте лимит в запросе по количеству показанного и отдавайте только то, что нужно юзеру. например, по 50 строк. 2. откажитесь от xml. посмотрите хотя бы в сторону json |
|
|||||
Регистрация: May 2010
Сообщений: 543
|
Цитата:
Ну и производительность падает не фатально, а, фактически в пределах допустимой погрешности, да и то, только в каких-то действительно сложных ситуациях.
__________________
Вы грабите бедных людей. Парень со свирелью накажет вас. Хонгильдон (с) |
|
|||||
Modus ponens
|
Цитата:
Так вот PDO это прослойка, которая помогает учесть несовпадения между диалектами SQL, и при этом создает более общие абстракции. Например, в MySQL есть limit ключевое слово, а в MSSQL его нет, зато есть top для тех же целей. Используя PDO вам не нужно будет переписывать значительную часть кода с одного диалекта SQL на другой, т.как это будет сделано автоматически. Но с точки зрения ОП, PDO полезен в первую очередь тем, что предлагает механизм для подстановки значений в запросы (не нужно изобретать механизмы защиты от сиквел-инйекций), а так же убирает необходимость самому перерабатывать полученные данные в нужные типы / делает эту процедуру более универсальной. В менее тривиальных ситуациях, он может помочь организовать транзакции / выборки в которых есть несколько результатов одновременно. Что до ORM, есть задачи где объектный подход ничего хорошего не сулит. Например, обработка статистических данных, таких как, моделирование моллекул белков / извлечение информации из текста на есстесственном языке. Т.е. ситуации, когда таблицы не хранят в себе состояние, которое можно представить как объект, а наборы отношений, которые лучше представляются типами данных типа графов.
__________________
Hell is the possibility of sanity Последний раз редактировалось wvxvw; 24.06.2013 в 12:37. |
|
|||||
[+5 18.06.13]
[+1 20.07.13] Регистрация: Apr 2012
Адрес: ifinterface.com
Сообщений: 158
|
Очень походит на разговор глухого со слепым.
Пока автор топика не разберется как взаимодействовать с БД (PHP, а потом уже mysqli или PDO) и что это такое на ощупь, данная дискуссия останется в статусе прикола.
__________________
Небольшая часть реализации моего внутреннего мира |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Цитата:
Цитата:
Цитата:
Сравнивать ODBS и ORM вообще не стоит. ODBC – драйвер, который умеет делать разные операции с таблицами. ORM уже работает с отношениями. Это абстракция выше. Вероятно, что многие реализации ORM являются надстройками над ODBC. Раз такая пьянка, то я посмотрел что есть PDO и оказалось, что это обёртка над ODBC (или выглядит так, как обёртка). И честное слово, у меня нету идей по которым ты рекоммендуешь его как альтернативу ОРМу. Да, они делают похожие вещи – только ORM навяжет делать красиво и отDRYено. Тут звучал такой аргумент, что мол, это медленно. Вообще, стоило подумать о производительности выбирая PHP, но речь сейчас не об этом. Если этот проект мелкий, то зачем тратить время и силы на "ручную" поддержку фич, которые уже есть? Мелкие проекты априори не хайлоад, а красивый код и быстрая разработка всегда актуальны. Хайлоад же проекты обязаны горизонтально масштабироваться. Это, конечно, вообще другая тема, но я предвижу боль шардинга без ORM. А с ним можно просто сказать моделькам, где они хранятся.
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Modus ponens
|
Что мало где / почти нигде не реализовано в полном объеме из стандарта:
- домейны. - триггеры. Частично это есть, местами даже почти все есть, но как правило все-таки не все. Триггеры особенно в контексте виртуальных таблиц - это очень заморочливая сама по себе вещь, с которой так просто не разобраться. MySQL в этом плане самый простой и наивный, мало чего умеет, и может иногда гадость сделать. Postgres - ближе всего к стандарту, наверное. ОРМ - это связывание таблиц с объектами в прикладной программе. Для этих целей придуман специальный вид UML, который позволяет выяснить отношения между таблицами, такие как наследование / компизиция, и перевести это в описания классов программы, которая работает с базой данных. ПДО ничем таким не занимается, он только обеспечивает совместимость / устраняет наиболее часто встречающиеся неудобства. Использовать ПДО - ничуть не сложнее / не накладнее, чем использование библиотек привязаных к конкретной базе данных. Это вас ни к чему на уровне проектирования программы не обязывает. Используя ПДО вы можете вообще объекты не создавать, если ван не нравится. Не нужно сначала разбираться с mysql_* группой функций, а потом переходить на использовние ПДО - ничего хорошего вы из mysql_* не почерпнете / ничего не потеряете если будете всегда использовать ПДО.
__________________
Hell is the possibility of sanity |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Цитата:
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Modus ponens
|
С чего бы это? А если в языке их нет? Или, если это совсем плохо подходит к задаче? Например, в базе у вас хранится несколько миллионов молекул белков (расписаных как последовательности аминокислот), заводить на каждый белок по классу? Может еще наследовать их как-то? Есть много задачь, где обьекты не особо в тему...
Опять же, используете вы ПДО или нет - использовать или не использовать объекты - сугобо лично ваше дело. ПДО нет дела до того, что вы будете делать дальше с данными. ОРМ - это привязка объектов к таблицам (отношениям). Это не техническое действие, а теоретическое, как, например, умножение. Продолжая аналогию с умножением: ПДО - это конвенция о том, какой последовательностью битовых операций на процессорах архитектуры x86-64 выполнять умножение, в какие регистры помещать множители, а в какой результат и т.д. Можно ли использовать ПДО для реализации ОРМ? - да. Можно ли использовать ОРМ для реализации ПДО? - нет. Может ли существовать ОРМ без ПДО? - да. Может ли существовать ПДО без ОРМ? - да.
__________________
Hell is the possibility of sanity |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Я уже хорошо понял, чем ПДО от ОРМа отличается, не стоит повторять. Но вот примеры... Часто ли приходится на пхп решать задачи о белках или задачи, в которых полученные с таблиц данные противопоказано вязать с моделями? Да, ОРМ вполне себе может быть без адаптеров к базам данных. Но мне доводилось использовать только те, которые были с ним.
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Modus ponens
|
Можно, но иногда бессмысленно: зачем вам миллион разных уникальных объектов-синглотонов?
Представлены? Ну, я видел разные варианты, более специализорованое ПО использует не реляционные базы, а графовые. Но можно и просто создать таблицу с несколько тысяч колонок и считать колонки порядковыми номерами аминокислот. На ПХП - ну бывает на самом деле, в лаборатории, где работала моя знакомая большей частью использовали Перл и Питон, но ПХП от них в этом смысле не сильно отличается. У Питона просто гораздо лучше с математикой, поэтому он предпочтительнее, но если бы, например, драйвер для какой-то базы был только для ПХП, то и его бы использовали.
__________________
Hell is the possibility of sanity |
Часовой пояс GMT +4, время: 13:42. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|