Svenska ElektronikForumet

Om det är samma komponent så spelar det väl ingen roll vilken som är levernatör? Att det finns två poster för en och samma komponent verkar lite förvillande tycker jag (bara levernatör som skiljer). Då är det bättre att seprarera komponentens (EN post) leverantörer till en annan tabell m.h.a. en referenstabell.
Alla vägar bär till Rom, kan ta lite olika lång tid att ta sig dit bara. =) Det finns många sätt som fungerar, vissa bra, vissa dåliga.
Hur du väljer att lagra samma komponent från olika levernatörer är ju en smaksak kanske. Men övergripande databasdesign underlättar en hel del. Med det menar jag det som vfr och pagge redan skrivit, nämligen att undvika redundant data (dina leverantörsuppgifter finns t.ex. i alla poster i alla tabeller) samt att undvika dynamisk tabellhantering (det enda som skiljer mellan tabellerna är ju faktiskt komponenttypen och det skulle du kunna ha I en tabell istället för SOM en tabell).
Hoppas du är med? =) Jag har själv börjat precis som dig och det tar ett tag att förstå "tänket" när det gäller smart databaskonstruktion...

Dessvärre är jag inte med tillräckligt.

"Att det finns två poster för en och samma komponent verkar lite förvillande tycker jag (bara levernatör som skiljer). Då är det bättre att seprarera komponentens (EN post) leverantörer till en annan tabell m.h.a. en referenstabell."

Menar du att leverantörerna (säljare) får en egen tabell? Vad mer ska den innehålla än en lista på de olika säljare? När kommer den tabellen användas?

Att jag har med säljare är bara för att veta vilken inköpslista varje komponent ska hamna i när de börjar ta slut. Det betyder alltså inte att jag har samma komponenter från olika tillverkare. Däremot ska man kunna ha det ifall t.ex Trimlog upphör och jag tidigare köpt en viss komponent därifrån. Tills dessa tagit slut i mitt lager så finns det dubbla uppsättningar, där den nya artikeln kommer från en annan säljare. Hur skulle man annars ha löst detta?



Det finns förresten en viktig grejj med mitt projekt: När man använder databasen (genom php-sidorna) så ska man inte behöva byta mellan flera olika sidor. Såhär har jag tänkt:

Sida 1) Här väljer man komponent-typ och ser alla sådana komponenter som finns i lager. Där kan man även söka efter specifika komponenter.

Sida 2) Här lägger man till nya komponenter och editera de som redan är inlagda.

Sida 3) Här visas de komponeter som börjar ta slut. En lista för Elfa, en för ClasOhlsson, en för Kjell, osv. Dessa listor ska enkelt kunna överföras till Excel eller beställnings-mail. De olika säljarnas listor är därför formatterade lite olika för att passa varje leverantörs beställnings-formulär. Egentligen består denna sida av flera undersidor, men det gör inget eftersom man spenderar minst tid här. I de flesta fall man använder systemet så lägger man till eller tar bort antal för komponenterna.

Alltså: Vill man bara titta i listan väljer man sida 1. Vill man editera väljer man sida 2. Vill man beställa väljer man sida 3. Lätt som en plätt.

Menar du att leverantörerna (säljare) får en egen tabell? Vad mer ska den innehålla än en lista på de olika säljare? När kommer den tabellen användas?
Ja precis, de får en egen tabell som ser ut såhär:
tbl_levernatörer
-index (autoincrement, unik siffra)
-namn
-adress
-tel

Det enda du anger för "levernatör" i din komponenttabell är då vilket index som återförsäljaren har i tbl_leverantörer. Hänger du med? På så vis kan du uppdatera leverantörerns adress genom att ända på ETT ställe. Det finns många andra fördelar också men jag är för hungrig för att komma på dom nu Ledsen att jag inte har fler argument, men en av grundtankarna med databaser är att "separera" objekt i den mån det går...

Ok, överkursen:
Låt säga att du alltid vill ha BC547 på lager. Dessa finns hos både Elfa och Farnell.
Att "berätta det" på ett smart sätt i databasen kan göras på följande vis:

I komponenttabellen(Index, typnr, beskr., antal):
1;NE555;En timer;45;
2;BC547;Transistor;4;
3;2N2222;Transistor;2;

I leverantörstabellen (Index, namn, tel):
1;Elfa;08-12345;
2;Farnell;08-54321;
3;Kjell.com;08-98765;

Referenstabellen (komponentindex, leverantörsindex):
2;1
2;2

I referenstabellen kan man se att komponent 2 finns hos leverantör 1 samt att komponent 2 finns hos leverantör 2. Att lägga in 3;1 skulle ge betydelsen : "2N2222 finns att beställa från Elfa"

Artikelnumret då? Jo eftersom artikelnummer är unikt för en kombination av komponent<->levernatör så bör det läggas in som en kolumn i referenstabellen.


Lösningen med siduppdelningen låter mycket bra! En sak i taget helt enkelt!


