Можете ли вы представить объект приложения так, чтобы его могла понять реляционная база данных?

Question

У Билла Карвина есть запись в блоге под названием " Почему вы должны использовать ORM ?" который обсуждается на Reddit, и я был смущен несколькими моментами.

В нем он говорит в разделе комментариев:

OODBMS и ORM работают только на объектах что мы создали в прикладной уровень. То есть нет выбора сделать запрос, подобный этому:

ОБНОВЛЕНИЕ Багов SET состояние = 'ЗАКРЫТО' ГДЕ состояние = «ОТКРЫТО»;

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

Это иллюстрирует преимущество язык как SQL, который рассматривает множества как первоклассный тип данных. ОО Парадигма не может заменить реляционная парадигма во всех случаях. Есть несколько простых операций этот SQL может сделать намного лучше.

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

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

Answer 1

Не существует ли способа представить объект, чтобы его можно было понять в реляционной базе данных?

Вы упустили смысл моих заявлений. Я не имел в виду, что нельзя хранить объект в реляционной базе данных. Я имел в виду, что парадигма ОО предполагает, что у вас есть экземпляр этого объекта в пространстве приложения . То есть вы можете вызывать методы и обращаться к свойствам объекта:

$bug->status = 'CLOSED';
$bug->save();

Но в любом ORM, который я видел ^*, вы не можете оперировать экземпляром объекта без предварительного извлечения его из базы данных. Вы также не можете оперировать целыми наборами строк одновременно, как в SQL.

Было бы интересно увидеть пакет ORM, который имел тип объекта, сопоставленный с набором данных. Затем, когда вы меняете атрибут, он применяется ко всем строкам в этом наборе. Я не видел ни одной попытки ORM сделать это.

Это было бы очень сложно из-за проблем параллелизма. Включает ли набор строки, которые были в этом наборе при создании экземпляра объекта, или при выполнении изменения, или при сохранении изменений? Если он поддерживает все эти перестановки в качестве параметров, он становится настолько сложным в использовании, что можно справедливо подумать, что он не представляет реального улучшения по сравнению с непосредственным использованием SQL.

Ваш комментарий: Нельзя сказать, что наборы и объекты несовместимы. Набор может быть объектом (в Java даже есть классы для Collection и Set). Но парадигма ОО предполагает, что операции применяются к одному экземпляру объекта, тогда как реляционные операторы всегда применяются к наборам (набор из одной строки все еще является набором). И на самом деле существующие в настоящее время пакеты ORM предполагают, что можно изменить только один экземпляр строки за раз, и вы должны были выбрать эту строку, прежде чем сможете ее изменить.

Теоретически возможно расширить возможности ORM для работы на съемочных площадках - но AFAIK никто не пытался сделать это. Я утверждаю, что ORM, который может сделать все того, что могут сделать реляционные операторы, будет намного хуже, чем SQL.

^* Я исключаю SQL-подобные псевдоязыки, такие как HQL, которые являются частью пакета ORM (Hibernate в случае HQL), но сам этот псевдоязык не может рассматриваться как ORM. 1030 *

Answer 2

Основная цель ORM - преобразовать данные из одного представления в другое; тон вашей цитаты таков, что SQL лучше подходит для пакетной обработки, и это правда - поскольку ORM преобразует таблицы реляционных данных в графы объектов, а затем обратно в таблицы.

(очень свободная) аналогия - это чан с мякотью, который вы хотите покрасить в красный цвет. Если чан представляет базу данных SQL, вы просто добавили бы краситель и пошевелили его. Использование ORM было бы похоже на преобразование целлюлозы в бумагу, окрашивание отдельных листов, а затем повторное измельчение (теперь цветной) бумаги для возврата в чан.

Answer 3

ORM отображает состояние объектов в эквивалентное состояние в базе данных. Итак, если вы хотите изменить состояние чего-либо в базе данных с помощью ORM , единственный доступный вам механизм - это сначала манипулировать объектами, представленными базой данных, а затем сохранять их состояние.

Я не уверен, что вы подразумеваете под:

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

Вы имеете в виду сериализацию объекта в структуру, которую вы могли бы преимущественно хранить в плоском файле (например, в формате XML), а затем хранить эти данные в базе данных? Если это так, да, вы могли бы. Задача будет, когда вы хотите найти эту информацию. Скажем, вы хотите найти все «закрытые» ошибки, вам нужно будет прочитать каждую ошибку, десериализовать ее и проверить ее состояние, чтобы увидеть, следует ли ее включить в список.