Re: [python] MySQL - nativní rozhraní pro Python
Ked ste sa uz o tomto tak rozpisali, tak prihodim jednu otazku aj ja. Dost by ma zaujimalo ako sa s tymto daju robit zlozitejsie SQL dotazy, napr. nejake JOINy a podobne. Moc si to neviem predstavit. -Pôvodná správa- Od: Jan Bednařk [mailto:[EMAIL PROTECTED] Komu: Konference PyCZ python@py.cz Predmet: Re: [python] MySQL - nativní rozhraní pro Python 2008/6/29 zu1234 [EMAIL PROTECTED]: Doufám že to někdo nevezme jako provokaci, ale opravdu by mi občas bodlo dostat se prostě do obrazu. Takže, byl by někdo ochotný obeznámit nás začátečníky s pojmy jako je SQLAlchemy a Django. Ale prosím opět polopatě a prakticky a lidsky. ZU SQLAlchemy je aplikace, která ti umožní pracovat s tabulkami a záznamy v databázi jako s běžnými objekty. Je určena pro integraci do jiných aplikací, jako databázová vrstva. Nemusíš tak být odborník na SQL, aby jsi mohl jednoduše a pohodlně pracovat s databází, teoreticky ani nemusíš vědět, jak databáze fungují a co to SQL je. Koukni na http://www.sqlalchemy.org/docs/05/ormtutorial.html a pochopíš, oč jde. Django je RAD (Rapid Application Development) framework pro tvorbu internetových aplikací. Funguje na principu MTV = Model Template View. V první úrovni - Model - nadefinuješ modely. To jsou třídy reprezentující tabulky v databázi a jejich závislosti a pak s nimi pracuješ jako s objekty. Je to hodně podobné jako ta SQLAlchemy s hlavním rozdílem v tom, že nedefinuješ jen typické datové typy (varchar, int, atd.), ale můžeš použít i speciální jako EmailField, IPAddressField, apod., které jsou v databázi uloženy třeba jako obyčejný varchar, ale při práci mají speciální schopnosti, jako třeba že ten EmailField při přiřazení kontroluje, zda je hodnota platná e-mailová adresa. Teď trochu odbočím, ale musím prozradit jednu z bezkonkurenčních (pokud jsem dobře informován) výhod Djanga oproti jiným webovým frameworkům, a tou je automaticky generovaná administrace. Na základě zadefinovaných modelů generuje velmi propracované administrační rozhraní. Proto je tam taky spousta různých datových typů, které ve výsledku mají vliv jen na chování té administrace (různé formulářové prvky s JS/AJAX vylepšeními). A když jsou nadefinované modely, přide na řadu část View. To znamená nadefinovat šablony pro URL a k nim odpovídající view funkce, které se mají zavolat (dle potřeby s parametry získanými z URL). Tady je to hlavně o hraní s objekty modelů. Ve view získáš potřebná data, která se zpracují v poslední části - Template. Template jsou (X)HTML (nebo XML, nebo jakékoliv jiné) soubory, které obsahují speciální značky, které Django nahradí hodnotou z view. Pole hodnot vypíše cyklem. Aplikuje na hodnoty různé výstupní filtry třeba na pěkné zobrazení data či zaokrouhlení měny. A tak podobně. Je toho spousta, co by šlo o Djangu napsat, doporučuji ale rovnou zkusit. Je to zábava s ním pracovat. Ještě jsem si vzpoměl na jedno video z nějaké přednášky o Djangu, které stojí za to shlédnout http://video.google.com/videoplay?docid=-70449010942275062q=djangoei=7mhpSMG7Jpyc2wLx8dyoCg Honza ___ 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
Re: [python] MySQL - nativní rozhraní pro Python
Já myslím, že toto zase není třeba vysvětlovat. Zadej si do Google Django: 1. odkaz: http://www.djangoproject.com/ SQLAlchemy: 1. odkaz: http://www.sqlalchemy.org/ a myslím, že číst už umíš. Tomas On 29.6.2008 22:33, zu1234 wrote: Doufám že to někdo nevezme jako provokaci, ale opravdu by mi občas bodlo dostat se prostě do obrazu. Takže, byl by někdo ochotný obeznámit nás začátečníky s pojmy jako je SQLAlchemy a Django. Ale prosím opět polopatě a prakticky a lidsky. ZU Jan Bednařík napsal(a): 2008/6/29 Jirka Vejrazka [EMAIL PROTECTED]: Možná to k ničemu nebude, ale přihodím trošku do mlýna :-) Momentálně na jednom projektu ke zjednodušení práce s databází (konkrétně MySQL) používám Django. Je sice určené na vývoj webových aplikací, ale vrstva která se stará o databáze je pro mé účely vyhovující a zbytek frameworku prostě ignoruju. Třeba to pomůže... Jirka Na to bych použil spíš SQLAlchemy, ale i ořezané Django může být příjemné řešení. Honza ___ 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 ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
Tady je ukazka z dokumentace:
http://www.sqlalchemy.org/docs/05/documentation.html#datamapping_joins
Nebo muzes proste delat standardni SQL funkce bez tech vopicek.
Cili nejjednoduseji treba takhle:
from sqlalchemy import create_engine
dbe = create_engine('sqlite:///:memory:', echo=True)
db = dbe.connect()
vysledek = db.execute(LIBOVOLNY SQL DOTAZ).fetchone()
Opet vse viz dokumentace.
Tomas
On 1.7.2008 9:10, azurIt wrote:
Ked ste sa uz o tomto tak rozpisali, tak prihodim jednu otazku aj ja.
Dost by ma zaujimalo ako sa s tymto daju robit zlozitejsie SQL dotazy,
napr. nejake JOINy a podobne. Moc si to neviem predstavit.
-Pôvodná správa-
Od: Jan Bednařk [mailto:[EMAIL PROTECTED]
Komu: Konference PyCZ python@py.cz
Predmet: Re: [python] MySQL - nativní rozhraní pro Python
2008/6/29 zu1234 [EMAIL PROTECTED]:
Doufám že to někdo nevezme jako provokaci, ale opravdu
by mi občas bodlo dostat se prostě do obrazu.
Takže, byl by někdo ochotný obeznámit nás začátečníky s pojmy jako je
SQLAlchemy a Django. Ale prosím opět polopatě a prakticky a lidsky.
ZU
SQLAlchemy je aplikace, která ti umožní pracovat s tabulkami a záznamy
v databázi jako s běžnými objekty. Je určena pro integraci do jiných
aplikací, jako databázová vrstva. Nemusíš tak být odborník na SQL, aby
jsi mohl jednoduše a pohodlně pracovat s databází, teoreticky ani
nemusíš vědět, jak databáze fungují a co to SQL je. Koukni na
http://www.sqlalchemy.org/docs/05/ormtutorial.html a pochopíš, oč jde.
Django je RAD (Rapid Application Development) framework pro tvorbu
internetových aplikací. Funguje na principu MTV = Model Template View.
V první úrovni - Model - nadefinuješ modely. To jsou třídy
reprezentující tabulky v databázi a jejich závislosti a pak s nimi
pracuješ jako s objekty. Je to hodně podobné jako ta SQLAlchemy s
hlavním rozdílem v tom, že nedefinuješ jen typické datové typy
(varchar, int, atd.), ale můžeš použít i speciální jako EmailField,
IPAddressField, apod., které jsou v databázi uloženy třeba jako
obyčejný varchar, ale při práci mají speciální schopnosti, jako
třeba že ten EmailField při přiřazení kontroluje, zda je hodnota
platná e-mailová adresa. Teď trochu odbočím, ale musím prozradit jednu
z bezkonkurenčních (pokud jsem dobře informován) výhod Djanga oproti
jiným webovým frameworkům, a tou je automaticky generovaná
administrace. Na základě zadefinovaných modelů generuje velmi
propracované administrační rozhraní. Proto je tam taky spousta různých
datových typů, které ve výsledku mají vliv jen na chování té
administrace (různé formulářové prvky s JS/AJAX vylepšeními). A když
jsou nadefinované modely, přide na řadu část View. To znamená
nadefinovat šablony pro URL a k nim odpovídající view funkce, které se
mají zavolat (dle potřeby s parametry získanými z URL). Tady je to
hlavně o hraní s objekty modelů. Ve view získáš potřebná data, která
se zpracují v poslední části - Template. Template jsou (X)HTML (nebo
XML, nebo jakékoliv jiné) soubory, které obsahují speciální značky,
které Django nahradí hodnotou z view. Pole hodnot vypíše cyklem.
Aplikuje na hodnoty různé výstupní filtry třeba na pěkné zobrazení
data či zaokrouhlení měny. A tak podobně. Je toho spousta, co by šlo o
Djangu napsat, doporučuji ale rovnou zkusit. Je to zábava s ním
pracovat.
Ještě jsem si vzpoměl na jedno video z nějaké přednášky o Djangu,
které stojí za to shlédnout
http://video.google.com/videoplay?docid=-70449010942275062q=djangoei=7mhpSMG7Jpyc2wLx8dyoCg
Honza
___
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
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
Re: [python] Guido o funkcich reduce(), filter() a map() v Python 3000
Opravdu dlouho jsem odolaval, abych do teto diskuze nezasahl, ale nyni se opravdu uz neudrzim. Chca nechca musim dat za pravdu supermanovi. Nevim kolik lidi z tech co tu tak jasaj nad Pythonem 3000 psali nebo ridili nejakej vetsi projekt. Ja par takovych projektu tvoril nebo ridil. Bavime se o statisicich radku kodu. Kodu ktery pilujeme uz nekolik let. V jadru se zmeny delaji jen minimalne a spis se rozsiruje funkcnost, presne jak psal superman. Opravdu si nedokazu predstavit, ze by se mi pod rukama zmenila syntax jazyka a ja musel se svym tymem prochazet stovky zdrojaku a opravovat je. Co na tom, ze mi nejakej tool praci ulehci a nejaky zakladni konstrukce prevede. Porad jich zbyde dost, s kterymi si neporadi. Nechci znova prochazet veskery jiz odladeny kod a ladit ho znovu. Co je na tom tak tezce pochopitelnyho? Nejake zmeny v jazyce muzou byt urcite bezva. Ovsem poruseni zpetne kompatibility v takovem meritku je proste neakceptovatelne. lachtan superman napsal(a): Stále mě nabádáte, abych si našel nějaká fakta. Taky byste to měl někdy zkusit. Ale souhlasím s tím, že by Python mohl běžet ještě rychleji, což dokazuje třeba Psyco. Já to zkusil, právě proto píšu to co píšu. Navíc pomalost Pythonu je logická už z principu jazyka a z principu runtime. Nicméně pomalost neznamená vadu, je to daň za jiné pěkné vlastnosti, za které se platí rychlostí. A pak také daň za neustálé překopávání jazyka - to je další negativní důsledek Rossumových akcí - kdyby Python byl stálý, věřím, že by někomu stálo za to vyvinout dobrý runtime pro Python spolu s dynamickou optimalizací (které v Pythonu není) a možná i JITem (která je nesplnitelným snem). Taková Java například to z velké pomalosti dotáhla na to, že v rychlosti čistého kódu se blíží rychlosti jazyka C. Je to důsledek vývoje runtimu, který trval mnoho let. Ale Python prostě musí mít špatný a pomalý runtime, protože při neustálém překopávání jazyka nelze naprogramovat nic složitějšího, než v podstatě primitivní runtime prakticky bez optimalizací. Lidé pořád zapomínají, že změna v jazyce znamená změny v obrovském množství kódu a nástrojů. U hotové aplikace není důvod ani potřeba nic přepisovat. Nevím, jakou máte představu o tom, jak přejít na Python 3000, ale nikdo netvrdí, že musíte ze dne na den přejít z Pythonu 2.5 na Python 3000 (klidně můžete zůstat na Pythonu 2.5 až do smrti, přítomnost Pythonu 3000 ho nezruší). U většiny aplikací, u kterých probíhá vývoj, při plynulém přechodu na Python 2.6 a pak na Python 3000 s využitím připravených nástrojů, žádné extra náklady navíc nevzniknou. Jednou Vás to donutí přejít - pokud jste trochu zběhlý v praxi, tak se prostě nedá časem nepřejít. Jednoho dne se objeví něco - nepodpora něčeho v okolí programu, která je jenom v nové verzi a přejít prostě musíte chca nechca. Proč nutně musí u aplikací probíhat vývoj? A to s těmi žádnými extra náklady je dobrá věta - na prvního Apríla. Ono totiž i když probéhá vývoj, tak v aplikaci jsou obrovské části kódu, na které se nesahá. To může být klidně i 90% kódu, které zůstávají beze změny. Mění se jen část projektu. Ty nezměněné části jsou odladěné, a je na ně spolehnutí. Ovšem při změně syntaxe jazyka musíte sáhnout na vše - na 100% kódu. Minimálně je otestovat - a jestli to neznamená dodatečné náklady navíc, pak jsem čínský papež. Takže je těch vlivů tolik, že stejně nelze určit, proč je Python někdy populární více a jindy méně. S tím nesouhlasím. Je rozdíl mezi tvrzením je tam hodně vlivů a tvrzení nelze určit, které vlivy to jsou. Vy jste dost nekorektně bez důkazu tato dvě tvrzení zaměnil. I v případě Hitlera byla drtivá většina lidí, kterých se jeho činy dotýkaly, proti. V demokratické společnosti platí názor většiny, a pokud je většina pro změny, nic s tím nezmůžete. Je to blbej systém, ale ty ostatní jsou jenom horší. Ano? Zkuste si vzít obrovský prostor zvaný Německo a zkuste si zjistit jak moc lidí bylo proti. Demokracii sem netahejte - navíc znovu - dokažte tvrzení že všechny ostatní systémy jsou horší, než demokracie - měl byste logický problém. Miloslav Ponkrác ___ 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
Re: [python] MySQL - nativní rozhraní pro Python
Vzpomínám si, jak jsme měřili síly já (SQL) a kolega (Django db vrstva) na jenom praktickém příkladě - měli jsme jako vstup cca 10 vzájemně provázaných tabulek (násobné M:N) a cílem bylo získat dataset pro vyrenderování webové stránky. 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. Nakonec jsme společnými silami i to Django dotlačili do podobné výkonnosti jako čisté SQL, ale znamenalo to nejen podrobně znát, jak relační stroje fungují, ale i pro mě dost speciální formát dotazování se objektovým způsobem. Django way jsme nakonec ponechali kvůli kompatibilitě s datovým modelem (v případě rozšíření datového modelu by se musely SQL příkazy přepsat), ale důrazně varuji před přístupem nemusím znát relační databáze, stačí mi objektový wrapper. Marek 2008/7/1 Jan Bednařík [EMAIL PROTECTED]: aplikací, jako databázová vrstva. Nemusíš tak být odborník na SQL, aby jsi mohl jednoduše a pohodlně pracovat s databází, teoreticky ani nemusíš vědět, jak databáze fungují a co to SQL je. ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
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
Re: [python] MySQL - nativní rozhraní pro Python
Dost by ma zaujimalo ako sa s tymto daju robit zlozitejsie SQL dotazy, napr. nejake JOINy a podobne. Moc si to neviem predstavit. Uz to tady padlo, ale hodim link na tu konkretni stranku s dokumentaci: http://www.djangoproject.com/documentation/db-api/ Jirka ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
Pane Bednařík - super odpověď!!! Moc Vám děkuji. ZU Jan Bednařík napsal(a): 2008/6/29 zu1234 [EMAIL PROTECTED]: Doufám že to někdo nevezme jako provokaci, ale opravdu by mi občas bodlo dostat se prostě do obrazu. Takže, byl by někdo ochotný obeznámit nás začátečníky s pojmy jako je SQLAlchemy a Django. Ale prosím opět polopatě a prakticky a lidsky. ZU SQLAlchemy je aplikace, která ti umožní pracovat s tabulkami a záznamy v databázi jako s běžnými objekty. Je určena pro integraci do jiných aplikací, jako databázová vrstva. Nemusíš tak být odborník na SQL, aby jsi mohl jednoduše a pohodlně pracovat s databází, teoreticky ani nemusíš vědět, jak databáze fungují a co to SQL je. Koukni na http://www.sqlalchemy.org/docs/05/ormtutorial.html a pochopíš, oč jde. Django je RAD (Rapid Application Development) framework pro tvorbu internetových aplikací. Funguje na principu MTV = Model Template View. V první úrovni - Model - nadefinuješ modely. To jsou třídy reprezentující tabulky v databázi a jejich závislosti a pak s nimi pracuješ jako s objekty. Je to hodně podobné jako ta SQLAlchemy s hlavním rozdílem v tom, že nedefinuješ jen typické datové typy (varchar, int, atd.), ale můžeš použít i speciální jako EmailField, IPAddressField, apod., které jsou v databázi uloženy třeba jako obyčejný varchar, ale při práci mají speciální schopnosti, jako třeba že ten EmailField při přiřazení kontroluje, zda je hodnota platná e-mailová adresa. Teď trochu odbočím, ale musím prozradit jednu z bezkonkurenčních (pokud jsem dobře informován) výhod Djanga oproti jiným webovým frameworkům, a tou je automaticky generovaná administrace. Na základě zadefinovaných modelů generuje velmi propracované administrační rozhraní. Proto je tam taky spousta různých datových typů, které ve výsledku mají vliv jen na chování té administrace (různé formulářové prvky s JS/AJAX vylepšeními). A když jsou nadefinované modely, přide na řadu část View. To znamená nadefinovat šablony pro URL a k nim odpovídající view funkce, které se mají zavolat (dle potřeby s parametry získanými z URL). Tady je to hlavně o hraní s objekty modelů. Ve view získáš potřebná data, která se zpracují v poslední části - Template. Template jsou (X)HTML (nebo XML, nebo jakékoliv jiné) soubory, které obsahují speciální značky, které Django nahradí hodnotou z view. Pole hodnot vypíše cyklem. Aplikuje na hodnoty různé výstupní filtry třeba na pěkné zobrazení data či zaokrouhlení měny. A tak podobně. Je toho spousta, co by šlo o Djangu napsat, doporučuji ale rovnou zkusit. Je to zábava s ním pracovat. Ještě jsem si vzpoměl na jedno video z nějaké přednášky o Djangu, které stojí za to shlédnout http://video.google.com/videoplay?docid=-70449010942275062q=djangoei=7mhpSMG7Jpyc2wLx8dyoCg Honza ___ 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
Re: [python] MySQL - nativní rozhraní pro Python
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
Re: [python] MySQL - nativní rozhraní pro Python
Souhlea, myslim ze nikdo neceka ze jakykoli framework bude stejne rychly a efektivni jako dobre napsane SQL. Na druhou stranu ocekavam, ze standardni webova aplikace (a toto byla standardni webova aplikace, zadny DWH) bude mit standardni dobu odezvy. Ja nehazim spinu na Django, sam ho a jeho databazovou vrstvu pouzivam. Jen pripominam, ze i v dobe high level jazyků a nástrojů je potřeba znát background a principy. Ani dnes bez toho nejde napsat kloudná webová aplikace. Marek ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
Ja nehazim spinu na Django, sam ho a jeho databazovou vrstvu pouzivam. Jen pripominam, ze i v dobe high level jazyků a nástrojů je potřeba znát background a principy. Ani dnes bez toho nejde napsat kloudná webová aplikace. Kde to muzu podepsat? ;-) Jirka ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
