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 02. 02. 2006.   #51
degojs
I'm a PC too.
Wrote a book
 
Avatar degojs
 
Datum učlanjenja: 06.06.2005
Lokacija: Kanada
Poruke: 1.354
Hvala: 82
130 "Hvala" u 89 poruka
degojs će postati "faca" uskorodegojs će postati "faca" uskoro
Default

Citat:
Hteo sam da upitam šta ti dobijaš time što definišeš posebno relacije da bi generisao view-ove na koje potrošiš više vremena, pa onda ih koristiš tako "definisane" u odnosu na jednostavno izvršenje querija. Ne vidim nikakvu uštedu.
Kako to definisem posebno relacije da bi generisao view-e?
__________________
Commercial-Free !!!
degojs je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #52
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

Do GPL 3. A onda cemo morati sami da pisemo kod.
bojan_bozovic je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #53
bluesman
Goran Pilipović
Sir Write-a-Lot
 
Avatar bluesman
 
Datum učlanjenja: 18.05.2005
Lokacija: Beograd
Poruke: 5.450
Hvala: 288
1.247 "Hvala" u 446 poruka
bluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušati
Pošaljite ICQ poruku za bluesman
Default

degojs: Ti si nekako uspeo da se ubaciš na pola priče, nisam siguran da znaš i history, stvar je u tome da su neki tvrdili kako ima je lakše da postupe otprilike ovako:

Naprave XML (ili neku alternativu) sa strukturom baze
Provuku taj XML kroz neku klasu koja im izgeneriše druge klase
Onda imaju sistem koji im omogućuje da ne pišu te osnovne querije
Zatim, za bilo šta ozbiljnije, imaju poseban sistem u kojem opet moraju da navedu tačne relacije u bazi, ključeve, posebne "view"-ove (ne ono na šta ti misliš), pa onda to tako opet provlače kroz neke scriptove koji ime opet generišu neke kodove koji im omogućavaju da se "ne zezaju sa mysql".

Po meni, svako radi kako mu odgovara, priča je o tome da to olakšava život. Ja tvrdim da je utrošeno vreme i energiju moglo efikasnije da se iskoristi, cela priča je samo o tome.

Znači ne pričamo o mogućnostima mysql, evo, prvi post je krenuo ovako:
Citat:
Jako se mnogo prica o portabilnosti koda sa jedne baze na drugu, ali nisam siguran koliko to prakticno ima znacaja? Da li vam se ikada desilo da ste naknadno morali da portujete neki web projekat sa jedne baze na drugu?
a pitanje koje je lajtmotiv je: Koje je vase misljenje o tome da li se isplati koristiti abstraction layere uopste?

uz direktno pitanje: "Kakva su vasa iskustva?"

Ne bih sada da ponavljam, ionako sam već nekoliko puta u ovoj temi, svoja iskustva po tom pitanju, kao i svoje stavove, samo podsećam na glavni tok.
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman
I don't always know what I'm talking about but I know I'm right!
bluesman je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #54
degojs
I'm a PC too.
Wrote a book
 
Avatar degojs
 
Datum učlanjenja: 06.06.2005
Lokacija: Kanada
Poruke: 1.354
Hvala: 82
130 "Hvala" u 89 poruka
degojs će postati "faca" uskorodegojs će postati "faca" uskoro
Default

Pa ja sam iz tog razloga i napisao u svojoj, cini mi se drugoj, poruci o cemu ne pricam (ORM i sta-ti-ja-znam-sta).

Dalje, ovo sto mi koristimo (MyGeneration (koji podrzava cini mi se i PHP) i jos jedan alatcic "in-house-made") omogucuje mnogo vise (i sutra ako bi trebali da promenimo bazu, a necemo, ne bi imali nikakvih problema - svoj kod ne bi morali da menjamo, znaci imamo apstrakciju!), ali niti nas je briga za to, niti nam pada na pamet..(jeste, nesto se suska da bi mogli da menjamo jednu bazu, ali o tom kad bude..)


