"Drágább lett a MySQL"

 ( trey | 2010. november 4., csütörtök - 20:54 )

"Megszűnt a legolcsóbb csomag [...] Az Oracle-nál mostantól négy MySQL változat érhető el, ami valójában hármat jelent, a Classic ugyanis csak szoftverfejlesztők számára érhető el, hogy alkalmazásaikba beépítsék. Ezzel a MySQL Standard Edition lett az alapváltozat, amely az adatbázison, konnektorokon és replikációs képességen felül a MySQL Workbenchet, illetve a MyISAM és InnoDB tárolómotorokat tartalmazza. Az Enterprise Edition ezt particionálással, valamint a MySQL Enterprise Monitorral és Backuppal egészíti ki."

A teljes cikk itt olvasható.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

no comment

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Ha a Sun is ezt csinálta volna lehet hogy még ma is élne...

Nem hiszem, hogy ezen múlott. Nem olvastam egyetlen mérlegjüket sem és egyetlen elemzést sem a Sunról, de nem ezen múlott az tuti.


-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Hat min?

tompos

Azon múlott, ami - többek között - a mysql-lel kapcsolatos semmittevést is eredményezte: a koncepciótlanságon. Éveken keresztül semmi épkézláb ötletet nem sikerült megvalósítani a "hogyan csináljunk pénzt a mysqlből" témakörben.

Oracle piacat elvenni volt az egyik lehetoseg, meg idoben vettek meg oket.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Egyértelműen az mostanában az irány, hogy költsünk többet az IT-re...


suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.

Nem tudom, csak úgy felvetettem. Persze nekem sem szimpatikus az 0racle. Meg mondjuk pl. az ODF import plugin ami többe kerül mint a komplett MS Office licenc már kicsit túlzás.

> Egyértelműen az mostanában az irány, hogy költsünk többet az IT-re...

Kösz, ezt jó tudni.

ironizált.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

> ironizált.

Akkor rejteget valamit, azért nem fogalmaz egyenesen.

igen.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Unbreakable...


-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

http://www.mysql.com/products/ szerint a classicban nem lesz innodb.

t

és?

De az opensource editionban benne van nem?

benne, és?

és 5.5-től az a default storage engine :)

a classic-ban valószínűleg nem.

Még mindig nem értettem meg, miért fizetnek az emberek azért, amit a közösségtől ingyen is megkaphatnak.
Support, szokták mondani, nade annyira jó hogy megérjen ennyi pénzt? Vagy a monitorozási lehetőségek?

mit kapsz meg a kozossegtol?

szerinted hany ember fog neked innodb tuning tanacsokat adni melyrehatoan, szemelyre szabva?
segitenek majd optimizalni a queryjeidet a forumon, mind a felmilliot?

vannak dolgok amiket a support megcsinal, bizonyos fix valaszidovel. egy forumot, akarmilyen "kozosseg"et ne emeld erre a szintre.

meg sosem volt dolgod igazi supporttal?

Sun és Oracle supporttal is. Azért annyira ne dícsérd őket.


suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.

nem dicserem, de abban egyetertunk, hogy vannak fontos dolgok, amiket (elvileg) a support tud nyujtani, es nem varhato el "a kozosseg"tol?

Vannak. De a gyakorlat számomra azt mutatja, hogy eddig a (fejlesztői)közösség nekem sokkal gyorsabban és hatékonyabban reagált, mint bármelyik support, vagy jól képzett belső szakember.


suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.

ha masra nem, arra biztos jo, hogy a fonokenek tudja mutogatni a szerzodest az ember, hogy "nezd gazsi, hat vettunk hozza supportot!" :)

++
Nem mindegy, hogy ha valami kaki van, akkor ki viszi el a balhét. Aki teheti, bebiztosítja a popóját.
--
unix -- több, mint kód. filozófia.
Life is feudal

Mi használjuk mind2t és nekem semmi bajom az Oracle supportal, a Sunról nem tudok nyilatkozni mert azt én nem használom, de akik használják a cégnél azoktól se halottam hogy panaszkodtak volna rá.
Jó azt aláírom, hogy kemény pénzeket fizetünk mind2nek a support-ért de hála jó égnek nincs velük probléma.

