[PHP] Nieuwsitems + foto's -> in goede DB

[Verwijderd]

Zoals de titel al een beetje aangeeft ben ik zoek naar een goede database indeling voor A. mijn nieuws items en B. de daarbij behorende foto's. Ik kan niet echt een goede database indeling bedenken, misschien zit ik er wel te lang op maar graag jullie mening. Ik heb nu:

A. Nieuwsberichten
nieuws_id (sleutel, autonummering)
nieuw_datum
nieuws_kop
nieuws_bericht


B. foto's
foto_id (sleutel, autonummering)
nieuws_id
foto_categorie
foto_naam
foto_plaats

het probleem is dat een foto bij meerdere nieuws berichten kan komen, dus volgens mij staat het nu redelijk goed. Maar hoe trek ik het straks netjes uit de database, en krijg ik de foto's netjes bij mijn nieuws item. Ik hoef geen hele scripts, maar als er ergens een voorbeeld beschikbaar is in de vorm van een tutorial of iets dergelijks dan kan ik het zelf wel weer aanpassen. bedankt zover

[Erkens]

Je moet nieuws_id niet bij de foto tabel doen maar andersom.
Dus een foto_id bij je nieuws tabel en als je meer foto's bij een artikel wilt moet je een extra tussentabel hiervoor maken.

Daarna is het gewoon een kwestie van een simpele join maken om de plaatjes eruit te krijgen

[NMe]

Zoek eens op (inner) joins.

Overigens kan één foto nu maar bij één nieuwsbericht horen. Wil je een foto aan meerdere nieuwsberichten koppelen, dan heb je een koppeltabel (of kruistabel) nodig.

[Verwijderd]

een kruis tabel..jaja begint weer te dagen..tis ff geleden dat ik dat gedaan heb..maar wat zou die kruis tabel moet bevatten dan?!

[Eijkb]

Foto ID en Nieuws ID. Dus je kan dan per Nieuws ID meerdere foto ID's hebben.

[Andre-85]

Je zou een koppeltabel kunnen gebruiken.

C. Koppel
koppel_id
nieuws_id
foto_id

Op deze manier kan je een foto aan meerdere nieuws items koppelen en meerdere foto's aan een nieuws item.

[Erkens]

nieuws_id en foto_id, meer niet

[edit]

Andre-85 schreef op maandag 23 mei 2005 @ 22:53:
Je zou een koppeltabel kunnen gebruiken.

C. Koppel
koppel_id
nieuws_id
foto_id

Op deze manier kan je een foto aan meerdere nieuws items koppelen en meerdere foto's aan een nieuws item.

waarom zou je daar nog een koppel_id aan toe kennen, wat is daar het nut van?

[ Voor 87% gewijzigd door Erkens op 23-05-2005 22:54 ]

[Andre-85]

Eh ja goeie vraag
Nee koppel_id is idd niet nodig, het is een beetje een automatisme dat iedere tabel een id heeft.

[CH4OS]

sleutel is PK (Primary Key) neem ik aan?
En waarom foto's in een DB? Het maakt je DB namelijk supertraag...

[Verwijderd]

oke oke...we komen er wel...
dus

A. Nieuwsberichten
nieuws_id (sleutel, autonummering)
nieuw_datum
nieuws_kop
nieuws_bericht

B. foto's
foto_id (sleutel, autonummering)
foto_categorie
foto_naam
foto_plaats

C. Koppel
nieuws_id
foto_id

en dan met een join de juiste SQL pakken... ga ik zo ff zoeken welke joins er ook weer waren..

edit: nou de foto's komen er niet in, maar de namen van de foto's zoals ze op de server staan, leek me wel makkelijk?

[ Voor 16% gewijzigd door Verwijderd op 23-05-2005 22:58 ]

[NMe]

GJ-tje schreef op maandag 23 mei 2005 @ 22:56:
sleutel is PK (Primary Key) neem ik aan?
En waarom foto's in een DB? Het maakt je DB namelijk supertraag...

Ik zie nergens dat de foto fysiek in zijn DB zit.

[Verwijderd]

Het wil ook nog wel is helpen de database visualiseren, om aan meer ideeen etc te komen. is zowiezo een handig tooltje voor iedereen die mysql gebruikt.

