Lagre int[] i en cell?

[Techster]

Hei,

 

Jeg skulle gjerne kunne satt inn en verdi som dette: 5,67,10,599,45 i en celle.

Det lar seg tydeligvis ikke gjøre. Gjør jeg noe feil eller skal det ikke gå?

Noen tips?

[terjeelde]

Jeg skulle gjerne kunne satt inn en verdi som dette: 5,67,10,599,45 i en celle.

Det lar seg tydeligvis ikke gjøre. Gjør jeg noe feil eller skal det ikke gå?

Noen tips?

 

Tror tips nummer en er å fortelle hvilke database du bruker.

 

Noen databaser (PostgreSQL f.eks) støtter Arrays, mens andre gjør det ikke.

 

Hvordan du kan løse det i databasene som ikke støtter arrays spørs litt på hvordan du skal bruke data.

 

Du kan f.eks dra ut allt int'ene i en egen tabell?

 

Eller du kan pakke dem sammen i en binær-streng?

[blackbrrd]

Du kan jo, som terjeelde bruke datatype int[] i postgres

 

Nå kommer spørsmålet: hva skal du bruke dataene til. Hvis dette er en snedig måte å lagre en-til-mange forhold på vil jeg anbefale en annen framgangsmåte.

[Techster]

Det ligger ann til å bli Microsoft Sql Server.

 

Jeg skal bruke verdiene til følgende;

 

Har en tabell med objekter som klienter må ha bli gitt tilganger til å gjøre diverse handliger på.

 

Update,Read,Write,Download er handlingene.

 

Tanken er å sette in IDen som korresponderer med brukerene som har f.eks download rettigheter til et objekt i Download cellen til et gitt objekt.

Siden det er mange forskjellige brukere trenger jeg å kunne sette inn flere verdier i denne cellen.

 

 

Kanskje det fins en bedre måte å gjøre det hele på?

[kaffenils]

Nåvet jeg ikke detaljer om hvordan du bruker data du har i eksisterende tabeller, men basert på det lille du har fortalt vill jeg gjort noe slik.

 

Objekt(ObjektId int PK, ....)

Bruker(BrukerId int PK, BrukerNavn varchar(25),...)

Handling(HandlingId int PK, Handling varchar(25),...)

BrukerRettigheter(BrukerId int, ObjektId int, HandlingId int) --PK er alle kolonnene

 

Med dette designet kan du lett spørre på og oppdatere rettigheter.

[terjeelde]

Det ligger ann til å bli Microsoft Sql Server.

 

kaffenils svarer bra, så lite for meg å tilføye.

 

Er litt nyskjerrig dog... Hvorfor MS-SQL?

[Techster]

Det ligger ann til å bli Microsoft Sql Server.

 

kaffenils svarer bra, så lite for meg å tilføye.

 

Er litt nyskjerrig dog... Hvorfor MS-SQL?

 

Ja, det blir en løsning som han foreslår.

 

MS-SQL, ja si det. For øyeblikket er det det jeg har erfaring med og syns det funker greit.

Hvorfor noe annet?

[blackbrrd]

Fordi MS-SQL express ikke er gratis hvis du har større databaser enn x gb og vil bruke mer enn y antall prosessorer og z mengde ram.

 

(tror tallene er 4gb hdd, 1 prosessor og 1gb ram)

 

Hvis du skal kjøpe MS-SQL server som takler 2-4 prosessorer, 70gb database, 16gb ram osv så begynner det å koste rimelig mye.

 

Alternativet er da å f.eks bruke Postgres. http://www.postgresql.org/

Bruker postgres der jeg jobber og vi er veldig fornøyd valget vi gjorde for 6-7 år siden.

 

Utenom kostnadsspørsmålet så har jeg ikke noe imot MS-SQL. Vi portet faktisk applikasjonen vår fra MS-SQL til Postgres på 2-3 dager. (Mao er det ikke så stor forskjell fra applikasjonens side).

Endret 6. desember 2008 av blackbrrd

