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

woensdag 7 september 2005 @ 23:27:19 #101

JeRa

quote:
Op woensdag 7 september 2005 22:02 schreef wonderer het volgende:
Ik wil graag backupbestanden van 200000 records terugzetten... hoe kan ik dat het beste doen? Uploaden via SQL gaat niet...

Je doet dit waarschijnlijk via phpMyAdmin? Die heeft de beperking van HTTP file uploads, enkele MB's dus. Wat je kunt doen:

andere tools gebruiken die geen limiet hebben en direct contact kunnen maken met de MySQL server

je backupbestanden opsplitsen zodat de afzonderlijke delen kleiner zijn dan de maximale toegestane limiet om te uploaden

donderdag 8 september 2005 @ 12:21:12 #102

markiemark

FR 1908

ik heb even een klein vraagje.. heb het niet eens nodig of zo, maar kan het hier niet ff zo proberen, maar wil het toch even weten..

stel ik heb een pagina met daarin een include.. kan ik dat dan zo doen dat de URL variabele meegestuurd wordt? dus bijv.

1
2
3

<?php
include "header.php?pagina=homepage";
?>

zodat header.php een actie uitvoert die afhangt van de get variabele pagina...

ben benieuwd..

Amsterdam, stad van hash en coke,
Waar de vrouwen zich vrouwelijk gedragen..
En de mannen ook..

donderdag 8 september 2005 @ 12:23:29 #103

Roonaan

Strictly

<?php
$pagina = 'homepage';
include 'header.php';
?>

Of

<?php
include "http://www.mijndomein.nl/header.php?pagina=homepage";
?>

volledige url dus. Lijkt me alleen niet verstandig vanuit performance point of view.

donderdag 8 september 2005 @ 13:53:47 #104

JeRa

De eerste oplossing van Roonaan is dus de beste

ik weet het natuurlijk niet zeker maar ik gok dat je een index.php hebt die zo wordt aangeroepen:

index.php?pagina=blaat

En dat je nu header.php wilt includen die dezelfde informatie doorkrijgt. Door deze te includen gaat PHP in feite de broncode van header.php in je index.php zetten, waardoor header.php dus exact dezelfde variabelen als index.php kan gaan benaderen. In feite doe je in header.php dus hetzelfde als hetgeen je in index.php doet om die variabele te achterhalen

donderdag 8 september 2005 @ 16:31:55 #105

Chandler

offtopic (beetje) misschien is het eens leuk om een PHP regex archive op te zetten?

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

donderdag 8 september 2005 @ 18:06:26 #106

JeRa

quote:
Op donderdag 8 september 2005 16:31 schreef Chandler het volgende:
offtopic (beetje) misschien is het eens leuk om een PHP regex archive op te zetten?

Die bestaan al, maar het zou wel eens leuk zijn om een archive te zien die zich ook aan de standaarden houdt

(probeer maar eens een eenduidige regular expression te vinden die een e-mailadres checkt).

vrijdag 9 september 2005 @ 11:05:22 #107

MaxPowered

Au Gurk!

Hoi,

Ik last laatst een artikel over SQL injection. Dus ik ff mijn site daarop gecheckt.

Een voorbeeld van SQL Injection uit het artikel:

1
2
3
4
5
6
7
8
9
10

<?php
mysql_connect("localhost", "root", "");
mysql_select_db("hack");

$query = mysql_query('SELECT bla FROM users ORDER BY bla '.$_GET['ORDER']);

while($row = mysql_fetch_array($query)) {
echo $row[bla];
}
?>

Als men daarna http://localhost/hack.php?ORDER=desc; DROP TABLE users zou uitvoeren, zou de tabel users verwijderd worden.
Mijns inziens is dit bullshit. Als ik het in de browser plak, krijg ik het volgende als ik op enter druk:
http://localhost/hack.php?ORDER=desc;%20DROP%20TABLE%20users

Is hiermee aangetoond dat SQL-injection niet werkt?

Alvast bedankt voor de tips,

m@x

-= Rogue lvl 66 =- -= Warrior lvl 70 =- -= Warlock lvl 70 =-
----------============= Nordrassil =============----------

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 14:05:27 #108

Swetsenegger

Egocentrische Narcist

quote:
Op vrijdag 9 september 2005 11:05 schreef MaxPowered het volgende:
Hoi,