Gratis en vooor niets.
http://www.fabforce.net/dbdesigner4/

[pietje63]

C kan wel een koppel_id hebben om de volgorde van de foto's in het nieuwsbericht in te stellen. Dan kan je bijvoorbeeld een {image} tag aanmaken en dan zorgen dat elke foto op de goede plaats staat.

[Erkens]

pietje63 schreef op dinsdag 24 mei 2005 @ 10:51:
C kan wel een koppel_id hebben om de volgorde van de foto's in het nieuwsbericht in te stellen. Dan kan je bijvoorbeeld een {image} tag aanmaken en dan zorgen dat elke foto op de goede plaats staat.

om een volgorde aan te geven gebruik je doorgaands niet een of ander ID, maar daarvoor maak je een normaal veld waarin je de volgorde aangeeft.

[NMe]

Erkens schreef op dinsdag 24 mei 2005 @ 10:55:
om een volgorde aan te geven gebruik je doorgaands niet een of ander ID, maar daarvoor maak je een normaal veld waarin je de volgorde aangeeft.

Niet eens doorgaans: je doet het gewoon niet. Een ID-veld verkrachten om het als volgorde te laten dienen is brak. Wat als je de volgorde wil veranderen? Dan moet je het ID aan gaan passen, en laat dat nou juist een van de dingen zijn die je absoluut nooit zou moeten doen in een relationele DB.

[imp4ct]

GJ-tje schreef op maandag 23 mei 2005 @ 22:56:
sleutel is PK (Primary Key) neem ik aan?
En waarom foto's in een DB? Het maakt je DB namelijk supertraag...

Ermm... 'k weet niet of je het principe van een SQL database kent, maar hierin kan je geen echte files opslaan ofzo hoor, wat hij doet is een verwijzig maken naar z'n images door tekst op te slaan in de DB, zodat je bij je posting systeem gewoon met een dropdownlist kan kiezen bv. om die foto te gebruiken, daarvoor dient die DB wat foto's betreft.

Verwijderd schreef op maandag 23 mei 2005 @ 22:58:
oke oke...we komen er wel...
dus

A. Nieuwsberichten
nieuws_id (sleutel, autonummering)
nieuw_datum
nieuws_kop
nieuws_bericht

B. foto's
foto_id (sleutel, autonummering)
foto_categorie
foto_naam
foto_plaats

C. Koppel
nieuws_id
foto_id

en dan met een join de juiste SQL pakken... ga ik zo ff zoeken welke joins er ook weer waren..

edit: nou de foto's komen er niet in, maar de namen van de foto's zoals ze op de server staan, leek me wel makkelijk?

Bij je foto's ... persoonlijk zou'k de plaats weglaten, mits ik het verstandiger vind je foto's op je eigen server te zetten en ze niet te gaan downen van de oorspronkelijke site, als deze dan down is of iets anders, dan krijg je de foto niet te zien.
Geen goeie service denk ik dan. Als je dan zegt, wat met m'n url, simpel. In je code geef je een standaard url al op. (bv. "http://www.jouwsite.nl/images/"$foto_naam."gif") misschien een nadeel van het zo te doen is dat je alle foto's gif's moeten zijn, of natuurlijk een andere extensie.

Dan die categorie, fout... dat moet waarschijnlijk een categorie_id worden, want ik denk niet dat je altijd het gaat intypen bij het toevoegen, vrij nutteloos en tijdrovend, niet ? Dus maak nog een tabel aan met een ID en de categorienaam.

Nog een tip bij kruistabellen, zorg dat beide variabelen 1 primaire sleutel vormen, anders kan je in problemen geraken.

Ook een tip voor je datum, als je met PHP zou werken, ga voor een unix timestamp, want je kan hier echt heel leuke dingen mee doen. Een unix timestamp is een INT van 10 cijfers lang, en je kan deze opvragen via de functie $datum = date(U);

[ Voor 24% gewijzigd door imp4ct op 24-05-2005 14:36 ]

[T-MOB]

