Goede opzet database???

[Verwijderd]

Ik ben bezig met het opzetten van een database waarin foto's opgeslagen gaan worden. De volgende situatie is het geval.

Jaarlijks worden er 10.000 foto's gemaakt van verschillende kledingmerken, op verschillende locaties. Je hebt bijvoorbeeld een zomercollectie van 2001 tijdens een shoot in Milaan. Dit voor zowel foto's van mannen als vrouwen. Elk jaar worden er zo dus op verschillende locaties foto's gemaakt van een groot aantal kledingmerken. Deze foto's moeten geupload worden naar een website en zo gecategoriseed weergegeven worden op een site.

Ik heb de volgende entiteiten in mijn hoofd: Foto, Stad, Jaar, Seizoen, Merk.

Je kan Seizoen, Jaar en Stad samenvoegen tot een Fotoshoot:
Fotoshoot (ID, Seizoen, Jaar, Stad,....)

Daarnaast kan Seizoen, Jaar en Merk samengevoegd worden tot een Collectie:
Collectie (ID, Seizoen, Jaar, Merk,....)

Persoonlijk denk ik dat het Merk als een losse entiteit benaderen beter is.

Het enige wat ontbreekt is dus of het een mannelijke of vrouwelijke foto dan wel fotoshoot dan wel collectie betreft. Geslacht oid zal dus als attribuut voor een van de entiteiten.

Ik weet niet precies hoe ik mijn datamodel zo goed mogelijk in elkaar kan laten vallen.

Een ander probleem is dat er nogal wat foto's geupload moeten worden. Dit moet zo makkelijk mogelijk gebeuren en met grote hoeveelheden tegelijk. Via een webinterface wordt dit lastig dus uploaden mbv FTP is een optie. Maar deze foto's moeten na uploaden dus nog wel in de database opgenomen worden.
Wie heeft er adviezen voor me... ?

[raptorix]

Als het om zulke grote aantallen gaat is misschien handig dat men de boel fysiek opstuurt en vervolgens de kleinere dingetjes gewoon online kan doen.

[drm]

probleem a.
---------------
Ik zou Foto als aparte entiteit nemen, Fotoshoot en Collectie ook.
Geslacht _{(zou ook een andere veldnaam kiezen, wat ben ik nog niet helemaal uit )}, als attribuut van Foto.
Vervolgens een relatie tussen Fotoshoot en Foto, en Collectie en Foto, die 1:1 of 0:0 mag zijn.

Kortom, een FK in je tabel die naar de andere verwijst, waarbij als het veld NULL is (ofzo) dus niet in een fotoshoot/collectie voorkomt

probleem b.
---------------
Ik zou alles in een directory zetten, met een scriptje uitlezen, vervolgens alle database code uit je upload scriptje op die code toepassen, waarbij je de code die het geuploade bestand in de juiste directory zet, het bestand niet uit de tmp directory haalt maar uit de directory waar je al je meuk hebt geupload (met FTP, dus)

hth

[Janoz]

Een foto hoort toch bij een fotoshoot? Op zich heb je dus weer een apparte tabel waarin je de eigenschappen van een foto opslaat (man/vrouw/groepje)

Zijn foto's altijd van 1 merk? of zitten er ook van die mode reportages bij waarbij kleding van verschillende merken wordt samengevoegd? Op dat moment heb je namelijk een iets groter probleem... Dan zul je je hele model overhoop moeten gooien en merk aan de foto's ipv aan de shoot koppelen..

Is een fotoshoot in een bepaald seizoen van een jaar altijd de fotoshoot van de collectie van dat sezoen en jaar? Anders gaat de koppeling tussen de twee al gegeven tabellen de mist in.

[Verwijderd]

Een ERD diagram maakt het allemaal een stuk duidelijker !

[Verwijderd]

Als de attributen per shoot in plaats van per foto worden bepaald, kan je simpel een PHP-upload scriptje schrijven, dat als volgt werkt:

1. User vult shoot-details in
2. User selecteert ZIP file met alle foto's
3. Server-side worden alle foto's eruit gehaald en in de juiste dir geplaatst (afhankelijk van punt 1.)
4. Plemp details in database
5. Jeeee!

[Verwijderd]

Een foto hoort maar bij 1 shoot en 1 merk. Dus elke foto komt maar 1 keer voor op de website.

Verder heb ik het volgende nu:

Klant (klant_id, voornaam, tussenvoegsel, achternaam, adres, postcode, woonplaats, bedrijf, telnr, fax, email, wachtwoord, regdatum,...)

Order (order_id, klant_id^, datum,...)

