По моему опыту, ORM являются отличным инструментом для использования на внешнем интерфейсе, где вы в основном просто читаете данные или обновляете по одной строке за раз. На сервере, где вы принимаете потерянные данные одновременно, они могут вызвать проблемы из-за того, как они обычно взаимодействуют с базой данных.
В качестве примера предположим, что у вас есть объект Person с длинным списком друзей (скажем, на данный момент 100). Вы создаете объект Person и назначаете ему 100 друзей, а затем сохраняете его в базе данных. Обычно наивное использование ORM выполняет 101 запись в базу данных (по одной для каждого друга, по одному для человека). Если бы вы делали это в чистом SQL на более низком уровне, вы бы сделали 2 записи, одну для человека, а затем одну для всех друзей одновременно (вставка со 100 фактическими строками). Разница между этими двумя действиями значительна.
Есть несколько способов обойти эту проблему.
- Используйте API базы данных более низкого уровня, который позволяет написать команду типа «вставьте 100 друзей за один вызов»
- Используйте ORM, который позволяет писать SQL более низкого уровня, чтобы вставлять Friends в виде одной команды SQL (не все из них допускают это, и я не знаю, есть ли в Rails)
- Используйте ORM, который позволяет выполнять пакетную запись в один вызов базы данных. Это все еще 101 запись в базу данных, но это позволяет ORM объединить их в один сетевой вызов базы данных и сказать «сделайте эти 101 вещь». Я не уверен, что ORM позволяют это.
- Возможно, есть другие способы
Суть в том, что использование ORM для загрузки любого объема данных реального размера может привести к проблемам с эффективностью. Понимание того, что ORM делает изнутри (лучший способ понять, что он делает - попросить его записывать все вызовы БД) - лучший первый шаг. Как только вы поймете, что он делает, вы можете найти способы сказать ему: « то, что я делаю, плохо вписывается в обычный шаблон, давайте изменим способ его использования » ... и Если это не работает, вы можете использовать API более низкого уровня, чтобы учесть это.
Я укажу еще одну вещь, на которую вы можете посмотреть с СИЛЬНЫМ предостережением, что это должно быть одной из последних вещей, которые вы считаете. При массовом добавлении строк в базу данных можно создать необработанный текстовый файл со всеми данными (формат зависит от БД, но концепция аналогична CSV-файлу) и передать этот файл в базу данных для массового импорта. Это плохой путь почти во всех случаях, но я хотел включить его, потому что он существует как опция.
Редактировать : В качестве дополнительного примечания, комментарий о более эффективном синтаксическом анализе XML тоже стоит посмотреть. Использование SAX vs DOM или другой библиотеки XML может быть очень выигрышным во времени до завершения. В некоторых случаях это может быть даже более выигрышным, чем более эффективное взаимодействие с базой данных Например, вы можете анализировать много XML с большим количеством небольших фрагментов данных, а затем использовать только небольшие их части. В таком случае анализ может занять много времени через DOM, в то время как SAX может игнорировать части, которые вам не нужны ... или он может использовать много памяти для создания объектов DOM и замедлять все из-за мусора коллекция и т. д. По крайней мере, стоит посмотреть.