[Techster]

Fordi MS-SQL express ikke er gratis hvis du har større databaser enn x gb og vil bruke mer enn y antall prosessorer og z mengde ram.

 

(tror tallene er 4gb hdd, 1 prosessor og 1gb ram)

 

Hvis du skal kjøpe MS-SQL server som takler 2-4 prosessorer, 70gb database, 16gb ram osv så begynner det å koste rimelig mye.

 

Alternativet er da å f.eks bruke Postgres. http://www.postgresql.org/

Bruker postgres der jeg jobber og vi er veldig fornøyd valget vi gjorde for 6-7 år siden.

 

Utenom kostnadsspørsmålet så har jeg ikke noe imot MS-SQL. Vi portet faktisk applikasjonen vår fra MS-SQL til Postgres på 2-3 dager. (Mao er det ikke så stor forskjell fra applikasjonens side).

 

Ja, det koster.

 

Skal teste postgresql. Takk for info.

[terjeelde]

Alternativet er da å f.eks bruke Postgres. http://www.postgresql.org/

Bruker postgres der jeg jobber og vi er veldig fornøyd valget vi gjorde for 6-7 år siden.

 

Utenom kostnadsspørsmålet så har jeg ikke noe imot MS-SQL. Vi portet faktisk applikasjonen vår fra MS-SQL til Postgres på 2-3 dager. (Mao er det ikke så stor forskjell fra applikasjonens side).

 

Hadde lignende tanker når jeg kom med spørsmålet.

 

PostgreSQL var ikke spesielt å anbefale for windows for bare noen år siden, men har (vistnok) blitt veldig bra.

 

Har også fordelen av at det blir lett å flytte den over på en kraftig UNIX eller Linux-maskin ved behov osv.

[blackbrrd]

En av fordelene med linux når vi flyttet over til den plattformen var veldig bra 64 bits støtte, som igjen gjorde at vi kunne bruke mer enn 4gb ram uten et dyrt operativsystem.

 

Det skal ihvertfall være rimelig enkelt å teste postgres, tar 5 minutter å innstallere med pgadmin som admin verktøy.

[Techster]

Har lastet det ned, installert og testet PostgreSQL littegrann. (Hvordan uttaler man det forresten?).

 

Skal se hvordan det funker mot webservicen nå, og ser det er flere forskjellige klasser å bruke i .NET for å koble til PostgreSQL.

