Virusscanner tips?
Problemen met auto_increment mysql
Ik heb een tabel genaamd garage, daar worden alle auto's ingezet die de gebruiker koopt/steelt. Nu komt het voor dat wanneer hij alles verkoopt, dat er helemaal niks meer in de tabel staat, na verloop van tijd krijg je dan opnieuw id 1, terwijl ik gewoon verder wil met het id waar de tabel gebleven is. Weet iemand daar een oplossing voor?
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
$sql =
"DELETE
FROM garage
WHERE auto_id=
".$row['auto_id']."
";
$query = mysql_query($sql);
?>
$sql =
"DELETE
FROM garage
WHERE auto_id=
".$row['auto_id']."
";
$query = mysql_query($sql);
?>
Dit lijkt me goed te gaan. Het is ook alleen als ik een halve dag geen gebruik maak van mijn database terwijl die leeg is...
Update: Ik weet inmiddels hoe het komt. Auto_increment stopt met doortellen wanneer de server herstart. Aangezien ik dit lokaal doe, gebeurd dit elke keer als ik wamp afsluit en weer opstart. Hoe kan ik dit omzeilen?
Gewijzigd op 08/12/2012 21:09:38 door Richard Hansma
1. Je gebruikt ze als foreign key als het record al verwijderd is
2. Je gebrukt ze als externe referentie, dwz je geeft de gebruiker of een extern systeem er toegang toe.
Bij oorzaak 1 had je ofwel de foreign keys moeten verwijderen, ofwel het auto record niet mogen verwijderen. 'Niet verwijderen' kun je bijvoorbeeld doen door een startdatum en een einddatum op te nemen. Je maakt er dan 'historische data' van zodat je later nog wel kunt nagaan welke auto er wanneer in de garage heeft gestaan.
Een andere benadering zou kunnen zijn om ook een garage record te maken, met garage_id als primary key. Voor auto's die in de garage staan maak je dan een relatietabel met twee foreign keys: auto_id en garage_id. Zo kun je zowel de auto als de garage gewoon in je database houden en weet je toch welke auto's er in welke garage staan. En inderdaad, als je een tweede garage erbij neemt hoef je je programma niet aan te passen :-)
Bij oorzaak 2 had je zowiezo beter een afzonderlijk veld kunnen maken voor een externe referenties. Dit voorkomt dat de externe systemen eisen kunnen gaan stellen aan jouw keys en foreign keys. Een voorbeeld: In de eerste serieurze applicatie die ik ontwikkelde had ik productcodes als key (en foireign key) gebruikt. Deze waren voor de gebruiker betekenisvol en hij zocht er ook producten mee op. Na een tijdje klaagde hij dat er geen functie was om de productcode mee te wijzigen. Nogal wiedes vanuit het oogpunt van database ontwerp, maar daar heeft een gebruiker natuurlijk geen boodschap aan. Maar de key en alle foreign keys wijzigen is niet ideaal, want een bugje (of onafgeronde transactie zonder rollaback) en je zit met de gebakken peren. Sindsdien geef ik alle tabellen een numeriek id veld mee dat ik gebruik als key/foreign key, en houd ik die buiten het zicht van de gebruikers. Kleine moeite en voorkomt later een hoop ellende.
In jouw geval had je voor extern gebruik bijvoorbeeld een in de werkelijke wereld betekenisvolle eigenschap kunnen gebruiken: het kenteken of een chassisnummer of zo. Dan weet je later tenminste nog iets over de eigenlijke auto die in de garage stond. Voor intern gebruik houd je gewoon de auto_id er in en dat blijft de primary key. Dat die dan soms weer vanaf 1 gaat tellen zou niet uit mogen maken, want er zullen (door cascaded delete) in dat geval toch geen records met foreign keys meer zijn.