DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 16. 02. 2006.   #11
zextra
Boris
Grand Master
 
Avatar zextra
 
Datum učlanjenja: 01.12.2005
Lokacija: Novi Sad
Poruke: 775
Hvala: 5
156 "Hvala" u 2 poruka
zextra is on a distinguished roadzextra is on a distinguished road
Default

Koja je uopste poenta te tvoje price? Uzmi MySQL, osakati ga malo, nemoj da koristis stvari koje po tebi usporavaju rad, i problem resen. Tacno da sve te stvari usporavaju rad same baze (sta mislis zasto je MyISAM najbrzi za proste SELECT upite? E, a kada dodje do relacionih zadataka, tu su negde i MySQL i svi ostali RDBMS-i)

Ako smatras da su connectionless i flatfile baze bolje, probaj nesto kao SQLite (koji, uzgred budi receno, radi i na perlu i na php-u)...

Na osnovu cega konstatujes da je Perl ili PHP suvise spor? Nije problem u kolicini podataka - problem je u nacinu na koji pristupas podacima, a to nije razlog da jezik osudis kao spor.

Moram da navedem ilustrativan primer - ako hoces da preneses recimo stolicu iz jednog stana u drugi, nije logicno unajmljivati sleper za slican posao, osim ako ne mislis da ce se u medjuvremenu javiti potreba da prevezes 100 stolica, za sta ti ne bi bio dovoljan automobil, kojim bi mogao ceo posao da zavrsis da je jedna stolica u pitanju... Ti sad upravo govoris da ne treba da koristimo slepere za male stvari - zasto, ako ti sleperi ne kostaju vise od automobila? Naravno, ako hoces nesto srednje-veliko ili srednje-malo da jako brzo prevezes na odrediste, sleper otpada...
__________________
"It’s important to have goals when you pet. Otherwise you’re just rubbing another mammal for no reason." - Scott Adams

Poslednja izmena od zextra : 16. 02. 2006. u 18:47.
zextra je offline   Odgovorite uz citat
Staro 16. 02. 2006.   #12
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

Najgore je što je, koliko razumem, ovde u pitanju izbor između toga da koristiš postojeći šleper ili da praviš auto.
jablan je offline   Odgovorite uz citat
Staro 16. 02. 2006.   #13
bojan_bozovic
expert
Master
 
Avatar bojan_bozovic
 
Datum učlanjenja: 20.12.2005
Poruke: 730
Hvala: 0
0 "Hvala" u 0 poruka
bojan_bozovic is on a distinguished road
Default

@zextra

Ja sam siguran da Perl ima implementiranu (bas kao i PHP) f-ju za quicksort - ali ti to sa milion recorda nece mnogo pomoci. Prakticno, da bazu implementiras u Perlu, jel' to mislis? SQLLite je (sad sam cuo za njega) upravo ono o cemu sam i mislio.

@jablan

To si mislio na Ferrari? Mozda je dobro da se isti strorage engine koristi i za desktop aplikaciju?

Poslednja izmena od bojan_bozovic : 16. 02. 2006. u 18:51.
bojan_bozovic je offline   Odgovorite uz citat
Staro 16. 02. 2006.   #14
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

Citat:
Originalno napisao bojan_bozovic
To si mislio na Ferrari? Mozda je dobro da se isti strorage engine koristi i za desktop aplikaciju?
Ne znam da li te dobro razumem - MS sa svojom paletom servera ide upravo u tom pravcu: isti se endžin koristi i za heavy-duty veb servere i desktop aplikacije (MSDE).

Ako sam te dobro razumeo - ti predlažeš bazu koja bi čuvala podatke u memoriji. Ne znam zašto brineš o tome - OS i DBMS se staraju o tome da neke delove baze keširaju u memoriji kako bi se upiti brže izvršavali.

A ako ti uopšte nije potrebno da se nešto čuva na disku, što uopšte potežeš DBMS?

Poslednja izmena od jablan : 16. 02. 2006. u 19:00.
jablan je offline   Odgovorite uz citat
Staro 16. 02. 2006.   #15
zextra
Boris
Grand Master
 
Avatar zextra
 