Ik last laatst een artikel over SQL injection. Dus ik ff mijn site daarop gecheckt.

Een voorbeeld van SQL Injection uit het artikel:
[ code verwijderd ]

Als men daarna http://localhost/hack.php?ORDER=desc; DROP TABLE users zou uitvoeren, zou de tabel users verwijderd worden.
Mijns inziens is dit bullshit. Als ik het in de browser plak, krijg ik het volgende als ik op enter druk:
http://localhost/hack.php?ORDER=desc;%20DROP%20TABLE%20users

Is hiermee aangetoond dat SQL-injection niet werkt?

Alvast bedankt voor de tips,

m@x

Nee, daarmee is aangetoont dat je browser aan url encoding doet

Een pagina terug staat er een discussie over sql injection. Tussen quotes heb je minder kans op injection, maar is nog wel degelijk aanzweig.

De uitkomst van de discussie was dat je sowieso ALTIJD userinput moet controleren.

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 18:31:05 #109

JeRa

...en dat je in een query altijd het goede type moet laten vertegenwoordigen, om zo geen onnodige risico's of trage queries te introduceren

edit: overigens, ik geloof dat het al een tijdje zo is dat je in PHP geen meerdere queries in één keer kunt uitvoeren door puntkomma-gescheiden queries achter elkaar te zetten. Die injectie zou dus wrs niet eens willen werken

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 20:27:59 #110

Swetsenegger

Egocentrische Narcist

Ik heb 3 tabellen, hieronder de relevante velden

table ad

1 2	ad_id id_user

table user

1 2	user_id name

table rate

1
2
3

rate_id
user
rating

Ad heeft bij elke record een corresponderende user in ID-user
User spreekt voor zich
rate KAN een aantal records met de corresponderende user hebben.

Ik wil uit ad het totaal aantal reords van user
uit user de naam
uit rate de gemiddelde rate van desbetreffende user (indien die bestaat)

1
2
3
4
5
6
7

<?php
SELECT COUNT(ad.ad_id)  AS number, user.name, AVG(SUM(rate.rating))
FROM ad
INNER JOIN user ON (id_user = user_id)
RIGHT JOIN rate ON (id_user = user)
WHERE ad.id_user=1
?>

Dit geeft 'invalid use of group function' terug.

Mijn sql is niet zo sterk. Dus het zal ongetwijfeld aan mij liggen

Iemand die wat licht op de zaak kan schijnen?

[ Bericht 2% gewijzigd door Swetsenegger op 09-09-2005 20:56:40 ]

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 22:02:10 #111

SuperRembo

Sinds 1998

Er moet nog een GROUP BY user.name bij en volgens mij moet het een LEFT JOIN zijn in plaats van RIGHT JOIN.

1
2
3
4
5
6

SELECT user.name, COUNT(ad.ad_id) AS number, AVG(SUM(rate.rating))
FROM user
INNER JOIN ad ON ad.id_user = user.user_id
LEFT JOIN rate ON rate.user = user.user_id
WHERE user.user_id = 1
GROUP BY user.name

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 22:03:57 #112

Swetsenegger

Egocentrische Narcist

quote:
Op vrijdag 9 september 2005 22:02 schreef SuperRembo het volgende:
Er moet nog een GROUP BY user.name bij en volgens mij moet het een LEFT JOIN zijn in plaats van RIGHT JOIN.
[ code verwijderd ]

Dat had ik inderdaad ook al geprobeerd.

'invalid use of group function'

als ik de AVG eruit haalt werkt dit prima overigens. Naam: 3 records.
In de SQL documentatie las ik dat AVG(SUM(field)) niet kan en dat je dan een subquery in de FROM statement moet gebruiken:

SELECT AVG(sum_field) FROM (SELECT SUM(field) AS sum_field FROM table GROUP BY field)

maar wanneer ik dit overneem krijg ik een sql error 'nearby SELECT SUM(fiels....' etc.

In de documentatie staat geen sql versie vermeld, dus ik neem aan dat dit gewoon op SQL 4.0.24 werkt

[ Bericht 18% gewijzigd door Swetsenegger op 09-09-2005 22:09:47 ]

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 22:17:20 #113

SuperRembo

Sinds 1998

Subquery's zijn dacht ik mogelijk vanaf MySQL 4.1.

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 22:20:08 #114

Swetsenegger

Egocentrische Narcist

