python in postgresql

???,
kaj bi pa naj bilo to, da bi bilo dostojno 21. stoletju?

Takole je, naprej preberem vse zapise, ki jih imam v tebali in v seznam shranim tiste, po katerih hočem iskati, torej navaden

SELECT row1, row2, row4 from tabel1;

Te zapise potem shranim v seznam.

v qniz, pa berem isklani niz, ki ga vnese uporabnik grafični vmensnik

qniz=main.uporLeIskanje.text()

potem za vsak pritisk tipke, se pokiče funkcija in primeraj, če je vneseni niz v bazi in če je, tiste zapise shranim v imenik.

for row in cursor:
for i in row:
if str(qniz).lower() in str(i).lower():
imenik.append((str((row[0])),row[1],row[2]))
break

ja, nekako, mislim, da je takšna rešitev najhitrejša, no mogoče se motim.

Ne nobenega trima nisem uporabil. Vendar ko sem delal debug, sem opazil,da pri podatku iz baze je v nizu \xoA, pri pytonu pa ne, čeprav je oboje presledek mi program pri primerjavi ne dela.

Saj če ne bo durge, bom tudi sikal s pomočjo baze.

Hvala zaenkrat

@WarpedOne:Čakam na tvoje predloge.

Moj predlog: Vrži stran nesmiselne predloge WarpedOne in vprašaj koga, ki dejansko zna programirat. To, kar ti počneš, je obsceno na vseh mogočih nivojih (in python tega ne spremeni, čeprav WarpedOne postane penast, ko vidi sodoben programski jezik).

fortran + ini, dat datoteke.

lopow, poglej zasebna sporočila.

lopow> Ker nimam toliko pojma o pragmiranju, sem se obrnil na vas. Sam sem predvidelva, da če iz baze najprej preberem vse npr. vse naslove in ID in jih shranim v python seznam, bo potem zadeva tekla hitreje, kot pa če grem za vsako črko izvajat sql stavek.

Zelo težko boš hitrejši od baze, ker imaš podatke v bazi in jih moraš v vsakem primeru prebrati.

Če bi rad izjemno hitro splošno iskanje, potem moraš tako in tako uporabiti Lucene ali podobno knjižnico, ampak IMO v tvojem primeru to nima smisla.

Uporabi poizvedbo na bazi in poskrbi, da imaš ustrezne indekse na stolpcih, po katerih poizveduješ.

SELECT a, b, c FROM tabela WHERE a ILIKE 'niz%' OR b ILIKE 'niz%' OR c ILIKE 'niz%'

Iluvatar> Za vsako vnos v iskalno polje sedaj opraviš poizvedbo na bazi? Zakaj se ti zdi to dobra ideja?

Ker so indeksi na bazi bistveno učinkovitejše reči kot loopanje po celotni tabeli skozi python loop, ki temu ni bil nikdar namenjen.

In na koncu ste prišli do istega mojega predloga:

Vrži stran posrednika (python sranje) in iskanje izvedi v bazi preko klasičnih SQL poizvedb.

Vmes pa še mal pumpanja lastnega ega, kako to ni ok in moderni jadajadajada.

Če prideš v situacijo ko SQL LIKE postane prepočasen, maš en širok spekter možnih ukrepov, ki stvar pospešijo. Kaj narest najprej je odvisno od konkretne vsebine in načina iskanja. Težko boš prišel v situacijo, ko bo preveč podatkov za hitro iskanje. Izvedba iskanja preko middlemana bo v taki situaciji zelo zelo hitro.

Bom probal, danes popoldan sprogramirat zadeva tako, da bo za vsak pritisk tipke, šel gledat v bazo in bom videl če se bo kaj poznalo na hitrosti.

http://seldo.com/weblog/2011/08/11/orm_...

p.s.: Četrt sekunde je pri UI ogromno.

technolog> p.s.: Četrt sekunde je pri UI ogromno.

Drži. Še vedno manj kot pol leta, pa enkrat bo treba naložit podatke v pomnilnik.

lopow> 2000 zapisov obrača zelo hitro.

To baza drži v pomnilniku skupaj z indeksi in se odzove v nekaj milisekundah.

A to si opisoval svoje jamranje nad dvema preizkušenima in povsod prisotnima tehnologijama?

Žalostno stanje stvari o teh zadevah pove vse kar je treba povedat - They tipicaly stink.

Za ilustracijo:

... sploh, ko imamo v službi programe, ki obračajo iste podatke, veliko počasneje.

Ogromno stvari je s temi "preizkušenimi in povsod prisotnimi tehnologijami" narejneo obupno zanič.

2000 zapisov prebrat in držat v middlelayeru še ni nek problem. 20k načeloma tut ne, 200k je že vprašanje, 2M pa ni več niti vprašanje ali je to še OK.
Sploh ker je ta middlelayer prepogosto narejen na osnovi slikarja šlemita.
Ko testiratš dela vse super duper, v produkciji čez kak mesec stvar začne postajat neodzivna itd.