Nekem az a tapasztalatom, hogy az Oracle és a Microsoft is nagyon jó supportot biztosít. Az OTN is nagyon jó, de túrni kell ezerrel. Mondjuk mind az Oracle és az MS is szorgalmazza a munkatársait hogy használják a közösségi eszközöket, figyeljék az OTN-t, blogoljanak, postoljanak stb. Viszont pl. az OTN esetében akár 1-2 napig is eltarthat, mire válasz érkezik egy-egy kérdésre, ami project környezetben nem túl hatékony. A Sun-al kapcsolatban nincs tapasztalatom, de gondolom az Oracle keményen rendbeteszi ha kell, mert a support nagy pénzeket hoz neki.

***
programozó nők rémálma: a végtelen ciklus

Valóban nem volt még dolgom igazi supporttal. Saját tapasztalat, hogy ezeket úgy megcsinálják, hogy megéri kifizetni a díját?

mysql supporttal pont nincs tapasztalatom, installshield supporttal volt pozitiv elmenyem, illetve 3rd party supportosokkal (X ceg garantal neked valamit a cuccodra, bar azt alairom, hogy ez nem az itt targyalt support kategoriaja)

Ha egy cegtol olyan termeket vasarolsz a ceged szempontjabol kritikus szoftvert, ahol a ceg visszatartja a dokumentaciot, akkor muszaj supportot venni. Akkor is muszaj, ha maskepp nem adnak licenszt. Akkor is muszaj, ha maskepp nem adjak oda a patchet.

Azokban az informaciokban, amik publikusak (tehat nem tartjak vissza) a kozosseg sokkal hatekonyabb/gyorsabb, mint a support, felteve ha te is ertessz hozza. Ha nincs helyi hozzaertes, akkor marad a gyartoi support, hiszen nem tudsz ertelmes kerdest feltenni a kozossegnek/googlinak.

Emiatt vesz a fonok gyartoi supportot (hiszen nem alapozhat a beosztott mernokre)
Es amiatt erzik az adott terulethez erto szakik, hogy a gyartoi support nagyon vacak

+1


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

+100

Csak amikor a gyártói supportnak feltett kérdésedet 1 órával később viszontlátod a -devel listán, akkor kicsit elszomorodsz.

Tapasztalatok alapjan is azt mondhatom, hogy a kep igencsak aranyalt. Tudnek sok olyan peldat mondani, amikor a "kozossegi support" (legyen az egy forum, levlista, irc csatorna, vagy intenziv guglizas) sokkal tobbet segitett mint a hivtalos support, megis egy ceg nem alapozhat erre, neki papir kell arrol, hogy support, es valaki alairta, stb. Aztan sokszor megesik persze, hogy "kozossegi support" lesz a dologbol, mert a hivtalos az vagy inkompetens, vagy tul lassu, vagy egyeb problema van vele, de a fontos amit irtam: gyakran nem is a support minosege dont, hanem hogy a fonok tudja lobogtatni a papirt, hogy "van support", aztan lehet o maga fog szolni neked, hogy "nezz utana a neten akkor, ha ezek nem segitenek egy oran belul" ...

Szerintem most jobban képbe kerülnek a MySQL szakértelemmel bíró kis fejlesztő és support cégek.

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

persze hogy benne :)

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

ha nincs innodb, min fogsz tranzakciózni?

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

ehhez nekem mi közöm?

te kérdeztél...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

igen, hogy mi a mondanivalója ezzel a classic témával. tehát szerinted az, hogy nem fog tudni tranzakciózni.

akkormeg? mit nem értesz?

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

elfelejted, hogy ez csak a te feltételezésed. tibyke azóta se válaszolt.

Ezek szerint az Oracle komolyan veszi a MySQL -t, csodalkoztom hogy eddig nem tettek ra az Oracle logo arat.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Vagy csak szeretné csökkenteni az iránta mutatkozó olthatatlan vágyat.


suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.

Csak meglódul az a PostgreSQL tábor, na.

Azert az eleg szanalmas lenne, ha a psql-t azert kellene valasztani, mert occsobb.

