MySQL når version 5.0

För närvarande är jag så trött på mySQL att jag... well, kräks nästan på det.

Visst, mySQL är gratis och snabb, men saknar ju nästan varje funktion man behöver.

Och när man väl hittar en ny, trevlig, funktion, som igår när jag hittatde group_concat(), inser man att den bara finns från 4.1 som knappt är släppt ännu och som inte ett enda kommersiellt webbhotell kör.

Sen att inte subselects och vyer stöds (ja, det kommer i femman) är ju svagt rent ut sagt av mySQL AB.

Och ja, jag vet att jag är gnällig, men det är varken lätt eller kul att försvara open source när bristerna är så stora som de är.

Som tur är har jag och postgreSQL funnit varandra, så det är inte riktigt så illa...

För att slänga in en morot i tråden känns ta mig tusan mysql lite som quark express där uppdateringar med grundläggande funktioner ligger år in i framtiden

*Puh*! Skönt att skriva av sig

Håller med scooterbabe om vartenda ord. Förut, på den tiden då MySQL 3.23 och PostgreSQL 6.5 var allenarådande i opensource-världen, så fanns det en bra anledning att använda MySQL eftersom det var den enda fria databasen som hade riktigt bra prestanda. Då kunde man ha överseende med att SQL-implementationen i MySQL var usel, och att man var tvungen att låta middlewaren göra databashanterarens jobb. Minns fortfarande med fasa när jag blev tvungen att implementera en motsvarighet till SQL92:s UNION-syntax helt i php...

Men nu så har utvecklingen bland fria databaser gått lite längre. PostgreSQL har optimerats rejält och har numera otroligt bra prestanda, och nu finns dessutom Firebird, en helt fri databas som avknoppats från Borland Interbase. Båda databaserna har i princip fullständiga SQL92-implementationer (plus stora delar av SQL99), och båda har dessutom en massa bra "egen" funktionalitet utöver det (t.ex. regelsystemet i PostgreSQL, eller Firebirds distribuerade transaktioner). MySQL känns ordentligt utdaterad vid jämförelse, och har dessutom alltför många buggar och bisarra beteenden för sig.

http://www.sql-info.de/mysql/gotchas.html
http://vulcanus.its.tudelft.nl/~acm/got/antimysql.php

Jag satt bara och väntade på ett inlägg i den här tråden från dig Samuel...

Jag vet att många "hatar" på MySQL, och det absolut anledningar till det. Men samtidigt måste man ju tänka på att en av fördelarna med opensource är just "choice". Funkar inte MySQL till det man hadde tänkt sig, då finns det ju alternativ som tex PostgreSQL.

För mig personligt funkar MySQL rätt ok i dagens läge (även om jag saknar subselects), men sen jobbar jag inte heller med enterprise projekt direkt så jag förstår varför ni säger som nii gör.

"Use the right tool for the job" som någon engång sa!

Förövrigt kan jag tillägga att Yahoo körs på MySQL (under freebsd dessutom), och tycks mig läsa nångång att MySQL AB ingick samarbetsavtal med tyska SAP killarna?

Helt riktigt! Det enda är bara att jag i nuläget har mycket svårt att föreställa mig ett endaste projekt där MySQL tekniskt sett skulle vara det bästa valet.

Förut var situationen en helt annan, eftersom MySQL var den enda opensource-databasen som var lätt att komma igång med och som hade riktigt bra prestanda "out of the box". Därför var MySQL ibland ett lämpligare val för mindre projekt och nybörjare. Den skillnaden finns inte längre, utan alla opensource-databaserna är i nuläget ungefär lika enkla att komma igång med. Den huvudsakliga skillnaden blir då att MySQL har en buggig och ofullständig SQL-implementation, medan alternativen inte har det.

Att Yahoo körs på MySQL är en sanning med modifikation. Yahoo Finance använder sig iofs av MySQL, men bara i en mindre del av sitt system. Huvuddelen av Yahoo:s innehåll ligger i en helt egenutvecklad databashanterare som är noggrannt optimerad efter det egna användningsmönstret.