Datum učlanjenja: 01.12.2005
Lokacija: Novi Sad
Poruke: 775
Hvala: 5
156 "Hvala" u 2 poruka
zextra is on a distinguished roadzextra is on a distinguished road
Default

Ne, ja nisam mislio na sortiranje milion zapisa, vec na tvoju konstataciju da su perl i php spori jezici.
__________________
"It’s important to have goals when you pet. Otherwise you’re just rubbing another mammal for no reason." - Scott Adams
zextra je offline   Odgovorite uz citat
Staro 16. 02. 2006.   #16
bojan_bozovic
expert
Master
 
Avatar bojan_bozovic
 
Datum učlanjenja: 20.12.2005
Poruke: 730
Hvala: 0
0 "Hvala" u 0 poruka
bojan_bozovic is on a distinguished road
Default

@jablan

Citat:
A ako ti uopšte nije potrebno da se nešto čuva na disku, što uopšte potežeš DBMS?
To za MSDE ce da radi sa wordpadom. A sto se ovoga tice, mozda mi treba biblioteka kojom cu sam da odlucujem kad je nesto u memoriji a nije? (ako mi sad ne treba mozda mi zatreba, a ima kome treba). DBMS potezem zbog b-tree i binarne pretrage.

@zextra
To je relativno. Za regex Perl ce najverovatnije da bude brzi od svega ostalog. Zavisi od konkretnog problema sta koristis kao optimalno.

Evo sta hocu reci - nema biblioteke koja je i za deo RDBMS i standalone lib za implementaciju trazenja i menjanja podataka na niskom nivou za desktop. Transakcije ti ne trebaju na desktopu npr. a SQLLite ih podrzava - opet idu na nivo podrske za SQL koji je potreban knjigovodstvu u Deutsche Bank, mada cu da pogledam tu biblioteku.
bojan_bozovic je offline   Odgovorite uz citat
Staro 16. 02. 2006.   #17
zextra
Boris
Grand Master
 
Avatar zextra
 
Datum učlanjenja: 01.12.2005
Lokacija: Novi Sad
Poruke: 775
Hvala: 5
156 "Hvala" u 2 poruka
zextra is on a distinguished roadzextra is on a distinguished road
Default

Starije verzije nisu imale transakcije kad sam ja gledao koristio (sto znaci da nisam gledao vec neko vreme).
__________________
"It’s important to have goals when you pet. Otherwise you’re just rubbing another mammal for no reason." - Scott Adams
zextra je offline   Odgovorite uz citat
Staro 17. 02. 2006.   #18
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

pa to o cemu ti pricas vec postoji, ima veoma brzo pretrazivanje po jednom kljucu, odlicno odradjeno keshiranje, a i programirano je na izuzetno niskom nivou i veoma efikasno... zove se fajl sistem
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 12. 03. 2006.   #19
DejanVesic
old school
Professional
 
Avatar DejanVesic
 
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
DejanVesic će postati "faca" uskoro
Default Re: RDBMS vs. FlatFile

Htedoh da sve spojim u jedan post, ali ne vredi, idemo redom:

Citat:
Originalno napisao bojan_bozovic
Palo mi je u oci da zbog DELETE upita mozete imati primarne kljuceve koji nisu po redu, tj da RDBMS ne moze da vrsi binarnu pretragu po primarnim kljucevima = mora da prolazi kroz sve recorde - imate ih milion - milion. Idealno je da se izsortira pa vrsi binarna pretraga, ali to ne moze ako svi kljucevi nisu prisutni, tj imate bar jedan koji fali+dobro je da su po redu ako ih mnogo ima.
Apsolutno netačno. Kod svakog RDBMS postoji indeks nad primarnim ključem, koji je u formatu B stabla najčešće i koji se ažurira kako se menjaju slogovi. Ono što je bitno je da kada se koristi indeks ovog tipa, za operaciju pretraživanja (nalaženja sloga) za dalju operaciju nikada ne treba više od log(N) u vremenu - što jako sporo raste u odnosu na broj slogova u tabeli.

