database model goed?

Iemand die het anders zou doen? Is dit goed?
kastabel -> planttabel = 1 op veel toch?



Als hij hem niet goed weer geeft hier, kan je hier klikken: http://www.c-jochemsen.nl/agrarier.JPG

illegale weed plantage ??

Ik geloof dat je met dit soort vragen beter terecht kunt bij GoT.

Maar idd, 1 op veel, want een plant kan maar in 1 kas staan, maar in een kas kunnen wel meerdere planten staan.

Edit:
Zoek eens naar Dezign for Databases of DBDesigner, handige tools voor het maken van een nette ERD.

kweet zeker dat hier ook heel wat mensen zitten die er wat vanaf weten.
tweakers ga ik wel kijkje nemen. had me ooit geregistreerd maar weet username en pass nie meer

Oh ja is ook wel zo, maar het serieuze reply gehalte is tamelijk laag

ja maar zitten meestal wel paar goeie tussen en daar heb ik hopelijk genoeg aan

Overigens zie ik er niet zoveel fouts aan (alhoewel ik geen ster ben in database ontwerp)

Wel zou ik in de plantensoort tabel nog even een numeriek ID aanmaken (plantensoort is ongetwijfeld uniek maar toch), misschien is dat een persoonlijke voorkeur, ik vind het iig fijn.

Tsja, heeft wel wat....

Hangt beetje vd toepassing af.

Ik zou zelf al die gegevens in 1 rijtje zetten.
Dan kun je nl met 1 query al die gegevens opvragen.

Heb nu een rijtje data.
Tja, dat heeft wel wat, en nu?

Dat kan sowieso wel met het gebruik van JOINs en UNIONs

Hmmm, joint lus ik ook wel....

Dat werkt wel beter idd.

Ik zou dat zowieso met namen ed doen.
Evt link je die tag aan een naam. Er zijn verschillende dingen mogelijk.

Maar ik denk dat je je moet gaan richten op het proces dat uit te voeren is. Dan weet je nl ook, welke gegevens je nodig bent, en hoe je die moet indelen.

Ik zou zeker nog primary en foreign keys aangeven in je diagram.

Daarnaast valt er wat voor te zeggen om een tabel te maken met planten en een aparte tabel met iets als oogsten. Een oogst verwijst dan naar een bepaalde plant (waarbij een plant weer naar een soort kan verwijzen).

de bovenste velden zijn de keys en autoincrement.
Bij de plant soorten moet idd nog een soortID ofzo komen bovenaan.
Maar ik neem aan dat dit ontwerp opzich wel ok is?
Want iemand anders zei nog dat ik de luchtvochtigheid en temp velden in de tabel plantensoorten moest doen. Maar dat snap ik dan weer niet want alles staat goed met elkaar in verbinding doormiddel van relaties dus lijkt me niet nodig.

ik kan dat plaatje helemaal niet goed zien

daarom heb ik de link er bij gezet zodat hij wel op goeie grootte opend

o

wat is dit voor model, er staat helemaal niet in wat 1 op veel veel op 1 enz relaties zijn...

mja klopt. gaat meer om de velden. De relaties kan je ff weg denken, of die streepjes zijn voldoende.
van kastabel -> plantentabel = 1 op veel
van plantentabel -> verzendingtabel = 1 op 1 lijkt me
van plantsoorttabel -> plantentabel = 1 op veel

volgens mij klopt veiling onder planten niet... dat hoort in verzending tabel, want een verzending gaat naar 1 veiling en niet een plantsoort er kunnen meerdere verzendingen van 1 plantsoort zijn die naar verschillende veilingen gaan.....

Hmm verzendingstabel is niet echt goed, das een procesgegeven als je het mij vraagt en is dan eerder een veel op veel relatie met entiteit veiling. Daar naast moet je plantsoort op kas hangen. En je vergeet wat attributen. Je krijgt de volgende tabellen. Ze zijn al genormaliseerd dus relaties kan je vinden:

Planttabel:
Plant_ID
Plantsoort_ID
Plant_naam

Plantsoorttabel:
Plantsoort_ID
Plantsoort_naam

Kastabel:
Kas_ID
Plantsoort_ID
Kas_naam
Luchtvochtigheid
Temperatuur

Oogsttabel:
Oogst_ID
Oogst_naam/omschrijving


Plant_wordt_geoogsttabel:
Plant_ID
Oogs_ID
Startdatum_oogst
Einddatum_oogst

Veilingtabel:
Veiling_ID
Veiling_naam/omschrijving

Plant_veiling_verzendingtabel:
Plant_ID
Veiling_ID
Verzendcode
Hoeveelheid
Datum_verzending

die is wel te groot denk ik hoor.
http://c-jochemsen.nl/database.jpg

oogst kan eigenlijk in de plantentabel. Je gaat naar de plant, en klikt op een knop "oogsten" en de plant staat op geoogst.
Heb vandaag al toets gehad met iets moeilijkere opdracht, maar die moest ik in access maken, met querys enzo dus, is me niet gelukt.. kan gewoon niet met access werken, ookal is de SQL vrijwel het zelfde.

Ik heb nu JSP met java beans maken enzo, ken er ook geen klote van overmorgen tentame over zelfde shit als jij, dat gaat wel lukken denk ik...

tering...als je al moeite hebt met zo'n simpele database

jahaha idd born
maar hijs niet te groot hoor.. trust me. Anders krijg je een tabel plant, met overal: geoogst (of niets) en dat moet je vermijden (dubbele gegevens / redundantie) ter alle tijden. geloof me maar.. je kan niet een TE grote database hebben, tenzij je overbodige gegevens bijhoudt.

en ik zou modelleren dat een veiling meerdere zendingen heeft. kan geen kwaad om erin op te nemen. je weet maar nooit

Klinkt misschien overbodig, maar met welk database programma ga je het maken en wat is het doeleinde voor de database?

En je tabel klopt wel, wel moet je even goed letten op de keys die je gebruikt en de relaties.

en ik zou niet alles in 1 tabel gooien want dan zul je merken dat je op den duur last krijgt van inconsistentie in je database.
(door opjecten die meerdere malen in dezelfde tabel voorkomen, zodat je zoek query's niet correct meer werken)

p.s. als je verder hulp nodig heb met SQL language dan kan ik je wel verder helpen.

veel succes ermee.

vraagie.
als je in een tabel de volgende waardes hebt:

1 - 4

1 = artikel 1
4 = artikel 4

hoe voorkom je dan dat de database 4 - 1 bevat? Want die gegeven zou er dan 2 keer in staan

?

ja die volg ik ook niet helemaal

ik ook niet! dubbele gegevens vermijd je door het een eigen entiteit te geven. Dan is er namelijk sprake van een 1 op veel relatie