Kelljen azert, mert jobb.

tompos

Nem pont erre az aspektusra gondoltam.

jobb is, de ennek közvetlen következménye, hogy bonyolultabb is.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Mivel bonyolultabb egy Pg ugyanabban, mint amit a MySQL is tud?

----------------
Lvl86 Troll

http://hup.hu/cikkek/20101104/dragabb_lett_a_mysql#comment-1152796

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Szerintem semmivel nem bonyolultabb. Több mindent tud, ami az elején picit bonyolultabbnak láttaja talán.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

"elején picit bonyolultabbnak láttaja talán"

legtöbb mysql huszárnak ez kínai nagy fal méretű akadály. a mysql faék jogosultsági szintjei után csak a hba-t átlátni egyeseknek lehetetlen küldetés.

illetve aki le van ragadva a subqueryk bonyolultsaganal, az nem fog hirtelen pg/plsql-ben procedure-t kodolni, mert az jobb.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

En azt latom, hogy a mysql jobban fejlodik most, mint a Sun felvasarlas utan. Azokkal is egyetertek, akik azt mondjak, hogy a 2005-os InnoDB felvasarlasnal sokkal jobb lehetosege volt az Oracle-nek megolni a termeket. A hot backup-pal egyenerteku open source megoldas van, a mysql enterprise monitor viszont tenyleg jo. A query analyzer proxys megoldasanal nekem jobban tetszik az mk-query-digest. Enterprise mysql regen is volt InnoDB nelkul, gondolom nem arulok el nagy titkot azzal, hogy ezt beagyazott rendszereknel szokas hasznalni.

Jó látni, hogy végre az Oracle rendbeteszi a MySQL-t. Még a végén egy használható termék lesz belőle. A címválasztás nem a legszerencsésebb...

***
programozó nők rémálma: a végtelen ciklus

+1
Azért az Oracle-nek elég nagy tapasztalata van DB szinten, és én hiszek benne, hogy a célja az, hogy jobbá tegye a MySQL-t és ezáltal a piacnak ezen a részén is ő uralkodjon. És ha valakinek az kevés amit a "kistestvér" nyújtani tud, akkor szépen majd áttér a "nagyobb" változatra.

Haha.. Remélem, hogy a MySQL-ben is megjelennek az Oracle vackokból ismert semmitmondó hibaüzenetek és az elbaszott hisztizések minden minimális kényelmi szintaxon.

(Hiszti, mert van bármi a SELECT előtt, hiszti mert a tábla mezőit és a megszorítások közé üres sort akarok rakni, stb. Továbbá az ilyen sokatmondó "XML Parse error" jellegű üzeneteket is szeressük...)

----------------
Lvl86 Troll

DBMS_METADATA.get_ddl SQLDeveper-ben nem megy, sqlplus -al megy, elvileg hasonlo problema tobbszor is volt javitva. Valoszinuleg a NLS (kod lap) beallitasok terhettek el.

Amit meg szeretek, hogy az osszes export schema/DB to SQL forum kerdesre azt mondjak minek exportalni SQL -be, ott van exp meg az imp, oszt legyen jo neked valami binaris retekben.

MySQL -re Oracle-bol migralos toolokra vannak utalsok a neten, de erosen eltunoben (mysql oldalan volt). (Meg Sun felvasarlas elott irtak oket)
pg -re migralasra van tool: http://pgfoundry.org/projects/ora2pg/


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kiváncsiságból kipróbáltam ezt a DBMS_METADATA.get_ddl -t hogy tényleg nem megy e SQLDeveloperrel, mert én amúgy mást használok, nálam tökéletesen működik SQLDeveloper-rel.Nem tudom neked mi a bajod vele.Egyetlen hibája van de az mindenhol hogy a ; -t nem teszi a szükséges utasítások végére ezt sajnos neked kell megcsinálnod.
Ezt a "bináris retek"-et meg nem értem, minek kell neked SQL-be a séma tábláinak adatai, ha ennyire szükséges akkor gyártasd le ezt egy erre alkalmas eszközzel.Bár én nem akarom tudni mekkorák lehetnek azok az sql fileok amik egy 40-50 GB -os séma adatait tartalmazzák insert utasításokkal teletűzdelve, és akkor ez még nem is olyan nagy séma.

