[Alg] database ontwerp bakkerij *

[Verwijderd]

Hey,

Ik zou een klein programaatje willen schrijven met php,mysql. Momenteel ben ik nog bezig met de database layout op te maken maar ik zit een beetje strop.

De site is bedoelt voor onze bakkerij waar de klanten hun bestellingen online kunnen invoeren. Ze moeten hun klantnr invoeren en leverdatum gevolgd door de bestelling zelf.

Mijn database layout ziet er momenteel zo uit:

klanten:
klantnr, klantnaam, NAW

koffiekoeken:
koeknr, koeknaam

bestelling:
bestelnr, leverdatum, koeknr, klantnr

Dit is nu maar even een ruwe schets maar iets zegt me dat er al iets niet juist zit. Hoe kan ik nu in de tabel bestelling de klant meerdere koeknr's laten invoeren? Weet iemand raad zodat ik verder opweg kan?

tnx

oei ik heb de topic verkeerd ingesteld denk ik. [ALG] dus

[ Voor 5% gewijzigd door Verwijderd op 20-09-2004 19:55 ]

[Voutloos]

Je wil meerdere koeknr per bestelling, dus moet je een relatie toevoegen als je een beetje op normalisatie let. Dus koeknr uit bestelling weghalen en een tabel bestelnr-koeknr erbij.

[.oisyn]

* Even je titel verduidelijkt

Je hebt een koppeltabel nodig die één of meerdere koeknr's aan een bestellingsnummer koppelt. Een aantal erbij zou ook wel handig zijn. In die nieuwe tabel krijg je dus per bestelling een aantal rijen, met voor elke rij hetzelfde bestelnr maar verschillende koeknr's.

Overigens heb je een tabel klanten en koffiekoeken, dus waarom geen bestellingen?

[Verwijderd]

Dat zit dus fout in je database model.

Wat je kan doen is een aparte tabel: bestellingen_inhoud.
Deze tabel bevat dan als velden: bestelnr, koeknr (ookwel: koppeltabel)

Zo kan je dus meerdere rijen invoegen met hetzelfde bestelnl, en verschillende koeknummers.

Het veld bestelnr is dan gekoppeld aan "bestelnl" uit de tabel "bestellingen".

Edit: /spuit 11...ik moet sneller leren typen .

[ Voor 10% gewijzigd door Verwijderd op 20-09-2004 20:00 ]

[gorgi_19]

bestellingen:
bestellingid (PK)
bestelnr (FK)
koeknr (FK)
orderdatum
leverdatum
klantnr
aantal

iets als dit bijvoorbeeld?

[ Voor 10% gewijzigd door gorgi_19 op 20-09-2004 20:01 ]

[Megamind]

Maak een tabel met producten aan ipv koffiekoeken:

Tabel: prodocuten
Kolommen: ID, Product Type, Prijs, enz

Dan kan je verschillende producten kwijt in 1 tabel, maar ik snap dit stukje niet van je

Verwijderd schreef op 20 september 2004 @ 19:54:
Hoe kan ik nu in de tabel bestelling de klant meerdere koeknr's laten invoeren? Weet iemand raad zodat ik verder opweg kan?

Je kan toch een klant de producten uit laten kiezen uit lijstjes, die opgehaald worden uit de producten tabel en daarna kan je bv alle productID's bij elkaar plakken met een implode, zodat je dit ziet in je tabel: 1,3,5,6,234,523.

[Alarmnummer]

Je moet niet op deze manier beginnen om een database model op te stellen. Je begint (bij het ontwerpen van een database) met een ERD (Entititeit Relatie Diagram). Daarbij definieer je eerst welke entiteiten er zijn (Klant, Bestelling, BestellingRegel, Product), wat de attributen zijn van de entiteiten (voornaam,achternaam, klantnr) en wat de relaties zijn + de cardinaliteiten (een klant heeft een of meer orders.. een order hoort bij 1 klant). En daarna ga je pas over op een datadictionary.

[R4NCOR]

Vat het niet verkeerd op, maar: Zou je met zulke geringe kennis van zaken een taak als deze - met toch wat verantwoordelijkheid - niet eens heroverwegen?

