[PHP/(My)SQL] voor dummies - Deel 62 | Digital Corner (DIG/DEV)

zaterdag 30 augustus 2008 @ 11:30:08 #154

GlowMouse

l'état, c'est moi

Zeg eens welke velden nu allemaal geïndexeerd staan (of beter, geef je CREATE TABLE query), en toon EXPLAIN eens met die FORCE INDEX.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 11:35:47 #155

Chandler

Ik heb even een create table dump gemaakt:
http://www.bruggema.nl/tables.sql

Dit zijn alle tabellen die gebruikt worden.

Force index snap ik nog niet geheel, ben de documentatie nog aan het doorspitten

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 11:40:29 #156

GlowMouse

l'état, c'est moi

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT fish.id,
               fish.user_id,
               fish.catchdate,
               fish_categories.name,
               users.username,
               media.id AS photo_id
        FROM fish FORCE INDEX(id)
        LEFT JOIN users ON users.id = fish.user_id
        LEFT JOIN media ON media.source_id = fish.id
        LEFT JOIN fish_categories ON fish_categories.id = fish.fish_id
        GROUP BY fish.id
        ORDER BY fish.id DESC
        LIMIT 0,4

En zoveel keys zijn het nog niet. Inserts/updates gaan wel wat trager nu, dus als je relatief veel inserts of updates hebt, moet je het aantal indices tot een minimum beperken. En indices die je helemaal niet gebruikt kun je sowieso beter helemaal weglaten.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 11:42:48 #157

Chandler

Nu heb ik die query gedaan en kreeg opeens te zien dat na het weghalen van de FORCE het opeens geen filesystem meer gebruikt als sorteer optie!? hoe kan dat?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 11:47:02 #158

GlowMouse

l'état, c'est moi

Filesort hoeft niet van het filesystem gebruik te maken hoor. En hoe het kan? Indices stonden net toch verkeerd, of heb je een analyze table gedaan?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 11:56:44 #159

Chandler

ik had niets aangepast, maar blijkbaar had MySQL zelf even de indexes aangemaakt oid.

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 11:58:40 #160

GlowMouse

l'état, c'est moi

Is dat even makkelijk

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 12:00:49 #161

Chandler

Maar toch is de site nog sloom, maar goed; dan heb ik weer wat te doen.

-edit-doethetal

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 12:02:07 #162

GlowMouse

l'état, c'est moi

Laat hij standaard gewoon zien. Maar ik zou er een scriptje voor maken. Voeg dan wel SQL_NO_CACHE toe aan je query, anders zul je zien dat de meest complexe queries anders in no-time worden uitgevoerd. En houd er ook rekening mee dat tabellen op een gegeven moment in het geheugen zitten, en het dan een stuk sneller gaat dan wanneer iemand je site bezoekt wanneer die tabel niet meer in het geheugen zit.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zondag 31 augustus 2008 @ 21:40:54 #163

Chandler

Nu we toch bezig zijn met indexes, heb ik het volgende; dit heb ik ergens gelezen op het internet en wilde eens weten of dit klopt

Stel je hebt een tabel waarin je personen zet.
voornaam,
achternaam
leeftijd,
woonplaats

en nu heb je op deze tabel heel veel queries draaien, maar je wilt zorgen dat dit alles snel gaat. De meeste queries zoeken op voornaam, achternaam en of woonplaats.

Dan moest je volgens het artikel de volgorde van je INDEXES volgen (bij gecombineerde indexes).
voorbeeld INDEX (voornaam, achternaam, woonplaats)

Volgens het artikel waren de volgende zoek mogelijkheden mogelijk:
SELECT voornaam, achternaam, leefttijd, woonplaats
FROM personen
WHERE woonplaats = 'Groningen'
AND achternaam = 'Test'
AND voornaam = 'Eric'