Noen bruker odbc mens andre bruker npgsql (http://pgfoundry.org/projects/npgsql/).

 

Noen formeninger om hva man bør velge?

[terjeelde]

Skal se hvordan det funker mot webservicen nå, og ser det er flere forskjellige klasser å bruke i .NET for å koble til PostgreSQL.

Noen bruker odbc mens andre bruker npgsql (http://pgfoundry.org/projects/npgsql/).

 

Noen formeninger om hva man bør velge?

 

ODBC for OLE DB-saker

npgsql for .NET-saker

[kaffenils]

PostgreSQL var ikke spesielt å anbefale for windows for bare noen år siden, men har (vistnok) blitt veldig bra.

 

Det finnes fortsatt bare 32bits utgave av Postgres til Windows. For små systemer er det forsåvidt greit, men å anbefale Postgres på Windows for store databaser høyt bruksmønster fører bare til problemer.

[terjeelde]

Det finnes fortsatt bare 32bits utgave av Postgres til Windows. For små systemer er det forsåvidt greit, men å anbefale Postgres på Windows for store databaser høyt bruksmønster fører bare til problemer.

 

Må si meg litt enig. Helt greit å kjøre på Windows for test, utvikling og mindre bruk. Blir det snakk om veldig store databaser, med veldig mye last, så er det greit å flytte den over på en UNIX eller Linux maskin.

 

Fortsatt enklere enn å f.eks utvikle mot MS-SQL, og så bytte til PostgreSQL på UNIX, og billigere enn å kjøpe "ekte" lisens på MS-SQL.

[blackbrrd]

PostgreSQL var ikke spesielt å anbefale for windows for bare noen år siden, men har (vistnok) blitt veldig bra.

 

Det finnes fortsatt bare 32bits utgave av Postgres til Windows. For små systemer er det forsåvidt greit, men å anbefale Postgres på Windows for store databaser høyt bruksmønster fører bare til problemer.

 

Er du sikker på dette? Tviler på at postgres bruker mer enn 2gb ram på vår server med 16gb ram. De siste 14gb-ene med ram blir brukt til disk-caching av linux.

 

Jeg ville nok heller ikke kjørt postgres i windows for noe annet enn lette applikasjoner eller utvikling.

Endret 7. desember 2008 av blackbrrd

[kaffenils]

Er du sikker på dette? Tviler på at postgres bruker mer enn 2gb ram på vår server med 16gb ram. De siste 14gb-ene med ram blir brukt til disk-caching av linux.

 

Hvis du har en dedikert databaseserver, en database på flere titalls GB hvor mye av dataene er i bruk regelmessig så hadde jeg blitt sjokkert hvis databasesystemet ikke cachet så mye som mulig i minnet. Hva er poenget med ubrukt RAM?

[terjeelde]

Hvis du har en dedikert databaseserver, en database på flere titalls GB hvor mye av dataene er i bruk regelmessig så hadde jeg blitt sjokkert hvis databasesystemet ikke cachet så mye som mulig i minnet. Hva er poenget med ubrukt RAM?

 

F.eks PostgreSQL cacher ikke. Det er OSets jobb egentlig. Bruker minne som arbeidsminne etc, men cacher ikke "så mye som mulig". Opp til OSet å passe på at de tingene som brukes ofte er i minne.

 

Tingen her ang. 32/64bits er at hvis du har 20GB på serveren, 64bits kjerne, og 32bits PostgreSQL, så kan det godt tenkes PostgreSQL utnytter hele de 20GB akkurat slik den ville om det var 64bits version, og fult ut.

[kaffenils]

F.eks PostgreSQL cacher ikke. Det er OSets jobb egentlig. Bruker minne som arbeidsminne etc, men cacher ikke "så mye som mulig". Opp til OSet å passe på at de tingene som brukes ofte er i minne.

 

Det virker jo helt ulogisk for et databasesystem. Nå har jeg aldri satt meg skikkelig inn i PostgreSQL konfigurering og tuning, men jeg vil anta at det ikke er veldig anderledes enn andre systemer, f.eks. MSSQL.

 

Hvis du har en dedikert databaseserver (som de aller fleste har) så konfigurere du PostgreSQL til å få så mye RAM som mulig. Selvfølgelig må du la det være nok igjen til at OSet kan kjøre skikkelig. Har du en server med 16GB RAM, og du vet at OSet trenger 1GB for å kjøre, så gir du 15GB til PostgreSQL.

 

PostgreSQL må da selv får styre hva som skal ligge i dette buffer cachet, og kun gi reaqd/write kommandoer til OSet. Det blir helt jo tullete om OSet skal ha algoritmer for hvilke datapages som skal inn/ut av buffer cachet som det har tildelt PostgreSQL. Da blir det i prinsippet umulig for utviklerene av PostgreSQL å forbedre bufferhåndteringsalgoritmene, da det er overlatt til OS. Dessuten er det livsviktig for ACID-kompabilitet at PostgreSQL selv styrer når en datapage skal skrives til disk.

 

Det eneste OSet skal gjøre er å ta imot read/write kommandoer fra PostgreSQL. Det skal absolutt ikke styre når det synes en datapage bør skrives til/leses fra disk.

 

Hvis du har tildelt PostgreSQL 15GB med RAM, så er det helt meningsløst å la noe av dette være ubrukt hvis det kan brukes til å holde deler av databasen i RAM.

[kaffenils]

Teorien min stemmer godt overens med denne artikkelen. Riktignok fra 2001, men prinsippet har nok ikke endret seg særlig mye.