I_M_P_A_C_T schreef op dinsdag 24 mei 2005 @ 14:29:
[...]
Ermm... 'k weet niet of je het principe van een SQL database kent, maar hierin kan je geen echte files opslaan ofzo hoor, wat hij doet is een verwijzig maken naar z'n images door tekst op te slaan in de DB, zodat je bij je posting systeem gewoon met een dropdownlist kan kiezen bv. om die foto te gebruiken, daarvoor dient die DB wat foto's betreft.
[...]

Dat kan wel hoor, in een BLOB veld. Over de voor- en nadelen is al uitgebreid gediscussieerd op dit forum. Laten we het er op houden dat beide methoden hun voordelen hebben... (edit: [PHP] plaatje uit mysql database)

Bij je foto's ... persoonlijk zou'k de plaats weglaten, mits ik het verstandiger vind je foto's op je eigen server te zetten en ze niet te gaan downen van de oorspronkelijke site, als deze dan down is of iets anders, dan krijg je de foto niet te zien.
Geen goeie service denk ik dan. Als je dan zegt, wat met m'n url, simpel. In je code geef je een standaard url al op. (bv. "http://www.jouwsite.nl/images/"$foto_naam."gif") misschien een nadeel van het zo te doen is dat je alle foto's gif's moeten zijn, of natuurlijk een andere extensie.

Het hardcoden van de lokatie in je script kan ook zijn nadelen hebben. Als foto's op verschillende plaatsen kunnen staan moet je de relatieve locatie gaan opnemen in het het naam veld. Doe je dat niet dan ben je gedwongen om afbeeldingen in één en dezelfde map op te slaan. Daarnaast is door het hard-coden het verplaatsen van afbeeldingen een hele onderhoudsklus geworden.
Ik zou zeggen dat de beste oplossing is om een extra tabel met locaties aan te maken en daar naar te linken in de tabel foto's. Dat is het best genormaliseerd en het meest flexibel.

Dan die categorie, fout... dat moet waarschijnlijk een categorie_id worden, want ik denk niet dat je altijd het gaat intypen bij het toevoegen, vrij nutteloos en tijdrovend, niet ? Dus maak nog een tabel aan met een ID en de categorienaam.

Nog een tip bij kruistabellen, zorg dat beide variabelen 1 primaire sleutel vormen, anders kan je in problemen geraken.

Helemaal mee eens...

Ook een tip voor je datum, als je met PHP zou werken, ga voor een unix timestamp, want je kan hier echt heel leuke dingen mee doen. Een unix timestamp is een INT van 10 cijfers lang, en je kan deze opvragen via de functie $datum = date(U);

Daarover valt te twisten. Een datumveld in de database lijkt mij een beter alternatief. Zelfs MySQL heeft een vrij uitgebreid scala aan datum-functies om met datumvelden te werken. Die functionaliteit zet je overboord met een timestamp. En als je een timestamp nodig hebt kun je die gewoon opvragen uit een datumveld.

[ Voor 6% gewijzigd door T-MOB op 24-05-2005 14:58 ]

[Eärendil]

I_M_P_A_C_T schreef op dinsdag 24 mei 2005 @ 14:29:
[...]
Ermm... 'k weet niet of je het principe van een SQL database kent, maar hierin kan je geen echte files opslaan ofzo hoor, wat hij doet is een verwijzig maken naar z'n images door tekst op te slaan in de DB, zodat je bij je posting systeem gewoon met een dropdownlist kan kiezen bv. om die foto te gebruiken, daarvoor dient die DB wat foto's betreft.

offtopic:
Dat is wel degelijk mogelijk, in een BLOB-veld. Of het handig en efficient is, is een tweede, maar het is mogelijk en het wordt ook gebruikt.

[imp4ct]

Eärendil schreef op dinsdag 24 mei 2005 @ 14:54:
[...]

offtopic:
Dat is wel degelijk mogelijk, in een BLOB-veld. Of het handig en efficient is, is een tweede, maar het is mogelijk en het wordt ook gebruikt.

Lol, mja sorry van mijn opmerking dan. Ik heb dus ongelijk, maar dat wist ik dus niet. Mijn excuses, weeral iets bijgeleerd. Maar wat je zegt, mij lijkt het nie echt efficiënt.

