Jeg har kigget lidt på nettet og set lidt youtube men syntes ikke jeg kan se fordelen vs ulempen ved at starte op med EN samlet tabel med alle mine data iforhold til at lave en database med flere tabeller ?
Min plan er at lave en database med en table hvor jeg skal indtaste samme data, feks kunder, ordre,dato,antal,bemærkninger,priser tilbudt dagligt...
Mit "problem" er at jeg ikke helt forstår det med at lave relationer imellem flere tabeller (igen har læst,set youtube men fatter det stadigvæk ikke alt det en-mange-mange-mange og hvordan man kan få flere tabelelr felte til at "linke" til hinanden.......)
Og derfor ville jeg gerne undgå dette med flere tabeller hvis jeg kunne det, ved at indtaste alle mine data i en tabel som jeg så gerne ville kunne lave forespørgelser på udfra forskellige kriterier i fremtiden.
Men mit spørgsmål er så hvis jeg går videre med at lave EN tabel/database, vil jeg så i fremtiden, når database er blevet fyldt godt op med data, løbe ind i nogle problemer som jeg ikke kan løse da jeg har alle data i EN tabel ? feks i forbindelse med at jeg vil kunne trække data ud til en forespørgelse ?
I må undskylde hvis dette spørgsmål er "basic" access viden inden man går igang / lære om det men som sagt, syntes ikke jeg har kunne finde ulempen fordelen ved kun at labe en tabel vs flere tabeller (da jeg som sagt er usikker på det med relationer)
Tusind tak for alle inputs i måtte have der kan hjælpe mig :)
Jo, det er "basic", og derfor er der heller ingen vej udenom. Du er nødt til at have dette på rygmarven, ellers bliver det kun bump på bump, frustration og mærkelige krumspring.
Det kan ikke læres på et kvarter, men så er det altså heller ikke sværere, bare man starter et solidt sted som fx hos Microsoft Learn:
Det er desværre ikke min beslutning at den skal laves i Access iforhold til feks Excel, men et ønske fra min chef😊 men som jeg forstår jeres svar så vil det give mig et problem ved kun at have en tabel med alle data, ville det hjælpe hvis jeg feks forsøgte mig med en tabel til kunde data og tabel til alt andet❓ eller hvad er det for problemer jeg kan få med denne løsning, udover at det måske ikke er den korrekte måde at starte en ny database på😊
Jeg synes det er vigtigt at tage designet og de generelle overvejelser seriøst. For os som har lidt erfaring, og for dem som har meget, ved hvor stor værdi de indledende foreberedelser har.
Blot fra hvad du skriver der, så vil jeg sige at du allerede misser behovet for en tabel med varestamdata.
Hvis din chef vitterligt insisterer på access. Så synes jeg også at ideen om databasestruktur følger med. Ikke at jeg skal være fortaller for at tage på kursus, men det synes aktuelt at overveje det i denne situation.
Men igen, det kommer an på hvor kritisk i ser behovet for dataopsamlingen og processorne forbundet hermed.
Jeg synes også at jeg vil foreslå at tage et kig i den database som #3 nævner. Måske den er over målet i forhold til jeres behov. Men at kigge på tabel designet og de indbyrdes relationer, giver jer et lille indblik i hvad er på vej ud i.
Excel er ikke en database og bør ikke anvendes som sådan - det siger både Microsoft og din chef. Men modsat Excel kan man ikke på femten minutter sætte sig ned og lave noget i Access, og da du tilsyneladende også har et arbejde at passe samtidigt, må du enten have tildelt tid til opgaven og kursus/selvstudium, eller opgaven bør lægges ud til andre.
Men om ikke andet så hent den engelske Nortwind 2.0. Begynderversionen giver et udmærket indtryk af det minimumniveau, man skal ramme for at få noget, der er nogenlunde brugbart. Udviklerversion er også nyttig, men her er vægten mere lagt på at vise, hvordan forskellige snedigheder kan drejes. Virker det stadig for overvældende, bør I lægge opgaven ud eller finde noget færdiglavet, der kan justeres til jeres eksakte behov.
Du skal forstå begrebet 'redundante data' dvs data, der gentages overflødigt. Med en tabel, så skal du have et varenummer til en blyant hårdhed hb fra firma xx og alle andre blyanter skal have andre varenumre (du løber hurtigt tør) Hvis du havde en tabel med et varenummer på blyant og en anden tabel med hårdhedstyper på blyanter, så kan du søge på alle blyanter, der har hårdhed HB (og evt også en opdeling i firmanavne) Med opdelingen en 'undergrupper' så få du langt lettere styring af dit varekartotek, og det kan let og logisk udvides med nye varer. Men en opdelt database, så søger du logisk, dvs fx på blyant, HB, Viking. så så får du alle af den type og intet andet. Databasemæssigt er det en let søgning. Med din metode, så ville der slukke læses sekventielt igennem hele databasen, og for hver enkelt post skulle testes på, og det er en blyant, om det er HB og fra firmaet Viking. Du vil godt lære og forstå database-opbygning.
Tusind Tusind tak for alle jeres input, gode ideer, links mm Jeg kan godt se at der er meget for mig at lære endnu og har lært at jeg skal læse mere på mht opbygninger af databaser, da EN tabel IKKE er den rigtige vej at gå.
så jeg må bare forsøge at læse, kigge på nettet, jeres links og så se om jeg kan forstå det hele ellers kan det jo være at jeg tillader mig at spørge om lidt hjælp her længere frem i tiden :)
Men lige nu er jeg bare glad for den fine hjælp i alle har været med til at give mig... Tusind tak - ha en skøn aften !!
Den hurtigste vej er måske noget sidemandsoplæring. Jeg tilbyder mig gerne til at sidde ved siden af - eller via teams / zoom - og fortælle dig, hvad du skal gøre. Hvis interesseret, så kan je kontaktes på stz at stz dot dk. Jeg har mere end 30 års erfaring med at opbygge databaser i Access
relationsdatabasens 60+ årige sejsgang vidner om hvor relevant den er for at organisere data. Derfor er det er et emne til indfri ambitioner om at lave god info - hvilket er både godt og skidt fordi meget højtravende på flere planer fylder. I tillæg har vi nu fået det famøse AI - og den kan 'snakke' pæredansk.
Tabeller er navneord for konkrete eller abstrakte ting. De enkelte observationer hedder på dansk poster og ikke som i excel linier, idet de nemlig er identificeret på anden vis (unik nøgle f.eks) Relationer benyttes også om tabeller i sig selv, idet alle felter relatere navnerordet vha. et udsagsord - Person(id,adresse,telefonnumer,skonummer) _har_ id, _bor_ på adresse, _har_ telefon nummer, _bruger_ skonummer osv. Dermed er en tabel noget der knytter identificerende sæt af sammenhængende observationer sammen under et navneord.
Og navnet på tabellen der indeholder alt kan kunne være MISKMASK - den indeholde en masse null felter som ikke har betydning for det enkelte sæt af sammenhørende observationer.
Faktisk kan du godt komme 'ud over rampen' med MISKMASK - bara du er villig til løbende at mutere og være den der sørger for konsistens='data vedr. det som administreres står kun et sted' i processen at lave de rigtige tabeller og relatere mellem dem. Access relationer vinduet er også en god dokumentation at vende tilbage til for at huske hvordan ting er organiseret og forklare det til andre.
Der er ingen vej uden om at sætte sig ind i normalisering mm og arbejde meden række tabeller. Der kan laves mange hurtige ting i excel - men det bliver hurtigt uoverskueligt og svært at teste ændringer ordentligt. Og endnu værre opgaven kan ikke overdrages...
En anden vigtig ting er data disciplin - pludselig skal data bruges til noget nyt - se hvor ringe det gik 2 gange da der skulle penge ud til folk med gasfyr. Undskyldning det skulle gå hurtigt -6 mdr er ikke hurtigt - var data i orden kunne det laves meget bedre og meget hurtigere.
>MSchlamovitz, tak for dit tilbud om sidemands hjælp, er det noget som jeg skal betale for ?
............Den hurtigste vej er måske noget sidemandsoplæring. Jeg tilbyder mig gerne til at sidde ved siden af - eller via teams / zoom - og fortælle dig, hvad du skal gøre. Hvis interesseret, så kan je kontaktes på stz at stz dot dk. Jeg har mere end 30 års erfaring med at opbygge databaser i Access
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
