Puttar, skulle liksom vara kul med ett svar

Vet ej…men sysslar inte med databashantering ;=)

En databas behöver inte ha en historik…det beror ju på vad databasen ska användas till.
Oftast sköts "historiken" genom backup av databasen så att man kan återläsa.
En databas mår ju bäst av att vara så minimal som möjligt men är den korrekt skriven så går det snabbt att söka även i gigantiska databaser.

#3 men om man får ut fel historiska uppgifter från data basen? Jag jobbar med statistik och då måste man ju jobba med historien  kan man då kalla det en databas?

En databas är enbart en lagring. Oftast bestående av en serverapplikation som man "skickar" ner data till och hämtar data från. Vissa databaser har sk transaktionsloggar. Vad som lagras i en databas är helt upp till den applikation som skickar eller hämtar data till/från databasen.

Kända databaser är MS-SQL server, mySQL, Oracle.

Tex skulle jag tippa på att alla inlägg här på iFokus lagras i en databas, troligen i SQL server då hela sajten tycks vara programerad i något MS språk (VB eller C# skulle jag tro)

joooo, men vårt, på jobbet, skulle fungera så att om man skriver ett nytt inlägg så försvinner det gamla och går inte att spåra = en användare ett inlägg  och jag (och min närmaste chef) tycker att man liksom ska få någon form av historia.

Ta en bil som ett ex om bilen besiktigas och får 5 tvåor då står det vid ombesiktning skriver man över och dom fem tvåorna försfinner. Hur får man då fram historik på bilen?

Detta har ju med hur applikationen som man använder är skriven. Använd/utveckla en vettig applikation så sparas saker och ting. Detta är iof inget som har med databaser att göra utan enbart hur applikationen är skriven.

 Nu vet jag ju inte vad det är för en applikation som ni använder och vad syftet med den är, men vist låter det korkat…. Frågan är vad inköparen beställt, hur kravspec ser ut osv, det gäller att hänga rätt person…..

Problemet är att den är amatörbyggd, och beställaren nog inte riktigt vet vad man egentligen skulle kunna kräva av en databas.

Jag vill att den ska lagra alla förändringar i objektens status och att om man frågar efter information att den då är sann…..att man kan spåra vad som hänt och under vilken tid, det kan väll inte vara förmycket begärt.

Som det nu är, så är det ett formulär också ändrar man i det om något ändras, så man vet var föremålet är nu men inte för ett halvår sen då får man gå in i våra papperspärmar och leta historiken  jag har lite svårt att kalla det för en databas

Det är som du säger. Det är beställaren av databasen som bestämmer vad den ska innhehålla och hur den ska användas.

Men det som du beskriver är en ändå en databas. Den lagrar data om olika objekt, men tyvärr inte på det viset du vill.

OK, jag får väll kalla det för databas  tyvärr har den dåliga historiken gjort att vi håller på att bygga en parallel databas som lagrar uppgifterna så vi har lite historia också.

jag hade lika gärna kunnat använda word och lagra uppgifterna och säkert både säkrare och effektivare

#10 Det är alltid billigast att göra rätt från börgan. Uppenbarligen har varken ni eller tillverkaren vetat/kunnat komunicera vad som krävs. Även om det kan kosta en slant är det alltid billigast att ta hjälp innan man skaffar en applikation. För gör den inte det den ska kostar all frustration och tid mycket mer än ett väl utfört utredningsarbete skulle göra….

#11 jag är rädd att det kommer att bli dyrt, det är liksom tre år som är som är bortslängt. Jag är nyanställd och har just fått beställaren (han just över mig) att förstå vad man kan få, jag sitter liksom i en lite knivig situation.

Jag skulle liksom vilja ha mer konkret vad bör en databas klara???

#12 Det handlar väll mer om vad det är ni vill att applikationen skall göra. Frågan är lixom fel ställd….. Börja med att strukturera ner på ett papper vad applikationen skall göra, databas är bara en del av en teknisk lösning på ett deffinierat problem, inte det man i sig skall börja fundera kring.

När du köper en bil börjar du inte fundera över hur bensintanken är konstruerad utan du börjar med krav som tex:

ta mig från A-B
Rymma 5 personer
Kunna dra ett hästsläp
osv, osv….

Deta är inte tekniska lösningar utan deffinierade problem/önskemål på vad bilen skall klara av. De tekniska lösningarna är svaren för att kunna uppfylla frågorna.

På det sätt som jag uppfattar dina funderingar kring databaser är mer att betrakta som Jepardy…typ. Eller som det berömda svaret "42" i Liftarens guide till galaxen….

Svaret är mao värdelöst om man inte känner till frågan. Hoppas jag har utrykt mig förståligt, inte så lätt utan en witeboard ;-)

