[MYSQL] 4 queries naast elkaar zetten

[0fbe]

Beste Forumers

Ik ben bezig met een query waar ik niet uit kom, ook niet met google:

Mijn tabel:

code:

| ZendingID | LogtagID | Time | Temp | RH |
|        1  |        1 |  xxx | 18.9 | 50 |
|        1  |        2 |  xxx | 20.0 | 60 |
enz.

Nu kan ik de individuele records opzoeken met

SQL:

SELECT *
FROM templog
WHERE ZendingID = '1'
AND LogtagID = '1'

en

SQL:

SELECT *
FROM templog
WHERE ZendingID = '1'
AND LogtagID = '2'

Wat ik echter graag als output wil is het volgende, waarbij op de Time gejoind word:

code:

| ZendingID | Time | Temp1 | Temp2 | RH1 | RH2 | 
|        1  | xxx  | 18.9  | 20.0  | 50  | 60  |

Ik kan de 2 queries wel samen voegen dmv UNION maar hierbij worden ze onder elkaar gezet. Is mijn probleem op te lossen met MYSQL? Of moet ik hiervoor naar PHP (wat veel performance kost)

In het voorbeeld heb ik 2 queries gebruikt, maar uiteindelijk moet het mogelijk zijn met maximaal 4 (dezelfde queries)

[ Voor 6% gewijzigd door 0fbe op 19-05-2007 16:04 ]

[rickmans]

De oplossing staat hier al een beetje genoemd imho: [SQL] 2 gegevens uit zelfde tabel adhv ID uit andere tabel

[0fbe]

rickmans schreef op zaterdag 19 mei 2007 @ 16:44:
De oplossing staat hier al een beetje genoemd imho: [SQL] 2 gegevens uit zelfde tabel adhv ID uit andere tabel

Sorry maar met die oplossing kom ik er niet uit.

Hoezo een alias gebruiken?

Ik heb nu dit:

SQL:

SELECT templog.Time AS Time2, templog.Temp AS T2, templog.Temp, templog.LogtagID, templog.LogtagID AS LogtagID2
FROM templog
WHERE Time = Time

Maar dat werkt niet: Ik krijg nog steeds alle rijen terug, niet de helft.

[ Voor 14% gewijzigd door 0fbe op 19-05-2007 17:08 ]

[Verwijderd]

SQL:

SELECT
   tbl1.ZendingID
   tbl1.Time,
   tbl1.Temp AS Temp1,
   tbl2.Temp AS Temp2,
   tbl1.RH AS RH1,
   tbl2.RH AS RH2
FROM
   tbl AS tbl1
   INNER JOIN tbl AS tbl2 ON(
      tbl1.ZendingID = tbl2.ZendingID
   )
WHERE
   tbl1.ZendingID = 1

[0fbe]

^^ Bedankt, ik wil alleen joinen op Time maar dat is een kleinigheidje. Zelf had ik dmv table alias het volgende bedacht, maar efficient is het niet.

SQL:

SELECT templog.ZendingID, templog.Time, templog.Temp, templog2.Temp, templog.RH, templog2.RH
FROM templog AS templog2, templog
WHERE templog2.Time = templog.Time
AND templog2.LogtagID <> templog.LogtagID

Edit bovenstaande code werkt toch ook niet,

De code van Cheatah geeft 4x resultaten weer ipv 1x.

Edit:
Heb nu het volgende: Het werkt probleem is dat het over ruim 7000 rows niet bepaald snel is (resultaat is dus de helft 3500 rows)

SQL:

SELECT DISTINCT templog.ZendingID, templog.Time, templog.Temp, templog2.Temp AS Temp2, templog.RH, templog2.RH AS RH2
FROM templog AS templog2, templog
WHERE templog2.Time = templog.Time
AND templog2.LogtagID <> templog.LogtagID
AND templog.ZendingID = '1'

[ Voor 41% gewijzigd door 0fbe op 19-05-2007 17:39 ]

[0fbe]

Sterker nog de query duurt langer dan 60 seconden (1 m 47.95 s), eens kijken of ik wat anders kan verzinnen want dit gaat niet werken.

[ Voor 5% gewijzigd door 0fbe op 19-05-2007 18:39 ]

[Verwijderd]

Zet 's een index op dat Time veld, daar wordt je database blij van en 't zal een hoop tijd schelen...

[0fbe]

Verwijderd schreef op zaterdag 19 mei 2007 @ 19:13:
Zet 's een index op dat Time veld, daar wordt je database blij van en 't zal een hoop tijd schelen...

Kan niet, Time is niet uniek (hij kan 4x per waarde voorkomen)

[rickmans]

timcooijmans schreef op zaterdag 19 mei 2007 @ 19:34:
[...]

Kan niet, Time is niet uniek (hij kan 4x per waarde voorkomen)

een gewone key vereist ook niet dat de values in de key zelf uniek zijn. Bij een primary of unique key is dat wel het geval .