Edit: Verkar finnas en länk mellan pagges och min hjärna... men jag var sekunden före. =)
För att förhindra problem: Har man PHP4 så kan man INTE använda nästlade SELECT. JOIN fungerar dock men är krångligare. Från och med PHP5 fungerar nästlade select (och en massa annat godis).

Det här är ett sätt att lägga upp systemet på så du aldrig behöver göra nya tabeller och ingen data lagras på två ställen. Man försöker hela tiden tänka "Vilka saker hör ihop" eller "Vad är specifikt för den här saken" och samla ihop dessa.

Tab1 Hemmalager:
KomponentId, Antal
1, 8
2, 4
//Vilka komponenter har du hemma.

Tab2 Återförsäljare
säljarId(unik), Säljarnamn, Övrigt...
1, "Elfa", "dyr men snabb leverans"
2, "Lawicel", "trevlig leverantör med uC fokus"
//Allt generellt för en viss återförsäljare hamnar här.

Tab3 Återförsäljarlager
komponent, återförsäljare, artikelnummer, pris
1, 1, "73-647-06", 33
1, 2, "ATMEGA88-20PU", 29
2, 1, "73-646-56", 23
2, 2, "ATTINY2313-20PU", 26
//Här lägger man allt som är specifikt för en viss komponent hos en viss återförsäljare. t.ex. artilkelnummer är specifikt för en viss återförsäljare och produkt, därför hamnar det här.

Tab4 Komponenter:
KomponentId(Unik), Namn, ÖvrigKomponentSpecifikInfo
1, "ATmega88-20PI", "Gullig mellan uC"
2, "ATtiny2313", "Gullig liten pytte uC"
//Enkelt att lägga till fler komponenttyper här. Allt som är specifikt för en viss komponent, men oberoende av återförsäljare hamnar här. Därför är artikelnummer inte med i denna tabell, det varierar med återförsäljare.

Vill du lista namnet på alla komponenter du har hemma kan du göra en sånhär fråga (Detta kanske man bör göra mha join, men det har jag aldrig lärt mig. principen är densamma dock )

select * from hemmalager,komponenter where hemmalager.kompoentId=komponenter.komponentId && antal>0;

notera att jag måste specificera vilken tabell jag skall använda om fälten heter samma i bägge därav komponenter.komponentId istället för bara komponentId

Vill du ha fram vilka säljare som säljer en mega88 tar du idnummret du (bland annat) fick i förra frågan och frågar

select * from återförsöljarlager, återförsäljare where säljarId=återförsäljare && komponent=1 order by pris

Med reservation för diverse slarvfel tror jag detta skall funka

Blev det lite klarare?

sodjan skrev:> Sen står det också i API att mysql_db_query är deprecated och
> att man bör använda mysql_query istället, inte för att det bör
> ha något med detta felet att göra.

Och varför skulle det inte ha något med felet att göra ?
Funktionerna har olika antal parametrar (3 resp 2) och kan inte
bara bytas ut mot varandra hur som helst (med samma parametrar).

Vad jag menar är att felet är inte att metoden är deprecated, felet är att han använder metoden på fel sätt alt. fel metod.

Man kan fortfarande använda metoder som är deprecated även om det inte är tänkt så för nyutveckling. Ungefär som ditt prat om att inte använda uråldriga PIC mikrokontrollers

/andreas

oJsan & Pagge: Nu blev det mycket klarare!

Det skulle ju ge massor med nya och bra möjligheter om jag byggde databasen så istället.


Hm, jag ska nog uppgradera till PHP5. (kör PHP4 nu.)
Det är väl inget som bör försvinna? Ska förstås ta backup ändå, men det kan vara bra att veta om man kan förvänta sig några "konstigheter".
Eller, vänta nu... det är ju Linux vi pratar om. Då bör det vara lugnt.

Om du behöver ny funktionalitet så uppgradera, annars är ett tips att köra med den version du har. Uppgraderade själv för någon vecka sedan och det blev en hel del problem med egna klasser och externa libs som jag använder mig av. Nu behöll jag 5:an ändå och gjorde de förändringar som behövdes, främst för att inte slösa tid. Men som sagt, hade jag tänkt till innan hade jag skippat uppgraderingen och sparat ett antal timmar...

/offe

En komponentdatabas verkar ju intressant. Tom så intressant, att jag bestämde mig för att snickra ihop en:

Förstasidan:


Lista alla komponenter*:


Sök**:


Kateorogilista***:


Ändra namn på kateorogi****:


Ny inmatning*****:




TODO:

*: Sort-texten visar nu ID:n kateorogin har. Detta skall fixas så att den visar kateorogins text istället. Modifiera och Ta en-länkarnas kodning har inte ens påbörjats EDIT: Fixat så att kateorogitexterna skrivs ut istället för siffror.

**:Sökfunktionen är inte ens påbörjad

***:Konstigt(?) nog fungerar allt här

****:Fungerar ej att byta namn på komponentgrupp

