Några frågade i början av tråden efter ett ekelt program så man kan hålla
reda på alla sina komponenter på ett enkelt sätt,
själv använder jag FileAmigo 7 .. funkar bra för mig.
Komponent-databas och SQL
> Databasbehandling är inte nytt för mig. Däremot är sql [...] nytt för mig...
OK, du har alltså jobbet med databaser *utan* SQL interface.
Var det rellationsdatabaser ? Det verkar inte så eftersom det
är så mycket tjafs om normalisering och (tabell-) design...
> För att kunna börja lägga till de antal av varje komponent som finns i
> lager så *måste* man fylla i:
>
> Tabell 1: Leverantörens namn
> Tabell 2: Komponent-typerna som ska användas i databasen
> Tabell 3: Art-nr och komponentvärde.
Exakt, självklart.
Poängen är att det är något man sannolikt gör som en separat operation
skiljd från uppdateringen av "lagret".
Tabell 1 behöver bara fyllas i om det är en hittills oanvänd leverantör.
Även tabell 2 fylls lämpligen i i förväg (efter att man har funderat lite på det så att det blir en vettig uppdelning...)
Tabell 3 kommer kanske att fyllas i lite mer ofta, t.ex m.h.a ett pop-up fönster från
"lager-bilden" så att man kan lägga till artnr "on the fly" medan man fyller i lagret.
Självklart kan man ha liknande funktioner för lev och komptyper också om man vill ha det...
Jag kan hålla med om att man skulle kunna (miss-) tolka oJsan's inlägg på det sätt du gör,
men då får man allt ta i lite extra...
OK, du har alltså jobbet med databaser *utan* SQL interface.
Var det rellationsdatabaser ? Det verkar inte så eftersom det
är så mycket tjafs om normalisering och (tabell-) design...
> För att kunna börja lägga till de antal av varje komponent som finns i
> lager så *måste* man fylla i:
>
> Tabell 1: Leverantörens namn
> Tabell 2: Komponent-typerna som ska användas i databasen
> Tabell 3: Art-nr och komponentvärde.
Exakt, självklart.
Poängen är att det är något man sannolikt gör som en separat operation
skiljd från uppdateringen av "lagret".
Tabell 1 behöver bara fyllas i om det är en hittills oanvänd leverantör.
Även tabell 2 fylls lämpligen i i förväg (efter att man har funderat lite på det så att det blir en vettig uppdelning...)
Tabell 3 kommer kanske att fyllas i lite mer ofta, t.ex m.h.a ett pop-up fönster från
"lager-bilden" så att man kan lägga till artnr "on the fly" medan man fyller i lagret.
Självklart kan man ha liknande funktioner för lev och komptyper också om man vill ha det...
Jag kan hålla med om att man skulle kunna (miss-) tolka oJsan's inlägg på det sätt du gör,
men då får man allt ta i lite extra...
Vad jag menade var att DU fyller i php-formuläret och DATORN fyller tabellen/tabellerna.JimmyAndersson skrev: "Åter igen, det är ju inte DU som fyller i tabellen, det gör ju datorn... ...."
Sanning med modifikation...JimmyAndersson skrev: För att kunna börja lägga till de antal av varje komponent som finns i lager så *måste* man fylla i:
Tabell 1: Leverantörens namn
Tabell 2: Komponent-typerna som ska användas i databasen
Tabell 3: Art-nr och komponentvärde.
Skillnaden ligger i HUR man fyller i _formuläret_ när det gäller leverantör och komponenttyp! Istället för att _skriva_ in dem manuellt varje gång så fyller man en dropdownlist med fördefinerade data (från leverantörs- och komponenttyps-tabellen).
Säg aldrig aldrig, ge programvaran 10år till så kanske..JimmyAndersson skrev: Om datorn kan ordna det själv så har jag totalt underskattat PHP och MySQL!
Danei: 
:
Jimmy:
Försök designa en programvara (PHP kod i detta fall) som inte behöver ändras en rad om du vill utvidga med t.ex. fler leverantörer och komponenttyper. Även om det känns som lite extrajobb i början att göra en generell kod så lönar det sig nästan alltid i slutändan.
Användarinterfacet, dvs webbsidan, behöver inte se ett dugg olika ut, vilken databashanteringsmetod du än använder. Men använder du den av många föreslagna modellen utan redundans så är det mycket lättare att undvika buggar när du programmerar och databasen blir garanterat mindre.
Ett tips är att du gör så kallade Use Cases innan du börjar med nåt annat, dvs du tänker igenom alla olika sätt du vill använda din databas på. Skriv ner (på vanligt papper ) hur du vill använda programmet, t.ex.
1) Kontrollera vad jag har i lager
2) Ta reda på vilken återförsäljare som är billigast på en komponent
m.m.
När du vet vad programmet måste klara av kan du skissa lite grovt hur du vill att programmet skall uppföra sig, så kallad "Story board". Gör en liten seriestrip mycket grovt skissad på papper hur du vill att guit skall förändra sig i olika lägen (use cases). I slutändan när du har gjort en seriestripp för allt du skall göra kan du börja om från början och kolla om din design uppfyller alla use cases.
Sen när du vet ganska exakt vad du vill att programmet skall göra så kan du börja fundera på hur detta skall implementeras i databas. Jag vet av bitter erfarenhet att många problem bottnar i att man inte riktigt har tänkt i genom vad programmet skall göra och kodar olika bitar som inte riktigt passar i varandra. Sen behöver man inte göra det krångligare än vad det är, några enkla skisser på papper tycker jag gör underverk för att snabba upp kodararbetet.
:Jimmy:
Försök designa en programvara (PHP kod i detta fall) som inte behöver ändras en rad om du vill utvidga med t.ex. fler leverantörer och komponenttyper. Även om det känns som lite extrajobb i början att göra en generell kod så lönar det sig nästan alltid i slutändan.
Användarinterfacet, dvs webbsidan, behöver inte se ett dugg olika ut, vilken databashanteringsmetod du än använder. Men använder du den av många föreslagna modellen utan redundans så är det mycket lättare att undvika buggar när du programmerar och databasen blir garanterat mindre.
Ett tips är att du gör så kallade Use Cases innan du börjar med nåt annat, dvs du tänker igenom alla olika sätt du vill använda din databas på. Skriv ner (på vanligt papper
) hur du vill använda programmet, t.ex. 1) Kontrollera vad jag har i lager
2) Ta reda på vilken återförsäljare som är billigast på en komponent
m.m.
När du vet vad programmet måste klara av kan du skissa lite grovt hur du vill att programmet skall uppföra sig, så kallad "Story board". Gör en liten seriestrip mycket grovt skissad på papper hur du vill att guit skall förändra sig i olika lägen (use cases). I slutändan när du har gjort en seriestripp för allt du skall göra kan du börja om från början och kolla om din design uppfyller alla use cases.
Sen när du vet ganska exakt vad du vill att programmet skall göra så kan du börja fundera på hur detta skall implementeras i databas. Jag vet av bitter erfarenhet att många problem bottnar i att man inte riktigt har tänkt i genom vad programmet skall göra och kodar olika bitar som inte riktigt passar i varandra. Sen behöver man inte göra det krångligare än vad det är, några enkla skisser på papper tycker jag gör underverk för att snabba upp kodararbetet.
Hej Jimmy,
Har gjort något liknande en gång men i MSAccess, JA ja vet men det är enkelt och gjorde vad det skulle för mig, så här kommer ett litet tips,
Skapa en möjlighet att länka/infoga dokument (datablad, errata, etc, etc) till komponenter.
Gör det enkelt att hålla orning på det annars växande "filbibloteket med kryptiska filnamn"
Har gjort något liknande en gång men i MSAccess, JA ja vet men det är enkelt och gjorde vad det skulle för mig, så här kommer ett litet tips,
Skapa en möjlighet att länka/infoga dokument (datablad, errata, etc, etc) till komponenter.
Gör det enkelt att hålla orning på det annars växande "filbibloteket med kryptiska filnamn"
-
JimmyAndersson
- Inlägg: 26417
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Tack för alla svar.
Känner på mig att det här kommer bli ett långt inlägg, så var beredda.
När det gäller databas-systemen jag har använt så har det handlat om gigantiska system för planering av radioreklam. Tänk er en hel skärm som ser ut som som Excel, fast för DOS. Alla fält måste fyllas i med koder som ser ut ungefär såhär: S1051A. Varenda fält är relaterat till varandra. Varje tecken i koden betyder olika saker som t.ex längd på reklamen, företaget som gör reklamen, vilken kampanj, vilken sorts reklam (mat, kläder, hemelektronik, osv.) Databasen håller koll på allt detta och sorterar posterna enligt massa beräkningar som gör att t.ex OKQ8 och Shell inte hörs efter varandra, mm mm. Systemet består av flera olika sånahär sidor som är relaterade till varandra enligt olika uppsatta regler. De flesta som sett detta tycker det ser ut som den klassiska Matrix-koden, så det är ingen liten pytte-databas jag jobbat med. Den typen av jobb kallas förresten för "traffic", inte att förväxla med trafficing.. 
Men för att återgå till ämnet:
sodjan:
"Tabell 1 behöver bara fyllas i om det är en hittills oanvänd leverantör. "
oJsan:
"Istället för att _skriva_ in dem manuellt varje gång så fyller man en dropdownlist med fördefinerade data (från leverantörs- och komponenttyps-tabellen)."
Svar till båda:
Hur kommer denna fördefinierade leverantör in i tabellen?
Just det, man måste skriva in det. Jag har tjatat om detta många gånger nu och jag vet inte hur jag kan förklara det tydligare, men jag gör ett försök till:
När jag gjort klart php-koden och skapat alla tabeller så är ju databasen tom på data. Eller hur?
Det finns alltså inget i leverantörs- och komponenttyps-tabellen. ALLA leverantörer är okända. Är ni med?
Därför kan jag inte börja lägga in de antal av varje komponent som finns i lagret. - Det finns ju inga komponent-typer i databasen.
Ni har hela tiden skrivit att jag inte behöver skriva in leverantör, komponent-typ, art-nr och komponentvärde. Istället har det flera gånger skrivits att man väljer detta från de fördefinierade tabellerna leverantör och komponent-typ. Inte ett ord om att man måste fylla i dessa *INNAN* man kan börja mata in uppgifter i tabellen som innehåller komponent-lagret.
Sodjan skriver att det inte låter som om jag jobbat med relationsdatabaser eftersom det är "så mycket tjafs om normalisering och (tabell-) design".
Vad har det med saken att göra?
Vidare skrev sodjan:
"Jag kan hålla med om att man skulle kunna (miss-) tolka oJsan's inlägg på det sätt du gör, men då får man allt ta i lite extra... "
Jag har inte tolkat överhuvudtaget. Jag har bara läst vad som står.
Jag är ganska trött på att behöva upprepa mig hela tiden angående tabellerna med leverantör, art-nr och komponenttyp. Gissar att ni är lika trötta på att behöva läsa det. Men allt jag fått till svar är att detta är fördefinierat, att man inte behöver fylla i dem varje gång, att man väljer med dropdown-menyer, att datorn uppdaterar tabellerna, osv osv osv.
Tanken var att jag ville få reda på mer om detta. -Det är ju därför man frågar.
Förstår ni nu hur jag menar?
Annars får ni komma hit på en fika så jag kan visa.
Känner på mig att det här kommer bli ett långt inlägg, så var beredda.
När det gäller databas-systemen jag har använt så har det handlat om gigantiska system för planering av radioreklam. Tänk er en hel skärm som ser ut som som Excel, fast för DOS. Alla fält måste fyllas i med koder som ser ut ungefär såhär: S1051A. Varenda fält är relaterat till varandra. Varje tecken i koden betyder olika saker som t.ex längd på reklamen, företaget som gör reklamen, vilken kampanj, vilken sorts reklam (mat, kläder, hemelektronik, osv.) Databasen håller koll på allt detta och sorterar posterna enligt massa beräkningar som gör att t.ex OKQ8 och Shell inte hörs efter varandra, mm mm. Systemet består av flera olika sånahär sidor som är relaterade till varandra enligt olika uppsatta regler. De flesta som sett detta tycker det ser ut som den klassiska Matrix-koden, så det är ingen liten pytte-databas jag jobbat med.
Den typen av jobb kallas förresten för "traffic", inte att förväxla med trafficing.. Men för att återgå till ämnet:
sodjan:
"Tabell 1 behöver bara fyllas i om det är en hittills oanvänd leverantör. "
oJsan:
"Istället för att _skriva_ in dem manuellt varje gång så fyller man en dropdownlist med fördefinerade data (från leverantörs- och komponenttyps-tabellen)."
Svar till båda:
Hur kommer denna fördefinierade leverantör in i tabellen?
Just det, man måste skriva in det. Jag har tjatat om detta många gånger nu och jag vet inte hur jag kan förklara det tydligare, men jag gör ett försök till:
När jag gjort klart php-koden och skapat alla tabeller så är ju databasen tom på data. Eller hur?
Det finns alltså inget i leverantörs- och komponenttyps-tabellen. ALLA leverantörer är okända. Är ni med?
Därför kan jag inte börja lägga in de antal av varje komponent som finns i lagret. - Det finns ju inga komponent-typer i databasen.
Ni har hela tiden skrivit att jag inte behöver skriva in leverantör, komponent-typ, art-nr och komponentvärde. Istället har det flera gånger skrivits att man väljer detta från de fördefinierade tabellerna leverantör och komponent-typ. Inte ett ord om att man måste fylla i dessa *INNAN* man kan börja mata in uppgifter i tabellen som innehåller komponent-lagret.
Sodjan skriver att det inte låter som om jag jobbat med relationsdatabaser eftersom det är "så mycket tjafs om normalisering och (tabell-) design".
Vad har det med saken att göra?
Vidare skrev sodjan:
"Jag kan hålla med om att man skulle kunna (miss-) tolka oJsan's inlägg på det sätt du gör, men då får man allt ta i lite extra... "
Jag har inte tolkat överhuvudtaget. Jag har bara läst vad som står.
Jag är ganska trött på att behöva upprepa mig hela tiden angående tabellerna med leverantör, art-nr och komponenttyp. Gissar att ni är lika trötta på att behöva läsa det.
Men allt jag fått till svar är att detta är fördefinierat, att man inte behöver fylla i dem varje gång, att man väljer med dropdown-menyer, att datorn uppdaterar tabellerna, osv osv osv.Tanken var att jag ville få reda på mer om detta. -Det är ju därför man frågar.
Förstår ni nu hur jag menar?
Annars får ni komma hit på en fika så jag kan visa.
> Hur kommer denna fördefinierade leverantör in i tabellen?
"Fördefinierad" är rellativt. Det betyder bara att du *tidigare* har haft en *annan*
komponent med *samma* leverantör, och *då* fylldes lev-info i.
*Nu* med den nya komponenten så är leverantören "fördefinierad". Allt är rellativt...
Det betyder att i 99% av alla inmatningar av komponenter så kommer
leverantören att vara "fördefinierad".
> Inte ett ord om att man måste fylla i dessa *INNAN* man kan börja
> mata in uppgifter i tabellen som innehåller komponent-lagret.
Det är väll fullständigt självklart...
> Annars får ni komma hit på en fika så jag kan visa.
Gärna ! Allvarligt menat. Skulle vara himla kul att se dina studios också.
För ett par år sedan pendlade jag till jobb i Visby och åkte via
Oskarshamn varannan vecka...
> Gissar att ni är lika trötta på att behöva läsa det.
När det gäller databaser blir jag *aldrig* trött...
PS:
När det gäller radioplaneringssystemet så var du alltså *användare*
inte designer eller DBA. Det är inte alls samma sak. Eller hade du
även konstruerat databas systemet ? Ungefär som att säga att man har
"jobbat med databaser" för att man har beställt prylar från ELFA...
"Fördefinierad" är rellativt. Det betyder bara att du *tidigare* har haft en *annan*
komponent med *samma* leverantör, och *då* fylldes lev-info i.
*Nu* med den nya komponenten så är leverantören "fördefinierad". Allt är rellativt...
Det betyder att i 99% av alla inmatningar av komponenter så kommer
leverantören att vara "fördefinierad".
> Inte ett ord om att man måste fylla i dessa *INNAN* man kan börja
> mata in uppgifter i tabellen som innehåller komponent-lagret.
Det är väll fullständigt självklart...
> Annars får ni komma hit på en fika så jag kan visa.
Gärna ! Allvarligt menat. Skulle vara himla kul att se dina studios också.
För ett par år sedan pendlade jag till jobb i Visby och åkte via
Oskarshamn varannan vecka...
> Gissar att ni är lika trötta på att behöva läsa det.
När det gäller databaser blir jag *aldrig* trött...
PS:
När det gäller radioplaneringssystemet så var du alltså *användare*
inte designer eller DBA. Det är inte alls samma sak. Eller hade du
även konstruerat databas systemet ? Ungefär som att säga att man har
"jobbat med databaser" för att man har beställt prylar från ELFA...
Visst står det i tidigare inlägg, Jimmy!
Titta i mitt tidigare inlägg ang. inmatning av grunddata. Givetvis måste man mata in även t.ex leverantör om den ligger i en separat tabell. Men det matas bara in en gång per leverantör innan man börjar mata in komponenenter. Sedan när man hanterar komponenter och skall ange leverantör så använder man t.ex en dropdown för att välja bland dom redan förinlagda leverantörerna. D.v.s vid varje komponentinläggning så blir det mindre jobb än om leverantörerna inte varit fördefinierade.
Även om leverantörerna inte låg i en egen tabell skulle du ju bli tvungen att mata in det vid varje komponentinmatning, förutsatt att du vill ha den uppgiften med. Skillnaden är att nu skriver du in det en gång och sedan väljer du bara från fördefinierade.
Titta i mitt tidigare inlägg ang. inmatning av grunddata. Givetvis måste man mata in även t.ex leverantör om den ligger i en separat tabell. Men det matas bara in en gång per leverantör innan man börjar mata in komponenenter. Sedan när man hanterar komponenter och skall ange leverantör så använder man t.ex en dropdown för att välja bland dom redan förinlagda leverantörerna. D.v.s vid varje komponentinläggning så blir det mindre jobb än om leverantörerna inte varit fördefinierade.
Även om leverantörerna inte låg i en egen tabell skulle du ju bli tvungen att mata in det vid varje komponentinmatning, förutsatt att du vill ha den uppgiften med. Skillnaden är att nu skriver du in det en gång och sedan väljer du bara från fördefinierade.
Jag tycker också att det framgått tidigare...
Länkar åter igen till min automationssida och tar den som praktiskt exempel.
(Databasen bakom sidan är uppbyggd på det sätt vi försöker beskriva här i tråden, dvs med relationstabeller och _avsaknad_ av redundas).
Mina enheter (lamporna) skapar jag EN gång. (på samma sätt som du gör med leverantörer och komponenttyper).
Sedan går jag till sidan "Hantera grupper" och klickar på "Visa enheter" för gruppen "Vardagsrum" (förutsatt att själva gruppen är skapad).
Här kan jag nu se vilka lampor som ingår i den gruppen och vilka som inte gör det (och alltså går att lägga till).
Om relationsdatabaser:
Gruppering av lampor sker mha tre tabeller. Den första innehåller data om varje enskild lampa samt lampans index. Den andra tabellen innehåller en beskrivningar av grupperna samt ett index för varje grupp.
Den tredje tabellen innehåller två kolumner med enbart siffror och används för att binda samman de två första tabellernas index.
När jag lägger till eller tar bort en lampa ur en grupp så är det enbart referenstabellen som uppdateras.
Relationstypen kallas 1:N eftersom EN lampa kan ingå i FLERA grupper. På liknande vis kan en N:N-relation byggas upp med en referenstabell.
(1:1 "finns inte" då de istället är lämpligast att lägga datat i samma tabell.)
Vet inte om det är jag eller någon annan som skrivit fel, eller om det är du Jimmy som uppfattat det fel, men "art-nr" är inte av typen "fördefinerad"... "Komponenttyp" och "Leverantör" kan dock vara fördefinerade data som hämtas ur respektive tabell.
Ps.
Jag skulle också tycka att det vore kul att komma på fika... så lova inte för mycket nu!
Länkar åter igen till min automationssida och tar den som praktiskt exempel.
(Databasen bakom sidan är uppbyggd på det sätt vi försöker beskriva här i tråden, dvs med relationstabeller och _avsaknad_ av redundas).
Mina enheter (lamporna) skapar jag EN gång. (på samma sätt som du gör med leverantörer och komponenttyper).
Sedan går jag till sidan "Hantera grupper" och klickar på "Visa enheter" för gruppen "Vardagsrum" (förutsatt att själva gruppen är skapad).
Här kan jag nu se vilka lampor som ingår i den gruppen och vilka som inte gör det (och alltså går att lägga till).
Om relationsdatabaser:
Gruppering av lampor sker mha tre tabeller. Den första innehåller data om varje enskild lampa samt lampans index. Den andra tabellen innehåller en beskrivningar av grupperna samt ett index för varje grupp.
Den tredje tabellen innehåller två kolumner med enbart siffror och används för att binda samman de två första tabellernas index.
När jag lägger till eller tar bort en lampa ur en grupp så är det enbart referenstabellen som uppdateras.
Relationstypen kallas 1:N eftersom EN lampa kan ingå i FLERA grupper. På liknande vis kan en N:N-relation byggas upp med en referenstabell.
(1:1 "finns inte" då de istället är lämpligast att lägga datat i samma tabell.)
Vet inte om det är jag eller någon annan som skrivit fel, eller om det är du Jimmy som uppfattat det fel, men "art-nr" är inte av typen "fördefinerad"... "Komponenttyp" och "Leverantör" kan dock vara fördefinerade data som hämtas ur respektive tabell.
Ps.
Jag skulle också tycka att det vore kul att komma på fika... så lova inte för mycket nu!
-
JimmyAndersson
- Inlägg: 26417
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Gokväll
Börjar med sodjan eftersom han svarade först:
"När det gäller databaser blir jag *aldrig* trött... "
Låter bra.
"När det gäller radioplaneringssystemet så var du alltså *användare*
inte designer eller DBA. Det är inte alls samma sak."
Till största delen var jag bara användare. (Inte så bara egentligen. Arbetet kändes som om man skulle skriva en 100kB HEX-fil för en PIC-krets manuellt.)
Grundsystemet med databasen hade jag inte konstruerat. Däremot ett tilläggsystem (programmerat i Phyton och Perl) som sökte, hämtade och behandlade data från databasen och skickade till rätt datorer i nätverket.
"> Annars får ni komma hit på en fika så jag kan visa.
Gärna ! Allvarligt menat. Skulle vara himla kul att se dina studios också.
För ett par år sedan pendlade jag till jobb i Visby och åkte via
Oskarshamn varannan vecka..."
Vore kul. Det är inga jättestudios, men skulle man samla ihop apparaterna så skulle de lätt fylla ett rum på ca 25m (förutsatt att man staplar dem på varandra, annars behövs nog en liten lägenhet.)
vfr & oJsan: Diskussionen med att man måste fylla i leverantör och sånt innan man gör något annat började för många inlägg sedan. Det handlade om att mitt (gamla) sätt krävde färre tabeller och var betydligt lättare att koda. Men det finns roligare saker att diskutera.
oJsan:
"Jag skulle också tycka att det vore kul att komma på fika... så lova inte för mycket nu!"
Hm, måste nog städa först. Brevid mig ligger högar med datablad på golvet. Vardagsrumsbordet är till hälften täckt med kretskort som väntar på montering i TFT-UV-boxen...
Men åter till tabellerna. Så här har jag alltså tänkt:
Tabell: säljare
* index
* namn
* adress
* tel-nr.
Tabell: komponenttyp
* index
* sort (t.ex motstånd, kondensator, osv)
Tabell: komponent
* index
* komponenttyp (kopplat till index i komponenttyp-tabellen)
* värde (t.ex 10k eller kanske "röd" om det gäller en lysdiod.)
* effekt (t.ex 1/4w eller "20mA" om det är en lysdiod.)
* övrigt (t.ex ytmonterat.)
* antal i lagret
* art-nr
* säljare (kopplat till index i säljar-tabellen)
Något som bör ändras?
Börjar med sodjan eftersom han svarade först:
"När det gäller databaser blir jag *aldrig* trött... "
Låter bra.
"När det gäller radioplaneringssystemet så var du alltså *användare*
inte designer eller DBA. Det är inte alls samma sak."
Till största delen var jag bara användare. (Inte så bara egentligen. Arbetet kändes som om man skulle skriva en 100kB HEX-fil för en PIC-krets manuellt.)
Grundsystemet med databasen hade jag inte konstruerat. Däremot ett tilläggsystem (programmerat i Phyton och Perl) som sökte, hämtade och behandlade data från databasen och skickade till rätt datorer i nätverket.
"> Annars får ni komma hit på en fika så jag kan visa.
Gärna ! Allvarligt menat. Skulle vara himla kul att se dina studios också.
För ett par år sedan pendlade jag till jobb i Visby och åkte via
Oskarshamn varannan vecka..."
Vore kul.
Det är inga jättestudios, men skulle man samla ihop apparaterna så skulle de lätt fylla ett rum på ca 25m (förutsatt att man staplar dem på varandra, annars behövs nog en liten lägenhet.) vfr & oJsan: Diskussionen med att man måste fylla i leverantör och sånt innan man gör något annat började för många inlägg sedan. Det handlade om att mitt (gamla) sätt krävde färre tabeller och var betydligt lättare att koda. Men det finns roligare saker att diskutera.
oJsan:
"Jag skulle också tycka att det vore kul att komma på fika... så lova inte för mycket nu!"
Hm, måste nog städa först. Brevid mig ligger högar med datablad på golvet. Vardagsrumsbordet är till hälften täckt med kretskort som väntar på montering i TFT-UV-boxen...
Men åter till tabellerna. Så här har jag alltså tänkt:
Tabell: säljare
* index
* namn
* adress
* tel-nr.
Tabell: komponenttyp
* index
* sort (t.ex motstånd, kondensator, osv)
Tabell: komponent
* index
* komponenttyp (kopplat till index i komponenttyp-tabellen)
* värde (t.ex 10k eller kanske "röd" om det gäller en lysdiod.)
* effekt (t.ex 1/4w eller "20mA" om det är en lysdiod.)
* övrigt (t.ex ytmonterat.)
* antal i lagret
* art-nr
* säljare (kopplat till index i säljar-tabellen)
Något som bör ändras?
-
JimmyAndersson
- Inlägg: 26417
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Såhär blir kanske bättre:
(Gjorde ingen edit ifall någon precis svarade på min förra tabell-struktur.)
Tabell: säljare
* index
* namn
* adress
* tel-nr.
Tabell: komponenttyp
* index
* sort (t.ex motstånd, kondensator, osv)
Tabell: återförsäljarlager
* index
* komponenttyp (kopplat till index i komponenttyp-tabellen)
* värde (t.ex 10k eller kanske "röd" om det gäller en lysdiod.)
* effekt (t.ex 1/4w eller "20mA" om det är en lysdiod.)
* övrigt (t.ex ytmonterat.)
* art-nr
* säljare (kopplat till index i säljar-tabellen)
Tabell: hemmalager
* index
* komponenttyp (kopplat till "index" i komponenttyp-tabellen)
* värde (kopplat till "värde" i återförsäljarlager-tabellen.)
* effekt (kopplat till "effekt" i återförsäljarlager-tabellen.)
* övrigt (kopplat till "övrigt" i återförsäljarlager-tabellen.)
* antal i lagret
* art-nr (kopplat till "art-nr" i återförsäljarlager-tabellen.)
* säljare (kopplat till index i säljar-tabellen)
Något som är galet?
(Gjorde ingen edit ifall någon precis svarade på min förra tabell-struktur.)
Tabell: säljare
* index
* namn
* adress
* tel-nr.
Tabell: komponenttyp
* index
* sort (t.ex motstånd, kondensator, osv)
Tabell: återförsäljarlager
* index
* komponenttyp (kopplat till index i komponenttyp-tabellen)
* värde (t.ex 10k eller kanske "röd" om det gäller en lysdiod.)
* effekt (t.ex 1/4w eller "20mA" om det är en lysdiod.)
* övrigt (t.ex ytmonterat.)
* art-nr
* säljare (kopplat till index i säljar-tabellen)
Tabell: hemmalager
* index
* komponenttyp (kopplat till "index" i komponenttyp-tabellen)
* värde (kopplat till "värde" i återförsäljarlager-tabellen.)
* effekt (kopplat till "effekt" i återförsäljarlager-tabellen.)
* övrigt (kopplat till "övrigt" i återförsäljarlager-tabellen.)
* antal i lagret
* art-nr (kopplat till "art-nr" i återförsäljarlager-tabellen.)
* säljare (kopplat till index i säljar-tabellen)
Något som är galet?
Då ska vi se...
Klarar mySQL av object med svenska tecken ?
Jo, jag vet att det du har skrivit kanske inte är tabellnamnen,
men varför inte göra det direkt så slipper du "översätta" namnen
senare... ?
Kalla inte fält för "index", ett index är ett speciellt object i databasen.
"Index" *bör* vara ett reserverat ord...
Samma sak med "sort" (d.v.s "sortera" på engelska), undvik det.
Så här ser det ut efter uppsnyggning och borttagning
av onödiga fält (specielt i "hemmalager" !) :
Tabell: lev
* lev_nr
* namn
* adress
* tel-nr.
Tabell: komptyp
* komptyp_nr
* ben (benämning, t.ex motstånd, kondensator, osv)
Tabell: levlager
* levlager_nr
* lev_nr
* komptyp_nr
* värde (t.ex 10k eller kanske "röd" om det gäller en lysdiod.)
* effekt (t.ex 1/4w eller "20mA" om det är en lysdiod.)
* övrigt (t.ex ytmonterat.)
* art-nr
Tabell: hemlager
* hemlager_nr
* levlager_nr
* antal i lagret
Vad som är primära resp. främande nycklar framgår av fältnamnen.
Nägra andra detaljer...
Jag skulle ersätta "effekt" och "övrigt" med ett fält "beskrivning".
"Effekt" är inte rellevant för alla komp.typer och att redan på
designstadiet säga att man ska skriva "20mA" i ett fält som heter
"effekt" är *väldigt* soppig design !
Sen är det antagligen många komponenter som t.ex har
"1/4W ytmonterat" som "beskrivning", och jag skulle lägga det i
"komptyp" istället. Dete blir alltså några fler poster i "komptyp",
men betydligt mindre data (per post) i "levlager". D.v.s att det skulle se
ut så här :
Tabell: lev
* lev_nr
* namn
* adress
* tel-nr.
Tabell: komptyp
* komptyp_nr
* beskrivning ("Motstånd 1/4W ytmonterat", "LED 20 mA" eller liknande)
Tabell: levlager
* levlager_nr
* lev_nr
* komptyp_nr
* värde (t.ex 10k eller kanske "röd" om det gäller en lysdiod.)
* art-nr
Tabell: hemlager
* hemlager_nr
* levlager_nr
* antal i lagret
Det är fortfrande inte helt logiskt med rellationen mellan
"levlager.värde" och "komptyp.beskrivning"...
Men det får man fundera vidare på
Klarar mySQL av object med svenska tecken ?
Jo, jag vet att det du har skrivit kanske inte är tabellnamnen,
men varför inte göra det direkt så slipper du "översätta" namnen
senare... ?
Kalla inte fält för "index", ett index är ett speciellt object i databasen.
"Index" *bör* vara ett reserverat ord...
Samma sak med "sort" (d.v.s "sortera" på engelska), undvik det.
Så här ser det ut efter uppsnyggning och borttagning
av onödiga fält (specielt i "hemmalager" !) :
Tabell: lev
* lev_nr
* namn
* adress
* tel-nr.
Tabell: komptyp
* komptyp_nr
* ben (benämning, t.ex motstånd, kondensator, osv)
Tabell: levlager
* levlager_nr
* lev_nr
* komptyp_nr
* värde (t.ex 10k eller kanske "röd" om det gäller en lysdiod.)
* effekt (t.ex 1/4w eller "20mA" om det är en lysdiod.)
* övrigt (t.ex ytmonterat.)
* art-nr
Tabell: hemlager
* hemlager_nr
* levlager_nr
* antal i lagret
Vad som är primära resp. främande nycklar framgår av fältnamnen.
Nägra andra detaljer...
Jag skulle ersätta "effekt" och "övrigt" med ett fält "beskrivning".
"Effekt" är inte rellevant för alla komp.typer och att redan på
designstadiet säga att man ska skriva "20mA" i ett fält som heter
"effekt" är *väldigt* soppig design !
Sen är det antagligen många komponenter som t.ex har
"1/4W ytmonterat" som "beskrivning", och jag skulle lägga det i
"komptyp" istället. Dete blir alltså några fler poster i "komptyp",
men betydligt mindre data (per post) i "levlager". D.v.s att det skulle se
ut så här :
Tabell: lev
* lev_nr
* namn
* adress
* tel-nr.
Tabell: komptyp
* komptyp_nr
* beskrivning ("Motstånd 1/4W ytmonterat", "LED 20 mA" eller liknande)
Tabell: levlager
* levlager_nr
* lev_nr
* komptyp_nr
* värde (t.ex 10k eller kanske "röd" om det gäller en lysdiod.)
* art-nr
Tabell: hemlager
* hemlager_nr
* levlager_nr
* antal i lagret
Det är fortfrande inte helt logiskt med rellationen mellan
"levlager.värde" och "komptyp.beskrivning"...
Men det får man fundera vidare på
Hmmmm....
Den senaste halvtimmen spenderade jag med att skriva ett inlägg med den tabellstrukturen jag tycker skulle vara den riktiga. Jag jobbar som programmerare på ett företag som gör ERP-program så jag är helt inom rätt bransch. Men då jag var klar så fick jag kalla fötter...det liknade alldeles för mycket grundstrukturen på jobbet. Så det blev till Ctrl-A + Delete
Men några tips har jag, det här är ju bara vad jag tycker så ni behöver absolut inte göra så.
1. Det känns väldigt mycket mer rätt med engelska tabell- och fältnamn.
2. Jag tycker om att tabell-namn och fältnamn är skrivna med versaler.
3. Snåla absolut inte med antalet tabeller! Ett stort program kan lugnt ha 1000 tabeller så att detta projekt skulle ha 20-30 stycken är inte alls konstigt.
4. Databashantering är nästan exakt samma sak som objektorienterad programmering. Dela upp allting i objekt och i beståndsdelar.
COMPONENT
------------------
ID
CODE
NAME
VALUE
POWER
DESCRIPTION
EXTENDED
SUPPLIER
------------------
ID
CODE
NAME
EMAIL
PHONE
ADDRESS
ZIP
CITY <-- Jo jag vet att man borde flytta ut CITY till en CITIES-tabell med bara ZIP och CITY så slipper man denna redundanta data...men hur praktiskt är det egentligen?
COUNTRY
SALESPERSON
------------------
ID
CODE
SUPPLIER
FORENAME
LASTNAME
EMAIL
PHONE
Osv...osv... Till exempel är det väldigt opraktiskt med ett personnamn som NAME. Det ska delas upp i FORENAME och LASTNAME så är det enklare att söka och sortera...
CODE-fältet är bara smaksak men det kan vara väldigt smidigt... Det ska vara en kort unik kod som beskriver t.ex. komponenten. R1K50W6 (Resistor 1.5kohm 0.6watt) på så sätt kan man själv komma ihåg vad man ska skriva in (om man inte använder en combobox förstås...). Så här gör ju butiker för att söka reda på sina produkter på datorn.
Den senaste halvtimmen spenderade jag med att skriva ett inlägg med den tabellstrukturen jag tycker skulle vara den riktiga. Jag jobbar som programmerare på ett företag som gör ERP-program så jag är helt inom rätt bransch. Men då jag var klar så fick jag kalla fötter...det liknade alldeles för mycket grundstrukturen på jobbet.
Så det blev till Ctrl-A + DeleteMen några tips har jag, det här är ju bara vad jag tycker så ni behöver absolut inte göra så.
1. Det känns väldigt mycket mer rätt med engelska tabell- och fältnamn.
2. Jag tycker om att tabell-namn och fältnamn är skrivna med versaler.
3. Snåla absolut inte med antalet tabeller! Ett stort program kan lugnt ha 1000 tabeller så att detta projekt skulle ha 20-30 stycken är inte alls konstigt.
4. Databashantering är nästan exakt samma sak som objektorienterad programmering. Dela upp allting i objekt och i beståndsdelar.
COMPONENT
------------------
ID
CODE
NAME
VALUE
POWER
DESCRIPTION
EXTENDED
SUPPLIER
------------------
ID
CODE
NAME
PHONE
ADDRESS
ZIP
CITY <-- Jo jag vet att man borde flytta ut CITY till en CITIES-tabell med bara ZIP och CITY så slipper man denna redundanta data...men hur praktiskt är det egentligen?
COUNTRY
SALESPERSON
------------------
ID
CODE
SUPPLIER
FORENAME
LASTNAME
PHONE
Osv...osv... Till exempel är det väldigt opraktiskt med ett personnamn som NAME. Det ska delas upp i FORENAME och LASTNAME så är det enklare att söka och sortera...
CODE-fältet är bara smaksak men det kan vara väldigt smidigt... Det ska vara en kort unik kod som beskriver t.ex. komponenten. R1K50W6 (Resistor 1.5kohm 0.6watt) på så sätt kan man själv komma ihåg vad man ska skriva in (om man inte använder en combobox förstås...). Så här gör ju butiker för att söka reda på sina produkter på datorn.