Een tweakert had de oplossing

1
2
3
4
5
6

SELECT user.name, COUNT(ad.ad_id)  AS number, AVG(rate.rating) AS average
                        FROM user
                        INNER JOIN ad ON ad.id_user = user.user_id
                        LEFT JOIN rate ON rate.user = user.user_id
                        WHERE user.user_id =".$_GET['id']."
                        GROUP BY user.name"

 | FOK! Schrikkelbaasch

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 22:27:46 #115

Swetsenegger

Egocentrische Narcist

Een nadeel, als er geen rating is, laat hij de rest ook niet zien

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 22:40:15 #116

Roonaan

Strictly

waarom heb je zo'n komische naamgeving in je tabellen?
wrom niet gewoon:
[users]
user_id, user_name, user_whatever
[ads]
ad_id, ad_user
[ratings]
rate_id, rate_value, rate_user

Heb je vervolgens nergens meer problemen met ambigue fields of de noodzaak om de table.field constructie te gebruiken..

vrijdag 9 september 2005 @ 22:50:02 #117

SuperRembo

Sinds 1998

Ja da's handig zeg. Nu hoef je niet meer soms "table." voor een veldnaam te zetten, nee je zet er altijd "table_" voor

vrijdag 9 september 2005 @ 23:01:55 #119

JeRa

quote:
Op vrijdag 9 september 2005 22:50 schreef SuperRembo het volgende:
Ja da's handig zeg. Nu hoef je niet meer soms "table." voor een veldnaam te zetten, nee je zet er altijd "table_" voor

Ik snap deze opmerking niet

wat zeg je nu eigenlijk?

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 23:02:03 #120

Swetsenegger

Egocentrische Narcist

Ik gebruik nergens ambigue fields zoals je ziet.

En waarom niet zoals roonaan zegt... tja geen idee. Ik vind naamgeving irritant, zou alles het liefst een nummer geven

Overigens werkt de query wel, maar je moet natuurlijk in je life table wel dezelfde veldnamen gebruiken als in je test tabel

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 23:02:53 #121

SuperRembo

Sinds 1998

Ik ben niet lui hoor. Je moet weten wat je doet. Zelfs als je al je veldnamen in je database uniek maakt, dan is dat nog geen garantie dat je veldnamen in een query uniek zijn.

vrijdag 9 september 2005 @ 23:04:35 #122

Light

quote:
Op vrijdag 9 september 2005 23:02 schreef Swetsenegger het volgende:
Ik gebruik nergens ambigue fields zoals je ziet.

En waarom niet zoals roonaan zegt... tja geen idee. Ik vind naamgeving irritant, zou alles het liefst een nummer geven

Overigens werkt de query wel, maar je moet natuurlijk in je life table wel dezelfde veldnamen gebruiken als in je test tabel

Dat lijkt me sowieso een vereiste

fokstok.nl

vrijdag 9 september 2005 @ 23:07:10 #123

SuperRembo

Sinds 1998

quote:
Op vrijdag 9 september 2005 23:01 schreef JeRa het volgende:

[..]

Ik snap deze opmerking niet wat zeg je nu eigenlijk?

Roonaan stelt voor om voor elk veld in de tabel "users" de string "user_" te plakken. Dan zijn de veldnamen uniek, en hoek je (meestal) geen tabelnamen te vermelden voor de veldnamen in je query.

In plaats van

1	SELECT foo.name, bar.name FROM foo INNER JOIN bar ON bar.id = foo.id

krijg je dan

1	SELECT foo_name, bar_name FROM foo INNER JOIN bar ON bar_id = foo_id

Ik zie 't voordeel niet. Ik zie wel nadelen.

vrijdag 9 september 2005 @ 23:20:55 #124

saban

hoi?

Iemand een suggestie welke NL boek ik kan kopen om MySQL meer onder de knie te krijgen ?

Ik heb nu 2 PHP/MYSQL boeken liggen, maar die gaan niet verder dan SELECT .. WHERE .. LIKE

ne okuyon, bokmu var?

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 23:29:26 #125

Swetsenegger

Egocentrische Narcist

quote:
Op vrijdag 9 september 2005 23:04 schreef Light het volgende:

[..]

Dat lijkt me sowieso een vereiste

Ja dat is best handig

 | FOK! Schrikkelbaasch

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

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

» digital corner

» digital corner