PHP/MYSQL vraagje..
 

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 :)

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

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
?

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

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

phpMyAdmin kun je zelf downloaden is gewoon een phpscript :)

DELETE * FROM is geen juiste syntax :p

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

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

DELETE FROM postTabel WHERE Id = 7

In het vervolg: RTFM.

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.

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

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

Verwijder rijen: 0

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

:/

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..

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.

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:
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.

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

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 die dingen doe ik zowieso al nooit.

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 :p)

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 :)