Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > Серверные технологии и Flash

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 24.06.2013, 09:23
bifidokk вне форума Посмотреть профиль Отправить личное сообщение для bifidokk Найти все сообщения от bifidokk
  № 31  
Ответить с цитированием
bifidokk
 
Аватар для bifidokk

Регистрация: Jan 2011
Сообщений: 200
зачем вы подсовываете человеку ORM, если ему нужно просто разбить запрос? задан вопрос по одному sql запросу, а тут уже ORM в предложениях.

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

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

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

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

Старый 24.06.2013, 10:39
carrotoff вне форума Посмотреть профиль Отправить личное сообщение для carrotoff Найти все сообщения от carrotoff
  № 32  
Ответить с цитированием
carrotoff
 
Аватар для carrotoff

Регистрация: May 2010
Сообщений: 543
Цитата:
зато придется долго париться с производительностью.
Я тоже долго был сторонником этой мысли. Но практика показала, что возможное падение производительности компенсируется приятными бонусами при разработке и, самое главное, поддержке.
Ну и производительность падает не фатально, а, фактически в пределах допустимой погрешности, да и то, только в каких-то действительно сложных ситуациях.
__________________
Вы грабите бедных людей. Парень со свирелью накажет вас. Хонгильдон (с)

Старый 24.06.2013, 12:23
wvxvw вне форума Посмотреть профиль Отправить личное сообщение для wvxvw Найти все сообщения от wvxvw
  № 33  
Ответить с цитированием
wvxvw
Modus ponens
 
Аватар для wvxvw

модератор форума
Регистрация: Jul 2006
Адрес: #1=(list #1#)
Сообщений: 8,049
Записей в блоге: 38
Цитата:
Сообщение от Psycho Tiger Посмотреть сообщение
Честно, я не знаю, что такое PDO, но при беглом просмотре мне показалось, что это как раз ORM =)
PDO - уровень абстракции базы данных. Тут тоже сложная история, т.как исторически задумывалось, что ODBC должно хватить всем, а на более высоком уровне все DBMS будут поддерживать стандары SQL. Но на практике выяснилось, что за несколько десятилетий существования, стандарт так полностью не реализовал практически никто.
Так вот PDO это прослойка, которая помогает учесть несовпадения между диалектами SQL, и при этом создает более общие абстракции. Например, в MySQL есть limit ключевое слово, а в MSSQL его нет, зато есть top для тех же целей. Используя PDO вам не нужно будет переписывать значительную часть кода с одного диалекта SQL на другой, т.как это будет сделано автоматически.
Но с точки зрения ОП, PDO полезен в первую очередь тем, что предлагает механизм для подстановки значений в запросы (не нужно изобретать механизмы защиты от сиквел-инйекций), а так же убирает необходимость самому перерабатывать полученные данные в нужные типы / делает эту процедуру более универсальной. В менее тривиальных ситуациях, он может помочь организовать транзакции / выборки в которых есть несколько результатов одновременно.

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


Последний раз редактировалось wvxvw; 24.06.2013 в 12:37.
Старый 24.06.2013, 12:43
ZicoRio вне форума Посмотреть профиль Отправить личное сообщение для ZicoRio Найти все сообщения от ZicoRio
  № 34  
Ответить с цитированием
ZicoRio
[+5 18.06.13]
[+1 20.07.13]

Регистрация: Apr 2012
Адрес: ifinterface.com
Сообщений: 158
Очень походит на разговор глухого со слепым.
Пока автор топика не разберется как взаимодействовать с БД (PHP, а потом уже mysqli или PDO)
и что это такое на ощупь, данная дискуссия останется в статусе прикола.

Старый 24.06.2013, 13:00
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 35  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Цитата:
Но на практике выяснилось, что за несколько десятилетий существования, стандарт так полностью не реализовал практически никто.
Насколько мне известно, наоборот: стандарт реализовали все, только каждый накидал сверху ещё разных "киллерфич".
Цитата:
Так вот PDO это прослойка, которая помогает учесть несовпадения между диалектами SQL, и при этом создает более общие абстракции. Например, в MySQL есть limit ключевое слово, а в MSSQL его нет, зато есть top для тех же целей. Используя PDO вам не нужно будет переписывать значительную часть кода с одного диалекта SQL на другой, т.как это будет сделано автоматически.
Ок. А чем по твоему занимается ORM? =)
Цитата:
Но с точки зрения ОП, PDO полезен в первую очередь тем, что предлагает механизм для подстановки значений в запросы (не нужно изобретать механизмы защиты от сиквел-инйекций)
Кстати, этим тоже занимается ORM. Я об этом писал.
Цитата:
а так же убирает необходимость самому перерабатывать полученные данные в нужные типы / делает эту процедуру более универсальной.
И об этом. Это диалог со мной или просто? Это всё делает как раз ORM.

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

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

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

Старый 24.06.2013, 18:52
wvxvw вне форума Посмотреть профиль Отправить личное сообщение для wvxvw Найти все сообщения от wvxvw
  № 36  