MySQL har inte bara ingått samarbetsavtal med SAP, utan de har rentav köpt upp dem. SAPdb är numera omdöpt till MaxDB, och håller på att integreras i MySQL-kodbasen. Däremot kommer det inte att leda till att MySQL AB kommer att börja följa standarder, utan de betonar ganska tydligt att framtida versioner av MySQL ska behålla bakåtkompatibiliteten. Huruvida februari även i fortsättningen kommer att ha 31 dagar har de dock låtit vara osagt...

Amen!

Men om vi vänder på det: Om jag skall koppla ett enda databasfält mot en hemsida så jag kan SELECT:a innehållet och UPDATE:a det ibland, på vilka sätt skulle postgre vara tekniskt sätt det bästa valet? Vad skulle jag tjäna på att byta till postgre i så fall?

Att *byta* databashanterare i ett befintligt projekt kan som bekant kräva en hel del jobb, men jag utgår från att du menar att bygga upp en helt ny webbsida. Jag skulle rekommendera Postgres av de här anledningarna:

1. För att det är lika enkelt att göra med Postgres som med MySQL.

2. Du får betydligt högre flexibilitet med Postgres. Vill du använda samma skript fast mot en databas som har en helt annan struktur kan du skapa en vy som beter sig precis som den ursprungliga tabellen, men vars data hämtas från olika tabeller i den nya databasen.

3. Regelsystemet i Postgres. Du kan t.ex. få Postgres att automatiskt föra en logg över varenda UPDATE du gör i din tabell, och det med bara ett trivialt "CREATE RULE"-uttryck.

4. Högre databasintegritet. Om en bugg i ditt skript gör att data som enligt tabelldefinitionen inte ska kunna läggas in i din databas kan du vara helt säker på att Postgres ger en varning och låter tabellen vara orörd. Exempelvis blir NULL aldrig "konverterat" till andra värden, och '!`-@2003#*^-&%02?!=-*!$31<' godtas aldrig som en giltig datumangivelse.

5. Du slipper de buggiga AUTO_INCREMENT-kolumnerna för ID-nummer.

6. Du kan använda resultatet av ett funktionsanrop som DEFAULT-värde i din tabell, så du kan t.ex. ha "now() + '7 days'" som DEFAULT för en kolumn.

Nu vet jag iofs inte hur du tänkte dig att din tabell skulle se ut, vad den ska innehålla och vilken funktionalitet som du vill att din databaskopplade webbsida ska ha. Därför är det jag har listat här ovan är bara saker jag kom på som är ganska "allmänt" tillämpbara. Men vi kan ju vända på saken: Varför skulle MySQL vara den bästa lösningen i fallet du nämner?

Har MySQL denna bug? Utveckla gärna detta.

Eller vad vet jag... det kanske är en feature? Tabeller i MySQL blir ganska förvirrade ifall man lägger in värden under 1 i kolumner deklarerade med AUTO_INCREMENT. Det gäller även ifall kolumnens datatyp kan anta negativa värden.

Prova t.ex. det här (taget från sql-info.de):

INSERT INTO exmpl3 VALUES(0, 'test');
INSERT INTO exmpl3 VALUES(1, 'test');

mysql> select * from exmpl3;
+----+------+
| id | val  |
+----+------+
|  1 | test |
|  2 | test |
+----+------+
2 rows in set (0.00 sec)

Ännu roligare blir det ifall värdet är mindre än 0, för då kan man få problem med att MySQL tror att samma värde förekommer två gånger (den verkar gå över till någon sorts absolutbelopp då).

Bug och bug... Testade lite och med ett manuellt värde på -1 för ID (key) börjar det strula. Men rimligen bör man ju ALDRIG manuellt hantera ID efter som det just är auto_increment:

mysql> select * from tb1;
+----+-------+
| ID | f1 |
+----+-------+
| 1 | Hej1 |
| 2 | Hej2 |
| 3 | Hej3 |
| -1 | Hej4 |
+----+-------+
4 rows in set (0.00 sec)

mysql> insert into tb1 values(NULL,'Hej5');
ERROR 1062: Duplicate entry '-1' for key 1

Hjälper inte heller att radera ID=-1. Strulet kvarstår. Inressant...

