DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Ok, klinkt wel aannemelijkquote:Op dinsdag 28 maart 2006 22:21 schreef Light het volgende:
[..]
Hoe wil je bij jouw voorbeeld steekwoord 3 (groen) aan foto 2 koppelen, zonder dat de koppeling met foto 1 verloren gaat?
Als steekwoord_ID de primary key is gaat het niet werken, omdat die key niet 2 keer voor mag komen. En als de PK bestaat uit steekwoord_ID en foto_ID dan kun je iig in theorie twee verschillende steekwoorden hebben, beide met steekwoord_ID 3, maar met een andere foto. Da's ook niet handig.
Meer info: zoeken op normalisatie.
Niemand een suggestie verder? Kan ik bijvoorbeeld 3 fields in m'n vorm aanmaken, zeg steekwoord1, steekwoord2, steekwoord3, en deze in een array zetten en dan via een query in de tabel steekwoord zetten én zodanig dat ze ook in de koppeltabel komen?
Of is daar een andere oplossing voor?
Ik ken karate, taekwondo en nog 19 andere gevaarlijke woorden
Uit het oogpunt van zoeken is het wel handiger. Of de kolom steekwoord_ID is overbodig, maar ik zou toch gaan voor een 3-tabellen oplossing.quote:Op dinsdag 28 maart 2006 22:32 schreef Swetsenegger het volgende:
[..]
Gewoon nog een keer invoeren.
Ik ging er van uit dat steekwoorden los worden ingevoerd.
Dan ga ik niet controleren of dat steekwoord al bestaat om die vervolgens via een koppeltabel aan een tweede foto te koppelen.
In mijn geval kan groen dus 3 keer voorkomen met 3 verschillende fotoId's.
Uiteraard kan ik NOG een tabel maken waar ik het steekwoord id koppel aan het het foto id, op die manier heb je nooit dubbele steekwoorden. Maar persoonlijk vind ik dat een beetje overkill eigenlijk.
Gewoon 3 rijen toevoegen in de koppeltabel, voor ieder steekwoord 1.quote:Op dinsdag 28 maart 2006 22:34 schreef Inbox4me het volgende:
[..]
Ok, klinkt wel aannemelijk
Niemand een suggestie verder? Kan ik bijvoorbeeld 3 fields in m'n vorm aanmaken, zeg steekwoord1, steekwoord2, steekwoord3, en deze in een array zetten en dan via een query in de tabel steekwoord zetten én zodanig dat ze ook in de koppeltabel komen?
Of is daar een andere oplossing voor?
Zolang je dan niet wil verwijderen op steekwoord is er weinig aan de handquote:Op dinsdag 28 maart 2006 22:41 schreef Light het volgende:
[..]
Gewoon 3 rijen toevoegen in de koppeltabel, voor ieder steekwoord 1.
Nu raak ik in de war. Is uit het oogpunt van zoeken jouw of mijn oplossing handiger?quote:Op dinsdag 28 maart 2006 22:39 schreef Light het volgende:
[..]
Uit het oogpunt van zoeken is het wel handiger. Of de kolom steekwoord_ID is overbodig, maar ik zou toch gaan voor een 3-tabellen oplossing.
Op zich maakt het toch niet veel uit?
Indien ik in jouw geval zoek op het steekwoord groen geeft hij een rijtje ID's van foto's terug.... en in mijn geval ook
in jouw geval wordt de query wat complexer omdat ik eerst uit de steekwoordtabel het id welke bij groen hoort moet trekken en vervolgens alle foto id's uit de koppeltabel moet trekken welke bij het eerder gevonden id horen en pas daarmee kan ik de juiste foto's uit de database halen.
Maar zonder gekheid.
Ik zie de voordelen wel van die 3e tabel. Maar ik zie ook nadelen (zoals inderdaad complezere queries) en de 2 tabellen oplossing zal voor de meeste apps welke de gebruikers van dit topic schrijven wel voldoen. Maar eigenlijk is jouw oplossing de enige juiste
Als je wilt verwijderen op steekwoord ook niet. Je moet er even het ID bijzoeken, en dan kun je op combinatie foto_ID, steekwoord_ID wel gaan verwijderen.quote:Op dinsdag 28 maart 2006 22:42 schreef DaFan het volgende:
[..]
Zolang je dan niet wil verwijderen op steekwoord is er weinig aan de hand
Normalisatie is leuk & aardig (en ik probeer het voor zover mogelijk ook altijd toe te passen) maar zodra je in een kritische applicatie met gigantische databases moet werken dan is een oplossing die qua schijfruimte en performance veel voordeel biedt meestal érg aantrekkelijk...
Is het niet net als met alles.quote:Op dinsdag 28 maart 2006 22:48 schreef JeRa het volgende:
Normalisatie is leuk & aardig (en ik probeer het voor zover mogelijk ook altijd toe te passen) maar zodra je in een kritische applicatie met gigantische databases moet werken dan is een oplossing die qua schijfruimte en performance veel voordeel biedt meestal érg aantrekkelijk...
Hou je zo veel mogelijk aan dit soort technieken en standaarden, omdat het in de regel tot betere resultaten leidt. Maar.... durf ook af te wijken van de regel indien het noodzakelijk is (waarbij dat kan gelden voor commercie of performance of prijs/kwaliteit van de app.)
Truequote:Op dinsdag 28 maart 2006 22:44 schreef Swetsenegger het volgende:
[..]
Nu raak ik in de war. Is uit het oogpunt van zoeken jouw of mijn oplossing handiger?
Op zich maakt het toch niet veel uit?
Indien ik in jouw geval zoek op het steekwoord groen geeft hij een rijtje ID's van foto's terug.... en in mijn geval ook
Dat kan gewoon met een simpele join. En je voorkomt dat er verschillende spellingen voor hetzelfde steekwoord worden gebruikt. Nu zal dat bij "groen" niet zo'n probleem zijn, maar als je "bureau" en "buro" hebt wordt zoeken al lastiger.quote:in jouw geval wordt de query wat complexer omdat ik eerst uit de steekwoordtabel het id welke bij groen hoort moet trekken en vervolgens alle foto id's uit de koppeltabel moet trekken welke bij het eerder gevonden id horen en pas daarmee kan ik de juiste foto's uit de database halen.
quote:Maar zonder gekheid.
Ik zie de voordelen wel van die 3e tabel. Maar ik zie ook nadelen (zoals inderdaad complezere queries) en de 2 tabellen oplossing zal voor de meeste apps welke de gebruikers van dit topic schrijven wel voldoen.
We zijn het eensquote:Maar eigenlijk is jouw oplossing de enige juiste
Maar hoe voeg ik die toe? Kan dat in één query, moet dat via arrays? Dat is mijn probleem waar ik op vast loop...quote:Op dinsdag 28 maart 2006 22:41 schreef Light het volgende:
[..]
Gewoon 3 rijen toevoegen in de koppeltabel, voor ieder steekwoord 1.
Ik ken karate, taekwondo en nog 19 andere gevaarlijke woorden
True. Het kan dan ook aantrekkelijk zijn om informatie redundant op te slaan. Niet qua schijfruimte, wel qua prestatie.quote:Op dinsdag 28 maart 2006 22:48 schreef JeRa het volgende:
Normalisatie is leuk & aardig (en ik probeer het voor zover mogelijk ook altijd toe te passen) maar zodra je in een kritische applicatie met gigantische databases moet werken dan is een oplossing die qua schijfruimte en performance veel voordeel biedt meestal érg aantrekkelijk...
quote:Op dinsdag 28 maart 2006 22:55 schreef Inbox4me het volgende:
[..]
Maar hoe voeg ik die toe? Kan dat in één query, moet dat via arrays? Dat is mijn probleem waar ik op vast loop...
| 1 |
Inderdaad. Aan de standaarden houden is één ding, een server hebben die de standaarden goed geïmplementeerd en geoptimaliseerd heeft is een tweede. Simpel voorbeeldje: een fantastisch genormaliseerde database kan alsnog traag zijn door de implementatie. MyISAM werkt met losse bestanden voor de tabellen, drie per tabel (structuur, index en data). Als je een beetje grote JOIN doet of een aantal INSERTs achter elkaar uitvoert krijg je zoveel random reads en writes dat zelfs de snelste SCSI-schijf er vraagtekens bij zet.quote:Op dinsdag 28 maart 2006 22:54 schreef Swetsenegger het volgende:
[..]
Is het niet net als met alles.
Hou je zo veel mogelijk aan dit soort technieken en standaarden, omdat het in de regel tot betere resultaten leidt. Maar.... durf ook af te wijken van de regel indien het noodzakelijk is (waarbij dat kan gelden voor commercie of performance of prijs/kwaliteit van de app.)
Dat er weinig over gezeurd wordt komt denk ik vooral door het relatief goedkope geheugen dat volop in databaseservers aanwezig is. De Linux-kernel heeft een prima memory management en zodra de block cache is volgelopen merk je niets meer van die traagheid neemt niet weg dat ik op een thuisservertje vaak wel eens tegen die traagheid aanloop...
[ Bericht 0% gewijzigd door JeRa op 28-03-2006 23:22:56 ]
*verwijderd*quote:
Ik ben eruit. Uiteindelijk steekwoorden in een array gezet, en mbv mysql_insert_id en informatie opvragen met een query is het allemaal gelukt
Thnx voor het meedenken
[ Bericht 24% gewijzigd door Inbox4me op 29-03-2006 02:11:14 ]
Ik ken karate, taekwondo en nog 19 andere gevaarlijke woorden
is niet helemaal geschikt voor dit topic, maar toch wel een beetje, en jullie weten vast het antwoord.
ik ben mezelf maar eens aan het verdiepen in validation, en nu kom ik hetvolgende tegen:
waarom slikt hij dat niet?
ik ben mezelf maar eens aan het verdiepen in validation, en nu kom ik hetvolgende tegen:
| 1 2 3 4 | system identifier could be generated. <a href="main.php?&mID=122&sID=163"> |
waarom slikt hij dat niet?
As a rule, I never touch anything more sophisticated and delicate than myself.
Die ampersand moet weg achter het vraagteken?
GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!
nee dat maakt niet uit..
was ff tijdelijk zo met dat ?&. maar ook al is het zonder ampersand, zelfde error.
was ff tijdelijk zo met dat ?&. maar ook al is het zonder ampersand, zelfde error.
As a rule, I never touch anything more sophisticated and delicate than myself.
Probeer het eens in lowercase? Verder zou ik niet weten wat er mis mee is.quote:Op woensdag 29 maart 2006 14:29 schreef Desdinova het volgende:
nee dat maakt niet uit..
was ff tijdelijk zo met dat ?&. maar ook al is het zonder ampersand, zelfde error.
GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!
Als je die eerste & (na het ?) weg laat dan zal je nog een foutmelding krijgen over sID. Als je een & in html zet dan moet je die vervangen door & amp;, ook als het onderdeel van een url is.quote:Op woensdag 29 maart 2006 14:29 schreef Desdinova het volgende:
nee dat maakt niet uit..
was ff tijdelijk zo met dat ?&. maar ook al is het zonder ampersand, zelfde error.
| 1 |
(de encoding van Replique klopt ook niet, & amp; wordt altijd & als je de spatie weglaat)
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
ik heb nu idd & van alle & tekens gemaakt, en dat werkt
goed om te weten voor de toekomst..
ik las iets over in php.ini de &-seperator vervangen met ;
wat is jullie mening hierover?
goed om te weten voor de toekomst..
ik las iets over in php.ini de &-seperator vervangen met ;
wat is jullie mening hierover?
As a rule, I never touch anything more sophisticated and delicate than myself.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | Foto_ID | Foto -------------------- 1 | blob1 2 | blob2 Tabel steekwoord: Steekwoord_ID | Steekwoord ----------------------------------- 1 | groen 2 | blauw Tabel Foto_steekwoord: Foto_ID | Steekwoord_ID ---------------------------------------------------- 1 | 2 2 | 2 |
En dan iets met inner join queries?
Of zie ik alles nu helemaal verkeerd?
Hoe wil je nu meerdere steekwoorden aan 1 foto koppelen dan?
Edit:
Heb zelf ook geen oplossing maar dit is nu niet mogelijk in ieder geval.
Probleem is dat je hier een many-to-many relatie hebt. Ergo: 1 foto kan meerdere steekwoorden hebben en 1 steekwoord kan meerdere foto's hebben.
Oplossing:
Je tabel klopt in principe wel
Je moet alleen Foto_ID óf Steekwoord_ID in de Foto_Steekwoord tabel níet auto-increment maken of unique.
Dan kan je dus ook zoiets krijgen:
[ Bericht 60% gewijzigd door DaFan op 29-03-2006 15:53:30 ]
Edit:
Heb zelf ook geen oplossing maar dit is nu niet mogelijk in ieder geval.
Probleem is dat je hier een many-to-many relatie hebt. Ergo: 1 foto kan meerdere steekwoorden hebben en 1 steekwoord kan meerdere foto's hebben.
Oplossing:
Je tabel klopt in principe wel
Je moet alleen Foto_ID óf Steekwoord_ID in de Foto_Steekwoord tabel níet auto-increment maken of unique.
Dan kan je dus ook zoiets krijgen:
| 1 2 3 4 5 | 1 | 1 1 | 2 2 | 1 2 | 3 |
[ Bericht 60% gewijzigd door DaFan op 29-03-2006 15:53:30 ]
Dan is er niks aan het handjequote:Op woensdag 29 maart 2006 16:21 schreef fokME2 het volgende:
Ja, dat bedoelde ik ook
Kostte me ff om door te krijgen omdat je kolom maar 2 rijen lang was
In die koppeltabel wil je helemaal geen auto-increment. Da's namelijk niet handig. Gewoon een primary key op (Foto_ID, Steekwoord_ID) en een index op Steekwoord_ID. Da's de handigste manier om beide kanten op te kunnen zoeken.quote:Op woensdag 29 maart 2006 15:43 schreef DaFan het volgende:
Hoe wil je nu meerdere steekwoorden aan 1 foto koppelen dan?
Edit:
Heb zelf ook geen oplossing maar dit is nu niet mogelijk in ieder geval.
Probleem is dat je hier een many-to-many relatie hebt. Ergo: 1 foto kan meerdere steekwoorden hebben en 1 steekwoord kan meerdere foto's hebben.
Oplossing:
Je tabel klopt in principe wel
Je moet alleen Foto_ID óf Steekwoord_ID in de Foto_Steekwoord tabel níet auto-increment maken of unique.
