Pridružite se akciji: save MySQL i potpišite peticiju!

Malo glupo pitanje, ali svejedno:

Bi li moglo zatvaranje MySQL-ovog koda, te pretvaranjem ga u komercijalni proizvod moglo rezultirati poskupljenjem web hostinga?

Uglavnom svaki web hosting na kojem sam hostao web stranice je podržavao MySQL, pa zato pitam.

Niti jedno pitanje nije glupo. :) - Da, svakako.

 -zar i ti (sine Brute...)?? Peticija? Primjetno, već neko vrijeme (od gripe), nisi više onaj stari... žalosno.

 -..

 -da (samo odgovori), pa protu-pitanje, dali će poskupljenje goriva i plina utjecati na više cijene hostinga, ili samo na cijenu gradskog parkinga, ili će možda cijene biti niže?

-btw. upravo je trajala akcija (pošto nisam plaćen, ne spominjem imena) ali hosting je postao vrlo jeftin.

-kretanje cijena nije tako (jednostavno) predvidljivo. Druga stvar što Oracle nije (za sad) promijenio ništa u svojim stavovima, MySQL je ista cijena kao i jučer... dakle nema razloga za promijenu. Zapravo, cijene hosting paketa na linux ili MS platformi je već godinama ista, pošto to što je MySQL bio (i još uvijek je) besplatan nije utjecalo na cijenu, nevidim razloga da se to promijeni. Osim samog interesa trgovca, koji naravno želi dignuti cijene. Uz podsjetnik da zbog krize, cijene padaju.

MySQL nije potpuno besplatna baza, iako je njezin veći dio besplatan. Uvijek se može koristiti potpuno otvoren i full besplatan Postgre SQL koji čak ima više mogućnosti nego MySQL.

Najjeftiniji (i neki besplatni hostinzi) su se najcesce vrtili na linux - apache - mysql - php jer za sve to ne moras potrosit kunu. Ako bi za upogonit jedan server trebalo jos par tisuca $ (koliko dodju najjeftiniji primjerci MS SQL servera, da ne spominjem cijene Oracle-a) onda se svakako trebaju dizati cijene samog hostinga da bi se to sve skupa isplatilo vrtiti.

Baza kao baza je besplatna... u svojoj placenoj verziji imas nekakve dodatne alate za centralizirani monitoring etc + support... A i ta placena verzija je osjetno jeftinija od MS i Oracle-ovih rijesenja...

PHP + mySQL su skoro pa simbioza... developeri ce nerado prijeci na postgre, mislim na ove koji su se navikli na mysql...

Zanimljivu izjavu sam cuo od Joel Spolskog (ima kompaniju koja radi bug tracking software, Fogbugz), koji upozorava da koristenje MySQLa nije besplatno ako aplikacija ovisi iskljucivo o toj bazi - onda se placa licenca. Besplatna je samo ako se moze preswitchati aplikacija na bilo koju drugu bazu bez izmjene source koda. 

Sam nisam isao citati licence agreement, tako da ne mogu potvrditi ove tvrdnje. 

Ma ok postoje neke razlike izmedju my i MS SQL u tipovima podataka, naredbama bla bla (neznam kakvo je stanje sa Postgreom jer sa njim nisam nikad radio, kao ni sa Oracleom). U ostalom postoje neke alternative mySQL-u koje rade na istoj bazi tako da to nebi trebao biti problem.

Na stranu tehnicka izvedba aplikacije sa mogucnoscu switchanja baze, meni je zanimljiv taj dio licence mysql-a. Valjda sve app koje ja znam ne bi nikako radile sa drugom bazom bez izmjene SQL naredbi u kodu ili store procedurama, sto znaci da sve te aplikacije krse licencu mysqla i autori bi trebali platiti nesto sunu/oraclu. 

Ali s druge strance, nisam cuo da je netko i platio tu licencu, odnosno da je sun/oracle nekoga i tuzio zbog toga.

Potpisano !!!

 -zato jer ozbiljne firme imaju svoj layer za bazu... (pa im je nebitno koja je baza iza, os itd..), zato je to i navedeno u licenci jer time ostaje 'open' -nije vezana uz jedno rješenje.

Ozbiljne firme iz 1995.? Jerbo, pisati vlastiti ORM koji je DB agnostic, je u najmanju ruku suludo.
Koristi se neki od desetka dostupnih ORM-ova i mnogi dopuštaju i promjenu baze, ali ne uvijek.

ako ne bude mysql, biti će yoursql, tj. forkaj, promijeni ime i tjeraj dalje. 

Ma ok, negdje i nisu toliko velike razlike, ali npr mySQL i MS SQL imaju poprilicne razlike u sintaksi. U ostalom, velike firme si nece dopustit takvo nesto, vec ce si kupit licencu i adio mare...