Obstaja pa tudi koncept cachinga, kjer ti nek objekt iz baze pripelješ v cache in rečeš, da je cache veljaven za neko časovno obdobje.

Baza ima cache. Tipično boljšega kot katerikoli middleman.

Do koliko približno zapisov, bi pa bilo to smiselno, da bi delal seznam v pyhtonu. 10.000, 100.000.?

Funkcija počasnosti ostalih delov sistema zato enoznačnega odogovora ni.

Tehnologija nikoli ne preprečuje norosti, jih pa pogosto skriva pod havbo.

Par random zadev, niti ne nujno najhujših:

...This approach is certainly safe, but it has (for the new Python programmer), a startling implication: in any Python program, no matter how many threads and how many processors are present, only one thread is being executed at any time.

Nobenega indeksiranja navadnih seznamov, ki bi lahko pospešilo iskanje:

For (unsorted) lists in Python, the "in" operation requires O(n) time---not good when you have a large amount of data

Obstajajo hitrejše strukture, a niso brezplačne ergo vprašljiva uporabnost, ko imaš za hranit veliko vsebine:

Both dictionaries and sets use hashing and they use much more memory than only for object storage. According to A.M. Kuchling in Beautiful Code, the implementation tries to keep the hash 2/3 full, so you might waste quite some memory.

Glede Postgre pa nevem kaj mi očitaš? Je baza, use it!
Zamerim ji 'le' obupno štorasto nalaganje stored procedur in zapletanje s string delimiterji.

WarpedGone je 24. mar 2014 ob 16:17 izjavil:

Par random zadev, niti ne nujno najhujših:

...This approach is certainly safe, but it has (for the new Python programmer), a startling implication: in any Python program, no matter how many threads and how many processors are present, only one thread is being executed at any time.

Nobenega indeksiranja navadnih seznamov, ki bi lahko pospešilo iskanje:

For (unsorted) lists in Python, the "in" operation requires O(n) time---not good when you have a large amount of data

Obstajajo hitrejše strukture, a niso brezplačne ergo vprašljiva uporabnost, ko imaš za hranit veliko vsebine:

Both dictionaries and sets use hashing and they use much more memory than only for object storage. According to A.M. Kuchling in Beautiful Code, the implementation tries to keep the hash 2/3 full, so you might waste quite some memory.

Glede Postgre pa nevem kaj mi očitaš? Je baza, use it!
Zamerim ji 'le' obupno štorasto nalaganje stored procedur in zapletanje s string delimiterji.

Ena stvar, ki jo v tem trenutku ne rabi je paralelizem.

Kar se tiče seznamov, za njega ne bo problem. Zahtevnejši uporabniki lahko uporabijo Numpy.

Da ne bomo preveč blodil o Pythonovi porabi pomnilnika... Si že kdaj slišal za Javo?

Back on topic. Opju priporočam, da si pogleda SqlAlchemy in si pomaga z njim. S tem mu bo omogočeno, da ne dela vsega v aplikaciji in da se ne bo rabil prekomerno zajebavat z bazo.

No vidiš, sedaj se pa že začenjaš premikat v "NASA" vode.

Načeloma imaš dva pristopa. Prvi in verjetno zate boljši je, da vsakemu uporabniku narediš svojo bazo/shemo in vse ostalo ostane enako (razen koraka avtorizacije, ko uporabniške poverilnice povežeš s pravo podatkovno bazo).

Drugi pristop je, da imaš eno podatkovno bazo in potem vse preostale tabele prilagodiš tako, da bo vsak zapis vezan na lastno organizacijo ali uporabnika. Ta pristop uporabiš kadar imaš za to dobre razloge.

V resnici ti priporočam uporabo kakega frameworka npr: http://flask.pocoo.org/

p.s.: Komentar o Javi je letel na BighWhala, ki je nekaj blodil o porabi pomnilnika. Python je recimo počasen kot pes, vendar v splošnem ne žre nekih enormnih količin pomnilnika. Java je mnogo hitrejša od Pythona, vendar se mimogrede zgodi da ti požre ves pomnilnik kar ga najde.

ZaphodBB> p.s.: Komentar o Javi je letel na BighWhala, ki je nekaj blodil o porabi pomnilnika

WarpedOne. BigWhale te reči še kar razume.

ZaphodBB> Java je mnogo hitrejša od Pythona, vendar se mimogrede zgodi da ti požre ves pomnilnik kar ga najde.

To ni lastnost Jave same po sebi.

WarpedOne> java, python, isti moderen SPOS.

Da slišimo, kaj predlagaš kot alternativo govnu.

a tiste zadeve, kot ste pravili (da je poizvedba v bazo hitrejsa kot drzanje v memory) veljajo tudi, ce je baza na networku oz. če je baza access?

Iluvatar je 24. mar 2014 ob 12:11 izjavil:

Jaz ne razumem točno tele kode:

if str(qniz).lower() in str(i).lower():

Zakaj si tu uporabil in operator?

