[SQL] ontwerp dbase probleem met foto's gekoppeld aan pages

[ReseTTim]

ik ben bezig met een website.. elke pagina heeft aan de rechter kant een drietal sfeerfoto's. per locatie willen die foto's verschillen maar max 3 foto's onder elkaar.

ik had als volgt een ontwerp gemaakt..

tbl_foto	tbl_sfeer
fotoid	sfeerid
fotogr	locid
fototn	projectid
alt	actueelid
	oversinethid
	faseid
	fotoid

fotoid, sfeerid zijn PK

wat dus het idee is dat elke foto heeft 1 of meerdere locaties, projecten, artikelen(actueel), fases.

toen bedacht ik mij omdat ik max 3 foto's gebruik per locatie kan ik natuurlijk ook gewoon bij elke project, artikel en locatie nog 3 kolommen erachter bij plakken. waardoor ik dus het volgende krijg:

tbl_foto	tbl_fase
fotoid	faseid
fotogr	soortfase
fototn	fasebeschrijving
alt	foto1
	foto2
	foto3

en dan zit er dus een koppeling fotoid met foto1, foto2 en foto3 en dit wordt dus in al die velden toegevoegd die laatste 3 kolommen (foto1,2 en 3).

mijn vraag is wat denken jullie dat het slimste is om te gebruiken.. in het eerste geval zit je iig met een grote koppelingstabel die niet noodzakelijk is en in het tweede geval is dit denk ik het makkelijkst te realiseren..

[ Voor 3% gewijzigd door ReseTTim op 16-02-2006 15:48 ]

[Verwijderd]

Tja, de tweede is misschien makkelijker te maken, maar de eerste is als je het mij vraagt flexibeler. Wil je bijvoorbeeld op een gegeven moment extra informatie over een sfeerfoto opslaan, dan zul je in het tweede geval drie extra kolommen moeten aanmaken (waarvan je er misschien slechts één wilt vullen). Ook ligt het er maar net aan welke queries je op de database wil gaan uitvoeren.

[Verwijderd]

Ik kan er echt geen touw aan vastknopen en er duiken een bak met vragen op.

Wat is een sfeer? Wat is een locatie (fysieke plaats van de foto? nee, want een foto heeft volgens jou 1 of meer locaties. Wat is het dan wel?)? Wat is een fase? Als je een database maakt, groepeer je de gegevens meestal per entiteit. Kennelijk zijn dit entiteiten, maar ik heb geen flauw idee wat ze betekenen en kan de samenhang daardoor niet vaststellen. Misschien is het voor jou duidelijk, maar voor mij niet. Ik kan daarom ook niets zeggen over de koppeltabel van optie 1.

Wat geven de pagina's waarover jij het hebt weer? Zijn die gebonden aan een bepaalde entiteit?

Probeer ook in schrijftaal te schrijven en niet in spreektaal, want alleen de gramaticafouten maken het al een lastig stukje om te lezen. Voorbeeld:

wat dus het idee is dat elke foto heeft 1 of meerdere locaties, projecten, artikelen(actueel), fases.

leest heel wat minder dan

elke foto heeft 1 of meerdere locaties, projecten, artikelen(actueel), fases

Overigens, als ik dit laatste stukje lees, vraag ik me af of er niet tussen iedere genoemde entiteit en de fototabel los een koppeltabel moet komen.

Kortom: omschrijf je probleem nou eens heel duidelijk.

[ReseTTim]

snel een screenie gemaakt..



rechterkant zie je 3 foto's dit noem ik ook wel sfeerfoto's daar komt dus sfeer vandaan..

zoals je ziet staan er bovenin links. elk van deze links heeft dus rechts ook weer een reeks foto's die rechts te zien zijn.

met 'locaties' bedoel ik de main page mee van: diensten, projecten, over sineth, contact, actueel
sommige van deze locaties hebben weer een sub pagina als in projecten een pagina heeft waarin 1 project staat of in actueel een artikel over bijv. de wetgeving, enz..

elke pagina heeft dus max 3 sfeer foto's!
zo kwam ik dus bij het tweede oplossing met: 'foto1, foto2 en foto3'
tbl_fase is een voorbeeld van een tabel die er dan zo komt uit te zien met: foto1,2 & 3

dan krijg je de max 3 foto's die per locatie, artikel, project horen..
als ik meer over een foto wil vermelden dan kan dat natuurlijk altijd in tbl_foto.

[ReseTTim]

*kick*

[Orphix]

Pak je eerste ontwerp. Dus een afbeelding als aparte entiteit.
Op de pagina pak je dan alle afbeeldingen voor die locatie, en die beeld je af.
Upload je drie afbeeldingen, laat je drie zien. Upload je twee, of vier, afbeeldingen dan komen er automatisch resp. twee of vier afbeeldingen onder elkaar. Je weet immers nooit of je eis van drie afbeeldigen in de toekomst gaat veranderen. En de uitvoering is erg simpel.