PHP/MYSQL vraagje..

[TAFKAB]

Hai,
Heb een guestbook gemaakt mbv een DB (mysql), gaat allemaal goed.
ECHTER nu is er dus een post (tussen de velen) die ik wil verwijderen, hoe dit te doen?!
Ik heb weinig sql/php ervaring, en heb gelezen dat sommige gasten dit doen mbv een admin systeem(die bij het guestbook zit).En dees heb ik dus niet.
Hoe kan ik dit het beste oplossen?
Alvast bedankt!

phpMyAdmin ervoor gebruiken
Is handig voor alles wat je met je DB wilt doen

[TAFKAB]

McLaren schreef:
phpMyAdmin ervoor gebruiken
Is handig voor alles wat je met je DB wilt doen

hmmm
Heb geen phpadmin, alleen een mysqladmin :/
Misschien even mijn provider e-mailen?

[Tom]

Beste oplossing is gewoon een kolom toevoegen aan je database met autonummering, zodat elk record automatisch een eigen (uniek) nummer krijgt. Aan de hand van dat nummer kun je een DELETE * FROM tabel WHERE id=$id; doen. Ik zorg in elke tabel (behalve soms bij koppeltabellen) dat er een ID-kolom is welke elk record een uniek ID meegeeft.

[TAFKAB]

Tom schreef:
Beste oplossing is gewoon een kolom toevoegen aan je database met autonummering, zodat elk record automatisch een eigen (uniek) nummer krijgt. Aan de hand van dat nummer kun je een DELETE * FROM tabel WHERE id=$id; doen. Ik zorg in elke tabel (behalve soms bij koppeltabellen) dat er een ID-kolom is welke elk record een uniek ID meegeeft.

Ditis de hele query? ;
DELETE *
from tabel
where id=$id
?

[Martin]

TAFKAB schreef:
Ditis de hele query? ;
DELETE *
from tabel
where id=$id
?

als je de boel netjes achter elkaar zet zal het beter werken

$query= DELETE * FROM (tabelnaam) WHERE ID=$ID

TAFKAB schreef:
hmmm
Heb geen phpadmin, alleen een mysqladmin :/
Misschien even mijn provider e-mailen?

phpMyAdmin kun je zelf downloaden is gewoon een phpscript

[TouchOfDarkness]

DELETE * FROM is geen juiste syntax

DELETE FROM `tabelnaam` WHERE field = '$identifier' lijkt me beter

[TAFKAB]

McLaren schreef:
phpMyAdmin kun je zelf downloaden is gewoon een phpscript

Uh ja? Waar? En dan?
Ik heb een Id kollom, nu wil ik bv post 7 (id=7) verwijderen...
Query==?

TAFKAB schreef:
Uh ja? Waar? En dan?
Ik heb een Id kollom, nu wil ik bv post 7 (id=7) verwijderen...
Query==?

http://www.phpmyadmin.org

kun je gewoon heel je mysql db mee beheren

[Chimera]

TAFKAB schreef:
Uh ja? Waar? En dan?
Ik heb een Id kollom, nu wil ik bv post 7 (id=7) verwijderen...
Query==?

DELETE FROM postTabel WHERE Id = 7

In het vervolg: RTFM.

[TAFKAB]

McLaren schreef:
http://www.phpmyadmin.org

kun je gewoon heel je mysql db mee beheren

Ja..dit alles gaat boven mn petje.
Veels te ingewikkeld.
Wil gewoon simpel 1 entry deleten, met een query (lijkt me nu t beste).
Dan zoek ik het verder wel uit met die admin..
Toch bedankt.

[TAFKAB]

Chimera schreef:
DELETE FROM postTabel WHERE Id = 7

In het vervolg: RTFM.

hmm vaag, hij werkte eerst wel.
Toen deed ik id=1, alleen nu nam ik bv 5, toen niet meer.. ?

[Chimera]

Nog een tip trouwens: zet bij een DELETE query altijd "LIMIT 1" erachter als je aan het testen bent. DELETE FROM tabelnaam zonder een WHERE stuk gooit nl. heel de tabel leeg. Dus dat wordt:

DELETE FROM tabelNaam WHERE Id = 7 LIMIT 1

[TAFKAB]

Verwijder rijen: 0

SQL-query :
DELETE FROM guests WHERE id = 5 LIMIT 1

:/

[TAFKAB]

Hoe loopt dat op eigenlijk? die ID's?
Had op t begin dus 1 tm 5 bv, nu del ik #1. Ging goed.
word 2 dan 1? of blijft 2-2?
Ik zie dat als ik het DB leeg haal, vervolgends weer post dat ie verder gaat (dus niet opnieuw bij 1 begint).
Erg verwarrend..

[TouchOfDarkness]

uhm dat primary key field van de DB is een unieke identificatie voor elke tupel in je tabel. Dat hoeft niet per se een ID veld te zijn, je kan ook wel een combinatie van kolommen een primary key laten zijn, maar omdat een integer auto increment kan hebben en omdat het imho minder opslagruimte vereist, gebruik ik die altijd (is ook wel algemeen geaccepteerd dacht ik).