Sorry, pythona sicer ne poznam, nikoli še nisem nič naredil v pythonu, vseeno pa mislim, da želiš primerjati dva niza med sabo
Če imaš torej nize
Mama
Mama tepe
Mama tepe radiator
Išeč pa niz Mama
se ti zankaš skozi seznam teh nizov, in iščeš kateri če kateri element v tem seznau ustrezna nizu "Mama" (uporabljaš IN operator, delaš torej object comparison).
Seveda dobiš zadetek, ker prvi element ustreza iskanemu.

Če pa vpišeš Mama in presledek, torej nobeden element ne ustreza iskanemu.
Zdi se mi, da bi moral uporabiti neko drugo primerjavo, nekaj v smuslu

if str(i).lower.startswith(str(qniz).lower())

in operator pomoje tu primerja dva objekta med seboj, ne pa dve vredosti objektov...
Lahko da sem brcnil v temo, saj pravim,ne poznam pythona.

tudi če uporabnik startswith, je enako,ko pritisnem preslednico ni več nobenih zapisov, kot da preslednici iz baze in iz isklanega niza nebi bile enake.

technolog je 24. mar 2014 ob 13:34 izjavil:

http://seldo.com/weblog/2011/08/11/orm_...

p.s.: Četrt sekunde je pri UI ogromno.

Hvala bogu za anti-pattern. Dokler si hitrejši od naše sposobni branja sprememb si OK. Za četrt sekunde bo prej krivo vse ostalo kot pa ORM :)
Manjka samo še folk, ki bo rekel, da bi njemu vse hitreje delalo v assemblyerju.
Ampak dokler bo on končal zadevo bo stranka ne samo že brala podatke iz pythona...vmes bo verjetno že 3 verzije OSja zamenjala če ne celo službe, kjer potrebe po programu sploh ne bo več :)

Isotropic je 24. mar 2014 ob 17:04 izjavil:

a tiste zadeve, kot ste pravili (da je poizvedba v bazo hitrejsa kot drzanje v memory) veljajo tudi, ce je baza na networku oz. če je baza access?

Odvisno od števila podatkov in tvojega računalnika.
Evo en debilen primer za folk, ki je navajen naredil "SELECT * FROM blabla" in se potem s podatki igrat v memoryju.
Kaj bo naredil, ko bo teh podatkov za par GB.
Kaj bo naredil če pade prepustnost mreže.
V vsakem primeru se ti splača aplikacijo napisat tako, da poizvedbe dela baza. Maš n-bar, ki jih lahko uporabljaš lokalno. Celo flat file based. Če te srce ne boli preveč in te ni sram uporabit kakšen framework, ki omogoča uporabo različnih baz lahko, ko podatki presežejo sposobnosti uporabnikovega računalnika zadevo preprosto preseliš na nek namenski strežnik, kjer teče nek SQL strežnik(ne se kregat, ker je najboljši...).
Brezveze se je že v štartu streljat v koleno.
Pa tko kot je jype napisal...če program glih ne dela ne vem česa (super 3d efektov in nekih zajebanih api klicev na komponente, ki so na klientovem računalniku ali uporablja kakšne COM pizdarije tretje stranke) potem se splača resno razmislit o WEB aplikaciji.
Razen če ti je res v interesu izstavljat račun, ker moraš vsakič na 200 mašin štimat posodobitve(se opravičujem če glede na "kodo", ki sem jo prebral v temi napačno sklepam, da avtomatičnih posodobitev verjetno ni).

Glede aplikacije so zadeve določene. Določena je vsebina in funkcionalnost , na meni je samo izvedba.

Vem, da bi bila web app bolj široko uporabna, vendar pa zaenrakt je prioriteta ne web app.

Glede isklanega niza, ki je bilo moje vprašanje pri odprtju teme, sem se odločil, na podlagi vaših mnenj, ta bom vseeno raje šel vsak klic v bazo, kot pa da naložim prvo v python seznam in potem primerjam.
Vendar me sedaj ne dela tako kot bi hotel.
Query je takšen:
cursor.execute("""
SELECT
"eDimnikar".uporabnik.sifra_stara,
"eDimnikar".uporabnik.naziv_1,
"eDimnikar".uporabnik.naslov
FROM "eDimnikar".uporabnik
WHERE "eDimnikar".uporabnik.naslov LIKE '%%{}%%'
""").format(qniz)

ampak dobim error:
AttributeError: 'NoneType' object has no attribute 'format'

Vem,da imam nekje napako pri zapisu, ker če dam npr.

cursor.execute("""
SELECT
"eDimnikar".uporabnik.sifra_stara,
"eDimnikar".uporabnik.naziv_1,
"eDimnikar".uporabnik.naslov
FROM "eDimnikar".uporabnik
WHERE "eDimnikar".uporabnik.naslov LIKE '%CEL%'
""")

imenik = []
for item in cursor:
imenik.append(item)
print(imenik)

Dobim rezultate, če pa hočem prebrati niz iz tipkovnice pa mi napiše tisti error

ja, hvala. Sedaj razumem.
Ampak. Problem je enak kot na začetku. Ko pritisnem presledek več ne dobim novenih zadetkov, ko da bi line Edit od Qt imel drug znak za presledek kot v bazi.