In ieder geval, een mogelijke oplossing... Maak 2 tabellen voor de bestellingen, eentje waaraan je een BestellingID aan een UserID koppelt, en eentje waarin je alle bestelde artikelen aan het BestellingID koppelt.

Succes.

edit: lekker laat dus weer

[ Voor 5% gewijzigd door R4NCOR op 20-09-2004 20:02 ]

[gorgi_19]

Megamind schreef op 20 september 2004 @ 20:00:
Je kan toch een klant de producten uit laten kiezen uit lijstjes, die opgehaald worden uit de producten tabel en daarna kan je bv alle productID's bij elkaar plakken met een implode, zodat je dit ziet in je tabel: 1,3,5,6,234,523.

Da's wel ontzettend eng, aangezien je op deze manier oa. je relaties / joins volledig vernaggeld.

[whoami]

gorgi_19 schreef op 20 september 2004 @ 20:02:
[...]

Da's wel ontzettend eng, aangezien je op deze manier oa. je relaties / joins volledig vernaggeld.

Idd, hoe ga je daar een snelle query rond bouwen, of wat als de klant z'n bestelling wil wijzigen, en een bepaalde 'koek' toch niet wil bestellen?
Als je zo bezig bent, dan kan je eigenlijk maar beter iets anders gaan doen...

[Verwijderd]

ok bedankt voor de vele reacties reeds. Ik weet dat dit een moeilijke opdracht is maar zo leer ik ook eens iets anders eh Heb het boek PHP,mysql,apache van Wrox gekocht, hopelijk helpt deze me iets verder.
Ik had nu iets als dit:

klanten:
klantnr, klantnaam, NAW

koffiekoeken:
koeknr, koeknaam

bestelling:
bestelnr, leverdatum, klantnr

klantenbestelling:
klantbestellingnr, bestelnr, koeknr

klantbestellingnr, bestelnr, koeknr, aantal
-------1-------, ---1---, 3002, ---250--
-------1-------, ---2---, 3003, ---254--
-------1-------, ---3---, 3002, ---200--

Trekt dit al op iets?

[ Voor 4% gewijzigd door Verwijderd op 20-09-2004 20:09 ]

[gorgi_19]

Hangt er van af of je nog in een historie in die database wil bijhouden

[whoami]

Ik snap niet goed wat klantbestellingnr in klantenbestelling is?

Ik zou de tabel Bestelling en 'klantenbestelling' er zo laten uitzien:

Bestelling
BestellingId (PK)
BestelDatum
KlantId
LeverDatum

