[thorsell]

Hej!

Har ett litet problem, visar nedan..

Har tex. följande gästbokstabeller:

TABLE guestbook1 (
`mynick` varchar(20) NOT NULL default '',
`mynickId` mediumint(9) NOT NULL default '0',
`fromnick` varchar(20) NOT NULL default '',
`fromnickId` mediumint(9) NOT NULL default '0',
`message` longtext NOT NULL,
`time` int(15) NOT NULL default '0',
`id` mediumint(9) NOT NULL auto_increment,
PRIMARY KEY *(`id`),
KEY `mynick` (`mynick`),
KEY `mynickId` (`mynickId`)
);

TABLE guestbook2 (
`mynick` varchar(20) NOT NULL default '',
`mynickId` mediumint(9) NOT NULL default '0',
`fromnick` varchar(20) NOT NULL default '',
`fromnickId` mediumint(9) NOT NULL default '0',
`message` longtext NOT NULL,
`time` int(15) NOT NULL default '0',
`id` mediumint(9) NOT NULL auto_increment,
PRIMARY KEY *(`id`),
KEY `mynick` (`mynick`),
KEY `mynickId` (`mynickId`)
);

Vill nu göra en sk. trådning mellan skickade inlägg...
Inläggen är sparade i olika gästbokstabeller beroende på vilket medlemsnummer du har, vill nu göra en JOIN-SQL som visar inläggen skickade mellan två olika medlemmar i rätt "tidsordning" om ni förstår vad jag menar... Får banne mig inte rätt på det

Någon som kanske, kanske har lite tips eller helst av allt vad jag ska skriva

[eg0master]

varför har du två likadana tabeller? Dit liv skulle nog bli enklare om du hade allt i en tabell. Ser ingen anledning till att ha flera olika tabeller...

[thorsell]

Originally posted by eg0master@Oct 26 2006, 15:40
varför har du två likadana tabeller? Dit liv skulle nog bli enklare om du hade allt i en tabell. Ser ingen anledning till att ha flera olika tabeller...

Det går mycket snabbare att ha det så här, 1000 medlemmar / gästbokstabell .. den blir väldigt stor, väldigt snabbt annars om man har allt i ett.

[nosnaj]

Precis som eg0master säger borde nog allt ligga i samma tabell, en databas är gjort att kunna lagra många rader om man bygger upp den bra.

Sedan kan man fråga sig varför du sparar användarnamn i tabellen, sånnt ska vara i en separat tabell helt klart. Tänk om man ska ändra namn, då behöver du göra det på et ställe istället för dina x tabeller. Dessutom ska man undvika duplikat data.

Har du allt i en tabell blir frågan ganska trvilial om jag fattat frågan rätt. Att lista alla inlägg mellan två användare....

[thorsell]

Originally posted by nosnaj@Oct 26 2006, 16:12
Precis som eg0master säger borde nog allt ligga i samma tabell, en databas är gjort att kunna lagra många rader om man bygger upp den bra.
Sedan kan man fråga sig varför du sparar användarnamn i tabellen, sånnt ska vara i en separat tabell helt klart. Tänk om man ska ändra namn, då behöver du göra det på et ställe istället för dina x tabeller. Dessutom ska man undvika duplikat data.
Har du allt i en tabell blir frågan ganska trvilial om jag fattat frågan rätt. Att lista alla inlägg mellan två användare....

Jo, vet..
Men fick tipset att det är smart att lägga upp det så här när det är många medlemmar, tydligen är det att rekommendera (prestandamässigt)...
Då man inte alltid varit smartast i världen *erhm* på att utveckla databaser (enligt 3NF), så är det en gammal kvarleva tyvärr att upplägget blev så.. (lite dubletter får man räkna med )

Någon gång när tid finnes ska det optimeras, men i dagsläget tänkte jag bara om någon visste hur jag kopplar ihop till den frågan jag skrev överst här

[tartareandesire]

Kan bara instämma med föregående talare, du bör tänka igenom din design av databasen en ytterligare gång.

[eg0master]

Originally posted by thorsell@Oct 26 2006, 16:18
[...]
Men fick tipset att det är smart att lägga upp det så här när det är många medlemmar, tydligen är det att rekommendera (prestandamässigt)...
[...]
Någon gång när tid finnes ska det optimeras, men i dagsläget tänkte jag bara om någon visste hur jag kopplar ihop till den frågan jag skrev överst här

Som sagt, databaser är till för att hantera stora mängder data. Att dela upp det kan iofs vara en prestandavinst, men ett bra index gör sannolikt samma sak för dig, och utan problemen när du skall joina ihop data (eftersom du får allt i en tabell).

Och vad säger att det stannar vid bara två tabeller som skall slås ihop?

Nåväl, för att svar på din fråga skulle jag inserta allt relevant data till en temptabell och sedan jobba vidare på den. Det är nog det enklaste.

Alternativet är att använda sig av case satser för att hämta data, men det komemr bli hårigt. Jag skulle köra temptabeller iväntan på tabellstädning.

[mbomelin]

Eftersom mysql har en storage-metod som heter MERGE så varför inte använda den?
Jag gör liknande för mail, segmenterar det med ungefär 1milj mail per tabell och skapar sedan en MERGE-tabell som samlar ihop alla till 1 virtuell tabell.
De sökningar man ska göra där man vet vilken tabell det ligger i kan man ju göra direkt i rätt tabell, och övergripande sökningar i MERGE-tabellen.

Får väl tillägga att jag delar upp det i flera tabeller på grund av begränsning av datamängden i en myisam-tabell, och INTE på grund av prestandan. Fast det e klart att det går snabbare att leta i en tabell med 10.000 rader än i en med 6 miljoner rader oavsett hur bra man indexerat.

[grazzy]

Merge är väl främst till för att komma undan när filsystemet gnäller om för stora filer? Ett index sköter ju som tidigare postare har nämnt problemet ...

[mbomelin]

Läser du grundfrågan så handlar frågeställningen om hur han ska kunna söka igenom sina tabeller på ett enkelt sätt. Han har redan valt att partitionera till flera tabeller så att slå samman de till 1 antar jag inte är relevant.

EDIT: Du har delvis rätt, det är ett sätt att komma runt begränsningarna i os:et men även för att snabba upp applikationer och ett sätt att kunna sköta underhållet av sina tabeller på ett smidigare sätt.
T.ex. skapa en ny tabell per månad som ingår i mergen och istället för att gå in och söka o rensa gamla records kan du droppa en hel månad från mergen utan att alls behöva förändra något egentligt innehåll varken i tabeller eller i index. otroligt snabbt o smidigt.
Du kan reparera/optimera/analysera delar för sig så du slipper låsa hela skiten samtidigt.
Du kan lägga delar av mergen på olika diskar för att få ännu bättre hastigheten på grejerna.
Och som jag skrev tidigare, vet du vilken av tabell-delarna du har informationen i som du letar efter så slipper du söka igenom hela rasket. I vissa fall kan det handla om att man söker igenom 100.000 rader istället för åtskilliga miljarder. Och säga vad man vill men du uppnår inte samma hastighet oavsett hur bra index du har.