Jobb database med SQL

[DanOve]

etter mye oppdrag på jobben så har det blitt mye rot.

bortglemte jobber. forvirring +++++

 

Jeg skal prøve å lage en database som holder orden på ting.

man må kunne legge inn en jobb, redigere jobb, ferdigstille den osv.

 

Bruker grensesnittet tenkte jeg skulle være en webside.

 

dette er mitt førsteforsøk på noe slikt, lurer på om noen vet om noen guider og slikt på dette.

 

hvordan å få ting fra websiden og inn i DB, søkemuligheter raporter og slikt.

 

det jeg har av programvare er DreamWaver, hva annet trenger jeg.

[Dryper]

Her har du et skript jeg mekka til deg det funker greit. men designet er ikke helt til å skryte av..

 

Noe lignende dette du ville ha?

dan.zip

Endret 29. juni 2008 av Dryper

[blackbrrd]

Dryper:

Hvorfor MyISAM? Da er jo ikke databasen ACID compliant og kan bli korrupt ved hardware/software kræsj, strømbrudd*, etc...

 

Hvorfor ikke bruke prepared statements så du slipper muligheter for SQL-injection?

 

Utenom det så synes jeg det var hyggelig av deg å gi DanOve et enkelt eksempel å forholde seg til.

 

*Å ikke ha UPS når du har endel brukere er ikke spesiellt smart, spesiellt hvis du f.eks bor i Kongsberg.

Endret 29. juni 2008 av blackbrrd

[Dryper]

Dryper:

Hvorfor MyISAM? Da er jo ikke databasen ACID compliant og kan bli korrupt ved hardware/software kræsj, strømbrudd*, etc...

 

Hvorfor ikke bruke prepared statements så du slipper muligheter for SQL-injection?

 

Utenom det så synes jeg det var hyggelig av deg å gi DanOve et enkelt eksempel å forholde seg til.

 

*Å ikke ha UPS når du har endel brukere er ikke spesiellt smart, spesiellt hvis du f.eks bor i Kongsberg.

 

Aldrig hatt problemer med det

og når det gjelder SQL injection så er vel det strengt talt ikke vits i dette tilfelle?

 

Med mindre han skal hacke seg selv da

 

Jeg forstod det slik at dette bare skulle være lokalt på pcen?

 

 

Ellers så funker det fett (Er sikkert mye som kan forbedres , men dette er da hva jeg klarer på 10-15 min.

Endret 29. juni 2008 av Dryper

[DanOve]

Her har du et skript jeg mekka til deg det funker greit. men designet er ikke helt til å skryte av..

 

Noe lignende dette du ville ha?

 

 

aaaaaahhhhh gull... dette er supert.

da kan jeg lære av det du har gjort å bygge videre på det

hadde tenkt meg mere avanserte greier men dette er en grei start.

var liksom det jeg lurte på hvordan man fikk teksta inn i en database,

så nå kjønner jeg mere.

NYDELIG

 

da er det bare å få den til å fungere på webserveren min.

har plass hos one.com

 

tusen takk

Endret 30. juni 2008 av DanOve

[DanOve]

tingen er at jeg har masse kunder.

jeg må holde styr på hva jeg har fått å gjøre ellers så blir det glemt.

Gule PostIt er liksom ikke til å stole på i lengden.

glemmer jeg en kunde så går denne til en annen en.

 

Jeg ville også ha en database som også inneholder kunde info adresse tlf +++++

tror det blir en egen database.

 

så skal jeg da ha jobber også interigret i denne.

så når jeg klikker på kunden så kan jeg se historikken der. hva jeg har gjort hos han.

 

hvis du kjønner gangen.

 

denne databasen kommer til å ligge hos one.com så mine ansatte kan finne den fram hvor enn de er. bare med nett tilgang.

 

tenkte på MySQL først men hva er MyISAM for noe

[blackbrrd]

MySQL kan kjøres med to motorer i bunn: MyISAM og og InnoDB.

 

MyISAM er kjapp, men mangler bl.a. transaksjoner, er ikke ACID compliant (du kan få en korrupt database hvis databasen kræsjer, os-et kræsjer, maskinen kræsjer eller f.eks strømmen går).

 

InnoDB er litt tregere enn MyISAM men har støtte for transaksjoner*, foreign keys** og er ACID compliant såvidt jeg vet om.

 

Jeg ville aldri ha kjørt MyISAM som databasemotor hvis dataene er såpass viktige at jeg tar backup av dem.

 

*)En transaksjon lar deg gjøre flere operasjoner mot databasen som en transaksjon. Hvis en av operasjonene feiler, feiler alle operasjonene.

 