BestelRegels (bij jou heet die dus KlantenBestelling
BestelRegelId (PK, auto-incr)
BestellingId (FK naar Bestellingen tabel)
KoekId (FK naar Koeken tabel)
AantalBesteld

[Verwijderd]

Dit klink als eens huiswerkopdracht, want aan je posts te lezen weet je hier bijna niks vanaf...relationele databases etc...en een bakker zou nooit iemand inhuren om een toch wel redelijk belangrijk deel van zijn digitalisering te laten maken.

Modbreak:

en wat bedoel je nou precies te zeggen met deze totaal niets toevoegende post?

[ Voor 17% gewijzigd door .oisyn op 20-09-2004 20:19 ]

[whoami]

Verwijderd schreef op 20 september 2004 @ 20:17:
Dit klink als eens huiswerkopdracht, want aan je posts te lezen weet je hier bijna niks vanaf...relationele databases etc...en een bakker zou nooit iemand inhuren om een toch wel redelijk belangrijk deel van zijn digitalisering te laten maken.

En dan? Huiswerktopics mogen nog altijd, zolang je maar zelf ook moeite doet als TS.

[Verwijderd]

Wij hebben al een site waar men bestellingen kan invoeren. Het probleem is dat deze in een formulier gebeuren en via mail doorgestuurd wordt. Het gevolg is dat we uren moeten tellen om een totaallijst op te stellen zodat we weten hoeveel we exact moeten maken. Nu wil ik via php en mysql dus dit automatiseren zodat we uiteindelijk een totaallijst krijgen en dan nog eens per klant een lijst (om achteraf klant per klant in te laden) en misschien nog een facturatie. Het is niet de bedoeling dat dit vlug vlug klaar is dus tijd is geen probleem. Ik zal het ook nooit laten gebruiken wanneer het niet correct werkt. Het is dus heus geen huiswerktaakje!

[GambitRS]

Als je makkelijk ongehinderd door enige kennis snel een database wilt ontwerpen kan je het programma Dezign eens proberen, van datanamic: http://www.datanamic.com/dezign/
Hiermee kan je snel een database genereren zonder dat je letterlijk SQL zit te typen (het is gewoon slepen en lijntjes trekken tussen tabbellen voor relaties) en zal je waarschijnlijk helpen om sneller je database design af te hebben. Je ziet dan de totale structuur ook veel overzichterlijker, dan hoef je niet met losse tabellen in je hoofd te gaan zitten werken.

Eventjes snel gemaakt:

code:

#========================================================================== #
#  Tables                                                                   #
#========================================================================== #

CREATE TABLE Klant (
    klantnr INTEGER NOT NULL,
    naam TEXT NOT NULL,
    adres TEXT NOT NULL,
    woonplaats TEXT NOT NULL,
    PRIMARY KEY (klantnr),
    UNIQUE KEY IDX_Klant1(klantnr)
) type=InnoDB;

CREATE TABLE Koffiekoeken (
    koeknr INTEGER NOT NULL,
    naam TEXT NOT NULL,
    PRIMARY KEY (koeknr),
    UNIQUE KEY IDX_Koffiekoeken1(koeknr)
) type=InnoDB;

CREATE TABLE bestelling (
    bestelnr INTEGER NOT NULL,
    leverdatum VARCHAR(40) NOT NULL,
    klantnr INTEGER NOT NULL,
    PRIMARY KEY (bestelnr),
    KEY IDX_bestelling1(klantnr),
    UNIQUE KEY IDX_bestelling2(bestelnr)
) type=InnoDB;

CREATE TABLE bestelling_Koffiekoeken (
    bestelnr INTEGER NOT NULL,
    koeknr INTEGER NOT NULL,
    aantal INTEGER NOT NULL,
    PRIMARY KEY (bestelnr, koeknr),
    KEY IDX_bestelling_Koffiekoeken1(bestelnr),
    KEY IDX_bestelling_Koffiekoeken2(koeknr)
) type=InnoDB;

#========================================================================== #
#  Foreign Keys                                                             #
#========================================================================== #

ALTER TABLE bestelling
    ADD FOREIGN KEY (klantnr) REFERENCES Klant (klantnr);

ALTER TABLE bestelling_Koffiekoeken
    ADD FOREIGN KEY (bestelnr) REFERENCES bestelling (bestelnr);

ALTER TABLE bestelling_Koffiekoeken
    ADD FOREIGN KEY (koeknr) REFERENCES Koffiekoeken (koeknr);

Dit zou een goede database moeten opleveren, tenminste als je mysql gebruikt met innoDB support (versie 4 en hoger heeft dat automatisch).

Owjah, van besteldatum is ook nog wel een datetime te maken oid, maar dat kan als je niet precies weet waar je mee bezig bent best lastig zijn, omdat je dan de goede syntax moet blijven gebruiken. Vandaar een varchar

[ Voor 69% gewijzigd door GambitRS op 20-09-2004 20:37 ]

[Verwijderd]

ok hartelijk bedankt
Ik was het enkel nog maar in acces bezig zodat ik ongeveer de layout al had.
Want mysql zal voor mij ook studeren worden hehe

Ik zal met al deze gevens die gepost zijn proberen een goede database te maken en dan het resultaat hier posten.

[Verwijderd]

Ik heb mijn database grof gecreëerd en via een simpel php scriptje wil ik alle velden uit de tabel "koeken" uitlezen.

De code is als volgt:

<?php
$connect = mysql_connect("localhost", "root", "deskjet400") or
die ("Hey er is iets mis met je server connectie");

mysql_select_db("bakker");

$query="SELECT *
FROM koeken
ORDER BY naam";

$results=mysql_query($query) or die(mysql_error());

while ($rows=mysql_fetch_array($results)) {
extract($rows);
echo $koeken_nr;
echo " --- ";
echo $koeken_naam;
echo "<br>";
}
?>

Dit is het resultaat dat ik krijg:

Warning: mysql_connect(): Access denied for user: 'root@localhost' (Using password: YES) in c:\web\test.php on line 2
Hey er is iets mis met je server connectie

Als ik in mijn my.ini Setup kijk van winMySqlAdmin zie ik het volgende:
[WinMySQLadmin]
Server=C:/mysql/bin/mysqld-nt.exe
user=root
password=deskjet400
QueryInterval=10

Weet er iemand wat er mis kan zijn?

de url die ik typ is: http://localhost/test.php


probleem opgelost
moest blijkbaar passwoord invullen in een config

[ Voor 19% gewijzigd door Verwijderd op 21-09-2004 01:00 . Reden: opgelost ]

[GambitRS]

ik zou eventjes je rechten tabel een beetje bijschonen. De standaard accounts zoals root zonder wachtwoord zijn natuurlijk een beetje riscant.

[SuperRembo]

Als er straks ook broden besteld moeten kunnen worden, dan ga je er toch geen tabel "broden" bij maken hè?

[Voutloos]

SuperRembo schreef op 21 september 2004 @ 11:33:
Als er straks ook broden besteld moeten kunnen worden, dan ga je er toch geen tabel "broden" bij maken hè?

De tabel 'koffiekoeken' de algemere naam 'Producten' geven lijkt mij geen slecht plan.

Maar goed, als hij per se wil kan hij een brood als Koffiekoek opslaan.

[ Voor 6% gewijzigd door Voutloos op 21-09-2004 11:40 ]

[Verwijderd]

Ik was eigenlijk wel vanplan aparte tabellen aan te maken
broden,koeken,drooggebak,taarten,pistolets

[djluc]

Verwijderd schreef op 21 september 2004 @ 22:36:
Ik was eigenlijk wel vanplan aparte tabellen aan te maken
broden,koeken,drooggebak,taarten,pistolets

Dat is niet aan te raden in dit geval. Een tabel producten is een betere optie. Een extra tabel met product_typen kan dan inderdaad die waarde broden/koeken/enz bevatten. Met behulp van de id's koppel je een producttype aan een product.

[Verwijderd]

Verwijderd schreef op 21 september 2004 @ 22:36:
Ik was eigenlijk wel vanplan aparte tabellen aan te maken
broden,koeken,drooggebak,taarten,pistolets

En het leerproces gaat door .

Bij het ontwikkelen van een database-model moet je letten op objecten en de eigenschappen van deze objecten.

Broden, koeken, taarten etc. zijn eigenschappen van het object producten.

Toelichting: In een bakker heb je allerlei producten die verkocht worden, elk product heeft allerlei eigenschapen...verkoopprijs, naam, etc. etc. (wat voor de bakker en/of klant interessant is)
In het begin lijkt het handig om de koeken allemaal in een tabel onder te brengen, maar dan moet je voor een nieuw product in het assortiment een nieuwe tabel aanmaken...wat de dynamiek niet bevorderd (stel je hebt meerdere tabellen, hoe weet de database dat een amandelkoek in de tabel koeken hoort? Dit zet je dus hardcoded in de source...).

Straks heb je dus 10 tabellen met dubbele kolommen...elke tabel heeft straks dezelfde eigenschappen van het product, lijkt het dan niet handig om dit in een tabel onder te brengen ?

Verder is normaliseren ( (link uit de FAQ) een belangrijk begrip als je het over relaties tussen tabellen hebt.

_{Als er echt iets fouts in staat...ik sta open voor commentaar}

[Verwijderd]

Verwijderd schreef op 21 september 2004 @ 23:25:
Broden, koeken, taarten etc. zijn eigenschappen van het object producten.

Broden, koeken, taarten etc. zijn instanties van het object producten

[kaandorp]

Ik zou zowieso in de tabel bestellingen geen klant_id, koek_id, etc opnemen. Als je namelijk een klant verwijderd omdat deze geen klant meer is zul je nooit meer de historie van een order kunnen bekijken. Hetzelfde geld voor producten. Als een product (door inflatie bijvoorbeeld) van prijs veranderd zal volgens het huidige model dit ook invloed hebben op de geplaatste orders. En dat wil je niet natuurlijk.

[MisterData]

Maak er dus een tabel bij:

code:

product_typen:

producttype_id (PK)
producttype_naam

En zet daar dan (1, "Koffiekoeken") etc in... die producttype_id gebruik je dan in je producten-tabel

[kaandorp]

Product_id etc gebruik je natuurlijk wel tijdens het samenstellen van de order. Echter wanneer de order wordt opgeslagen zou ik alle info gewoon "plat" in de order tabel plempen.

[ Voor 11% gewijzigd door kaandorp op 22-09-2004 10:21 ]

[whoami]

kaandorp schreef op 22 september 2004 @ 10:20:
Product_id etc gebruik je natuurlijk wel tijdens het samenstellen van de order. Echter wanneer de order wordt opgeslagen zou ik alle info gewoon "plat" in de order tabel plempen.

Wat bedoel je hiermee?

[kaandorp]

whoami schreef op 22 september 2004 @ 10:28:
[...]


Wat bedoel je hiermee?

Ik doe bijvoorbeeld het volgende voor een webshoppie in PHP.
Ik heb een tabel producten met daarin:
- product_id
- categorie_id
- product_name
- product_description
- etc.

en een tabel categories met daarin:
- categorie_id
- categorie_name
- etc.

Voor de order een tabel orderlines:
- orderline_id
- order_id
- product_name
- amount
- price
- etc.

en een tabel orders met daarin:
- order_id
- datum
- naam
- adres
- postcode
- etc.

Dus in de tabel orderlines zet ik geen product_id, maar echt de volledige naam en prijs, zodat je een order altijd terug kunt kijken en dan ook echt ziet hoe de order was ongeacht of het product in de tussentijd veranderd of verwijderd is.

Dat is eigenlijk een beetje wat ik bedoel

[Verwijderd]

Verwijderd schreef op 21 september 2004 @ 23:25:
[...]

En het leerproces gaat door .

Verder is normaliseren ( (link uit de FAQ) een belangrijk begrip als je het over relaties tussen tabellen hebt.

Ben ik het helemaal mee eens.

Begin ook niet direct met bouwen in PHP; als de structuur van de database niet goed blijkt kan je alles weer slopen. MS-Access is een leuke croft-tool, ontwerpen met pen en papier is ook best OK.

Verder heb ik hier nog een linkje over referentiele integriteit:
http://www.databasejourna...mysql/article.php/2248101
wat iets is wat nog wel es over het hoofd wordt gezien. Errug nuttig en errug prettig. MS-Access kent dit ook, daar kan je er lekker mee spelen.

[Eelke Spaak]

Alarmnummer schreef op 20 september 2004 @ 20:01:
Je moet niet op deze manier beginnen om een database model op te stellen. Je begint (bij het ontwerpen van een database) met een ERD (Entititeit Relatie Diagram). Daarbij definieer je eerst welke entiteiten er zijn (Klant, Bestelling, BestellingRegel, Product), wat de attributen zijn van de entiteiten (voornaam,achternaam, klantnr) en wat de relaties zijn + de cardinaliteiten (een klant heeft een of meer orders.. een order hoort bij 1 klant). En daarna ga je pas over op een datadictionary.

Misschien wat off-topic, maar aangezien we het toch over databaseontwerp in het algemeen hebben: hier ben ik het niet mee eens. Ik vind het maken van een ERD (of, nog erger, ORM-fact lijsten samenstellen) omslachtig en niet nodig. In mijn hoofd heb ik wel een idee van wat entiteiten zijn, hoe de relaties ongeveer moeten lopen en welke eigenschappen een entiteit kan hebben. Hiermee kan ik prima een volledig genormaliseerd databaseschema ontwerpen, en heb ik weer wat tijd bespaard .

[ Voor 1% gewijzigd door Eelke Spaak op 22-09-2004 14:46 . Reden: zinsbouw ]