Используя ORM или простой SQL? [закрытый]
Попробуйте также старый синтаксис для кастинга,
SELECT ROUND(AVG(some_column)::numeric,2)
FROM table;
работает с любой версией PostgreSQL.
В некоторых функциях PostgreSQL наблюдается нехватка перегрузок (почему? ?): Я думаю, что «это недостаток» (!), Но @CraigRinger, @Catcall и команда PostgreSQL согласны с «историческим обоснованием pg».
PS: еще одна точка вокруг округления - это точность, проверьте @ ответ ЯнКенни .
Перегрузка в качестве стратегии кастинга
Вы может перегрузить функцию ROUND с помощью
CREATE FUNCTION ROUND(float,int) RETURNS NUMERIC AS $$
SELECT ROUND($1::numeric,$2);
$$ language SQL IMMUTABLE;
Теперь ваша инструкция будет работать нормально, попробуйте (после создания функции)
SELECT round(1/3.,4); -- 0.3333 numeric
, но она вернется NUMERIC ... Чтобы сохранить первую перегрузку коммо-использования, мы можем вернуть FLOAT-тип, когда предлагается параметр TEXT,
CREATE FUNCTION ROUND(float, text, int DEFAULT 0)
RETURNS FLOAT AS $$
SELECT CASE WHEN $2='dec'
THEN ROUND($1::numeric,$3)::float
-- ... WHEN $2='hex' THEN ... WHEN $2='bin' THEN... complete!
ELSE 'NaN'::float -- like an error message
END;
$$ language SQL IMMUTABLE;
Попробовать
SELECT round(1/3.,'dec',4); -- 0.3333 float!
SELECT round(2.8+1/3.,'dec',1); -- 3.1 float!
SELECT round(2.8+1/3.,'dec'::text); -- need to cast string? pg bug
PS: проверка \df round после перегрузок, покажет что-то вроде:
Schema | Name | Result data type | Argument data types ------------+-------+------------------+---------------------------- myschema | round | double precision | double precision, text, int myschema | round | numeric | double precision, int pg_catalog | round | double precision | double precision pg_catalog | round | numeric | numeric pg_catalog | round | numeric | numeric, int
Функции pg_catalog являются стандартными, см. руководство по встроенным математическим функциям ].
9 ответов
ORMs имеют некоторые хорошие функции. Они могут обработать большую часть работы собаки копирования столбцов базы данных к полям объекта. Они обычно обрабатывают преобразование типов даты и времени языка к соответствующему типу БД. Они обычно обрабатывают связи "один ко многим" довольно изящно также путем инстанцирования вложенных объектов. Я нашел, разрабатываете ли Вы свою базу данных с достоинствами и недостатками ORM в памяти, это сохраняет большую работу во вкладывании данных и из базы данных. (Вы захотите знать, как это обрабатывает полиморфизм и many-many отношения, если необходимо отобразить их. Именно эти два домена обеспечивают большую часть 'несоответствия импеданса', которое выполняет некоторый вызов ORM 'Вьетнам информатики'.)
Для приложений, которые являются транзакционными, т.е. Вы выполняете запрос, получаете некоторые объекты, пересекаете их, чтобы получить некоторые данные и представить их на Веб-странице, налог на производительность является маленьким, и во многих случаях ORM может быть быстрее, потому что они будут кэшировать объекты, они замечены прежде, который иначе запросил бы базу данных многократно.
Для приложений, которые тяжелы созданием отчетов, или соглашение с большим количеством строк базы данных на запрос, налог ORM является намного более большим, и кэширование, которое они делают, превращается в большую, бесполезную нагрузку памяти-hogging. В этом случае простое отображение SQL (LinQ или iBatis) или кодированные рукой SQL-запросы в тонком DAL является способом пойти.
я нашел для любого крупномасштабного приложения, Вы будете использовать оба подхода. (ORM для простого CRUD и SQL DAL / тонкий DAL для создания отчетов).
ORM не является просто мобильностью (которого довольно трудно достигнуть даже с ORMs, в этом отношении). То, что это дает Вам, является в основном слоем абстракции по персистентному хранилищу, когда инструмент ORM освобождает Вас от записи шаблонных SQL-запросов (выбирает PK или предикатами, вставляет, обновляет и удаляет), и позволяет Вам сконцентрироваться на проблемной области.
Разговор, поскольку кто-то, кто провел довольно мало времени, работая с JPA (Персистентность Java API, в основном стандартизированный API ORM для Java/J2EE/EJB), который включает, в спящем режиме, EclipseLink, Toplink, OpenJPA и другие, я совместно использую некоторые свои наблюдения.
- ORMs не быстры. Они могут соответствовать, и большую часть времени соответствующий в порядке, но в среде низкой задержки большого объема они нет - нет;
- На языках программирования общего назначения как Java и C# Вам нужно очень большое волшебство заставить их работать (например, время загрузки, переплетаясь в Java, инструментарии, и т.д.);
- При использовании ORM, вместо того, чтобы добраться далее от SQL (который, кажется, намерение), Вы будете поражены, сколько времени Вы тратите тонкую настройку XML и/или аннотации/атрибуты, чтобы заставить Ваш ORM генерировать производительный SQL;
- Для сложных запросов, действительно нет никакой замены. Как в JPA существуют некоторые запросы, которые просто не возможны, которые находятся в необработанном SQL и когда необходимо использовать необработанный SQL в JPA, это не симпатично (C#/.Net, по крайней мере, имеет динамические типы - var - который намного более хорош, чем Объектный массив);
- существует очень много "глюков" при использовании ORMs. Это включает непреднамеренное или неожиданное поведение, то, что необходимо создать в возможности сделать обновления SQL базы данных (при помощи обновления () в JPA или похожих методах, потому что JPA кэшами по умолчанию все так это не поймает прямое обновление базы данных - рабочий прямой SQL обновляет, является общей производственной поддержкой деятельности);
- объектно-реляционное несоответствие всегда собирается вызвать проблемы. С любой такой проблемой существует компромисс между сложностью и полнотой абстракции. Время от времени я чувствовал, что JPA зашел слишком далеко и поразил правовые нормы убывающей доходности, где хит сложности не был выровнен по ширине абстракцией.
существует другая проблема, которая берет немного больше объяснения.
традиционная модель для веб-приложения должна иметь слой персистентности и уровень представления (возможно с сервисы или другие промежуточные слои, но это важные два для этого обсуждения). ORMs вынуждают твердое представление покинуть Ваш слой персистентности до уровня представления (т.е. Ваши объекты).
Одно из критических замечаний большего количества необработанных методов SQL - то, что Вы заканчиваете со всеми этими VOs (объекты значения) или DTOs (объекты передачи данных), которые используются просто одним запросом. Это рекламируется как преимущество ORMs, потому что Вы избавляетесь от этого.
Вещью являются те проблемы, не уходят с ORMs, они просто перемещаются до уровня представления. Вместо того, чтобы создать VOs/DTOs для запросов, Вы создаете пользовательские объекты представления, обычно один для каждого представления. Как это лучше? По моему скромному мнению, это не.
я записал об этом в ORM или SQL: Мы там уже? .
Моя предпочтительная технология персистентности (в Java) в эти дни является ibatis. Это - довольно тонкая обертка вокруг SQL, который делает 90% + того, что JPA может сделать (это может даже сделать ленивую загрузку отношений хотя не хорошо зарегистрированный), но с намного меньше служебным (с точки зрения сложности и фактического кода).
Это подошло в прошлом году в приложении GWT, которое я писал. Большой перевод от EclipseLink до объектов представления в реализации услуги. Если бы мы использовали ibatis, было бы намного более просто создать соответствующие объекты с ibatis и затем передать их полностью вверх и вниз по стеку. Некоторые пуристы могли бы утверждать, что это - Bad™. возможно, так (в теории), но я говорю Вам что: это привело бы к более простому коду, более простому стеку и большей производительности.
Для любого значительного дизайна будет нужна некоторая абстракция для базы данных, только для обработки несоответствия импеданса. Но самый простой первый шаг (и достаточный для большинства случаев) я ожидал бы, будет DAL, не тяжелый ORM. Ваши единственные опции не являются опциями в концах спектра.
<час>РЕДАКТИРОВАНИЕ в ответ на комментарий, запрашивающий меня описать, как я отличаю DAL от ORM:
А DAL - то, что Вы пишете себе, возможно, начинающий с класса, который просто инкапсулирует таблицу и отображает ее поля на свойства. ORM является кодом, который Вы не пишете или механизмы абстракции, выведенные из других свойств Вашей схемы DBMS, главным образом PKs и FKs. (Это - то, где Вы узнаете, начинают ли автоматические абстракции становиться текучими или нет. Я предпочитаю сообщать им намеренно, но который может просто быть моим персональным предпочтением).
Ключ, который заставил мое использование ORM действительно полететь, был генерацией кода. Я соглашаюсь, что маршрут ORM не является самым быстрым в терминах производительности кода. Но когда у Вас есть средняя и крупная команда, DB изменяет быстро способность повторно создать классы и отображения от DB, поскольку часть процесса сборки является чем-то блестящим для созерцания, особенно при использовании CI. Таким образом, Ваш код не может быть самым быстрым, но Ваше кодирование будет - я знаю, который я взял бы в большинстве проектов.
Моя рекомендация состоит в том, чтобы разработать использование ORM, в то время как Схема все еще жидка, используйте профилирование для нахождения узких мест, затем настройте те области, которым нужен он с помощью необработанного Sql.
Другая мысль, кэширование, созданное в, в спящем режиме, может часто делать крупные повышения производительности, если используется правильным способом. Больше никакого возвращения к DB к данным считанной ссылки.
Дилемма, использовать ли платформу или не довольно распространен в современном дневном сценарии разработки программного обеспечения.
, Что важно для понимания, то, что каждая платформа или подход имеют свои за и против - например, по нашему опыту, мы нашли, что ORM полезен при контакте с транзакциями, т.е. вставьте/обновите/удалите операции - но когда дело доходит до данных выборки со сложными результатами становится важно оценить производительность и эффективность инструмента ORM.
Также важно понять, что не обязательно выбрать платформу или подход и реализовать все в этом. Под чем мы подразумеваем, который является, у нас может быть соединение ORM и собственного языка запросов. Много платформ ORM дают точки расширения плагину в собственном SQL. Мы должны попробовать не к по использованию платформа или подход. Мы можем объединить определенные платформы или подходы и идти с соответствующим решением.
можно использовать ORM когда дело доходит до вставки, updation, удаления, управления версиями с высоким уровнем параллелизма, и можно использовать Собственный компонент SQL для поколения отчета и длинного списка
Нет никакого 'one-tool-fits-all' решения, и это также верно для вопроса, 'я должен использовать or/m или нет?'.
я сказал бы: если необходимо записать приложение/инструмент, которое является очень сфокусированными 'данными' без большой другой логики, то я 'd использую плоскость SQL, так как SQL является проблемно-ориентированным языком для этого вида приложений.
, С другой стороны, если я должен был записать бизнес/корпоративное приложение, который содержит большую 'доменную' логику, затем я записал бы богатую модель класса, которая могла выразить этот домен в коде. В таком случае картопостроитель OR/M мог бы быть очень полезным, чтобы успешно сделать так, поскольку он вынимает большую инфраструктуру кода из Ваших рук.
Одно из приложений, которые я разработал, было ботом IRC, записанным в Python. Модули, которые это использует выполненный в отдельных потоках, но я не выяснил способ обработать поточную обработку при использовании sqlite. Хотя, который мог бы быть лучше для отдельного вопроса.
я действительно должен был просто перефразировать обоих заголовок и фактический вопрос. Я на самом деле никогда не использовал DAL прежде ни на каком языке.
Я говорю что плоскость SQL для Чтений, ORM для CUD.
Производительность - что-то, что я всегда обеспокоен, особенно в веб-приложениях, но также и надежности кода и удобочитаемости. Для решения этих проблем, я записал SqlBuilder.