kombinere udtræk fra to mysql tabeller

Tags:    php mysql array tables

Jeg har lavet en lille intern webshop og har brug for at varerne listes med forskellige priser alt efter hvilken kunde man er ved at bestille varer til. Der er differenceret priser.
eksempel: kunden med "firma_id: 14" skal have listet en udsalgspris fra varenr "10" hvor prisen er "120" og hvis det var kunden med "firma_id: 18" skal prisen listes til "130"

Tabel: intra_varenr
+---------+----------+--------------------+---------+------------------+
| vare_id | varenr | varenavn | Kollistr| kategori |billede|
+---------+----------+--------------------+---------+------------------+
| 1 | 10 | Øko. Ap.juice10ltr | 1 | 1 |10.jgg |
| 2 | 20 | Øko. Æblemost 10ltr| 1 | 1 |20.jpg |
+---------+----------+--------------------+---------+------------------+

Tabel: intra_upriser.
id = ai øges kontinuerligt; Fima_id referer til kundens stamdata i en anden tabel; 10 - 20- 30 - 40 - 50 - 60 - 70 er det samme som varenr i intra_varenr
+---------+----------+------+------+------+------+------+------+------+
| id | firma_id | 10 | 20 | 30 | 40 | 50 | 60 | 70 |
+---------+----------+------+------+------+------+------+------+------+
| 1 | 14 | 120 | 110 | 80 | 30 | 250 | 270 | 270 |
| 2 | 18 | 130 | 115 | 90 | 30 | 260 | 270 | 270 |
+---------+----------+------+------+------+------+------+------+------+

hvordan pokker får jeg linket de to tabeller sammen så jeg får den rigtige pris frem
Her er det kode jeg har lavet:
Fold kodeboks ind/udPHP kode 




Indlæg senest redigeret d. 25.05.2014 23:34 af Bruger #16819
7 svar postet i denne tråd vises herunder
3 indlæg har modtaget i alt 8 karma
Sorter efter stemmer Sorter efter dato
Jeg vil mene at dit databasedesign er forkert. Du risikerer forskellige record-længder, afhængig af antal varenumre. Hvad gør du, hvis du får 10 nye varenumre?

Selvfølgelig er en løsning muligt med det du har, jeg mener bare ikke det er den rigtige løsning.

Overvej i stedet at prisfilen hedder:

id | firma | varenummer | pris | gældende fra dato
1 | 14 | 10 | 120 | 01-01-1900
1 | 14 | 20 | 110 | 01-01-1900
.
.
.
osv.

Bemærk at jeg har lagt en gældende dato ind. Den kan du undlade. Det er kun for at forberede dig på, at du kan lave prisændringer frem i tiden, så den automatisk finder den nye pris.

På denne måde, laver du bare en helt almindelig join mellem de to tabeller for at finde den rigtige pris.





Jeg har lavet en standard pris i tabellen med varenr.
Troede bare at det ville være tungt med så mange records. Men når det ikke er et problem med hastigheden så er det jo det eneste rigtige :-)


Igen bør du overveje dit database-design. Hvad vil du gøre, hvis alle dine standardpriser skal hæves fra 31/12 kl. 00.00? Vil du så sidde og gøre det nytårsaften?

Lav en pristabel med varenummer, pris og gældende-fra-dato. Så kan du sidde 20 dage før og lave dit arbejde i stedet for.







Hvis du har et godt indeks på din database så er det ikke noget problem. Så skal den nok selv finde data hurtigt.

Grunden til at det er et langt bedre database design skyldes hvis du i fremtiden måske får andre varenummer end dem du allerede har.
Det system du har i dag er ikke sikkert virker i morgen, så derfor programmer altid så det er fremtidssikret



Mange tak for dit input, super god ide med dato den

Jeg har overvejet den databastruktur som du har skrevet opover. Der er i idag 50 varenumre og over flere hundrede kunder. Derfor tænkte jeg at min struktur ville give det bedste overblik og de færreste records.
Hvis jeg eks. vis ganger 50 varenumre med 300 kunder så får jeg 15.000 records i denne tabel.
mod 300 på den første model.
hvad kan være for og hvad kan være imod strukturen i de 2 tabeller ???





ok, det giver mening
Tak for hjælpen :-)



Du kunne jo lave en tabel med listepriser pr. varenummer. Og hvis en kunde så har sin egen pris, så ligger den i den anden tabel og ellers ikke.

Men du skal gøre det, fordi det er et godt databasedesign og fordi behovet er der. For performance-mæssigt betyder det ikke noget med 150.000 records i en tabel du joiner med, hvis indexes er lavet ordentligt.



Jeg har lavet en standard pris i tabellen med varenr.
Troede bare at det ville være tungt med så mange records. Men når det ikke er et problem med hastigheden så er det jo det eneste rigtige :-)



t