Dette er f.eks nyttig hvis du skal importere en fil med data. La oss si at du skal sette inn 100 rader inn i en tabell og databasen kræsjer etter at du har lagt inn 38 av dem. Hvis du har kjørt dette i en transaksjon vil du kunne importere filen på nytt igjen når databasen kommer opp igjen. Hvis du har brukt MyISAM så må du finne ut hvor mye av filen som er blitt lagt inn i databasen, og så importere resten.

 

Ved å bruke transaksjoner sørger du for at dataene som ligger i databasen er konsistente.

 

**) Foreign keys gjør at du f.eks kan ha to tabeller, kunde og oppdrag. I oppdrag-tabellen har du en referanse til en rad i kunde-tabellen. Det vil ikke være mulig å slette en kunde som er referert til av ett oppdrag, eller legge inn et oppdrag som referer til en kunde som ikke eksisterer. Uten foreign keys så vil du måtte ta hånd om dette i applikasjonen. Hvis du gjør en feil i applikasjonen så kan du ende opp med f.eks å ha oppdrag som referer til kunder som ikke eksisterer fordi du ved en feiltakelse slettet kunden...

[DanOve]

MySQL kan kjøres med to motorer i bunn: MyISAM og og InnoDB.

 

MyISAM er kjapp, men mangler bl.a. transaksjoner, er ikke ACID compliant (du kan få en korrupt database hvis databasen kræsjer, os-et kræsjer, maskinen kræsjer eller f.eks strømmen går).

 

InnoDB er litt tregere enn MyISAM men har støtte for transaksjoner*, foreign keys** og er ACID compliant såvidt jeg vet om.

 

Jeg ville aldri ha kjørt MyISAM som databasemotor hvis dataene er såpass viktige at jeg tar backup av dem.

 

*)En transaksjon lar deg gjøre flere operasjoner mot databasen som en transaksjon. Hvis en av operasjonene feiler, feiler alle operasjonene.

 

Dette er f.eks nyttig hvis du skal importere en fil med data. La oss si at du skal sette inn 100 rader inn i en tabell og databasen kræsjer etter at du har lagt inn 38 av dem. Hvis du har kjørt dette i en transaksjon vil du kunne importere filen på nytt igjen når databasen kommer opp igjen. Hvis du har brukt MyISAM så må du finne ut hvor mye av filen som er blitt lagt inn i databasen, og så importere resten.

 

Ved å bruke transaksjoner sørger du for at dataene som ligger i databasen er konsistente.

 

**) Foreign keys gjør at du f.eks kan ha to tabeller, kunde og oppdrag. I oppdrag-tabellen har du en referanse til en rad i kunde-tabellen. Det vil ikke være mulig å slette en kunde som er referert til av ett oppdrag, eller legge inn et oppdrag som referer til en kunde som ikke eksisterer. Uten foreign keys så vil du måtte ta hånd om dette i applikasjonen. Hvis du gjør en feil i applikasjonen så kan du ende opp med f.eks å ha oppdrag som referer til kunder som ikke eksisterer fordi du ved en feiltakelse slettet kunden...

 

da er det InnoDB jeg er ute etter da. for databasene kommer til å linke til hverandre.

ikke vondt ment Dryper at jeg ikke vil ha basen din men trot InnoDB funker bedre i dette tilfellet.

 

tror jeg ender opp med 4 DB. en kunde. 2 jobb og en Ansatt.

