kilogram Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 En av hovedutviklerne har gått hardt ut mot Sun for å ha sluppet MySQL 5.1 for tidlig. Les mer Lenke til kommentar
siDDis Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Og MySQL 5.0 har heller ikkje akkurat så veldig mange mindre alvorlege feil. Det eg finnes mest problematisk uansett er at mange av dei alvorlege feila frå tidlegare versjoner finnes enda etter fleire års kjennskap..... For å ikkje nemne bugs i query planneren som dette: http://forums.mysql.com/read.php?24,229499,229499 Lenke til kommentar
Kimme Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Heldigvis så har jeg ditchet Amarok og lagt min elsk på Songbird og latt være i fred MySQL frustrasjonen. Lenke til kommentar
siDDis Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 (endret) SQLite fungerer nå mykje betre i Amarok, kva i all verden er det som får folk til å velgja ein langt treigare og meir komplisert database til Amarok? Er det fordi dere kan? For å legge til kva ein PostgreSQL core developer meiner om MySQL 5.1 releasen: http://blog.hagander.net/archives/128-On-t...y.html#extended Endret 9. desember 2008 av siDDIs Lenke til kommentar
DarkSlayer Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Det er ikke så lenge siden sun/mysql gjengen la ut en lengre liste over generelle feil, mangler og problemer med mysql. Den listen er jo ganske *slapp in the face* til de som skriker høyt om mysql er best i verden. Når det er sagt, så må man se ting i perspektiv her. Skal man lage en webside til seg selv, i skolesammenheng, lite verktøy på bedriften, liten ...whatever ... så kan man bruke fryktelig mye rart. Oracle, db2, mssql kan fint benyttes - bortsett fra det faktum at man må betale lisens, og det er lett å si at dem er overkill. Så lenge noe koster penger så legger det en demper på utviklingsfrihet - sånn er det bare. Mysql:myisam er en skitdårlig database, men funker helt ypperlig som "stupid storage". Og mange gutteromsprogrammerere er ikke eksperter i sql heller, noe som heller ikke taler for en lisens på oracle. Hva skal man med oracle om man ikke vet å utnytte den? Problemet med mysql er når man vokser i størrelse og kompleksitet. Du får ikke kjørt transaksjoner i myisam, og det er heller ikke radlåsing. Greit man får lagd kode som gjør "transaksjoner" men fyttegrisen så er det mange som ikke har filla peil også. mysql bør overhode ikke være et seriøst valg på større prosjeketer - men det er faktisk vanskelig å se om man ikke står oppi utfordringene. Men de bøggsa som er nå på 5.1 er for det meste rundt de nye replikeringsfunksjonene så jeg. Antar ingen er dumme nok til å kjøre slikt i produksjonsmiljø enda. Regelen er som altid - man bruker ikke bleeding edge stuff i produksjon, da ber du om bråk. Lenke til kommentar
Salt kjeks Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Kan dere slutte å starte artikkelnavn med bindestrek? Da kommer det "– MySQL 5.1 ikke klar" på RSS Eventuelt kan dere vel fikse det på en annen måte? Lenke til kommentar
alaruz Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 MySQL har jeg aldri likt nevneverdig. Er ikke lisenskostnader et problem er Oracle alltid et bra alternativ uansett plattform, også MS SQL på Windows. Er derimot lisenskostnader en problemstilling kan PostgreSQL vurderes. Lenke til kommentar
siDDis Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Hvorfor bruker penger på lisenser når ein kan kjøpe meir maskinkraft? Den einaste grunnen til å velge Oracle er replikering som fungerer 100% der. PostgreSQL er ikkje 100% ACID når det kjem til replikering. Lenke til kommentar
Gjest Slettet-Pqy3rC Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Sjelden noe godt tegn at utvikler og utgiver begynner å skylde på hverandre. Jeg har alltid vært litt forundret over populæriteten til MySQL uten at det i seg selv har noen betydning i denne saken. Lenke til kommentar
Bolson Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Sjelden noe godt tegn at utvikler og utgiver begynner å skylde på hverandre. Jeg har alltid vært litt forundret over populæriteten til MySQL uten at det i seg selv har noen betydning i denne saken. Nei, det er det ikke. Men samtidig kan slike "oppvasker" gi resultat framover. Populariteten til MySQL kan enkelt forklares med hvor den brukes mest, nemlig primært rene nettløsninger. I de sammenhenger medfører de kjente bugs relativt lite konsekvens, i og med at logikken er så fordømrande enkel i de fleste slike løsninger. Ikke det at jeg har overvettes sans for MySQL, men den har vært dønn stabil på alle nettsteder der jeg har den kjørende. Lenke til kommentar
siDDis Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Da høyrer du til den lille heldige gruppa! Ellers så kjører du InnoDB som faktisk fungerer nokonlunde. Lenke til kommentar
Bolson Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Da høyrer du til den lille heldige gruppa! Ellers så kjører du InnoDB som faktisk fungerer nokonlunde. Helst intelligent koding av selve CMS-et, slik at man ikke normalt fremtvinger noen av problemområdene. Større og større deler av tabellene er også flyttet over til InnoDB, og vil vel i neste hovedversjon bare bruke InnoDB. CMS-et har sin historie helt fra 1998, så det er egentlig utrolig at det henger med i svingene (kontinuerlig oppdatert dog). Men nettløsninger som ikke inneholder mye avansert applikasjonslogikk, noe som gjelder de fleste, er dog ikke særlig krevende på databasesida. Men som sagt, selv med min relativt begrensa kludring i databasen, har MySQL irritasjonsmomenter. Men faktisk opplever jeg i mitt miljø, og det er ikke noe småtteri i verdensmålestokk, at MySQL fungerer utrolig stabilt i forhold til denne nettløsningen. Lenke til kommentar
siDDis Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Min erfaring er det heilt motsatte, korrupte tabeller skjer altfor ofte. InnoDB fungerer mykje betre, men systemtabellane er enda MyISAM og kan kræsje. Har aldri opplevd det, men faren er der. Også er InnoDB siruptreig. Skal eg ha noko enkelt så går eg for SQLite, full ACID, full text søk og generelt sett 2-3 gonger raskare enn MyISAM på heilt enkle ting. Lenke til kommentar
Bolson Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 Merkverdig, vi fikk faktisk ytelsesøkning da man flyttet deler over til InnoDB. Korrupte tabeller har jeg heller ikke opplevd på ca 40 databaser med driftstid på fra 2 - 3,5 år. Nå er ingen av mine ekstremt store, de ligger vel på 50 - 400 MiB (noen mindre og). SQlite blir for puslete til denne løsningen, er prøvd og da datt faktisk ytelsen. Oracle etc fungerer bra på kjernen, men er litt lurvete på tilleggsmoduler. Lenke til kommentar
siDDis Skrevet 9. desember 2008 Rapporter Del Skrevet 9. desember 2008 (endret) SQLite er treigare om du oppretter mange "connections" mot en fil, da den låser heile fila. Så om du har mange samtidege brukerar så lønner SQLite seg ikkje. Det forklarer vell også kvifor InnoDB blei raskare då den låser på rad og ikkje tabellnivå som MyISAM gjer. Eg trur det er enda meir å hente på å bruke PostgreSQL som takler mange samtidige brukerar langt betre enn InnoDB. Endret 9. desember 2008 av siDDIs Lenke til kommentar
DarkSlayer Skrevet 10. desember 2008 Rapporter Del Skrevet 10. desember 2008 ...åssen i huleste får du korrupte tabeller i mysql..? Om du har 2 brukere som oppdaterer samme post samtidig, og du ikke låser tabellene(myisam), eller kjører transaksjoner(innodb) - da kan jeg forstå det. Nå er det mange plasser man ikke har behov for dette ofte og det er lett å glemme i farten. Ellers så har du jo kvoten over mystiske ting som bare skjer... manglende feilhåndtering når man får exceptions mot databasen er også gøyal.. Men ellers er det som tidligere sagt - mange webapps er kun lim mellom ofte relativ enkel sql og html. Da er mysql helt ok. Wikipedia kjører på mysql meg bekjent, og det er jo et ekstremt eksempel på at det går an om tar høyde for ting - men så er jo tjenesten 99% select fra en plass, og litt update og insert her og der. Lenke til kommentar
krigun Skrevet 10. desember 2008 Rapporter Del Skrevet 10. desember 2008 PostgreSQL, MySQL... It's all the same. Dagene til relasjonsdatabaser er forbi uansett. Lenke til kommentar
siDDis Skrevet 10. desember 2008 Rapporter Del Skrevet 10. desember 2008 (endret) ...åssen i huleste får du korrupte tabeller i mysql..? Om du har 2 brukere som oppdaterer samme post samtidig, og du ikke låser tabellene(myisam), eller kjører transaksjoner(innodb) - da kan jeg forstå det. Nå er det mange plasser man ikke har behov for dette ofte og det er lett å glemme i farten. Ellers så har du jo kvoten over mystiske ting som bare skjer... manglende feilhåndtering når man får exceptions mot databasen er også gøyal.. Men ellers er det som tidligere sagt - mange webapps er kun lim mellom ofte relativ enkel sql og html. Da er mysql helt ok. Wikipedia kjører på mysql meg bekjent, og det er jo et ekstremt eksempel på at det går an om tar høyde for ting - men så er jo tjenesten 99% select fra en plass, og litt update og insert her og der. Det er akkurat av dei grunnane at det kan skje at det er problematisk. Tap av data eller enda verre, feil data er svært alvorleg i ein database. Sider som Facebook som bruker MySQL har allereie opplevd dette. Facebook har dessuten begynt å bruke Oracle til eindel ting også. Endret 10. desember 2008 av siDDIs Lenke til kommentar
Bolson Skrevet 10. desember 2008 Rapporter Del Skrevet 10. desember 2008 PostgreSQL, MySQL... It's all the same. Dagene til relasjonsdatabaser er forbi uansett. Er det ikke fornuftig å begrunne et slik påstand. Lenke til kommentar
krigun Skrevet 10. desember 2008 Rapporter Del Skrevet 10. desember 2008 PostgreSQL, MySQL... It's all the same. Dagene til relasjonsdatabaser er forbi uansett. Er det ikke fornuftig å begrunne et slik påstand. Tenk deg da; du lagrer [i flesteparten av tilfellene] ALT på ett sted, og det du lagrer henger på en eller annen måte tett sammen med noe annet som du lagrer. ALT er satt inn i en firkantet boks, med predefinert schema, låser, replikering for å håndtere maskinfeil og whatnot. Jeg kan være enig i at noen ganger er det veldig fint med en relasjonsdatabase, men å prøve å jobbe smidig mot noe så satt som en RDBMS er bare håpløst. Velkommen CouchDB. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå