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.
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.
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
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...
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.
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.)
*verwijderd*quote:
1 2 3 4 | system identifier could be generated. <a href="main.php?&mID=122&sID=163"> |
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.
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 |
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 |
1 2 3 4 5 | 1 | 1 1 | 2 2 | 1 2 | 3 |
Dan is er niks aan het handjequote:
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.
Dat staat erquote:Op woensdag 29 maart 2006 16:34 schreef Light het volgende:
[..]
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.
Hoe bedoel je dat?quote:Op woensdag 29 maart 2006 22:41 schreef DaFan het volgende:
Is er een mogelijkheid om ná het zoeken van een string automatisch een variabele in te vullen in een form en deze te submitten?
Edit: In hetzelfde scherm. Ik heb de broncode in HTML, delen ervan zijn in Javascript maar in principe heb ik die niet nodig.
Nou je hebt een tabel met 4 tabellen. In de eerste kolom staat een type, in de tweede kolom hoeveel er daar van zijn en de 4e kolom bestaat uit een 'type=text'quote:
Nou ik maak straks in VB wel ff een formpje + screenshot dat maakt het wat duidelijker denk ikquote:Op donderdag 30 maart 2006 08:59 schreef fokME2 het volgende:
Als je een stukje code paste dan wordt het misschien allemaal wat duidelijker.![]()
1 2 3 4 5 | ----------------------------------------- Fietsen | 100 | Max | [textbox] Auto's | 50 | Max | [textbox] [Submit] |
Volgens mij kan ik daar wel wat mee, ik zie ook een functie online staan, vanmiddag maar ff testenquote:Op woensdag 29 maart 2006 22:02 schreef JeRa het volgende:
@Darkomen
Je kunt binnen één verbinding van database wisselen, zie deze functie bijvoorbeeld. Ook geloof ik dat er een bepaalde syntax bestaat waarbij je niet eens hoeft te wisselen maar binnen één query verschillende databases kunt aanspreken. Die moet ik even nazoeken.
edit: het is mogelijk
SELECT * FROM database1.tabel, database2.anderetabel
<input type="text" name="bla" value="$max"> moet gewoon werken toch?quote:Op donderdag 30 maart 2006 10:39 schreef DaFan het volgende:
[ code verwijderd ]
Ik wil zoeken op de string "Fietsen" bijvoorbeeld. Daarna wil ik dat er herkent wordt dat er 100 zijn, en er 100 invult in het tekstvak. En dan nog op submit ramt
Dat 'max' zit er, want dan wordt automatisch die 100 ingevuld. Maar ik wil het juist niet handmatig doen.
Edit:
En zo ziet de site eruit:
[afbeelding]
Ik wil dus 95 hebben staan in dat laatste vak. Onderop zit nog ergens de submitknop.
En ik wil gewoon weten of het überhaupt mogelijk is om iets in te laten vullen of moet je dan gewoon de variabelen meenemen na het scherm daarna?
Meer een HTML kwestie dus?quote:Op donderdag 30 maart 2006 11:13 schreef Desdinova het volgende:
[..]
<input type="text" name="bla" value="$max"> moet gewoon werken toch?
en alstie meteen moet submitten zou
<body onload="document.form.submit();">
voldoende moeten zijn..
mja, maar met een php waarde uit de database.quote:
Ik ga straks een wat beginnen met een eigen tabelletje, als dat werkt ga ik ze van die site af proberen te trekken. Bedankt voor de start iigquote:Op donderdag 30 maart 2006 11:28 schreef Desdinova het volgende:
[..]
mja, maar met een php waarde uit de database.
1 2 3 4 5 6 7 8 9 10 11 12 | case (empty($name)); echo "U heeft niet uw naam ingevuld"; case (empty($lastname)); echo "U heeft niet uw achternaam ingevuld"; case (empty($email)); echo "U heeft geen email adres ingevuld ingevuld"; case (empty($subject)); echo "U heeft geen onderwerp ingevuld"; break; default: echo "alle gegevens zijn correct ingevoerd.";} |
1 2 3 4 5 6 7 8 9 | if (empty($name)) $msg[] = 'U heeft niet uw naam ingevuld'; if (empty($lastname)) $msg[] = 'U heeft niet uw achternaam ingevuld'; // ... if (count($msg) == 0) { // alles goed } else { // toon de fouten } |
Dank je wel, ik ga het op die manier proberen.quote:Op zaterdag 1 april 2006 11:00 schreef SuperRembo het volgende:
Je zorgen dat altijd alle velden gecontroleerd worden en alle foutmeldingen verzamel je.
[ code verwijderd ]
1 2 3 | print date("Y-m-d", time()); print "\">"; |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | session_start(); # includes require("includes/mysql.php"); # defined variables $path = explode(".",$_SERVER['PHP_SELF']); $path = substr($path[0],0,5); $domain = $_SERVER['HTTP_HOST']; if(!isset($_COOKIE['hash']) && !isset($_COOKIE['SESSID'])) { if($_SERVER['REQUEST_METHOD'] == 'POST') { $hash='1'; setcookie("hash",$hash,time()+1000,$path[0],$domain,0); setcookie("SESSID",session_id(),time()+1000,$path[0],$domain,0); echo("form submitted"); //er is en formulier gesubmit } else { print($HTTP_COOKIE); include("includes/login.html"); //laat login scherm zien } } else { echo("er is een cookie gevonden met de volgende inhoud:<br>"); print_r($_COOKIE); } ?> |
Openen in een nieuw scherm doe ik niet, het gaat er nu net om dat ik voor mezelf alle strips die ik dagelijks lees op een rijtje bij elkaar hebquote:Op maandag 3 april 2006 17:07 schreef JeRa het volgende:
@De_Hertog
Zoals het nu is laat je de bezoeker het plaatje downloaden. Die bekijkt dat plaatje vanaf jouw domein en zal dat dus ook als referer doorsturen, wat leidt tot de blokkade van AD.
Eén oplossing is dat jij elk plaatje automagisch downloadt via PHP door een HTTP GET-request te doen naar files.ad.nl met de URI en de goede referer. Deze plaatjes kun je dan aan je bezoekers tonen, zorg er dan wel voor dat je ze cachet zodat het allemaal snel blijft.
Sommige browsers sturen geen referer mee als je een pagina of bestand opent in een nieuw scherm. Geen idee of dat bij IE en FF zo is, maar je zou het kunnen proberen.
Als je trouwens niet wilt kloten met fsockopen() raad ik je de CURL-library aanquote:Op dinsdag 4 april 2006 13:01 schreef De_Hertog het volgende:
[..]
Openen in een nieuw scherm doe ik niet, het gaat er nu net om dat ik voor mezelf alle strips die ik dagelijks lees op een rijtje bij elkaar hebJe andere oplossing zal ik proberen, bedankt!
Wat staat er in $domain, $path en waar draait je script?quote:Op dinsdag 4 april 2006 12:58 schreef mschol het volgende:
na een uurtje zoeken eindelijk het topic gevonden
het lukt mij om de een of andere reden niet om een cookie in te stellen:
[ code verwijderd ]
op de pagina na dde submit dan kan ik het cxookie perfect uitlezen (nogal wiedes,i op zelfde pagina gemaakt.
maar zodra ik de directoy opnieuw aanroep dan komt hij doodleuk weer met de melding om aan te melden?
wat doe ik verkeerd? (vast iets simpels maar toch)
$domain = server of pwaschool.com (afhankelijkvan hoe ik em benader)quote:Op dinsdag 4 april 2006 13:50 schreef JeRa het volgende:
[..]
Wat staat er in $domain, $path en waar draait je script?
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |