Array i mysql

[mysjkin]

Jeg skal opprette en database i mysql hvor jeg lagrer måleresultater, blant annet et spektrum som består av 512 heltall som representerer hver sin kanal. Den teoretisk riktige måten å gjøre det på, blir jo å opprette en tabell spekter som

 

create table spekter(

spekterid serial,

kanalid integer,

kanalverdi integer

)

 

men, dette vil i neste runde føre til mer (unødvendig) kompliserte (og sannsynligvis tregere) spørringer når jeg skal hente ut data.

 

Hadde jeg hatt tilgang til postgresql på systemet jeg bruker, ville jeg ha definert et felt som en array:

 

create table spekter(

spekterid serial,

kanalverdi integer[512]

)

 

Finnes noe tilsvarende i mysql?

 

Alternativt kan jeg jo lage en tabell med 512 felter for kanalene

 

create table spekter(

spekterid serial,

kanal001 integer,

kanal002 integer,

...

kanal512 integer

)

 

men kan ikke si at jeg synes det ser så pent ut...

 

alternativt kan jeg stappe rådataene som kommer som tab-oppdelte tall fra en tekstfil rett inn i databasen,

 

create table spekter(

spekterid serial,

kanalverdi varchar(65000) // eller hva som blir nok til å lagre hele spekteret som tekst.

)

 

og så splitte opp dataene i applikasjonen.

 

Noen andre forslag / kommentarer? Jeg har lett etter array datatype i mysql dokumentasjonen (bruker v 5) men har ikke klart å finne noe.

 

M.

[laaknor]

men, dette vil i neste runde føre til mer (unødvendig) kompliserte (og sannsynligvis tregere) spørringer når jeg skal hente ut data.

 

Mer komplekse - trolig, men definitivt ikke tregere. Det vil gå mye kjappere dersom du lager indexene dine riktig.

[siDDis]

Lag en ekstra tabell som referer til hovedtabellen.

 

Feks:

 

create table spekter(

spekterid INTEGER AUTO_INCREMENT,

kanalid integer,

FOREIGN KEY (kanalid) REFERENCES kanal(id)

)

 

 

create table kanal(

id INTEGER,

value integer,

value_number integer

)

[___]

Hmmm... Jeg ville kanskje gått for den mest teoretisk riktige måten å gjøre det på. Jeg tror du skal se på det alternativet først. Lag et lite program som pøser masse dummydata inn i tabellstrukturen, og gi det et forsøk. Regn med litt tuning av indekser. Den enkleste metoden er ofte den beste, og man skal ikke kimse av RDBMS, som jo er über-optimert for slike oppgaver.

 

Et annet alternativ ville jo vært å ha et varchar-felt med tilstrekkelig lengde, og lagre rådataene som semikolonseparerte verdier. Så kunne du laget en SQL-funksjon som trekker ut den verdien du er interessert i. På den måten hadde du ikke trengt å dra hele strengen til applikasjonen din. Men om det sistnevnte er mulig ennå i MySQL aner jeg ikke.

 

Werner

[mysjkin]

ja,jo, kanskje det er tingen allikevel, men, jeg sa det kanskje ikke tydelig nok i første post, jeg vil aldri være interessert i enkeltverdier, jeg vil alltid hente ut hele spekteret (alle kanaler for en gitt måling) og har litt vondt for å tro at det er raskere å hente ut 512 rader enn en stor rad...

 

(Men det er jo bare å teste... * Bretter opp ermene * )

 

M.

[kaffenils]

Hvis du alltid er interessert i alle kanalverdiene vil det selvsagt være mer effektivt, rent ytelsesmessig, med en rad pr. spekterid. Du kan f.eks. lagre dem i en eller annen binær datatype. Hvis hver kanalverdi er av type INT så kan du f.eks. lagre alle 512 verdiene i en BINARY(2048). Ulempen er at designet er veldig lite dynamisk hvis du skulle ønske å utvide til flere kanaler, eller lagre mer data for hver kanalid.

 

Av erfaring vet jeg at selv noen (f.eks. produkteier) påstår at antall kanaler ALLTID vil være 512 og det ALLTID er heltall som skal lagres osv, så stemmer dessverre ikke dette. Om noen år kan du regne med at vedkommende kommer krypende og ber om endringer. Av den grunn er det best å ha et design som er mest mulig normalisert, selv om normalisert ikke nødvendigvis alltid er synonymt med høyest mulig hastighet.

[Manfred]

Litt avhengig av hva slags system man lager vil det alltid være om å gjøre å finne den gyldne middelvei mellom ytelse og normalisering... de går sjelden hånd i hånd...