maar niet als je zo zocht:
SELECT voornaam, achternaam, leefttijd, woonplaats
FROM personen
WHERE voornaam = 'Eric'
AND achternaam = 'Test'
AND woonplaats = 'Groningen'

Klopt dit? zit nu niet echter een machine met MySQL en of wachtwoorden van sites

en zo ja, kan iemand dit dan eens duidelijk en zo mogelijk volledig uitleggen?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zondag 31 augustus 2008 @ 21:46:46 #164

GlowMouse

l'état, c'est moi

Nee klopt niet. Lees http://dev.mysql.com/doc/(...)-column-indexes.html eens door.

Belangrijkste is "A multiple-column index can be considered a sorted array containing values that are created by concatenating the values of the indexed columns"
Daarom werkt bij jou index zoeken op WHERE achternaam="blah" niet, maar op WHERE achternaam="blah" AND voornaam="hoi" wel. En daarom werkt het bij een OR niet zo goed, omdat hij alleen het tweede (en derde) stuk van een index gebruiken wanneer het eerste (en tweede) stuk constant is.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zondag 31 augustus 2008 @ 22:04:33 #165

Chandler

In het voorbeeld dat ik net las stond het volgende:

quote:
The name index is an index over the last_name and first_name columns. The index can be used for queries that specify values in a known range for last_name, or for both last_name and first_name. Therefore, the name index is used in the following queries

Nu zie ik dat de voorbeelden andersom moesten, dan klopt het!

nog een mooie quote:
MySQL cannot use an index if the columns do not form a leftmost prefix of the index gewoon index volgen in je where parameters beginnend van links naar rechts en eventueel meer toevoegen... ?