vet ikke hvordan jeg løser det med at jeg har 2 forkjellige avdelninger og jobbene skal være skilt men alikevel komme fram i den samme DB.

 

hvordan er det man bytter om fra MyISAM til InnoDB.

jeg er ikke ute etter at dere skal gjøre dette for meg. har lyst til å lære selv,

men hjelp til selv-hjelp er fint

Endret 30. juni 2008 av DanOve

[DanOve]

da har jeg laget et lite bruker grensesnitt.

vet ikke om jeg gjør det riktig.

jobblogg.zip

[blackbrrd]

bytt ut ENGINE=MyISAM med ENGINE=InnoDB

 

PS: du snakker om forskjellige databaser, antar du mener forskjellige tabeller. Det er ingen SQL-standard (såvidt jeg vet) som sier at det skal være mulig å kjøre spørringer på kryss av databaser.

 

Hvis du har to forskjellige jobb-typer kan du f.eks lage en jobb-tabell og en jobb-type-tabell. Du lager så en foreign key i jobb-tabellen som peker på primary key-en i jobb-type-tabellen.

 

Jeg hadde forresten ikke laget tabellnavn med mellomrom i. Det er vanlig å bruke _ istedetfor mellomrom. Jeg hadde også unngått store bokstaver og kun brukt små bokstaver på tabeller/kolonner. Da slipper du å skrive `` rundt hvert eneste tabell/kolonnenavn...

[Dryper]

Det du kan gjøre er å bruke bare 1 fil, isteden for å ha 100vis av små filer

 

<?
$side = $_GET['side'];

if($side == "hoved"){ //Hoved siden din

}elseif($side == "1"){ //Siden leggtiljobb

}elseif($side == "2"){

}elseif($side == "3"){

}elseif($side == "4"){

}elseif($side == "5"){

}else{ //Om sGET infoen ikke stemmer blir brukeren sendt til index?side=main

}
?>

 

 

Da henter du jo informasjonen $_GET (Adressebar) om er likt det som står i elseif ene så blir det hentet ut..

 

på den siste "else" kan du lage redirect til index.php?side=main eller noe

[___]

Det du kan gjøre er å bruke bare 1 fil, isteden for å ha 100vis av små filer

 

<?
$side = $_GET['side'];

if($side == "hoved"){ //Hoved siden din

}elseif($side == "1"){ //Siden leggtiljobb

}elseif($side == "2"){

}elseif($side == "3"){

}elseif($side == "4"){

}elseif($side == "5"){

}else{ //Om sGET infoen ikke stemmer blir brukeren sendt til index?side=main

}
?>

 

 

Da henter du jo informasjonen $_GET (Adressebar) om er likt det som står i elseif ene så blir det hentet ut..

 

på den siste "else" kan du lage redirect til index.php?side=main eller noe

 

Forslaget ditt henger ikke på greip. En slik monolittisk struktur gir bare problemer etterhvert som systemet vokser.

 

Werner

[Manfred]

La oss gi det pris for forumets dårligste råd hittil i år.

[blackbrrd]

Hva med å komme med forslag/hjelp til hvordan ting skal løses istedetfor å rakke ned på andres forslag?

 

Jeg er enig i at en monolitisk en-side løsning ikke akkurat høres ut som en god ide, men Wernie og Manfred, dere har ikke akkurat hjulpet trådstarter.

[DanOve]

prøver å forklare hvordan jeg vil ha det men vet ikke om jeg greier å si skrive det på en riktig måte.

 

Jobb logg funksjoner:

Legg til kunde info (Firma navn, Adresse, post nr, post sted, kontakt person, E-mail, +++)

Redigere Kunde info (Skal ikke gå ann å slette kunde når den først er lagt inn)

Legg til jobb (jobb info, lagt til av, lagt til dato, hvem er ansvarlig for jobben, estimert time bruk, prioritering(høy,lav) +++++)

Redigere Jobb (Skal ikke gå ann å slette jobb når den først er lagt inn)

ferdigstille jobb (Kommentarer, ferdig dato, gjort av hvem, timer brukt,++++)