Orderregel (orderregel_id, order_id^, foto_id^, aantal,...)

Foto (foto_id, fotoshoot_id^, locatie,...)

Fotoshoot (fotoshoot_id, seizoen, jaar, stad, geslacht,...)

Merken_per_fotoshoot (mps_id, fotoshoot_id^, merk_id^,...)

Merk (merk_id, naam, website,...)


Zijn hier mijn gegevens in op te slaan en ook weer op te halen?

[drm]

Zijn hier mijn gegevens in op te slaan en ook weer op te halen?

Dat ligt aan jouw progskillz natuurlijk


Als ik 't zo zie, kun je Merk beter aan Foto koppelen (1:n) dan aan (n:m) fotoshoot.

[Janoz]

Klopt het dat er bij een fotoshoot maar 1 model wordt gebruikt? Dan kun je idd die gegevens in fotoshoot opslaan...

drm >> nou, dan wordt het nog niet automatisch 1:n.. Wat nu als het model een broek van merk a aan heeft en een trui van merk b? Maar misschien is het wel handiger om het aan foto te koppelen (als er meerdere merken per fotoshoot worden gebruikt) omdat je dan ook makkelijk alle foto's van een bepaald seizoen op kunt vragen waarop een kledingsstuk van een bepaald merk staat ipv de gehele fotoshoots. Welke merken er bij een fotoshoot worden gebruikt is dan nog steeds te achterhalen door ook fotoshoot aan de tabel mee te koppelen.

[drm]

Janoz:
drm >> nou, dan wordt het nog niet automatisch 1:n.. Wat nu als het model een broek van merk a aan heeft en een trui van merk b?

Daar heb je gelijk in. Ik heb ook maar aangenomen dat elke foto focussed op 1 kledingstuk, en dat er daarom maar 1 merk per foto nodig is, maar dat hoeft natuurlijk niet

Welke merken er bij een fotoshoot worden gebruikt is dan nog steeds te achterhalen door ook fotoshoot aan de tabel mee te koppelen.

Je bedoelt de fotoshoot _nogmaals_ aan Merk te koppelen? Dat lijkt mij niet nodig, gezien de relatie (via foto) al bestaat...

[bonzz.netninja]

ik zeg maar 1 ding, normaliseren die hap, bij de 4e normaalvorm is het al stukken duidelijker, zoek op normliseren bij google voor handleidingen

[Verwijderd]

Modellen worden buiten beschouwing gelaten. Het gaat puur om de merken en of het een mannelijke of vrouwelijke collectie is.

Op de website wordt straks iets in de volgende orde opgesteld:

code:

               Lokatie 1                   Lokatie 2
            Man         Vrouw           Man         Vrouw
------------------------------------------------------------
2001    z.c. | w.c.  z.c. | w.c.    z.c. | w.c.  z.c. | w.c. 
2002    z.c. | w.c.  z.c. | w.c.    z.c. | w.c.  z.c. | w.c. 
2003    z.c. | w.c.  z.c. | w.c.    z.c. | w.c.  z.c. | w.c. 
------------------------------------------------------------

Dus per jaar is er een zomercollectie of wintercollectie te kiezen voor zowel mannen als vrouwen en per lokatie.

[Verwijderd]

Ik hbe gekeken naar die 4e normaalvorm. Maar wat bedoel je precies?
Moet ik Stad, Seizoen en Jaar loshalen ofzo ???

[Janoz]

drm schreef op 10 oktober 2002 @ 12:04:
[
Je bedoelt de fotoshoot _nogmaals_ aan Merk te koppelen? Dat lijkt mij niet nodig, gezien de relatie (via foto) al bestaat...

Dat bedoel ik ook ... De relatie is d'r al dus die info kun je nog steeds achterhalen

[bonzz.netninja]

mm, voor precies normaliseren moet je niet echt bij mij zijn, ik heb het wel geleerd, maar dat was 2e jaars vak, da's allemaal kwijt in mijn hersenen, probeer deze pdf is door te spitten, het lijkt zo op het eerste gezicht al heel wat duidelijkheid te geven in normaliseren: http://members.chello.nl/.../access_dl/tutorial_n.pdf

let wel op, de meeste mensen skippen het normliseren, omdat het vrij tijdrovend is, en je tijdens het ontwikkelen ook prima de DB kan bewerken. Toch is het, vooral bij complexe DB's een prima methode (en internationaal) om duidelijkheid te scheppen in de situatie.

ps. de 4e normaalvorm bestaat niet blijkt, foutje van mij, dat heet bachman anaylyse geloof ik