Valoszinuleg nem az SQLDeveloper a hibas, valami karakter kodolasra vissza vezetheto hiba uzenetet adott (x86_64 linuxon,en_US.UTF-8 locale, mast nem piszkaltam, a szerver talan Sparc/Solaris volt.).

Modjuk olyan nyilvanvalo okokbol, hogy a schema kurva kicsi, es sajat jatszoteremben szerettem volna jatszani vele, valamint SQL kodbol schema szerkezet olvasas nekem meg minidig atlathatobb, mint a legtobb grafikus (lassu) tool, foleg ha FK nincsenek is definialva (arra van terkep rajzolom).

Alapbol CLOB tipus-t tartalmazo (barmilyen rovid) tabla lekerese is kurva lassu, ha szerver a vilag masik vegen van, bar nehany varazslatos SET utan javul egy pottyet a helyzet. (Vagy, ha tipus kenyszerited masra a selectben)

Egyszeru kis valtozasokat, meg mindig egyszerubben tudok nezni egy mezzei diff -el, mint feltalalni ra sajat komlexebb toolomat, vagy schmakat clonozni agyba-fobe, es azt valami PL/SQL koddal hasonlitgatni.

Es Oracle DB -t sem teszek a desktopra jatszani, eleg memoria zabalo tool van mar igy is. (pedig sok memoriam van)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Tisztázzuk neked mi kell,
Ha a szerkezet kell akkor azt az importkor tudsz generáltatni, szép sql formájába (trigger, procedure,package, táblák szerkezete, grantok, user, type, index, comment és job, lehet kihagytam valamit ) Ezt parancssorból simán csinálhatód és baromira nem lassú.
Én úgy értettem neked a táblák adatai kellenek sql formába. (insert) Erre nem tudom, hogy van e parancssoros megoldás én ilyet csak grafikus programokkal csináltam, azt is elég keveset mert az a része nem hozzám tartozik.
Az oracle a DB-it nem desktopokra tervezte az hogy kiadták ezt az express edition nevű lebutított, tényleg csak játszani való DB-t az szép és jó, de ne csak abból ítéljük már meg az Oracle DB-ket.
Performanciában és rendelkezésre állásban az egyik legjobb DB típust az Oracle gyártja, és ha ezeknek a jó tulajdonságoknak egy kis részét belerakják a MySQL-be akkor szerintem jót tesznek azokkal akik nem tudják/akarják megfizetni az Oracle saját DB-it és emiatt használnak MySQL-t.

Ha a táblák tartalma kell diffeléshez, akkor írsz egy 20 soros perl scriptet, ami az adott select eredményét fix szélességű oszlopokba berakja, és az eredményekre nyomsz cli-ben diffet, az eredményt meg egy jólirányzott less -S-sel megnézed. Ha nagy táblákban kevés eltérést keserünk ezzel nagyon jól meg lehet találni.

Neki nem ez kellett ő szerette volna látni, ahogy sqlbe benne van az összes adatja ami az exportálandó táblában volt és nem binárisan mint ahogy az export csinálja, legalábbis nekem ez jött le belőle.
Amúgy az exp és imp tökéletesen megcsinál mindent de ha ennyire nem bízol benne a végén max írsz egy selectet ami megszámolja a sorokat az összes táblába és összehasonlítod a régi sémáéval és ha egyezik a száma akkor tuti megvan minden.
Én mikor átviszek valami sémát, akkor az adott séma objectjeinek számát és a méretet szoktam összehasonlítani, de a méret nem igazán mérvadó mert releasenként más lehet a tömörítési eljárás, ha van.
De ha valamit félreértettem akkor írjátok le, mert én úgy gondolom, hogy nem hülyeségből írták meg az exp és imp-et és szerintem tökéletesen megfelelő sémák, táblák és egyéb adatok mozgatására.

gondolom phpmyadmin jellegű struktúra+adat exportot akar.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Azt elismerem hogy vannak semmit mondó hibaüzenetek azoktól én is a falnak megyek. De ezeket a hisztiket én nem értem select előtt mi van amire hisztizik ?
Én nem azt mondom hogy az Oracle tökéletes hanem, hogy a mysql-en csak javítani tud ha épp nem az a cél hogy elbasszák.