[Verwijderd]

oke, ik ben dus op zoek gegaan naar een SQL code voor mijn gegevens, helaas wil het nog niet zo erg lukken. het is dus de bedoeling dat wanneer ik op een nieuws titel klik, ik de rest van het nieuws bericht krijg te zien met de daarbij behorende foto's. hieronder wat ik zover heb

code:

<?
    //vaste gegevens
    include "inc_bestanden/dblogin.inc.php";

        //query voor het opvragen van de rechten van de gebruiker
        $table_nieuws = 'nieuws';
        $table_foto = 'foto';
        $table_koppel = 'koppel';
        
        $query = "SELECT
                    $table_nieuws.nieuws_id         AS nieuws_id            ,
                    $table_nieuws.datum             AS datum                ,
                    $table_nieuws.tijd              AS tijd                 ,
                    $table_nieuws.titel_kort        AS titelkort            ,
                    $table_nieuws.titel             AS titel                ,
                    $table_nieuws.bericht           AS bericht              ,

                    $table_foto.cat_id              AS catid                ,
                    $table_foto.foto_naam           AS foto_naam            ,
                    $table_foto.foto_plaats         AS foto_plaats

                    FROM
                    $table_foto RIGHT OUTER JOIN $table_koppel ON $table_foto.foto_id = $table_koppel.foto_id LEFT OUTER JOIN $table_nieuws ON $table_nieuws.nieuws_id = $table_koppel.nieuws_id";
?>
<?
$resul = mysql_query($query) or trigger_error(mysql_error(),E_USER_ERROR);
?>

<?
        while($obj = mysql_fetch_object($resul))


            {
                echo"

            <TR>
            <TD WIDTH=1 HEIGHT=1 CLASS=tb1_ml></td>
            <TD BGCOLOR=white> <A HREF=toonbericht.php?id=$obj->nieuws_id target=midden>$obj->titel_kort</a> </td>
            <TD WIDTH=20 HEIGHT=1 CLASS=tb1_mr></td>
            </TR>
            ";
                    }
?>

De foutmelding die ik momenteel krijg is deze :

Warning: mysql_fetch_object(): supplied argument is not a valid MySQL result resource in /home/projects/mijndomein/default/hubertswegenbouw.nl/htdocs/www/koppel.php on line 31

ik zie het even niet meer, misschien kan iemand even helpen.

[ Voor 11% gewijzigd door Verwijderd op 25-05-2005 16:24 ]

[Erkens]

maak van regel 27 eens:

PHP:

$resul = mysql_query($query) or trigger_error(mysql_error(),E_USER_ERROR);

offtopic:
verder vind ik het een vieze manier van een query opbouwen met die variabelen er zo in

[Verwijderd]