AFAIK, samo Hibernate dopusta takav swich (Oracle, MySQL, PosgreSQL i HypersonicSQL), ali to dovodi druge probleme za sobom.

Hibernate npr. koristi svoj slang SQL-a koji je slican, ali ne i jednak standardnom SQL-u, i pitaj boga kako on to compilira iza zavjesa u nativni SQL baze kad za to dodje vrijeme. Kod iole kompliciranijih upita, iskreno se nisam usudio dati mu uopce sansu i napravio sam normalno DAO implementacije za svaki persistence target za koji smo izdavali aplikaciju.

Svakako Deuse, ali moraš negdje povući granicu. Nekoć sam optimizirao svoj 3d renderer u asm-u. Kao što smo jednom povukli granicu pa više ne pišemo optimizacije u ASM-u, već pustimo da kompajler iza zavjesa kompilira naš C++ kako njemu drago kad za to dođe vrijeme, tako je došlo i vrijeme da pustimo ORM da kompilira naše upite u SQL kada za to dođe vrijeme.

U velikoj većini slučajeva radi se često o kodu koji sami ne bismo napisali tako efikasno.

Prije nekog vremena na FESB-u je održano i predavanje o LINQ2SQL-u, MSSQL ORM-u i dokazano je, na praktičnom primjeru, kako taj ORM proizvodi bolji kod od onog koji ručno napišemo.

DB-agnostic je i Entity Framework koji također generira prilično zgodne rezultate, a nisam nezadovoljan ni NHibernateom.

Hm, da, ali velika je razlika izmedju komplilacije iz high-level languagea (C/C++) u low level language (ASM), i komplilacije izmedju jezika istog nivoa. Nije tu upitan sam Hibernate, vec zapravo Oracle - poznato je da kod kompleksnijih upita, zbog prirode SQL koji dopusta 1001 nacin za rijesiti neki problem, razlike u brzinama na sampleovima koji se broje milijunima redaka su u redovima velicine; osobno sam se u to uvjerio u gornjem primjeru, kad mi je DBA slozio drugaciji upit na bazu koji je, umjesto 2:36 sekundi trajao 0.10

Kako rekoh, nije Hibernate. Nego Oracle. Uvijek bio, uvijek ce biti.
Skupila se hrpa programera i krenula pisati bugove. Nakon godinu dana, kolekciju bugova su nazvali Oracle.

Nije SQL baš jezik istog nivoa kao Java/C#. Velike su razlike u produktivnosti i kompleksnosti i uopće težini upotrebe. SQL je kod većih upita nad tablicama itekako naporan, dok viši, pravi jezici to rade uglavnom bezbolno nad domenskim modelom.

Jednostavno se ne mogu složiti s tobom, jer SQL dobro napisan uvijek je blisko dobro napisan. Postoji više načina za sve, ali malo je onih pravih, a pod tim mislim na to da je za određeni upit uvijek dobar određeni način upita i jedini ispravan. Razlika od 2:36 na 0:10 je toliko drastična da se vrlo vjerojatno radi o pogrešci ili previdu u prvom upitu, radije nego tek jednoj od verzija.

Suprotstavljeno pisanju jedne SP koje može trajati danima u odnosu na slaganje upita u jednom LINQ-u koje može trajati satima, je jednostavno drastično različito. Sama upotreba domenskog modela u generiranju algoritama poslovne logike već je dovoljna prednost u odnosu na osnovnu CRUD manipulaciju tablicama.

Proučiš li malo moderne grafičke, UI i slične biblioteke, lako ćeš naći hrpu stvari koje bi najradije sam napisao bolje, i to je normalno. Ali ako idemo tako duboko uvijek, izmišljanje kotača bila bi glavna preokupacija cijelih timova developera i nitko se nikada nebi maknuo s mrtve točke razvoja.

Siguran sam da se u 95% softvera barem 50% komponenti brže i efikasnije može izvesti u čistom ASM-u s direktnim pristupom hardveru... ali u kojem vremenskom rasponu i za koju cijenu?

Postoji neka granica koje se treba držati. Ponekad je bolje kupiti dvije jezgre više i platiti duplo skuplje CPU, nego se brinuti od razlici u brzini izvođenja, jer optimizacije često koštaju desetke i stotine puta više od hardvera.

Uostalom, sam si se u to uvjerio na projektu znaš kojem...

neće ništa poskupjet, ista stvar ako ideš uspoređivat ASP.NET i PHP hostove, cijene iste ili mizerne razlike...

I da mysql propadne ne bi bio smak svijeta, izbora ima mnogo i neće biti nikakav problem prešaltat se na nešto drugo, naravno bolje da imamo i izbor više kao mysql :)