Nu när det är så många med MySQL-erfarenhet här, så tänkte jag passa på att fråga om det går att 'nollställa' ID (key). Jag har en databas där data läggs till under hela dagen och raderas 'bakifrån' på natten. Det innebär att minsta värdet för ID (key) är typ 45678. Kan man 'städa upp' i ID (key) så att det börjar på 1 igen. Så att de befintliga 3000 posterna har ID (key) 1 till 3000?

Tycker att ni är lite taskiga mot MySQL - bygger hellre logik i php eller c än att hålla på och härva med sql

Det jag gillar bäst med MySQL att den är grymts stabil, snabb och lätt administrerad!

Jo, jag tänkte en ny webbsida.

Det var verkligen en extremt enkel sida med en enda liten databaskoppling jag syftade på och skälet var för att se om det finns några skäl även på den allra mest grundläggande nivån (där MySQL hela tiden befunnit sig så att säga) att använda Postgre eller om det var på ett ut där.

1) För jag är lat och inte orkar lära mig nåt nytt utan bara återanvända mina sunkigt kodade sidor sen tidigare (absolut viktigaste punkten )
2) För att det går på ett ut om det är riktigt riktigt basic (alltså jag säger inte att det är så, men det var så jag tänkte när jag frågade) och om det går på ett ut så se punkt 1.
3) För att mitt favvowebbhotell xxx är jättebra på alla sätt och vis men bara har MySQL i det fina billiga kontot jag gillar att använda.
4) För att jag just upptäckt phpMyAdmin och gillar det.

phpPGAdmin, någon?

Då är det inte en SQL-databas du behöver över huvud taget. Varför inte byta till BerkeleyDB eller gdbm?

Tycker du underskattar kraften bakom SQL... Själv tycker jag det finns lite som ger samma tillfredställelse som att reducera logik-loopade SQL:er med en enda, för ändåmålet perfekt anpassad, SQL-sträng som gör allt man gjorde i php eller vad man använder tidigare.

Dessutom är det gryyyyyymt mkt snabbare...

(Har den här tråden gått OT?)

Löser man inte det genom att dumpa ut hela databasen till fil och sedan importera den i en fräsch och tom databas?

Om du kör php så är det i princip bara att köra sök-och-ersätt - de flesta funktionsanropen heter ungefär samma sak (fast börjar med "pg" i stället för "mysql") och har samma syntax, även om parametrarna för pg_connect skiljer sig lite mot för mysql_connect.

OK, då har vi lite olika syn på saken bara. Min ståndpunkt är att det är onödigt att använda olika databashanterare för små respektive stora projekt, när en databashanterare fungerar för allt.

Där har du en poäng faktiskt, även om jag inte anser att själva spridningen gör att MySQL är en bättre databas. Analogt skulle Windows då vara bättre än OS X och kackerlackor vida överlägsna människor, vilket jag personligen inte håller med om. Men det är lite underligt att inte fler webbhotell använder PostgreSQL också. Postgres skalar upp nästan linjärt och har därför väldigt höga prestanda vid många samtidiga anslutningar (gränsen sätts snarast av serverns internminne), medan MySQL har problem med prestanda (och att den ibland vägrar acceptera nya anslutningar) i just den sortens situationer. Men jag antar att webbhotellen kör det som pöbeln kör...

Systerprojektet phpPgAdmin skulle du nog också gilla i så fall - gränssnittet är i princip detsamma.

Jag ska inte ens säga hur enkelt det där är att göra i postgres...

det går. alter table någonting. Kommer dock inte ihåg syntaxen exakt, men det är förmodligen lika lätt som i postgre samuel

Så här enkelt?

SELECT setval('my_sequence', 100);

Det här sätter värdet på sekvensen som skapar id-numret (i exemplet har jag döpt räknaren till "my_sequence") till 100.

OT (liten historielektion ): "PostgreSQL" brukar förkortas till "Postgres" och inte "Postgre". Anledningen är att PostgreSQL från början hette Postgres, som 1986 knoppades av från Ingres. Mellan 1986 och 1995 använde man det egna språket PostQuel, men 1995 bytte man till ANSI SQL. För att markera ändringen bytte man först namn till Postgres95, men 1996 blev det PostgreSQL (uttalas "Postgres-Q-L") i stället.