even kleine aanpassing gemaakt, had verkeerder code (er stonden nog 2 oude regels in, die zijn er nu uit, plus Erkens zijn toevoeging

[Erkens]

maar je krijgt niet een mysql error?

[Verwijderd]

nee krijg geen error meer, kreeg er wel 1, maar die is eruit nu...maar ik krijg ook geen resultaten?!

[Erkens]

en de query gewoon uitvoeren met mysql krijg je wel results?

[Verwijderd]

uh, hoe bedoel je?!

[Erkens]

Gewoon die query uitvoeren met de standaard mysql client.

[Verwijderd]

ja oke, maar ik weet even niet hoe...

[Erkens]

ooit gehoord van een manual ofzo?

mysql -u username -p -h hostname database

[Verwijderd]

ja maar dat doe ik toch al met
require "dblogin.inc.php";

daarin staan die dingen die jij noemt..normaal gesproken met de andere pagina's werkt het gewoon

[Erkens]

op de command line, dus zonder PHP
of met iets als phpmyadmin als je geen toegang tot de command line heb
hoe moeilijk kan debuggen zijn

[xiD]

vervang $table_nieuws en dergelijke is gewoon door hun tabelnaam,

[Verwijderd]

oke in phpmyadmin krijg ik wel resultaten, en nog bijna de goede ook. In mijn koppel tabel staan de volgende gegevens

koppel_id	foto_id	nieuws_id
1	1	1
2	2	1

maar dan krijg ik dus met mijn huidige sql structuur 2 keer het nieuwsbericht..en dat heb ik niet nodig

[ Voor 27% gewijzigd door Verwijderd op 25-05-2005 17:16 ]

[Erkens]

overigens, waarom negeer je tips die in dit topic gegeven worden mbt dat koppel_id?

[NMe]

Waarom gebruik je outer joins? Je moet inner joins hebben. www.sqlcourse2.com

Verder: je laatste paar posts zijn bijna allemaal oneliners waar je blijkbaar aan het handje genomen wil worden. Dat is hier dus niet de bedoeling. Een beetje meer eigen inzet mag ook wel, en het grootste deel van die kleine vraagjes had je kunnen oplossen met een beetje debuggen.

[PanMan]

T-MOB schreef op dinsdag 24 mei 2005 @ 14:54:
[...]
Daarover valt te twisten. Een datumveld in de database lijkt mij een beter alternatief. Zelfs MySQL heeft een vrij uitgebreid scala aan datum-functies om met datumvelden te werken. Die functionaliteit zet je overboord met een timestamp. En als je een timestamp nodig hebt kun je die gewoon opvragen uit een datumveld.

Ze zijn beide vrij eenvoudig uitwisselbaar. in MySQL kan je unix timestamps ook genereren met UNIX_TIMESTAMP() en ook de normale datumfuncties erop loslaten met FROM_UNIXTIME(). Dus je behoud de MySQL fuctionaliteit. Bovendien vind ik (maar dat is persoonlijk) het vaak fijner om in PHP m'n data te formateren. En, wat ik wel handig vind is als je de laatste X uur/dagen/weken wilt hebben, je dat gewoon in sec van je query af kan trekken (WHERE timestampint>UNIX_TIMESTAMP()-24*3600 )
Overigens kan je in PHP de timestamp ook tevoorschijn toveren met time(), nog eenvoudiger .

[Janoz]

Rekenen in seconden kan problemen geven bij het wisselen van zomer en wintertijd (dagen van 25 en 23 uur) en eventuele schrikkelseconden. In dat geval is het veel beter om met de dateadd functies van mysql te werken. Het formateren van de data darintegen is inderdaad iets wat je niet in je queries moet doen. Ikzelf gebruik (wanneer ik uberhaupt ites met de php/mysql combo doe) in de database date(time) velden en binnen php timestamps. gewoon overal FROM_UNIXTIME(veld) en UNIX_TIMESTAMP(veld) in je queries gebruiken.

[T-MOB]

Janoz schreef op donderdag 26 mei 2005 @ 13:31:
Het formateren van de data darintegen is inderdaad iets wat je niet in je queries moet doen.

Dit is iets dat ik vaker hoor/lees waarvan ik de achterliggende gedachte niet helemaal vat. Waarom is het zo "not-done" om data te formatteren in je query. Om bij een datum te blijven, als je een datum als "Y-m-d" wil weergeven dan lijkt het me sneller om gewoon die "Y-m-d" op te vragen uit de DB. Het opvragen van een timestamp en vervolgens omzetten in "Y-m-d" voegt alleen extra conversieslag toe. In lompe gevallen kun je door data op te maken in de DB veel cycles en geheugen besparen.

[Erkens]

T-MOB schreef op donderdag 26 mei 2005 @ 13:52:
Dit is iets dat ik vaker hoor/lees waarvan ik de achterliggende gedachte niet helemaal vat. Waarom is het zo "not-done" om data te formatteren in je query. Om bij een datum te blijven, als je een datum als "Y-m-d" wil weergeven dan lijkt het me sneller om gewoon die "Y-m-d" op te vragen uit de DB. Het opvragen van een timestamp en vervolgens omzetten in "Y-m-d" voegt alleen extra conversieslag toe. In lompe gevallen kun je door data op te maken in de DB veel cycles en geheugen besparen.

Dat kan inderdaad sneller zijn ja, maar vaak schrijf je software wat zo open mogelijk moet zijn, vaak weet je dus niet bij het uitvoeren van je query wat de "opmaak" moet worden. Hoe een datum eruit ziet dat bepaald mijn template laag, en niet mijn database laag.
Door op deze manier te werken kan je eenvoudig de weergave aanpassen, of zelfs een datum op verschillende manieren weergeven als dat nodig is.

[Stilgar]

-NMe- schreef op woensdag 25 mei 2005 @ 17:39:
Waarom gebruik je outer joins? Je moet inner joins hebben. www.sqlcourse2.com

Outer joins lijken me hier wel een goed idee eigenlijk. Als er een nieuwsbericht is zonder afbeeldingen wordt dat bericht niet opgehaald als je inner joins gebruikt (omdat de kant van de kruistabel een NULL oplevert).

[curry684]

T-MOB schreef op donderdag 26 mei 2005 @ 13:52:
[...]

Dit is iets dat ik vaker hoor/lees waarvan ik de achterliggende gedachte niet helemaal vat. Waarom is het zo "not-done" om data te formatteren in je query. Om bij een datum te blijven, als je een datum als "Y-m-d" wil weergeven dan lijkt het me sneller om gewoon die "Y-m-d" op te vragen uit de DB. Het opvragen van een timestamp en vervolgens omzetten in "Y-m-d" voegt alleen extra conversieslag toe. In lompe gevallen kun je door data op te maken in de DB veel cycles en geheugen besparen.

Onzin, je database stored een datetime gewoon als een 8 byte veld, en ragt die net zo lief over de lijn als jouw resulterende string. Je verplaatst dus alleen de overhead van de conversie van de database naar de client. Daar zie je ook meteen de eerste zwakte van de opmerking: je belast je DB zwaarder dan nodig, terwijl je die nu juist zo min mogelijk load wil geven ivm scaleability. Vervolgens ga je ook nog custom client-dependent operaties (het formatteren namelijk) door je DB laten doen, waarmee je je client minder onderhoudbaar maakt omdat je geen generieke mechanismes meer kunt bouwen, en waarbij je de strikte data/presentatie layers ineens niet meer strikt scheidt.

[NMe]

Stilgar schreef op vrijdag 27 mei 2005 @ 10:50:
[...]

Outer joins lijken me hier wel een goed idee eigenlijk. Als er een nieuwsbericht is zonder afbeeldingen wordt dat bericht niet opgehaald als je inner joins gebruikt (omdat de kant van de kruistabel een NULL oplevert).

Klopt, niet bij stilgestaan.

[T-MOB]

curry684 schreef op vrijdag 27 mei 2005 @ 10:55:
[...]
Onzin, je database stored een datetime gewoon als een 8 byte veld, en ragt die net zo lief over de lijn als jouw resulterende string. Je verplaatst dus alleen de overhead van de conversie van de database naar de client. Daar zie je ook meteen de eerste zwakte van de opmerking: je belast je DB zwaarder dan nodig, terwijl je die nu juist zo min mogelijk load wil geven ivm scaleability.

Tenzij een datetime wordt opgeslagen als timestamp moet de DB voor het opvragen van de timestamp ook een conversie uitvoeren. Maar goed het is niet mijn bedoeling om eigenwijs te gaan doen over een bepaald voorbeeld.
In veel (webapp-)gevallen draait de database echter op dezelfde machine als het script waaruit je hem aanroept, vanuit performance oogpunt is het dan toch het aantrekkelijkst om het formatteren uit te voeren waar dat het snelst gebeurd?

Vervolgens ga je ook nog custom client-dependent operaties (het formatteren namelijk) door je DB laten doen, waarmee je je client minder onderhoudbaar maakt omdat je geen generieke mechanismes meer kunt bouwen, en waarbij je de strikte data/presentatie layers ineens niet meer strikt scheidt.

Het grootste voordeel ligt dus in wat Erkens hierboven ook al aangeeft: flexibiliteit en onderhoudbaarheid. Reden en duidelijkheid genoeg waarom men in principe geen data moet formatteren in de database.
Waar flexibiliteit niet zo'n issue is, bijvoorbeeld bij het exporteren van je data in een onveranderlijk bestandsformaat, kan formatteren in de DB dus best een uitkomst zijn. In MySQL is een CONCAT over 100 velden in elk geval aanzienlijk lichter dan het opvragen van 100 aparte velden.