"Drágább lett a MySQL"

MySQL, MariaDB

"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ó.

( Jason v | 2010. 11. 04., cs – 20:39 )

no comment

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

( gUHU | 2010. 11. 04., cs – 21:00 )

Unbreakable...

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

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?

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

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

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" ...

( turul16 v | 2010. 11. 04., cs – 21:06 )

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.

( STP | 2010. 11. 05., p – 10:07 )

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

"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.

( petya | 2010. 11. 05., p – 15:30 )

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.

( uid_16401 | 2010. 11. 05., p – 19:58 )

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.

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

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

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.