SELECT setval('my_sequence', 100);

Den där var ny för mig.

Följdfråga: den återställer "räknaren" till 100? Men vad sker med upptagna id'n? Säg att 100 existerar, men inte 101, men 102 o s v?

Kommer den i så fall att som nästa autoid sätta in 101 eller kommer den att sätta in max(id)+1?

/scooter

Det här börjar bli lite för OT, så jag skapade en ny diskussion i utvecklingsforumet:

http://99mac.se/forum/showthread.php?s=&threadid=38025

???
Enligt pressreleasen har de ingått ett strategiskt samarbete.

Inser det roliga i att MySQL skulle ha råd att köpa SAP

/hpe

Förstås. Men mina exempel var egentligen fiktiva utifrån vad jag tänkte att man möjligen skulle kunna komma på. Och sen så är det vanligare att webbhotellen redan har phpMyAdmin igång (men visst, om det är lika lätt att installera phpPGAdmin som phpMyAdmin så kan man ju få igång det själv rätt lätt).

Så det är ingen risk att jag skrivit SQL som bara fungerar med MySQL? Tänkte om nu MySQL var så dåligt på att följa SQL-standarden och jag kanske råkat skriva SQL som är anpassat för MySQLs lustigheter.

(Parantes: jag brukar skriva mot ADOdb hursomhelst för att underlätta ev byten av databas).

Jag förstår din poäng fullt ut. Men om man är en småhackare som bara gör småprojekt och vaggats in i MySQL-världen tack vare den otroliga mängd bra litteratur och tutorials som finns, då ser jag ändå inte att fördelarna med att byta upp sig (observera, jag skrev byta *upp* sig ) är så enorma.

Nä, herregud, det har jag verkligen aldrig hävdat, det vore ju otäckt om spridning var samma sak som kvalité (windows, IE, VHS you name it... )

Där kom det fram... Postgres (nu förkortade jag det rätt! ) är för snobbar och eliten!

Lättare, faktiskt. Bara packa upp arkivet - sen anger man login och lösen var gång som default.

Oroa dig inte - det är svårare att skriva effektiv SQL mot mysql än mot postgres eftersom inte mysql stöder alla delar av SQL-standarden. Med detta menas att inte alla smarta delar som förenklar ens utvecklarliv existerar i mysql - inte att mysql skulle köra någon alternativ syntax (möjlligtvis förutom själva skapandet av tabeller), till skillnad från M$ Access (som inte är en databas utan ett grafiskt skal för M$ Jet database eller vad tusan det heter...

Kanske, om möjligheten finns. Det är trots allt mycket enklare att skriva subselects än att skriva avancerade joins (vilket inte ens går i alla fall - ibland måste kombination göras med skapande av temporära tabeller och temporär överförelse av maaaaassor av data till dessa... *Brrrrr*...

Nä, vad tusan gör jag skrivandes lökiga inlägg på fyllan mitt i natten? Sleeping tajm it is!

Edit: glömde visst att stänga mina paranteser, men det pallar jag inte fixa...

Det mesta är detsamma, men det är några lustigheter man kan råka ut för. Språket MySQL använder sig av är en märklig reducerad SQL-dialekt med C-liknande inblandningar, men det är mest bara de här två sakerna man brukar kunna råka ut för:

1. I MySQL används "||" som synonym för "OR" och "CONCAT()" används för strängkonkatenering. I ANSI SQL används "||" för strängkonkatenering i stället.

2. MySQL använder C-kommentarer ("/* ... */" och "//"), men i ANSI SQL börjar kommentarer med "--".

Det mesta är faktiskt förvånansvärt enkelt att porta till Postgres - oftast är det bara funktionsanropen i middlewaren som behöver bytas ut. Men det finns faktiskt gott om PostgreSQL-relaterade tutorials också, och Postgres-dokumentationen är exemplarisk. Firebird är det däremot si och så med på den fronten.

I så fall är det lätt att ansluta sig till eliten! Men de riktigt förnäma kör väl bara Oracle antar jag...