ja Ok jag vet vad jag tycker den ska klara, problemet är att den har blivit byggd utan att någon beställt den och den som byggde är självlärd…..suck

Nu vill jag bara få argument att detta ska en databas kunna för att kallad databas, för mig är det bara en pärm där man slänger gamla papper när man får nya  oanvändbart

Se, det som om man vaccinerar en häst och får intyg vid vaccineringen på samma papper också har man suddat det gamla datumet, kan man kalla det en databas?

Ja man kan kalla det en databas, eftersom det är data som beskriver ett objekt.

Men vad jag tror du är ute efter är, (vi tar exemplet med bilar igen) att du vill spara alla besiktningsdokument som hör till bilen. Det kan man mycket väl göra. Samt allat annat du vill spara om bilen. OBS du kan spara hur många bilar du vill, med hur mycket data du vill om varje enskild bil i en databas. Du behöver bara bestämma dig för att göra det.

Tänk dig en databas som ett väldigt stort kartortek med stora kort där du kan beskriva en bil per kort, och du kan spara vad du vill om varje bil, så länge som du iförväg kan bestämma dig för vad du vill spara för uppgifter.

Som överkurs kan man i en databas även spara ren text vilket kan ge dig en möjlighet att spara uppgifter du inte viste att du ville spara på förhand, MEN detta gör att det blir svårt och tar längre tid att söka informationen i databasen.

Databasen blir bättre om du kan definera alla data du vill ha med i databasen INNAN du skapar den med det ena eller andra dabasverktyget.

Jag tycker absolut att man ska lagra historik i sin databas. Man vet aldrig när man kan ha nytta av den. En uppenbar fördel med att göra det är ju att man dels kan se vad som hänt med ett objekt över tiden, men också att man är lite mer skyddad mot att man gör misstag.

Ett tips är också att försök strunta i att prata om det tekniska till en början. Försök istället bestämma vad ni vet att ni behöver lagra och framför hur ni vill kunna använda informationen i framtiden. Vilka typer av rapporter vill man kunna få ut? Vad vill man kunna jämföra? Vad är unikt och vad är generellt för alla objekt? Ska man jobba flera personer samtidigt?

Olika verktyg har givetvis olika för- och nackdelar. Excel är ju extremt populärt för att alla har Excel och det är så enkelt att komma igång med, men samtidigt så är det så "platt" och ostrukterat för viss typ av data.

Access är också enkelt och smidigt, men jämfört med Excel så är det en relationsdatabas, vilket nästan alltid är ett måste så fort man vill göra något intelligent. Med Access kommer man längre än man kan tro faktiskt.

Nästa steg är att bygga en helt egen applikation. Det kan vara ett Windows-program eller en webbapplikation. Gemensamt för båda är ofta att man har en databas (Access, SQL Server, etc) under huven och sedan ett eget gränssnitt som läser och skriver till databasen.

Vad man väljer för gränssnittsteknik spelar mindre roll tycker jag. Fördelen med webb är att det är så enkelt att driftsätta och lansera uppdateringar eftersom man har endast ett ställe att uppdatera. Gör man en Windows-applikation får man ju lite mer fluff gratis som programmerare, men det ställer en del andra krav också, t ex att kunna installera det och lansera uppdateringar till alla klienter.

Under hösten upplever jag också att det blivit lite mer populärt att ha Excel som gränssnitt, men att man lagrar informationen i en databas. Då kan folk känna igen sig i Excel, men man får ändå fördelarna med en gemensam lagringsplats och bättre lagring i relationsdatabasen.

Jag jobbar på ett företag som bygger väldigt mycket anpassade lösningar med hjälp av Microsoft Office. Om du vill får du gärna höra av dig.

Har ni kurser i GBG också

Tack Johan nu är jag inte på jobbet längre så jag kan skriva lite mer. Just ditt svar var klockrent = vad jag ville ha, nu är jag lovad en (eller flera kurser i Excel) men jag känner att Access hade varit roligare och mer givande och vi har under dom senaste dagarna kommit fram till att vi ger blanka katten i databasen och skriver små Access baser i stället. Då kan vi i alla fall ha lite koll på det vi själva lagra, jag kan lite Access och sen tänkte jag att några till skulle läras upp så vi inte blir beroende av bara en.

Jag hoppas jag kan höra av mig längre fram om en kurs i GBG eller i huvudstaden.

Vi har kurser lite överallt i landet, så det går säkert att ordna. Om ni är några stycken skulle jag rekommendera att ni ordnar en anpassad kurs för ert företag. Om ni är 4-6 personer blir det både billigare och mycket bättre eftersom innehållet kan anpassas precis till er och att en fråga från en person berör alla andra personer.

#19 jättebra  jag ska lobba lite i frågan men återkommer

Om man går lär ni ut "tänket" då också?

jag saknar denna [](javascript:replaceText(' ???', document.postmodify.message);)