MySQL: hjälp med WHERE IN sats

Kan man verkligen göra sub-SELECTs i MySQL?

Tjenare

Nu är jag ju inte någon gud på SQL själv, men har suttit litta och pillat med de i skolan iaf.

Men i din subfråga så försöker du anropa en tabell jag inte kan hitta i dina tabeller (sasong_deltagan) den ger du aliaset D som sen används i select satsen --> blir fel på bägge ställena

summa summarum, kolla så de stämmer med sasong_deltagan

Sen att MySql inte skulle klara av subfrågor tycker jag verkar konstigt, klarar access av det måste ju MySql göra det också ;P

$denna_sasong = "1";
$spelarna = mysql_query("	SELECT s.*
				FROM spelarna s
				WHERE spelar_id IN
						(	SELECT d.spelar_id
							FROM sasong_deltagan d
							WHERE sasong_id = $denna_sasong
										)
						")		
				or die(mysql_error());

# Dump of table sasonger
# ------------------------------

CREATE TABLE `sasonger` (
  `sasong_id` smallint(6) NOT NULL auto_increment,
  `ute_inne` varchar(5) NOT NULL default 'ute',
  `period` varchar(10) NOT NULL default '2003',
  PRIMARY KEY  (`sasong_id`)
) TYPE=MyISAM;



# Dump of table spelarna
# ------------------------------

CREATE TABLE `spelarna` (
  `spelar_id` tinyint(4) NOT NULL auto_increment,
  `f_namn` varchar(20) NOT NULL default '',
  `e_namn` varchar(20) NOT NULL default '',
  `smeknamn` varchar(20) NOT NULL default '',
  `registrerad` timestamp(14) NOT NULL,
  `senast_andrad` timestamp(14) NOT NULL,
  `epost` varchar(40) default NULL,
  `icq` varchar(20) default NULL,
  `adress` varchar(50) default 'NULL',
  `post_nr` varchar(8) default 'NULL',
  `post_ort` varchar(25) default 'NULL',
  `h_tel` varchar(15) default NULL,
  `m_tel` varchar(15) default NULL,
  `vikt` tinyint(4) default '0',
  `langd` smallint(6) default '0',
  `p_nr` varchar(15) default 'NULL',
  `presentation` text,
  `kommentar` text,
  `bild_url` varchar(80) default 'NULL',
  PRIMARY KEY  (`spelar_id`)
) TYPE=MyISAM;

Ur MySQL-manualen:

Det finns _mycket_ som MySQL inte klarar. Närmare bestämt saknas runt 60% av de funktioner som SQL92 specificerar, om jag inte missminner mig alldeles...

SELECT s.*
			FROM spelarna s, sasong_deltagan d
			WHERE s.spelar_id = d.spelar_id
				AND sasong_id = 1

Det man kan utläsa av MySQL-manualen är att man alltså inte kan ha nästlade satser i SELECT-satser om man kör MySQL 4.0. Kan ju vara det som ställer till det...

Precis... börjar du kanske ana varför jag skyr MySQL som pesten?

Antar att de flesta som använder MySQL kör med rätt raka INSERT, UPDATE, DELETE och SELECT för att hantera webb-innehåll. Och då funkar det ju super.
Lite synd att inte PostgreSQL är lika spritt hos webbhotell och liknande. Där finns det större möjligheter har jag förstått.

Nu är jag ju som sagt inte så oerhört insatt i det här med SQL än, men jag har alltid fått förklarat för mig av alla som hållt på med databaser tidigare at MySQL är en väldigt kompetent databashanterare och att den ska klara det mesta.

Men det kanske är fel då?

Vad skulle ni rekommendera för en person som är beredd att lägga ner en del tid på att lära sig nått nytt bara det funkar så bra som det bara är möjligt?

MySQL är som sagt väldigt etablerad hos webbhotell mm, så det är nog inte fel att sätta sig in i hur det fungerar. Man kan väl säga att det allra mesta av det du lär dig om MySQL är relevant även för andra databassystem.

Och jag tror ändå att man klarar sig väldigt långt med MySQL. Det kanske lät lite som att det bara är hemmapulare som använder MySQL, men så är det ju inte.

Vad tänkte du använda det till?

Just nu handlar det mest om egna småprojekt för att lära sig det hela bättre.
Sitter och pular lite med ett... ja intranät kan man nog kalla det... Lite medlemsregister, grupper, gemensamma scheman, salbokningar osv.

Har tidigare varit med och arbetat med saker såsom Yamborii.net och det byggde vi på PHP och MySQL och har inte haft några problem med det hela, blev därför något överraskad när det sablades ner här tidigare i tråden. Där kodade jag inte utan höll mig till att skriva kravspecifikationerna till många av funktionerna så jag har inte haft möjlighet att bilda mig en egen uppfattning om det hela än.

Man klarar sig som HL säger faktiskt långt med MySQL, men det är lite på gränsen till masochism att använda MySQL till mer avancerade saker. För enkla applikationer som gästböcker, bloggar, enklare webbforum och liknande går man ju i stort sett aldrig bortom enklare databaser med ett lågt antal tabeller, och SQL-satserna är triviala historier som bara håller sig till ett fåtal rader. Till sådant duger MySQL bara fint, och i de fallen är det knappast lönt att byta till något annat.

Problemet uppstår när man behöver göra mer avancerade saker, t.ex. om man har en ganska omfattande applikation (kan t.ex. vara ett större order- eller bokningssystem) med många tabeller som ska kopplas samman på alla möjliga sätt och om man dessutom vill ha statistik på alltihop. Eftersom MySQL bland annat saknar vyer, sekvenser och ordentliga implementationer av transaktioner och nästlade SQL-satser blir det massor av extraarbete för utvecklaren. Dels måste man till med en massa osnygga workarounds i själva applikationen för att kompensera för databasens tillkortakommanden, och dels har man kraftigt begränsade möjligheter att dela upp über-komplicerade SQL-satser i hanterbara delar.

Sedan har ju MySQL lite andra roligheter för sig och deras implementation av SQL-standarden ger mig obehagliga pyttemjuk-vibbar ibland, men det är mer en religiös fråga tror jag. Låt oss bara säga att jag inte riktigt delar MySQL-teamets uppfattning om hur trasiga SQL-satser en databashanterare ska tolerera utan att protestera

Bästa alternativet om du är seriöst intresserad av en mer avancerad databas (och inte har 100 papp som du absolut vill bli av med) är enligt mig PostgreSQL. Spelar lite mer i samma liga som t.ex. Oracle och andra kommersiella "värstingdatabaser", men eftersom den är fri programvara är PostgreSQL _något_ billigare. Den kräver dock lite mer av dig som användare. Dels är SQL-implementationen gjord för att följa SQL92-specarna, och är av den anledningen inte alls lika förlåtande som MySQL. Det innebär att man t.ex. inte får använda kolumnalias i WHERE-satser eller blanda datatyper hur som helst i UNION-satser. Dels behövs manuell konfigurering för att få optimala prestanda - t.ex. ska man helst ställa in hur mycket fysiskt minne som ska reserveras (tabellerna ska helst rymmas helt och hållet i internminnet för att man ska slippa swappningar) och eftersom "garbage collection" inte görs automatiskt är det en bra idé lägga in en VACUUM-operation som ett nattligt cronjobb. Just konfigurationsbiten brukar folk ofta missa, men den är viktig om man vill få så bra prestanda som möjligt.

Eller så trotsar du både mysql och postresql och kör på lite hottare teknologier som http://www.sqlite.org/ !!

samt för det språk du jobbar med: http://cvs.hwaci.com/sqlite/wiki?p=SqliteWrappers

Verkar rätt intressant, även om man kan säga ett och annat om tillförlitlighetsgraden på prestandatesterna de visade. SQL-implementationen verkar ju rätt ok, fortfarande lite ofullständig men utvecklarna verkar ju ha ambitionen att fixa det framöver. Nyfiken som jag är måste jag ta och provköra lite när jag får tid...

Någon som vet hur pass bra SQLite skalar när antalet samtidiga användare ökar? Är den hyfsat linjär som PostgreSQL eller är det mer åt tvärdö-vid-givet-antal-anslutningar-hållet (à la MySQL )?

Beror ju helt på HUR mycket du tänker att det ska klara.

Mycket har ju att göra med hur man modellerar upp och använder sig av databasen. Med många cache lager skulle jag vilja säga att vilken databas som helst klarar "aftonbladet" trafik.

T.ex. polopoly som dn.se kör på har en stackars mysql i bakgrunden. så...

Om du nu vill ha något skalbart ska du titta på ZODB! en objekt orienterad databas som helt utan extra ansträngning kan distribueras på flera maskiner, även remote!! www.zope.org (finns under products).. (stora delar av zope baseras på ZODB så du har gott om bra kod att använda)!!