legge til ansatt (navn)

redigere ansatt (Skal ikke gå ann å slette en ansatt når først er lagt inn)

søk( finne fram til jobber ved å søke på det infoen man har)

Jobb liste. ( som man kan se hvilke jobb som ligger i kø.

 

dette er en drømme DB for meg.

det er ikke sagt at jeg vil ha dette med en gang men et mål fremover. et ønske.

litt hjelp på veien hadde vært fint.

 

når jeg begynner å forstå gangen i dette PHP/MySQL greiene så tror jeg greier mye selv. men det kommer sikkert opp noe jeg lurer på.

 

som sagt er jeg grønn på dette DB. kan litt design som kan gjøres i DreamWaver. eventuelt HTML side via Photoshop med CSS.

that'it.

 

er det noe måte å forhindre at DB blir treig når den begynner å bli stor?

vet at en Acces DB blir SYKT treg når den har lagt på seg litt.

vil forhindre det.

Endret 1. juli 2008 av DanOve

[Jonas]

Access er tregt fordi det er access. En god side derimot, men gode og velskrevne spørringer, kanskje til og med med et cache-system, kan vise sider på millisekkunder. Driver selv en mysql-database/side med rundt 50.000+ rader og executiontime er null problem.

Endret 1. juli 2008 av Jonas

[Prune]

Her har du et skript jeg mekka til deg det funker greit. men designet er ikke helt til å skryte av..

 

Noe lignende dette du ville ha?

 

 

Jeg fikk testet denne selv, og den funket bra som en liten tut. Når man er fersk trenger man enkle ting med alle "nuts and bolts."

 

Thanks!

[blackbrrd]

Access er tregt fordi det er access. En god side derimot, men gode og velskrevne spørringer, kanskje til og med med et cache-system, kan vise sider på millisekkunder. Driver selv en mysql-database/side med rundt 50.000+ rader og executiontime er null problem.

 

Drifter/Utvikler et program som har noen tabeller med 10millioner+ rader og det er ikke noe problem å kjøre spørringer mot de. Hvis spørringene blir litt kompliserte (10+ joins), så kan det noen ganger være nødvendig å bruke hodet litt..

 

Bruker postgresql og den skalerer veldig bra med hardwaren. Kjører nå på dual quad core med 16gb ram og 8xSAS disker. (Databasen er på ca 50gb). Det som er viktig er at de ofte brukte delene av indeksene ligger i ram. Hvis databasen begynner å lese disse indeksene fra harddisk fordi den ikke har nok ram, så vil det fort gå 1000x tregere...

 

For små systemer så kommer hele databasen til å være cachet i ram og det skal mye til før du synes noe går tregt.

[___]

Hva med å komme med forslag/hjelp til hvordan ting skal løses istedetfor å rakke ned på andres forslag?

 

Jeg er enig i at en monolitisk en-side løsning ikke akkurat høres ut som en god ide, men Wernie og Manfred, dere har ikke akkurat hjulpet trådstarter.

 

Hvis det ikke kan kalles hjelp, det å rette kritikk mot en løsning, så vet ikke jeg. Mitt synspunkt har forhåpentligvis ledet trådstarteren vekk fra den potensielle hengemyra det konkrete forslaget i mine øyne var.

 

Ellers har jeg en vag følelse av at det trådstarter ønsker, er enkelt å mekke i Access. Det er snakk om en enkelt person som ønsker å holde styr på oppdragene sine. Access er i mine øyne bare et av mange råtne egg i Office-kurven, men kanskje "right tool for the job" i dette tilfellet. Det er ikke snakk om noen komplisert datamodell, ei heller er det snakk om store datamengder.

 

Ellers finnes det mange ferdige programmer som har alle de funksjoner trådstarter spesifiserer, og mer til. Hvorfor finne opp hjulet på nytt?

 

Werner

[Wooho]

Den basen din hva er den skal inneholde egentlig? Kundeopplysninger, eller kundenes config settinger på diverse applikasjoner eller begge deler?