[0fbe]

rickmans schreef op zaterdag 19 mei 2007 @ 20:15:
[...]

een gewone key vereist ook niet dat de values in de key zelf uniek zijn. Bij een primary of unique key is dat wel het geval .

Sorry je had inderdaad gelijk, een index op Time geeft me nog steeds een tijd van 1 m 43.41 s.

[Verwijderd]

timcooijmans, lees je eens in over primary keys, foreign keys en indexen. Indices hoeven helemaal niks met je PK's of FK's te maken te hebben, maar als je ze goed kiest kunnen ze je performance gigantisch verbeteren!

Edit: Doe 's een EXPLAIN op die query?
Ik ben geen MySQL kenner (MSSQL en InterBase is meer mijn terrein), maar er zitten hier een hoop MySQL guru's.

[ Voor 26% gewijzigd door Verwijderd op 19-05-2007 20:50 ]

[Gwaihir]

Zet er even EXPLAIN voor en je kunt zien hoe 't komt

[0fbe]

Birdie schreef op zaterdag 19 mei 2007 @ 20:47:
Zet er even EXPLAIN voor en je kunt zien hoe 't komt

Had ik al gedaan:

code:

+----+-------------+----------+------+---------------+------+---------+------+------+-----------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra           |
+----+-------------+----------+------+---------------+------+---------+------+------+-----------------+
|  1 | SIMPLE      | templog2 | ALL  | NULL          | NULL | NULL    | NULL | 7854 | Using temporary |
|  1 | SIMPLE      | templog  | ALL  | NULL          | NULL | NULL    | NULL | 7854 | Using where     |
+----+-------------+----------+------+---------------+------+---------+------+------+-----------------+

Dit is mét index, daarom zag ik het nut van een index ook al niet

[BikkelZ]

Hoe is de exacte structuur van die tabel? Kun je er een SQL dumpje van laten zien?

[0fbe]

BikkelZ schreef op zaterdag 19 mei 2007 @ 21:35:
Hoe is de exacte structuur van die tabel? Kun je er een SQL dumpje van laten zien?

SQL:

`templog` (
  `ZendingID` int(11) NOT NULL,
  `LogtagID` int(11) NOT NULL,
  `Time` datetime NOT NULL,
  `Temp` varchar(5) collate latin1_general_ci NOT NULL,
  `RH` varchar(5) collate latin1_general_ci default NULL,
  KEY `Time` (`Time`)
)

Temp en RH zijn varchar omdat er ook waardes net zoals 'MARK' kunnen voorkomen

[user109731]

timcooijmans schreef op zaterdag 19 mei 2007 @ 21:00:

code:

+----+-------------+----------+------+---------------+------+---------+------+------+-----------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra           |
+----+-------------+----------+------+---------------+------+---------+------+------+-----------------+
|  1 | SIMPLE      | templog2 | ALL  | NULL          | NULL | NULL    | NULL | 7854 | Using temporary |
|  1 | SIMPLE      | templog  | ALL  | NULL          | NULL | NULL    | NULL | 7854 | Using where     |
+----+-------------+----------+------+---------------+------+---------+------+------+-----------------+

Dit is mét index, daarom zag ik het nut van een index ook al niet

MySQL gebruikt geen index nu... Die hoort dan volgens mij iig onder possible_keys en key te staan. Wat geeft SHOW INDEX FROM table?

Probeer dus eerst die index goed te krijgen, dat lijkt mij het grootste probleem nu

[ Voor 4% gewijzigd door user109731 op 19-05-2007 22:02 ]

[Voutloos]

timcooijmans schreef op zaterdag 19 mei 2007 @ 17:21:
Heb nu het volgende: Het werkt probleem is dat het over ruim 7000 rows niet bepaald snel is (resultaat is dus de helft 3500 rows)

SQL:

SELECT DISTINCT templog.ZendingID, templog.Time, templog.Temp, templog2.Temp AS Temp2, templog.RH, templog2.RH AS RH2
FROM templog AS templog2, templog
WHERE templog2.Time = templog.Time
AND templog2.LogtagID <> templog.LogtagID
AND templog.ZendingID = '1'

templog2.Time = templog.Time hoort in een ON clause.

Zodra een index gebruikt kan worden, is het wellicht interessant om de performance met een index als (ZendingID, Time) of (Time, ZendingID) te proberen.

timcooijmans schreef op zaterdag 19 mei 2007 @ 21:49:
Temp en RH zijn varchar omdat er ook waardes net zoals 'MARK' kunnen voorkomen

Het af toe voorkomen van een waarde welke 1 karakter korter is is een slechte reden om varchar te gebruiken. Tenzij in het gros van de rijen echt korte strings staat, meteen omzetten naar char(5) en voila, een constante row length.

Verder nog een klein puntje: om waardes van kolommen welke int zijn hoeven geen quotes.