E sad, sto ovaj tu jedan voli da mnogo prica o stvarima o kojima je verovatno samo citao.. kao da mi nismo culi za ORM, kao da i mi ne bi mogli da trubimo do zore.. Ali ja sam, kako rekoh, lepo napisao da o tome ne pricam.

A evo sta kazu na sql2Java stranici, komentarisu verovatno najpoznatiji i najpopularniji ORM alat na Javi - Hibernate:

Citat:
The point is that this kind of software is great, often technologically speaking they are damn great, but their learning curve are damn steep, and when an exception arise, you are damn lost ...
Meni se manji i laksi alati mnogo vise svidjaju, a za alatima kao sto je Hibernate jos nisam imao potrebe, jer jos nisam radio aplikaciju gde se krece sa druge strane (od objekata, a ne od baze).
__________________
Commercial-Free !!!

Poslednja izmena od degojs : 03. 02. 2006. u 05:28.
degojs je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #55
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

Off Topic: degojs, dolaziš iz potpuno drugog "sveta".

Začudio bi se koliko PHP programera ne zna šta su ovakve biblioteke, da postoje, kako rade, da su odlično testirane i stabilne, koliko vremena štede itd itd. Samo uzmi činjenicu da većina još nije prešla ni na PHP5 gde se tek može pričati o pravom OOP. Svest većine PHP programera o patternima, naprednim OO konceptima itd je uglavnom jako ograničena... Ono što je u Javi potpuno normalno u PHPu je uglavnom novotarija i "preseravanje".

No, to je sad već potpuno drugačija priča.


Proces o kome blues priča je nasleđen od Java ekipe pošto je prvi Propel bio čist port (čovek nije želeo da izmišlja toplu vodu). Odluku da se koristi XML kao jezik za opisivanje u neku ruku i odobravam, ali potreba da se korist build alat (PHP port Anta) je skroz debilna po meni. Možda je u Javi normalno koristi build alate, ali u PHPu definitivno nije...

To na stranu, način na koji ga je blues opisao zvuči kao da je to pola sata posla, što je daleko od istine. Sam proces se može podešavati tako da se izmene rade brže nego što neko može da otkuca jedan malo složeniji upit...

Poslednja izmena od Ilija Studen : 03. 02. 2006. u 06:42.
Ilija Studen je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #56
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

Citat:
Originalno napisao Ilija Studen
Samo želim da istaknem da se programiranje razvija u tom smeru da skraćuje vreme koje programer treba da uloži u prljav, vodoinstalaterski posao (jer SQL to uglavnom jeste) i omogući mu da se više koncentriše na konkretan problem koji treba da reši, stvari unikatne za projekat.

Slična stvar se desila i sa SQLom na ozbiljnim platformama (.NET, Java, Delphi...), a polako niču projekti koji portuju rešenja sa tih platformi (Propel je u suštini PHP verzija Torque projekta) ili osmišljavaju i implementiraju nova na "neozbiljnim" platformama.
Ja sam ranije radio dosta u Delphiju (a cini mi se da se i Pedje secam sa yu.prog.delphi newsa? ) i apsolutno podrzavam taj vid automatizacije koji recimo Delphi pruza. Dovuces par komponenti, popunis par propertija i imas npr potpuno funkcionalni data-grid. Dajte mi to za php i bicu srecan kao kuce, pa makar morao da pozivam objekte da uradim SELECT *...

Ali Delphi ti takodje nudi mogucnost i da stvari radis na vrlo niskom nivou, ako treba i asembler da koristis... autori ovih DB klasa koje sam ja imao prilike da vidim ne omogucavaju low-level alternativu i to je po meni problem..

Nije samo da je ponekad naprosto brze i lakse otkucati par sql komandi... ponekad (cak prilicno cesto) je prakticno neophodno iskoristiti neku specificnu foru baze koja zahteva kontrolu koju pruza SQL...