^{ik probeer het allemaal te begrijpen maar't gaat niet zo snel}

dus dit werkt met de index:
SELECT *
FROM personen
WHERE voornaam = 'Eric'

en

SELECT *
FROM personen
WHERE voornaam = 'Eric'
AND achternaam = 'Test'

en dus ook alle 3 en eventueel meer

SELECT *
FROM personen
WHERE voornaam = 'Eric'
AND achternaam = 'Test'
AND woonplaats = 'Groningen'
AND leeftijd < 50

maar hoe werkt het dan met dit:

SELECT *
FROM personen
WHERE voornaam = 'Eric'
AND achternaam = 'Test'
AND leeftijd < 50

zal deze dan ook de index gebruiken?

ik vraag maar hoor

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zondag 31 augustus 2008 @ 22:09:42 #166

GlowMouse

l'état, c'est moi

Via voornaam en achternaam (en bij die een na laatste ook woonplaats) haalt hij de rijen op die eraan voldoen, en daarna checkt hij bij die rijen de leeftijd. Daarom is Woonplaats niet zo nuttig om in je index te zetten: tenzij je de query SELECT woonplaats FROM table WHERE voornaam='a' AND achternaam='b' heel vaak gebruikt (zodat je een covering index hebt, maar dat is alleen nuttig als je hem heel vaak gebruikt), omdat er toch niet veel rijen overblijven na selectie op voornaam en achternaam. Want onthoud: hoe langer de index, hoe meer tijd hij kost om bij te werken, en hoe meer tekstvelden in een index, hoe trager hij wordt bij een SELECT-query omdat hij dan erg groot (veel kB's) wordt.

Overigens zie je via EXPLAIN SELECT ... welk deel van de index naar verwachting benut zal worden.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zondag 31 augustus 2008 @ 22:13:36 #167

Light

quote:
Op zondag 31 augustus 2008 22:04 schreef Chandler het volgende:
In het voorbeeld dat ik net las stond het volgende:
[..]

Nu zie ik dat de voorbeelden andersom moesten, dan klopt het!

nog een mooie quote:
MySQL cannot use an index if the columns do not form a leftmost prefix of the index gewoon index volgen in je where parameters beginnend van links naar rechter en eventueel meer toevoegen... ?

Als je een index hebt op (lastname, firstname) dan kun je queries doen als:
SELECT * FROM persons WHERE lastname="Test";
SELECT * FROM persons WHERE lastname="Test" AND firstname="Eric";
SELECT * FROM persons WHERE firstname="Eric" AND lastname="Test";
Maar niet:
SELECT * FROM persons WHERE firstname="Eric";

fokstok.nl

maandag 1 september 2008 @ 09:25:19 #168

Chandler

Duidelijk, dan zijn mijn queries toch aardig goed

en indexes ook

Een andere vraag stel ik wil het volgende opslaan.

71.231
302.121
5.1231

Wat moet ik daarvoor gebruiken? gebruik nu een char, maar dat lijkt me niet echt handig

Verder heb ik een query die best wel veel tijd neemt en heb deze met analyze geprobeerd te begrijpen:

1
2
3
4
5

EXPLAIN SELECT stats_ip_link.stat_id, count( stats_ip.id ) AS count
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE UNIX_TIMESTAMP( stats_ip_link.lastdate ) > ( UNIX_TIMESTAMP( NOW( ) ) - ( 60 *15 ) )
GROUP BY stats_ip_link.stat_id

nu krijg ik het volgende resultaat:

1
2
3

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE stats_ip_link ALL NULL NULL NULL NULL 70168 Using where; Using temporary; Using filesort
1 SIMPLE stats_ip eq_ref PRIMARY PRIMARY 4 gfxstatcom_db.stats_ip_link.ip_id 1 Using index

nu heb ik op het tabel stats_ip_link een index op stat_id en stat_ip en een index op 'lastdate` maar nog steeds is deze sloom

Anyone?

of is het handiger dat ik lastdate en firstdate (beiden datetime) verander naar timestamp oid?

[ Bericht 33% gewijzigd door Chandler op 01-09-2008 09:44:02 ]

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 10:21:55 #169

GlowMouse

l'état, c'est moi

Die nummers kun je het beste opslaan als een mediumint (signed/unsigned, afhankelijk van of je wel/geen negatieve nummers tegenkomt).

De index op stats_ip_link is lastig: je kunt hem op lastdate zetten voor de WHERE, je kunt hem op stat_id zetten voor de GROUP BY, maar op (lastdate,stat_id) heeft het geen zin omdat lastdate niet constant is en stat_id daarna niet meer benut kan worden. Het beste lijkt mij hier een index op lastdate, omdat hoe langer je die tabel houdt, je na toepassen van de WHERE altijd ongeveer evenveel resultaten overhoudt, zodat het in de loop der tijd niet langzamer wordt.
Die index moet wel benut kunnen worden, en als je een functie op een kolom loslaat, kan dat niet meer. Zelf werk ik altijd met unix timestamps in een database, maar jouw aanpak moet ook kunnen werken. Kun je niet iets doen als lastdate > mysqls datetime formaat van 15 minuten geleden?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:06:14 #170

Chandler

Ook een index op lastdate werkt niet qua snelheid bevordelijk!

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:07:52 #171

GlowMouse

l'état, c'est moi

Dat is gek, welke query gebruik je nu, en hoeveel rijen voldoen er aan WHERE UNIX_TIMESTAMP( stats_ip_link.lastdate ) > ( UNIX_TIMESTAMP( NOW( ) ) - ( 60 *15 ) ) ?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:23:10 #172

Chandler

80 rijen maar dit kan per seconde veranderen

en de query die ik eerder ook al gepost heb

1
2
3
4
5

SELECT stats_ip_link.stat_id, count( stats_ip.id ) AS count
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE UNIX_TIMESTAMP( stats_ip_link.lastdate ) > ( UNIX_TIMESTAMP( NOW( ) ) - ( 60 *15 ) )
GROUP BY stats_ip_link.stat_

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:32:26 #173

GlowMouse

l'état, c'est moi

Met 80 zou hij heel snel moeten zijn. Moet je wel dit in acht nemen:

quote:
Die index moet wel benut kunnen worden, en als je een functie op een kolom loslaat, kan dat niet meer. Zelf werk ik altijd met unix timestamps in een database, maar jouw aanpak moet ook kunnen werken. Kun je niet iets doen als lastdate > mysqls datetime formaat van 15 minuten geleden?

En die query moet ook wachten als de tabel geüpdatet wordt, dus dat kan wel wat traagheid veroorzaken, maar met een rij of 80 is het anders heel snel als die index benut kan worden.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:38:41 #174

Chandler

Zou ik ook zeggen maar helaas

het blijft toch sloom

Er staan ruim 70.000 items in dit tabel, waarbij lastdate geindexeerd is!. Je zou denken dat de server dit binnen 0.01 seconde zou moeten kunnen uitzoeken maar helaas, dat doet het niet

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:41:09 #175

GlowMouse

l'état, c'est moi

Hoe ziet je query er dan nu uit?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:42:47 #176

Chandler

Bedoel je met explain of zonder explain? zonder is de zelfde als bovenstaande

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:43:22 #177

GlowMouse

l'état, c'est moi

Ik quote mezelf toch niet voor niks? f(kolom) kan niet geïndexeerd worden, dus moet je je query aanpassen.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:45:57 #178

Chandler

Ik snap je niet helemaal (probeer het wel hoor

)

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:48:09 #179

GlowMouse

l'état, c'est moi

Je query moet in deze vorm staan:

1
2
3
4
5

SELECT stats_ip_link.stat_id, count( stats_ip.id ) AS count
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE stats_ip_link.lastdate > .......
GROUP BY stats_ip_link.stat_id

MySQL is niet slim genoeg om in te zien dat UNIX_TIMESTAMP een monotone functie is.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 12:18:50 #180

Chandler

Ik zie idd dat de snelheid bepaald wordt door unix_timestamp

1
2
3
4
5

SELECT stats_ip_link.stat_id, count( stats_ip.id ) AS count
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE stats_ip_link.lastdate > ( NOW( ) - ( 60 *15 ) )
GROUP BY stats_ip_link.stat_id

deze query duurde 0.022 terwijl deze (vorige) ruim 0.7xxx aan tijd nam.

Echter verschillen beide queries qua uitkomst :{

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 12:20:17 #181

GlowMouse

l'état, c'est moi

Dan kijk je naar de output van

1
2
3
4

SELECT *
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE stats_ip_link.lastdate > ( NOW( ) - ( 60 *15 ) )

en kijk je welke rijen er tussenstaan die er niet tussen zouden moeten staan.

Je ziet zelf al wat er fout gaat met deze query: SELECT NOW( ) , NOW( ) -15 *60

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 12:24:47 #182

Chandler

Ik zie het idd!

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 12:26:56 #183

GlowMouse

l'état, c'est moi

Doe eens deze query: SELECT NOW(), NOW( ) -15 *60, SUBTIME(NOW(),'0 0:15:0');
Dan zou je genoeg moeten weten

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 12:29:42 #184

Chandler

Super!!! dat scheelt per query zo'n 0.7xxx seconden!!!

Maar is het in mijn geval niet handiger om gewoon de timestamp op te slaan?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 12:31:32 #185

GlowMouse

l'état, c'est moi

Kwestie van voorkeur

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 12:46:31 #186

Chandler

Zou het geen preformance verschil (op de lange duur) met zich mee brengen? en het scheelt volgens mij ook in de grootte die het op de schijf neemt

quote:
TIMESTAMP requires 4 bytes.
DATETIME requires 8 bytes.

http://bitfilm.net/2007/08/25/choosing-optimal-mysql-data-types/

en ik denk dat timestamps gemakkelijker te indexeren zijn (denk ik)

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 13:03:04 #187

GlowMouse

l'état, c'est moi

Je index wordt de helft kleiner, dus het zal wel wat schelen. Maar dat verschil is heel klein, en wordt nauwelijks groter. Een TIMESTAMP zal op termijn (zeker in 20-30 jaar) trouwens ook naar 8 bytes gaan omdat je anders geen datums na 2037 op kunt slaan.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 14:37:30 #188

Nevermind

(-_-)

Ik wil in mijn .htaccess alles matchen, behalve afbeeldingen. Ik wil alle afhandeling van de querystring overlaten aan php. Dus:

http://domein.nl/blaat/bla/bla/bla -> index.php?querystring=blaat/bla/bla/bla
http://domein.nl/hoi.html -> index.php?querystring=hoi.html
http://domein.nl/plaatje.png -> geen match

Dat houdt in dat ook slashes gematcht moeten worden in de RewriteRule, en dat krijg ik niet werkend.

1
2
3
4
5

RewriteEngine On
RewriteBase /project

RewriteCond %{REQUEST_FILENAME} \.^(gif|jpe?g|png)$ [NC]
RewriteRule ^([A-Za-z0-9-\-.\/]+)$ index.php?input=$1

Ik zie iets over het hoofd. Afbeeldingen worden wel weergegeven, iets willekeurigs invullen als url geeft een 404.

GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!

maandag 1 september 2008 @ 15:09:07 #189

slakkie

Nevermind, dat heeft heul niks met php of mysql te maken.

maandag 1 september 2008 @ 15:33:48 #190

Nevermind

(-_-)

True, maar een nieuw topic openen voor zo'n kleine vraag is ook loos. Lijkt me dat hier veel mensen zijn die het antwoord wel weten

GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!

maandag 1 september 2008 @ 17:11:25 #191

slakkie

Jongens, maak je een for-loop in perl? Simpele vraag, kunnen mensen hier vast beantwoorden

maandag 1 september 2008 @ 18:42:18 #192

Chandler

Nog een vraagje, ik wil 2 timestamps gebruiken in 1 tabel, echter krijg ik dit niet voor elkaar.. Error in de zin van dubbele CURRENT_TIME oid. Hoe los ik dit op? of moet ik gewoon INT gebruiken?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 18:45:16 #193

Xcalibur

Je kunt geen twee timestamps in 1 tabel gebruiken... in ieder geval geen timestamps die automatisch geupdate worden iig. Erg irritant, ik snap ook echt niet waarom dat niet kan

maandag 1 september 2008 @ 19:15:38 #194

SuperRembo

Sinds 1998

quote:
Op maandag 1 september 2008 18:45 schreef Xcalibur het volgende:
Je kunt geen twee timestamps in 1 tabel gebruiken... in ieder geval geen timestamps die automatisch geupdate worden iig.

En waarom zou je dat dan willen

maandag 1 september 2008 @ 19:47:28 #195

Xcalibur

1 voor de create datum (automatisch bij inserten) en 1 voor de laatste wijziging datum (automatisch bij updaten)

maandag 1 september 2008 @ 20:00:21 #196

Chandler

Correct, daarom wil ik 2x een timestamp hebben die niet automatisch geupdated wordt!

of een mogelijkheid dat ik 2x een timestamp kan gebruiken!

-edit-
je kunt wel twee timestamps gebruiken maar zit er een máár aan!. De eerste timestamp zal automatisch geupdated worden en de tweede niet, beetje vervelend

http://michaelkimsal.com/(...)eatedupdated-values/

nu is de vraag wat moet ik gebruiken om een alternatieve manier voor timestamp in te kunnen voeren?

[ Bericht 22% gewijzigd door Chandler op 01-09-2008 20:09:26 ]

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 20:14:59 #197

SuperRembo

Sinds 1998

Kan dit dan niet tegelijk in 1 tabel?

1 2	created TIMESTAMP DEFAULT CURRENT_TIMESTAMP modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

[edit]
Dat kan dus blijkbaar niet:

quote:
MySQL said:
#1293 - Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause

Vreemd. Maar dan maak je gewoon 1 autoupdate kolom (modified) en de ceated insert je zelf. (Dat insert statement heb je uiteraard maar op 1 plaats staan, dus dat pas je ze aan

)

[ Bericht 38% gewijzigd door SuperRembo op 01-09-2008 20:37:13 ]

maandag 1 september 2008 @ 20:16:29 #198

Chandler

Nee, de eerste moet de modified zijn en de 2e de createdate, en helaas heb ik het in mijn huidig model net andersom

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 20:17:18 #199

SuperRembo

Sinds 1998

quote:
Op maandag 1 september 2008 20:00 schreef Chandler het volgende:
je kunt wel twee timestamps gebruiken maar zit er een máár aan!. De eerste timestamp zal automatisch geupdated worden en de tweede niet, beetje vervelend

Wat is het nut van twee kolommen waar altijd dezelfde waarde in staat?

maandag 1 september 2008 @ 20:35:58 #200

Chandler

Hoezo? 1 is voor de aanmaak datum de 2e is voor de laatste update? daar is toch niets het zelfde in? tenzij een record niet geupdated wordt na aanmaak???

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 22:20:55 #201

poepeneesje

bR33Z4h

Als ik probeer te verbinden met de database van mijn provider PCextreme krijg ik de volgende melding:

1	Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Wie-o-wie weet de oplossing, ik zal diegene eeuwig dankbaar zijn _O_.

Aan dit bericht kunnen geen rechten worden ontleend.

maandag 1 september 2008 @ 22:23:05 #202

Farenji

Ik gok dat je niet het juiste ipadres of de juiste hostnaam hebt ingevuld.

maandag 1 september 2008 @ 22:28:45 #203

poepeneesje

bR33Z4h

quote:
Op maandag 1 september 2008 22:23 schreef Farenji het volgende:
Ik gok dat je niet het juiste ipadres of de juiste hostnaam hebt ingevuld.

quote:
Database-server: sql10.pcextreme.nl (sql10.pcextreme.nl)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php
    $mysqlserver = "sql10.pcextreme.nl";
    $user = "user";
    $password = "password";
    $database = "database";

    $connect = mysql_connect($mysqlserver, $user, $password)
    or die (mysql_error());
    // echo "<p>Er is een connectie opgezet met de MySQL-server: <strong>" . $mysqlserver . "</strong>. ";

    mysql_select_db($database)
    or die (mysql_error());
    // echo " Van deze MySQL-server is de database <strong>" . $database . "</strong> geselecteerd.</p>";
?>

Aan dit bericht kunnen geen rechten worden ontleend.

maandag 1 september 2008 @ 23:44:14 #204

Hafez

Mafioso

Ik heb nu twee tabellen,

users & company.

tabel company bestaat uit id, naam en uids
tabel users bestaat uit id en naam

Nu wil ik in een pagina in een multi select box alle users tonen en meerdere users tegelijkertijd kunnen selecteren en de waarde daarvan toevoegen in tabel company.

Dus stel ik heb Erik met id 1 en Peter met id 2 en company Microsoft heeft beide users dan komt er in de row van Microsoft te staan: Microsoft met id 1 en uids 1;2 of misschien is dit als array ook mogelijk?

Wat heb ik is iig een simpel multi select box:

1
2
3
4
5
6
7
8

<?php
echo '<SELECT MULTIPLE SIZE=10>';
while($row = mysql_fetch_array($result)){
echo '<OPTION VALUE='.$row["id"].'>';
echo $row["name"];
}
echo "</SELECT>";
?>

Nu moeten de waardes van de geselecteerde items alleen toegevoegd worden aan company en juist daar zit ik nu een beetje mee..

Forum Opties
Forumhop:
Hop naar:	(afkorting, bv 'KLB')

[PHP/(My)SQL] voor dummies - Deel 62

» digital corner

» development

» digital corner

» development