Pl. a SELECT előtt van egy üres sor. Bár lehet, hogy ez APEX specifikus, szerencsére csak suliban kell vele foglalkoznom.

De majd munkatársat megkérem, hogy nézze már meg, hogy a 10 v 11g hogy mit szól ahhoz, ha pl. Java-ból kap egy olyan query-t, ami nem egyből a SELECT-l kezdődik. (Szerencsére kimaradtam abból a projektből).

----------------
Lvl86 Troll

ORM megoldasokrol hallottal-e mar? :)

Igen, nem releváns most jelen esetben. :)

----------------
Lvl86 Troll

Bevallom, a problémát sem értem.

C, C++, Java, perl, python, php - kb. csak ennyi nyelvből sikerült eddig Oracle-be/mysql-be SQL parancsokat küldeni, és sose volt olyan gondom, hogy a parancs elejére (ami ugye egy string az adott nyelven, amit átadok a megfelelő query végrehajtó API függvénynek) sikerült volna beszúrnom egy extra LF-et "véletlenül"...

Ennek rendkívül örülök, ettől még létezik ez a probléma.

Ld. APEX. Használod az SQL szerkesztőjét, szerkesztgetsz benne jobbra-balra, kivágsz, beszúrsz, aztán egyszer csak ott marad az elején egy üres sor. Hopp, máris nyafog, pedig a Query lehet, hogy jó.

Egyébként hogy gyakorlati példát mondjak: volt már olyan, hogy tettem egy kommentet egy SQL Query elé, hogy a debuggerünk SQL historyjában egyszerű legyen keresni, hogy melyik query is volt az, ami. (Sok hasonló, de minimálisan különböző query jött egymás után, így volt a legegyszerűbb).

----------------
Lvl86 Troll

a problema teljesen irrelevans, pebkac, user error, facepalm, etc.

Na, miután kirugóztad magad ezen, akkor mond el, hogy szerinted ez miért baj:

CREATE TABLE foo (
  a INT
  b INT

  CONSTRAINT foo_pkey PRIMARY KEY (a)
);

Mindezt úgy, hogy egy normális hibaüzenetet sem tud hozzá mellékelni a csodaoracle.

----------------
Lvl86 Troll

eddig arrol beszeltel, hogy a "\nSELECT..." parancsot nem eszi meg...

ne legyél write only..

"hiszti mert a tábla mezőit és a megszorítások közé üres sort akarok rakni,"

----------------
Lvl86 Troll

ezt tényleg nem eszi de ha a \n helyett enter van és a szövegszerkesztőd is annak veszi akkor tökéletesen lefut, mert az sql nem szövegszerkesztő, miért kéne tudnia hogy a \n az a sor vége? Ne várjuk el mást a programtól mint ami valójában el kéne várni tőle :)

create table proba (

ID NUMBER not null,
DATUM DATE not null,
VALAMI VARCHAR2(255) not null

);

Tökéletesen befutott, pedig előtte is hagytam ki sort meg utána is baromira nem ezen múlott, az más hogy a constraint más syntaxisal kell megadni.(alter table proba add constraint proba_pkey primary key (ID);)
És lefuttattam egy selectet is ahol volt előtte üres sor és közbe is tettem egy üres sort sőt még a FROM valami, valami2 közé is tettem egy üres sort és így is tökéletesen lefutott. Az hogy az apex egy szar azért nem a DB a hibás.

Az, hogy a CREATE TABLE-ba beleírd, az is megengedett.

Mindegy, majd megnézem valamelyik nap, most van más dolgom is.

----------------
Lvl86 Troll

No vessző seholse?
--
unix -- több, mint kód. filozófia.
Life is feudal

Jogos, természetesen vesszővel, így:

CREATE TABLE foo (
  a INT,
  b INT,

  CONSTRAINT foo_pkey PRIMARY KEY (a)
);

----------------
Lvl86 Troll

első ránézésre hiányzik belőle pl. kettő darab vessző.