Uzmi recimo "SELECT SQL_CALC_FOUND_ROWS ..." i "SELECT FOUND_ROWS()". Jako korisna stvar da izbegnes dupli upit na bazi kad koristis limit da prikazes samo deo rezultata (paged results), sto ce reci prakticno na svakoj strani gde se nesto lista iz baze. Sa pre-generisanim klasama si osudjen na 2 upita, jedan count(*) i jedan sa limitom...

Ili mozda i kriticnije, cinjenica da kod mysql-a ponekad zavisi koji ce index da se upotrebi (i da li ce se uopste upotrebiti) od redosleda uslova u WHERE klauzuli (to je po meni zapravo bug u query optimizeru, ali sta da se radi..). Kako ces to da kontrolises, ako ti klasa to pravi automatski i jos ti prepakuje tvoj SQL da bude kompatibilan sa 20 drugih baza?


to je jedna vrsta problema, mozda ne toliko bitna za generalnu publiku, jedan upit ili 5 tesko da je bitno, recimo prosecna strana bloga u Wordpressu uradi 30+ upita i opet ga svi srecno koriste (ukljucujuci i mene jer sam lenj..)

drugi ocigledniji problem (koji i mene muci priznajem) je naravno da je potrebno promeniti nacin razmisljanja o bazi za 90 stepeni, sto bas i nije jednostavno ako radis na odredjeni nacin godinama... za mene je SQL najprirodniji nacin obracanja bazi, jer sam tako naucio.. Da sam prethodno radio sa OO pristupom bazi (sto cenim da je po godinama slucaj sa Ilijom) verovatno bi mi se to cinilo kao super stvar u odnosu na kuckanje SQL-a... navika je mnogo gadna stvar...

ja za sada jos uvek skidam i isprobavam razna resenja, cekam nesto sto ce da napravi kompromis izmedju lakoce rada i mogucnosti...we'll see...
__________________
Leadership is the art of getting people to want to do what you know must be done.

Poslednja izmena od ivanhoe : 03. 02. 2006. u 07:23.
ivanhoe je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #57
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

Nisam koristio DB abstractiol layer. SQL? Pa to je jednostavno! Ne znam, ne volim da komplikujem kad moze jednostavno. BTW i performanse su mi bitne, sto se debagovanja SQL tice, samo udrim $querydump=$querydump." ". $query; pri svakom upitu i na kraju echo $querydump i imam i vise debagovanja nego sto mi treba Ne znam zasto da se mucim sa ko zna koliko komplikovanom bibliotekom za vrlo jednostavne stvari. Mozda, da moram da migriram na drugu bazu, ali je to sigurno vrlo pipavo, i opet bih zeleo da to redim rucno. Nemam onda tudji (citaj: bagovit) kod izmedju. Gresim li ja nesto ili je pravjenje XML za DB abstraction lejer isto sto i rucno dizajniranje baze? BTW mislim da je bolje da covek dizajnira bazu nego da imas 80 tabela u potpuno normalizovanom stanju ili sta vec glupi kompjuter moze da napravi. Kompjuter ne poseduje inteligenciju da me zameni u poslu, pa dali sam pravim CREATE upit za tabelu ili to pisem u XML, isto bi trebalo da bude.

PS: Kad moj kod zabrlja, bar znam sta je i gde je. Sa tudjim kodom nije tako, jer nemam dokumentaciju za kod.

Poslednja izmena od bojan_bozovic : 03. 02. 2006. u 08:57.
bojan_bozovic je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #58
degojs
I'm a PC too.
Wrote a book
 
Avatar degojs
 
Datum učlanjenja: 06.06.2005
Lokacija: Kanada
Poruke: 1.354
Hvala: 82
130 "Hvala" u 89 poruka
degojs će postati "faca" uskorodegojs će postati "faca" uskoro
Default

