On je základní problém, že databáze jsou relační, zatímco neustále se různé frameworky snaží z toho udělat objektový přístup. A rozdíl mezi těmito dvěma pojetí je tak značný, že objektový přístup nemůže být efektivní.
Ale zase - každý luxus něco stojí a je třeba vědět, zda se vyplatí, nebo ne. U objektového přístupu k relačním databázím je ten luxus (ztráta rychlosti) velmi značný, a v zásadě se vyplatí jen tehdy, pokud a) máte dostatečnou rezervu ve výkonu databáze, b) honíte tam přímo data z jednotlivých tabulek, v krajním případě dvou přes cizí klíč. Když to tak sleduji (o SQLAlchemy ani Django jsem nevěděl, ale studoval jsem), tak se téměř nikomu tento převod, kdy se na relační databázi dávám nějakým objektovým pohledem přes univerzální framework moc nepovedl. Přiznám se sám, že asi to chce ten OOP interface vymyslet jinak - to je můj vnitřní silný pocit. Na druhé straně musím uznat, že pro jednoduché sáhnutí do tabulky je to velmi luxusní a dostačující. On totiž SQL jazyk je dost schopný a různorodý a jdou tím až neuvěřitelné zázraky. A nedokážu si dost dobře představit, že bych přes framework hodil třeba to, co jsem teď stvořil (předem upozorňuji, že pro databázi jde o velmi efektivní dotaz, který zpracuje v zanedbatelném čase): SELECT plant_id,name,(SELECT name FROM plant_name AS n WHERE n.plant_id=boss.plant_id AND language='lt' ORDER BY priority,type LIMIT 1) AS lt_name,(SELECT GROUP_CONCAT(o.cs_name ORDER BY o.astrological_object_id SEPARATOR ',') FROM plant_astrological_object AS o WHERE o.astrological_object_id IN (SELECT astrological_object_id FROM plant_mn_object_plant AS rel WHERE rel.plant_id=boss.plant_id)) AS objects FROM plant_name AS boss WHERE fulltext_name LIKE '%' AND language IN ('cs') ORDER BY name COLLATE utf8_czech_ci Přitom jde o velmi jednoduchý SQL dotaz, a asi bych si nedokázal představit jak bych to nacpal přes framework. Obrovská výhoda frameworků ale je - a to je jejich neskutečně silná stránka, která se nedá pominout - že jsou nezávislé na konkrétním databázovém stroji. Prostě znelíbí se vám databáze XY, tak jí prostě vyměníte za jinou, a z hlediska aplikace se nic nemění. Všechny závislosti na konkrétní databázi vyřídí framework sám - a kvůli tomu se také velmi tyto abstrakční vrstvy používají. To je velmi častý důvod jejich nasazení. Platí se za to ovšem ztrátou výkonu a někdy dost značnou neefektivností ve složitějších datových případech. Miloslav Ponkrác Jirka Vejrazka napsal(a): >> Kolega, nadšen "jednoduchostí" objektoveho pristupu k databazi a bez >> hlubsich znalosti SQL udelal dotaz, ktery nad realnymi daty trval cca 16-20 >> sekund. Ja za pomoci SQL udelal dotaz, ktery generoval dataset cca 200-300 >> milisekund. >> > > Souhlea, myslim ze nikdo neceka ze jakykoli framework bude stejne > rychly a efektivni jako dobre napsane SQL. Zvlast pokud je to SQL > (ne)zdrave vylepsene desitkami az stovkami hintu :) > > Pokud potrebuju pracovat s velkym mnozstvim dat (warehouse) a nebo > potrebuju vyzdimat posledni kousek rychlosti z databaze (OTLP), pak se > _dobre_ naucim SQL (a PL/SQL nebo T-SQL) a optimalizaci. Kdyz budu > potrebovat udelat webovou aplikaci ktera pouziva databazi jako "neco > kam hodim data a pak je tam relativne rychle najdu" a ma tam svych 25 > tabulek z nichz kazda ma max 8 sloupcu (a jsou celkem malo provazane), > klidne sahnu po SQLAlchemy / Django / Pylons / TurboGears / .../ RoR > (at nemluvime jenom o Pythonu ;-) > > Jirka > _______________________________________________ > Python mailing list > Python@py.cz > http://www.py.cz/mailman/listinfo/python > > > _______________________________________________ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python