[python] MySQL - nativní rozhraní pro Python

[superman]

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 na py.cz
> http://www.py.cz/mailman/listinfo/python
>
>
>