*****:Kodning för ny inmatning inte ens påbörjad. EDIT: Fixat, det fungerar perfekt, förutom att alternativen är siffror som representerar ID-nummret för komponentkateorogierna, inte kateoroginamnet.


Jag har ledigt denna vecka från skolan (höstlov) så skall försöka få projektet klart. Källkoden är inte den bästa, det är i princip php.com-exempel jag modifierat att passa mig. Men det fungerar.
Dock finns det inte det minsta skydd för sql-injections, så man får skydda sidan med t.ex. .htaccess.

oJsan> Dessutom... vyer används väl inte för att förenkla för SQL-programmeraren,...

Ja, alltså att förenkla för den som skriver SQL kod mot databasen, det kallar jag "SQL-programmeraren".

Den som designar och lägger upp *vyerna* (och allt annat, index o.s.v.) jobber med DBA frågor, inte programmering...

> den största fördelen får ju PHP-programmeraren! (eller det språk man nu använder).

Precis vad jag sa (eller menade i alla fall...) !

> Eftersom det (troligtvis) är Jimmy som arbetar med båda sakerna så finns
> det inte så mycket att vinna på att använda vyer.

Jo, det finns en *jättestor* fördel. Man kan (inom vissa gränser) ändra den
fysiska designen av tabellerna utan att ändra "gränsnittet" mot (t.ex) PHP.

Många databaser kan pre-optimera vyer vilket kan ge bättre prestenda
jämfört med om motsvarande SQL skickas in som dynamisk SQL.
Nu tror jag inte att det spelar så stor roll i mindre/simplare databaser
som MySQL, den har ju inte mycket till optimerare i alla fall...

Var för övrigt i helgen hos en kund och jobbade med en *riktig* databas...

Ett allmänt tips för att hitta kodexempel är att använda googles sökmotor för källkod. Den finns på följande URL: http://www.google.com/codesearch

I sökningen kan man även ange saker som programspråk och licenstyp. Dessutom klarar den reguljära uttryck i söktexten.


Ett annat tips är att när du tröttnat på PHP och MySQL så kan du kolla på Ruby on Rails. http://www.rubyonrails.org/ För väldigt många är det många gånger väldigt mycket mer produktivt än egna PHP-lösningar från scratch. Om man ändå vill hänga kvar i PHP finns det ramverk för PHP som liknar ruby-on-rails.

Yay, lyckades skriva en whileloop som ändrar komponenttypsIDn till namn. Nu är det inte mycket kvar...

Tittade igenom www.php.net och såg några grejjer som jag testat och som bara fungerar på PHP5.
Sprang genast till Linux-burken och kollade:

Apache/1.3.34 (Debian) PHP/5.1.2-1

Jag hade visst redan PHP5. Lucky me!


Macce: Snyggt jobbat!

Har börjat jobba med den nya versionen av databas-strukturen nu.


Men det är en sak jag undrar över:
Hur får jag in artikel-nummren? De hör ju både ihop med leverantören och komponentvärdet.
Det slog mig att detta tänkande påminner om när jag läste systemteknik.

Sitter och lyssnar på John Schmidt nu. Mycket bra musik som passar utmärkt när man har myror i huvudet.

Titta på pagges exempel längre upp i tråden, han förklarar ganska bra där. Artikelnummer finns med i det exemplet så jag är inte riktigt med på vad det är du är ute efter?

/offe

Jmmy, i Tabell 3 finns artiklenummer och pris med. En annan sak. När men gör en sökning ur flera tabeller som jag gjorde i exemplen. Hur blir det egentligen då?
Tab1 husdjur:
Id, Namn
1, "Spinnarn"
2, "Voffen"

Tab2 djurinfo:
Id, Typ
1, "Katt"
2, "Hund"
3, "Hamster"

Nu vill du få fram sorten på namnen i första tabellen :lol:

Du gör en sökning
select * from husdjur,djurinfo where husdjur.Id=djurinfo.Id
Och får fram info om dina djur, men vad hände egentligen? Jag brukar tänka såhär (även om det med största säkerhet optimeras och inte går till exakt så i databasen).

Först skapas en tabell med alla kombinationer mellan raderna i de bägge tabellerna
husdjur.Id, namn, djurinfo.Id, Typ
1, "Spinnarn", 1, "Katt"
1, "Spinnarn", 2, "Hund"
1, "Spinnarn", 3, "Hamster"
2, "Voffen", 1, "Katt"
2, "Voffen", 2, "Hund"
2, "Voffen", 3, "Hamster"

Sen kollas kravet man lägger till efter sökningen, i det här fallet husdjur.Id=djurinfo.Id. Kvar blir då bara rad 1 och 5 i den långa tabellen,

husdjur.Id, namn, djurinfo.ID, typ
1, 1, "Spinnarn", "Katt"
2, 2, "Voffsen", "Hund"

Eftersom det är så oeffektivt så är det garanterat inte såhär det går till i verkligheten, men det funkar bra att tänka såhär när man skall skapa en fråga. "Alla rader paras ihop med alla, sen tillämpas where satsen"