Hei, jeg er ikkje veldig erfaren innen MySQL eller andre relasjonsdatabaser bortsett fra at jeg vet hvordan jeg bruker basic queries som SELECT, INSERT, UPDATE, DELETE, CREATE... osv. Men jeg har støtt på et litt mer avansert problem, der jeg har behov for en query som er litt mer avansert enn hva de basic kunnskapene mine kan lage. Eller jeg kan gjøre det med 16 enkle queries eller 8 mer avanserte. Men for å gjøre vedlikeholdet enklest mulig samt minst mulig scripting så håper jeg dere freaker kan bistå med å skrive et eksempel jeg kan bruke til å forstå hvordan dette foregår. Jeg har "tegnet" et eksempel på en relasjonsmodel i MySQL workbench, med 3 tabeller. Selve problemet jeg har består av 8 tabeller, men prinsippet er det samme, og jeg har jo ikkje tenkt å la dere freaker gjøre arbeidet for meg, alt jeg trenger er bare en veiledning i riktig retning.

Modellen ser slik ut:
http://i.imgur.com/VCTXOiY.png

Slik jeg ser det, så må dette gjøres med 6-8 queries:

1. SELECT'e data fra tabel1 og kontrollere om den finnes fra før.
2. Hvis data'en ikkje finnes INSERT'e data.
3. Hvis data'en ble INSERT'et: SELECT'e id'en.
4. SELECT'e data fra tabel2 og kontrollere om den finnes fra før.
5. Hvis data'en ikkje finnes INSERTE'e data.
6. Hvis data'en ble INSERT'et: SELECT'e id'en
7. SELECT'e data fra tabel3 og kontrollere om den finnes fra før.
8. Hvis data'en ikkje finnes INSERT'e data og bruke id'er fra steg 1 | 3 og 4 | 6.

Men det må finnes en enklere måte å gjøre dette på?

Sikkert et dumt spørsmål, men vil LAST_INSERT_ID () skille sesjonene fra hverandre? Slik at hvis to klienter INSERT'er data på samme tid at databasen kan skille disse?

My bad, det er InnoDB som brukes.

Ah, nei, jeg mener skjemaet ditt, ikke engine - de faktiske tabellene eller noe som likner. "Tabell1, data1" osv. blir så abstrakt at det er vanskelig å se noen forbedringsområder.

Når det gjelder LAST_INSERT_ID sier manualen at den er pålitelig per connection, så ja, du skal kunne stole på denne.

Høres ut som en perfekt plass å bruke transactions. INSERT IF NOT EXISTS er også noe som kan brukes for å kombinere 2 spørringer.

selvfølgelig, men 2 spørringer ødelegger ikke skalerbarheten noe særlig når de ikke inneholder mye joins eller sub-queries. (som er de to tingene som man må være forsiktig med). Det som ofte tar tid er å parse query-strengene - men dette kan man også unngå ved å bruker prepared statements på en ordentlig måte.

Så i mine øyne er det lesbarheten som her er viktigst

Nei, nei, var ikke noe sånt - ble mer interessert i hvordan en SQL parser ville håndtere det. Og ja, ser ut til at du har rett; det ser ut til å bli kjørt to spørringer.

0xFF ettersom du (hvertfall virker) som ganske kunnskapsrik så er jeg redd for å fornærme deg hvis jeg sier noe åpenbart, men men


Når det kommer til å gjøre det enklere så prøvde jeg meg litt fram, men kom ikke opp med noe som var enklere, men dette er i sammenheng med DRY og du ikke har lyst til å ha det i kodebasen så kan vel en SQL-procedure være 'løsningen'?

Nei, det må du ikkje være redd for. Relasjons databaser er ikkje min sterke sider som jeg skrev i første posten. Jeg har brukt MySQL en del, men dette bare i enklere sammenhenger der jeg har klart meg med enkle queries.

Jeg har følt med i denne tråden og gjort litt research, selv om jeg ikkje har svart i tråden. Men jeg setter stor pris på alle input som kommer her.