Ответить с цитированием
wvxvw
Modus ponens
 
Аватар для wvxvw

модератор форума
Регистрация: Jul 2006
Адрес: #1=(list #1#)
Сообщений: 8,049
Записей в блоге: 38
Что мало где / почти нигде не реализовано в полном объеме из стандарта:
- домейны.
- триггеры.
Частично это есть, местами даже почти все есть, но как правило все-таки не все. Триггеры особенно в контексте виртуальных таблиц - это очень заморочливая сама по себе вещь, с которой так просто не разобраться. MySQL в этом плане самый простой и наивный, мало чего умеет, и может иногда гадость сделать. Postgres - ближе всего к стандарту, наверное.
ОРМ - это связывание таблиц с объектами в прикладной программе. Для этих целей придуман специальный вид UML, который позволяет выяснить отношения между таблицами, такие как наследование / компизиция, и перевести это в описания классов программы, которая работает с базой данных.
ПДО ничем таким не занимается, он только обеспечивает совместимость / устраняет наиболее часто встречающиеся неудобства.

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

Старый 25.06.2013, 09:43
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 37  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Цитата:
Используя ПДО вы можете вообще объекты не создавать, если ван не нравится.
Именно. Это и есть ключевой момент: хорошей практикой является их как раз создавать. Лучше – модели, на крайняк – VO. Реальные запросы оборачивать в другие методы (скоупы) для последующего реиспользования. Создавать виртуальные атрибуты, калькулировать нужные значения. Список плюсов у создания модели гораздо больше, чем у не создания
Цитата:
ПДО ничем таким не занимается, он только обеспечивает совместимость / устраняет наиболее часто встречающиеся неудобства.
С моей стороны речь про то, что ORM тоже обеспечивает совместимость и тоже устраняет неудобства.

Старый 25.06.2013, 13:49
wvxvw вне форума Посмотреть профиль Отправить личное сообщение для wvxvw Найти все сообщения от wvxvw
  № 38  
Ответить с цитированием
wvxvw
Modus ponens
 
Аватар для wvxvw

модератор форума
Регистрация: Jul 2006
Адрес: #1=(list #1#)
Сообщений: 8,049
Записей в блоге: 38
Цитата:
Сообщение от Psycho Tiger Посмотреть сообщение
хорошей практикой является их как раз создавать.
С чего бы это? А если в языке их нет? Или, если это совсем плохо подходит к задаче? Например, в базе у вас хранится несколько миллионов молекул белков (расписаных как последовательности аминокислот), заводить на каждый белок по классу? Может еще наследовать их как-то? Есть много задачь, где обьекты не особо в тему...
Опять же, используете вы ПДО или нет - использовать или не использовать объекты - сугобо лично ваше дело. ПДО нет дела до того, что вы будете делать дальше с данными.
ОРМ - это привязка объектов к таблицам (отношениям). Это не техническое действие, а теоретическое, как, например, умножение. Продолжая аналогию с умножением: ПДО - это конвенция о том, какой последовательностью битовых операций на процессорах архитектуры x86-64 выполнять умножение, в какие регистры помещать множители, а в какой результат и т.д.
Можно ли использовать ПДО для реализации ОРМ? - да.
Можно ли использовать ОРМ для реализации ПДО? - нет.
Может ли существовать ОРМ без ПДО? - да.
Может ли существовать ПДО без ОРМ? - да.
__________________
Hell is the possibility of sanity

Старый 25.06.2013, 14:33
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 39  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Цитата:
Например, в базе у вас хранится несколько миллионов молекул белков (расписаных как последовательности аминокислот), заводить на каждый белок по классу?
А как они в базе представлены? Отображение запись в БД <-> объект в языке можно сделать всегда.

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

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

Старый 26.06.2013, 00:34
wvxvw вне форума Посмотреть профиль Отправить личное сообщение для wvxvw Найти все сообщения от wvxvw
  № 40  
Ответить с цитированием
wvxvw
Modus ponens
 
Аватар для wvxvw

модератор форума
Регистрация: Jul 2006
Адрес: #1=(list #1#)
Сообщений: 8,049
Записей в блоге: 38
Можно, но иногда бессмысленно: зачем вам миллион разных уникальных объектов-синглотонов?
Представлены? Ну, я видел разные варианты, более специализорованое ПО использует не реляционные базы, а графовые. Но можно и просто создать таблицу с несколько тысяч колонок и считать колонки порядковыми номерами аминокислот.
На ПХП - ну бывает на самом деле, в лаборатории, где работала моя знакомая большей частью использовали Перл и Питон, но ПХП от них в этом смысле не сильно отличается. У Питона просто гораздо лучше с математикой, поэтому он предпочтительнее, но если бы, например, драйвер для какой-то базы был только для ПХП, то и его бы использовали.
__________________
Hell is the possibility of sanity

Создать новую тему Ответ Часовой пояс GMT +4, время: 13:42.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 13:42.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.