Primary key
Wanneer jij wel een waarde hecht aan de waarde van het id, ga je dan eens verdiepen in databases. Dan heb je namelijk nog even een onderdeeltje gemist.
Kortom, je hebt helemaal geen probleem. ;)
Het doel van dit is dat als je meerdere tabellen hebt, je dus ervoor zorgt dat gegevens gekoppeld blijven, en ook aan de juiste gegevens.
Bijvoorbeeld:
Tabel: gebruikers
veld 1 : naam
veld 2 : (integer) primiary key, auto increment.
Tabel: wachtwoorden:
Veld 1 : wachtwoord
Veld 2 : Integer, refererend naar tabel gebruikers.veld2
Ga ik de primaiary key van Tabel gebruikers, opschonen en alles weer aansluitend, oplopend nummeren dan zou de wachtwoorden tabel en de referentie naar Tabel gebruikers niet meer kloppen.
Je zou het wel kunnen doen, maar dat wil je alleen als je bijvoorbeeld zelfs verwacht dat een BIGINT als primiary, autoincrement niet afdoende zou zijn.
De kans daarop is nihil dat jij zover zal komen.
Eigenlijk is de *gouden* regel, nooit aan je primiary key willen te sleutelen.
Edit:
Wat ik eigenlijk wilde zeggen, een auto increment primiary key gebruik je juist om een uniek referentie punt te hebben als je gegevens, gekoppeld aan de gebruiker in andere tabellen op slaat.
Wat ik eigenlijk wilde zeggen, een auto increment primiary key gebruik je juist om een uniek referentie punt te hebben als je gegevens, gekoppeld aan de gebruiker in andere tabellen op slaat.
Gewijzigd op 01/01/1970 01:00:00 door Danny Roelofs
Wanneer je met id's gaat lopen rommelen, kom je vrijwel altijd in de problemen wanneer je backups terug moet zetten. En dat is nu nét een moment dat je geen problemen wilt hebben, die heb je namelijk al genoeg! Je moet niet voor niks een backup terugzetten...
Ga dus nooit met id's rommelen, dat is vragen om grote problemen. Daarnaast voegt het niks toe, je neemt dus altijd onnodige risico's.
Ps. 'terugzetten' van een backup betekent vaak het intergreren van de huidige situatie met een oude situatie. Alleen een backup terugzetten is meestal niet zo'n probleem, de problemen zitten hem in de nieuwe data. Spreek uit ruime ervaring...
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Toevoeging:
Maar ik zal ook eerlijk toegeven, dat ik ook niet alles weet, heb me nog niet verdiept in iedergeval in relationele database, in de zin van.. dat ik wel weet wat het inhoud, maar er nog geen gebruik van heb hoeven te maken.
Gewijzigd op 01/01/1970 01:00:00 door Danny Roelofs
Ken gewoon geen enkele betekenis toe aan een id en klaar ben je.
Maar ik ga me in ieder geval maar eens oriënteren op een relationele database, was dit al van plan maar je gaf me even een herinnering aan een project waar ik mee bezig moet, en dat gaat het concept van joomla al zo wie zo overtreffen.
Dat gaat me de aankomende jaren bezig houden, in mijn eentje.. moet heel kort door de bocht een Multi CMS worden met nog eens de flexibiliteit dat er van alles mee gedaan kan worden, tot het creëren van een youtube, een hyves, een startpagina, een phphulp.. enzovoorts..
Ben benieuwd hoeveel toetsenborden ik zal verslijten ;-)
pgFrank schreef op 30.01.2008 21:41:
@pgFrank, Heb jij toevallig belangen daarin?? ;)
Maar wees niet ongerust, ook al gaat het project als uitgangspunt mysql gebruiken, ik zal ook trachten om deze middels een class universeel te maken
om ook postgresql te gaan gebruiken (te verkiezen als voorkeur in de configuratie installatie).
Maar denk eraan, ik moet het in mijn eentje doen ;-)...
Het leren van SQL en leren omgaan met relationele databases, dat kun je prima met pgSQL doen. Dan kun je later vrij eenvoudig overstappen op bv. MySQL, 80% van het verhaal ken je dan. Ga je eerst met MySQL aan de slag, dan breekt de pleuris uit, blijkt ineens dat de helft van je queries gewoon fout is en dat je nog helemaal geen SQL kent...
Leer het met pgSQL (op je eigen pc, eigen baas in eigen huis) en ga daarna aan de slag met de database van jouw keuze. Werkt uitstekend!
Dat pgSQL niet veel wordt aangeboden, is geen probleem, als jóuw provider het maar aanbiedt... ;)
Daarom is het ook wel de intentie om zowel Mysql als pgSQL enig zins ter gelijk aan te pakken, alleen ik kijk dan wat met Mysql mogelijk is, en hoe ik het dan mogelijk beter kan doen met pgSQL.
En ja, een DBMS was ook mijn gedachte gang, ik wil eigenlijk, als ik dat daar onder mag verstaan.. een class aanmaken die dus automatisch een juiste methode aanspreekt.
Ofwel, zou ik via mijn class een query doen richting Mysql, maar ik stuur een pgSQL opdracht, dan moet de class deze handelingen nabootsen. Dus als pgSQL het in éen query doet, dan zal de class deze trachten te simuleren.
Maar ik heb nog geen enkele ervaring met pgSQL, dus ik weet nog niet wat nodig is.. ofwel te verwachten is..
Maar het komt wel goed, ik ben toch iemand die altijd maar wil doorleren, zo ben ik naast php ook steeds bezig met javascript (ajax), en verdiep ik me ook in Flash en action scripting en wil ik ook nog mezelf bezig houden met perl (cgi)
Scheelt wel dat ik in het verre verleden in assembler z80 en m6800 heb geprogrammeert, me zelfs bezig heb gehouden met Basic talen als MSX, Amiga basic, Amox, Arexx, AmigaE Sas/C, ook nog eens op de PC met DevC++ heb gewerkt, enigzins met VisualBasic.
Maar het gaat wel goed komen met me en pgSQL
Danny Roelofs schreef op 31.01.2008 17:52:
Als je praat over een DBMS heb je het over een Database Management System en praat je dus over de database zelf. Daar komt geen regel php aan te pas ;-)En ja, een DBMS was ook mijn gedachte gang, ik wil eigenlijk, als ik dat daar onder mag verstaan.. een class aanmaken die dus automatisch een juiste methode aanspreekt.
Ofwel, zou ik via mijn class een query doen richting Mysql, maar ik stuur een pgSQL opdracht, dan moet de class deze handelingen nabootsen. Dus als pgSQL het in éen query doet, dan zal de class deze trachten te simuleren.
Ofwel, zou ik via mijn class een query doen richting Mysql, maar ik stuur een pgSQL opdracht, dan moet de class deze handelingen nabootsen. Dus als pgSQL het in éen query doet, dan zal de class deze trachten te simuleren.
Verder denk ik niet dat je het om de manier moet willen aanpakken die je hierboven omschrijft. Een van de grote krachten van een goede RDBMS zoals pgSQL is het gebruik van stored procedurs om bewerkingen op de database uit te voeren. Vanuit PHP roep je met een SQL query enkel nog zo'n SP aan met de benodigde parameters en de database doet de rest van het werk.
Het uitvoeren van INSERT, UPDATE en DELETE queries zul je dus ook nooit meer direct vanuit PHP doen. Sterker nog, PHP en daarmee de gebruiker, komt op geen enkele manier meer in direct contact met de gegevens die in de database opgeslagen zijn. Dit loopt allemaal via een API in de database die de gebruiker een arsenaal functies biedt om bewerkingen op de data uit te voeren.
Als je tenslotte toch een klasse wilt schrijven die de communicatie met de database afhandelt, zou ik ervoor kiezen om een uitbreiding op de bestaande PDO klasse te schrijven. Maar of je dit echt nodig hebt kun je je nog afvragen, het meeste werk zal immers door de database gedaan worden.
Enige nadeel van deze aanpak is dat MySQL hier natuurlijk helemaal buiten valt. Nou ja nadaal, je zou het ook een groot voordeel kunnen noemen. Maar goed, zoals Frank ook al zei, zou je beter geen systeem moeten willen schrijven dat met beide databases zal werken. Op die manier gooi je alle voordelen die een goede database voor je kan hebben, overboord.
ps. @Chris: bookmark dit topicmaar. Dan kun je er later nog eens naar kijken :-P
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
De kerntaak van een DBMS is het veilig opslaan en toegankelijk maken van data. Wanneer je ook nog de R van RDBMS meepakt, krijg je een relationele database, alle data sla je dus maar 1x op en krijgt relaties met andere data.
En hier hebben we al een paar essentieele problemen van MySQL te pakken:
- alleen in de innoDB-engine (die niet van MySQL is, maar van Oracle) kun je relaties leggen en onderhouden
- standaard doet MySQL nauwelijks enige poging om jouw data veilig op te slaan of te beheren.
Alleen wanneer iemand met kennis de boel heeft ingericht (vergeet je shared hosting provider dus maar...) is MySQL een bruikbare database. In alle andere gevallen zul jij met jouw PHP-script de ontbrekende delen van het DBMS moeten bouwen! Standaard zal MySQL een string van 31 karakters die je in een veld van 30 karakters probeert te stoppen, keurig afkappen. Je raakt dus een deel van je data kwijt. Een DBMS hoort hier een error op te geven. Dit is slechts 1 voorbeeldje van de vele tientallen ernstige problemen met MySQL als (R-)DBMS. Een goede DBMS geeft een error op een onmogelijke situatie en keurt de query af.
Een standaard installatie van MySQL is niet bruikbaar als DBMS en allleen met innoDB kun je relaties leggen en onderhoude. De rest van MySQL is onbruikbare rommel. Tenminste, wanneer je veiligheid (lees: data-integriteit) hoog in het vaandel hebt staan.
Sinds MySQL versie 5 is het al 100x beter dan met versie 4, maar het blijft behelpen. De standaard instellingen zijn dezelfde als die van versie 4 omdat er anders in buggy software ineens allerlei bugs opduiken. Die zitten er nu ook wel in, je ziet ze alleen niet op het eerste gezicht... Je moet er maar zin in hebben!