[MySQL] automatisch waardes invullen

Pagina: 1
Acties:

  • turkosh
  • Registratie: December 2003
  • Laatst online: 26-04-2025
Hoi,

Klein vraagje d.m.v. voorbeeld.
Voorbeeld:
2 tabellen

tabel 1: artikel
ID, artikel_omschrijving, prijs, btw, productid, barcode

tabel 2: verkoop
verkoopid, id, artikel_omschrijving, prijs, btw, productid, t_stamp

natuurlijk de (id) in tabel 2 references tabel 1.

Is het mogelijk om op een "makkelijke" manier andere gegevens automatisch af te lezen bij het vullen van de id (of elk ander kolom die in tabel 1 voorkomt)?
(Dus dat artikel_omschrijving, prijs, btw, productid automatisch worden ingevuld).
Dit in verband met dat een soort artikel meerdere malen verkocht wordt. Dus handig met het invullen van de verkoop tabel.

alvast tnx.

  • OkkE
  • Registratie: Oktober 2000
  • Laatst online: 10-11-2025

OkkE

CSS influencer :+

Ik zou in de verkoop tabel alleen de ID van de artikel-tabel opnemen. Waarom alles dubbel opslaan?

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.


  • -=bas=-
  • Registratie: Oktober 2000
  • Laatst online: 22-04-2025
[school mode]
Wat zijn de vijf normaliseringsregels ook al weer?
[/school mode]

Senile! Senile Oekaki


  • OkkE
  • Registratie: Oktober 2000
  • Laatst online: 10-11-2025

OkkE

CSS influencer :+

Zoeken bij Google op 'database+normaliseren'...

Leverd bijvoorbeeld het volgende PDF bestand op. Daar staat een hoop info in, als je die eens door leest kom je heel veel te weten over databases en hoe je ze het beste kunt indelen/opbouwen.

___ Edit ______________

tabel: Artikelen
ID
omschrijving
prijs
btw
product_id
barcode

tabel: Verkocht
ID
product_id
tstamp

Zo heb je geen onnodige dubbele informatie in je tabel. Als er nu iets verkocht wordt hoef je alleen Verkocht aan te passen, met maar 3 velden; waarvan ID auto_increment is en tstamp de datum+tijd.
Wil je nu de product informatie hebben van de verkochte artikelen doe je gewoon een JOIN, en klaar ben je. :)

[ Voor 38% gewijzigd door OkkE op 04-12-2003 16:18 ]

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.


  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

_bas_ schreef op 04 december 2003 @ 15:56:
[school mode]
Wat zijn de vijf normaliseringsregels ook al weer?
[/school mode]
Er zijn er meer dan vijf ;)

Overigens is het niet verstandig te normaliseren als de prijzen, omschrijvingen etc kunnen veranderen en je zeker wilt weten dat de verkoopregels in de toekomst nog steeds geldig zijn.

Overigens is dat op te lossen door iets als "verkoopbaar" in te voeren en elke keer dat je een verandering aan je product maakt een nieuw product toe te voegen ipv je oude te veranderen en de oude op onverkoopbaar te zetten.

  • turkosh
  • Registratie: December 2003
  • Laatst online: 26-04-2025
Hey bedankt voor de les, had het denk ik nodig.
Ik zit nog steeds te sukkelen tussen gegevens tabellen in een rapport (query) en opbouw van een tabel. Maar dat krijg je als je een db gaat opzetten (reconstrueren) aan de hand van een dag(shift)rapport van een zaak.

Trouwens,
Wat is de beste manier om een verkoop te simuleren. Dus dat er gegevens worden weggeschreven met invoeren van de artikel id of barcode (scannen). En daarna een simulatie dagrapport uitdraaien d.m.v. een automatische trigger?
Pagina: 1