Citat:
Originalno napisao bojan_bozovic
Flatfile db koji je dobro dizajniran uz binarnu pretragu ima da bije SQL kad je pretraga po primarnim indeksima po sredi - a za sve ostalo ne moze biti sporija jer takodje mozemo da napravimo virtuelnu tabelu, izsortiramo po koloni i vrsimo binarnu pretragu. Naravno da za komplikovaniji upit (dovoljno je WHERE NAME="Pera") mora da se prolazi kroz celu bazu. Zeleo bih malo da prodiskutujem o ovome, mada ne spada u SQL vec dizajn samog RDBMS. Naravno, ovde mislim na flatfile db koji nije na Perlu ili sl. jezicima vec npr. C/C++
Edit: prakticno pri trazenju po primarnom kljucu ne moze da otpadne sortiranje, sto je problem za veliku bazu. Mnogo bi bilo bolje da nema uopste DELETE upita i da su indeksi po redu.
FlatfileDB? Koji je dobro dizajniran uz binarnu pretragu? Pa ti implicitno radiš isto što i RDBMS - imaš podatke (FlatFile) i indeks (sortiran binarno) i koristiš indeks da nađeš slog; samo što je daleko lakše dodati novi slog na kraj tabele i njegov ključ u b-stablo indeks nego dodati novi slog u FlatFileDB, jer ovaj FlatFile u najgorem slučaju moraš da sortiraš ceo.
__________________
http://www.vesic.org | Blog: http://www.vesic.org/blog/ | Fina kolekcija programa: http://www.vesic.org/programi/
DejanVesic je offline   Odgovorite uz citat
Staro 12. 03. 2006.   #20
DejanVesic
old school
Professional
 
Avatar DejanVesic
 
Datum učlanjenja: 15.06.2005
Lokacija: Novi Beograd
Poruke: 448
Hvala: 21
70 "Hvala" u 46 poruka
DejanVesic će postati "faca" uskoro
Default

Citat:
Originalno napisao bojan_bozovic
jel' ti je velicina baze manja od velicine memorije? Ako jeste, sve u memorju pa menjaj i trazi podatke. To RDBMS ne moze. (MySQL moze sa HEAP tabelama, ali da li je onda to brze od direktnog pristupanja podacima, bez overheada za konekciju sa bazom?) Transaction safe baza mora da loguje sve na disk da ako negde pukne, podaci ne budu ugrozeni. Tu je pisanje na disk vrlo sporo. Prakticno, dobro napravljena (tu je teorija nuzna!) flatfile baza moze da bije SQL zato sto ti ne treba logovanje na disk, uspostavljanje konekcije sa serverom i sl., pod uslovom da ne moras da otvaras bazu svakicas (CGI)
Ovo mi je palo na pamet zato sto RDBMS podrzava mnogo toga sto nije potrebno na Webu (transakcije npr. snapshote, strane kljuceve i sl.) ako se to izbaci iz izoptimizuje mislim da bi to moglo biti nesto brze od MySQL, a svakako, uz manji load na serveru.
Očigledno mešaš babe i žabe: ako ti treba sigurna baza, koja prilikom pucanja (recimo tvoje aplikacije za prodaju na webu) ostavi sistem u konzistentnom stanju (pare si ili skinuo sa kartice i prodao proizvod, ili nisi i nisi umanjio stanje na lageru) ILI može da ga vrati u konzistentno stanje (kroz logove) onda koristiš RDBMS.

Ako ti to ne treba, nego ti treba lookup file, spremiš lepo file, sortiraš i eto tebi sve lepo taman za učitavanje u memoriju.
__________________
http://www.vesic.org | Blog: http://www.vesic.org/blog/ | Fina kolekcija programa: http://www.vesic.org/programi/
DejanVesic je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Najbolji, nema sta oksite Opušteno 0 27. 11. 2009. 01:23
google me je IZBACIO iz pretrage?! dootzky Opušteno 10 07. 06. 2007. 00:17
Realizacija pretrage Ilija Studen Planiranje i usability 7 13. 06. 2006. 13:47
Januarske pretrage Srpko Marketing i SEO 3 01. 02. 2006. 14:27
Razliciti rezultati za pretrage u mnozini cvele Marketing i SEO 0 18. 10. 2005. 03:17


Vreme je GMT +2. Trenutno vreme je 16:54.


Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.