Poceli smo i da se ispovedamo, a

Citat:
ivanhoe:
Nije samo da je ponekad naprosto brze i lakse otkucati par sql komandi... ponekad (cak prilicno cesto) je prakticno neophodno iskoristiti neku specificnu foru baze koja zahteva kontrolu koju pruza SQL...

Uzmi recimo "SELECT SQL_CALC_FOUND_ROWS ..." i "SELECT FOUND_ROWS()". Jako korisna stvar da izbegnes dupli upit na bazi kad koristis limit da prikazes samo deo rezultata (paged results), sto ce reci prakticno na svakoj strani gde se nesto lista iz baze. Sa pre-generisanim klasama si osudjen na 2 upita, jedan count(*) i jedan sa limitom...
Nije to problem. Svaki bolji generator daje, je li, sors kod. A ti ga posle izmeni kako hoces. Jos bolje, izmeni sablon, tako da u jednom cugu dobijes rezultate vise upita.
Npr. Java to podrzava bez problema. Vise upita, jedna komunikacija sa bazom, dobijes kolekciju ResultSet-a nazad. Nema problema.

Citat:
Kako ces to da kontrolises, ako ti klasa to pravi automatski i jos ti prepakuje tvoj SQL da bude kompatibilan sa 20 drugih baza?
Pazi, ovo sto mi koristimo ne daje kod koji moze da radi sa 20 baza "istovremeno", nego kod koji radi sa jednom bazom. Ali ti mozes lako da kazes hocu sad kod za tu drugu bazu pa za 30 sekundi, eto ti koda (optimizovanog) za drugu bazu. Stvar je da kod svoje aplikacije ne moras da menjas.

Citat:
drugi ocigledniji problem (koji i mene muci priznajem) je naravno da je potrebno promeniti nacin razmisljanja o bazi za 90 stepeni, sto bas i nije jednostavno ako radis na odredjeni nacin godinama... za mene je SQL najprirodniji nacin obracanja bazi, jer sam tako naucio.. Da sam prethodno radio sa OO pristupom bazi (sto cenim da je po godinama slucaj sa Ilijom) verovatno bi mi se to cinilo kao super stvar u odnosu na kuckanje SQL-a... navika je mnogo gadna stvar...
Ajd sad kad vec pricamo..

Nije tu samo to problem. Kod takvog pristupa dosta vremena ode na pocetku na dizajniranje klasa i odnosa medju njima, interfejsi, nasledjivanje.. a to znaci da vidljivih rezultata nema tako brzo. A samim tim ako sve to moras da radis skoro je sigurno da je veliki projekat u pitanju. Pitanje je da li tvoj projekat uopste spada u tu kategoriju.

Sa druge strane, bazu je uglavnom lako uraditi (pogotovo ako ti bluesman ne radi normalizaciju nakon sto si ti normalizovao pa denormalizovao istu ) i mozes da krenes sa front-endom (pogotovo ako imas dobar alat koji ce da ti ustedi sav vodoinstalaterski rad na relaciji front-end <-> baza). I rezultati, makar rada u toku, su brzo vidljivi, a to se cesto jos i trazi.

Mozda ce da bude drugacije kad jos i baze budu podrazumevano nudile tipove podataka a la java.Object, net.Object, php.Object i slicno..

"Doh!" sto bi rekao dinke, ovaj, Homer Simpson.
__________________
Commercial-Free !!!

Poslednja izmena od degojs : 03. 02. 2006. u 10:03.
degojs je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #59
Pedja
Predrag Supurović
Grand Master
 
Datum učlanjenja: 24.01.2006
Lokacija: Užice
Poruke: 791
Hvala: 3
200 "Hvala" u 12 poruka
Pedja is on a distinguished roadPedja is on a distinguished roadPedja is on a distinguished road
Default

Citat:
ivanhoe:

