Повечето реализации на DBAPI буферират напълно редовете, когато се извличат - така че обикновено, преди SQLAlchemy ORM дори да получи един резултат, целият набор от резултати е в паметта.
Но тогава, начинът Query работи е, че напълно зарежда дадения набор от резултати по подразбиране, преди да ви върне вашите обекти. Обосновката тук се отнася до заявки, които са повече от прости оператори SELECT. Например, при свързвания към други таблици, които могат да връщат една и съща идентичност на обекта няколко пъти в един набор от резултати (често срещано при нетърпеливо зареждане), пълният набор от редове трябва да бъде в паметта, за да могат да бъдат върнати правилните резултати, в противен случай колекции и т.н. може да е само частично попълнено.
Така че Query предлага опция за промяна на това поведение чрез yield_per()
. Това извикване ще предизвика Query за получаване на редове в партиди, където му давате размера на партидата. Както се посочва в документите, това е подходящо само ако не извършвате никакво нетърпеливо зареждане на колекции, така че по същество това е, ако наистина знаете какво правите. Освен това, ако основният DBAPI предварително буферира редове, пак ще има тази памет, така че подходът се мащабира само малко по-добре, отколкото да не се използва.
Почти не използвам yield_per(); вместо това използвам по-добра версия на LIMIT подхода, който предлагате по-горе, използвайки функции на прозореца. LIMIT и OFFSET имат огромен проблем, че много големите стойности на OFFSET карат заявката да става все по-бавна и по-бавна, тъй като OFFSET от N я кара да преминава през N реда - това е като да правите една и съща заявка петдесет пъти вместо един, всеки път, когато четете все по-голям брой редове. С подхода на функцията на прозореца предварително извличам набор от стойности на "прозорец", които се отнасят до части от таблицата, която искам да избера. След това излъчвам отделни оператори SELECT, които всеки извлича от един от тези прозорци наведнъж.
Подходът на функцията на прозореца е в уикито и го използвам с голям успех.
Също така имайте предвид:не всички бази данни поддържат функции на прозорци; имате нужда от Postgresql, Oracle или SQL Server. IMHO използването поне на Postgresql определено си заслужава - ако използвате релационна база данни, можете също да използвате най-доброто.