De waarden die je daar invult blijven altijd opeenlopend (mits auto incremented), dus die veranderen niet, ook al verwijder je wat, dus wat je zegt, 2 blijft 2 nadat je 1 verwijdert. Misschien dat sommige DBMS'en wel interne optimalisatie codes hebben die gaten in die lijst opnieuw opvullen/rangschikken, maar dat lijkt me niet omdat dan alle relaties ook gewijzigd moeten worden ivm foreign keys e.d. (of omdat sommige programmeurs hard coded primary keys ergens in de code verwerken, waaronder ik zelf )

Lees de handleiding op www.mysql.com maar eens door, misschien dat daar wat meer informatie staat.

[Chimera]

TouchOfDarkness schreef:

De waarden die je daar invult blijven altijd opeenlopend (mits auto incremented), dus die veranderen niet, ook al verwijder je wat, dus wat je zegt, 2 blijft 2 nadat je 1 verwijdert. Misschien dat sommige DBMS'en wel interne optimalisatie codes hebben die gaten in die lijst opnieuw opvullen/rangschikken, maar dat lijkt me niet omdat dan alle relaties ook gewijzigd moeten worden ivm foreign keys e.d. (of omdat sommige programmeurs hard coded primary keys ergens in de code verwerken, waaronder ik zelf )

Dat is dan ook bijzonder slecht. Een DB mag volgens de ANSI SQL specs auto-increment IDs recyclen. Sommige DBMS geven als nieuwe autoincrement ID gewoon hoogste id + 1.

Quote uit de MySQL manual:

For InnoDB ROW_FORMAT=COMPRESSED and BDB tables you can specify AUTO_INCREMENT on secondary column in a multi-column key. In this case the generated value for the autoincrement column is calculated as MAX(auto_increment_column)+1) WHERE prefix=given-prefix. This is useful when you want to put data into ordered groups.

Orderen op auto-increment columns is bad, doe dit liever op een timestamp column. Hard-coded IDs in je code worden 'magic numbers' genoemd, en zijn per definitie evil.

[Chimera]

TAFKAB schreef:
hmm vaag, hij werkte eerst wel.
Toen deed ik id=1, alleen nu nam ik bv 5, toen niet meer.. ?

Als die id niet bestaat, zul je inderdaad niets verwijderen.

[TouchOfDarkness]

Chimera schreef:
Dat is dan ook bijzonder slecht. Een DB mag volgens de ANSI SQL specs auto-increment IDs recyclen. Sommige DBMS geven als nieuwe autoincrement ID gewoon hoogste id + 1.

Ik heb dat af en toe wel eens nodig gehad, hardcoded een ID ergens opnemen. Doe het ook liever niet, maar ja als ik op die manier een oplossing voor een wijziging snel kan inbouwen, dan moet het maar. Tijdsdruk you know? Systemen bij ons worden ontwikkeld in PHP/MySQL en voor zover ik weet wordt in MySQL de laatste auto_increment key van een tabel opgeslagen, dus dat gaat gewoon goed.

Moet zeggen dat mijn eerdere stukje ook niet helemaal juist geformuleerd is....

Orderen op auto-increment columns is bad, doe dit liever op een timestamp column. Hard-coded IDs in je code worden 'magic numbers' genoemd, en zijn per definitie evil.

Orderen op die dingen doe ik zowieso al nooit.

[Chimera]

TouchOfDarkness schreef:
Ik heb dat af en toe wel eens nodig gehad, hardcoded een ID ergens opnemen. Doe het ook liever niet, maar ja als ik op die manier een oplossing voor een wijziging snel kan inbouwen, dan moet het maar. Tijdsdruk you know? Systemen bij ons worden ontwikkeld in PHP/MySQL en voor zover ik weet wordt in MySQL de laatste auto_increment key van een tabel opgeslagen, dus dat gaat gewoon goed.

Tja. Persoonlijk zou ik niet door een deadline gedwongen willen worden bagger af te leveren, maar ik weet wat je bedoelt

Wat betreft die auto_increment, dat werkt dus niet als je een auto_increment als 2e column in een primary_key hebt zitten.

[TouchOfDarkness]

Chimera schreef:
Tja. Persoonlijk zou ik niet door een deadline gedwongen willen worden bagger af te leveren, maar ik weet wat je bedoelt

Wat betreft die auto_increment, dat werkt dus niet als je een auto_increment als 2e column in een primary_key hebt zitten.

Nee ik weet het, ik heb er zelf ook een hekel aan om brakke systemen af te leveren, maar ja soms moet het maar. De tijd is er gewoon niet (die krijg ik ook nie )

Oh je bedoelt met primary keys die over meerdere columns gaan? Die gebruik ik toch al niet, met een ID column alleen red ik me prima