Ja sam ranije radio dosta u Delphiju (a cini mi se da se i Pedje secam sa yu.prog.delphi newsa? ) i apsolutno podrzavam taj vid automatizacije koji recimo Delphi pruza. Dovuces par komponenti, popunis par propertija i imas npr potpuno funkcionalni data-grid. Dajte mi to za php i bicu srecan kao kuce, pa makar morao da pozivam objekte da uradim SELECT *...
Eh Delphi... moram priznati da je su Turbo Pascal i Delphi nesto ponajbolje sto se dogodilo u mojoj programerskoj karijeri i principe na koje sam navikao u njima primenjujem gde god stignem.

Pogodio si me u zicu, jer je i moj ideal da u PHP imam alat koji omogucava da radim nesto sa tom dozom prakticnosti koju Delphi pruza a uveren sam da kada bi se napravile klase koje funkcionisu na principu Delphijevih objekata, to bi bila odlicna stvar. Zamisli samo tu liniju: TTable|TQuery -> TDataSource -> TDBGrid u PHP-u... pa eventi, koji bi u stvari mogli biti mnogo mocniji, jer su skriptovi, a ne prekompajliran kod, kao u Delphi-ju.

Meni se inace cini sasvim ok da koristim neki vizuelni alat kao sto je DBDesigner4 u kome opisem model baze, a onda tako definisan model koristim da izgenerisem osnovni wraper kod koji mi mora olaksati rad sa tim modelom. Ako bih morao rucno da pisem XML koji opisuje model, pa da, to bi bio sustinski neprihvatljiv pristup.


Nego...

Ova nadasve korisna i interesantna diskusija polako prelazi u nadmudrivanje i teoretisanje pa gubi ostricu.

Sta mislite da uzmemo neki zamisljeni poluslozeni model podataka i da malo prakticno i konkretno poradimo na razlicitim pristupima u apstrakciji?

Poslednja izmena od Pedja : 03. 02. 2006. u 16:05.
Pedja je offline   Odgovorite uz citat
Staro 03. 02. 2006.   #60
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

Citat:
Originalno napisao Pedja
Meni se inace cini sasvim ok da koristim neki vizuelni alat kao sto je DBDesigner4 u kome opisem model baze, a onda tako definisan model koristim da izgenerisem osnovni wraper kod koji mi mora olaksati rad sa tim modelom. Ako bih morao rucno da pisem XML koji opisuje model, pa da, to bi bio sustinski neprihvatljiv pristup.
DBDesigner4 čuva šemu u XML obliku tako da se taj dokument uz pomoć jednostavnog stila može transformisati u Propel XML fajl. Više o tome...

Propel XML fajl se može generisati i na osnovu postojeće baze podataka. Potrebno je koristiti creole target... Samom fajlu su kasnije potrebne sitnije dorade, ali je i to bolje nego pisati ga od nule. Na žalost ne mogu da pristupim Propel sajtu tako da ne mogu da linkujem na tutorijal.

PS: Ja se izvinjavam ako konkretizujem previše. Ovde su uglavnom PHP programeri tako da mislim da ove informacije i linkovi nisu na odmet. Ako ništa, a ono bar da se ljudi koje interesuju upoznaju sa stvarima koje ove biblioteke mogu jer često mogu više nego što se na prvi pogled čini

Poslednja izmena od Ilija Studen : 03. 02. 2006. u 18:08.
Ilija Studen 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
Koji font koristite u editoru? bluesman Programiranje 53 22. 10. 2009. 00:53
Koji tekst editor koristite i zašto? Milos Vukotic Opušteno 133 04. 06. 2009. 01:27
koji JS menu koristite? dootzky (X)HTML, JavaScript, DHTML, XML, CSS 6 17. 11. 2006. 22:32
Koji AV software koristite dinke Opušteno 22 12. 03. 2006. 07:05
Koji framework koristite? Ilija Studen PHP 3 19. 06. 2005. 19:25


Vreme je GMT +2. Trenutno vreme je 20:33.


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.