Voor een opdracht voor school moet ik een configuratiemanagement applicatie maken, nu heb ik vrij weinig ervaring met PHP en MySQL maar ik heb ondertussen wel al een paar simpele php scripts gemaakt.
Nu heb ik het voor elkaar gekregen om een configuratie toe te voegen aan de mysql database door middel van een form, ook heb ik een pagina waarin alle configuraties worden weergegeven in een tabel.
Nu wil ik ook graag een optie/knop in die tabel waarmee ik een specifieke configuratie/record kan aanpassen en updaten, ik heb al op internet naar informatie gezocht maar ik zie door de bomen het bos niet meer.
Als het serienummer uniek is dan is het niet nodig om nog eens extra een unieke auto increment kolom als primary key te gebruiken. Men noemt dit niet voor niets surrogate keys.
Het serienummer van het apparaat zou je als een foreign key kunnen beschouwen waarmee je een apparaat uniek identificeert. Het (aparte) auto_increment id daarintegen is de kapstok waar je deze en andere informatie aan ophangt.
Je kunt niet op voorhand zeggen dat het serienummer geschikt is als PK simpelweg omdat deze alle uit unieke waarden bestaan, dit moet ook blijken uit het gebruik. Stel bijvoorbeeld dat om wat voor reden dan ook het serienummer van een apparaat kan veranderen (er worden bijvoorbeeld onderdelen vervangen of wat dan ook), met jouw oplossing zul je dan ook gerelateerde tabellen moeten gaan omnummeren of je moet in deze tabellen constraints hangen dat daarin de waarden van foreign keys kunnen veranderen ofzo maar dat lijkt mij (als dat al kan) niet bepaald intuïtief.
Waarom niet voor een oplossing kiezen waar je dit probleem helemaal niet hebt? Het is ook een makkelijke rule-of-thumb: introduceer in alle tabellen (behalve wellicht koppeltabellen tenzij daar weer meer informatie in zit behalve enkel foreign keys) gewoon een auto_increment kolom.
Daarnaast is nog het issue met de indexeerbaarheid als deze serienummers (erg) lang zijn... Afhankelijk van (de ontwikkeling van) de lengte van de serienummers zou dat een probleem kunnen zijn.
Maar waarom zou je een oplossing kiezen waarbij je wellicht rekening moet houden met dit soort zaken als er een simpel alternatief is.
Het serienummer van het apparaat zou je als een foreign key kunnen beschouwen waarmee je een apparaat uniek identificeert. Het (aparte) auto_increment id daarintegen is de kapstok waar je deze en andere informatie aan ophangt.
Nee, de primary key is de kapstok waaraan de informatie hangt, of dit nu een surrogate key of een natural key is, is in die zin niet relevant.
Thomas van den Heuvel op 10/04/2015 14:34:43
Je kunt niet op voorhand zeggen dat het serienummer geschikt is als PK simpelweg omdat deze alle uit unieke waarden bestaan, dit moet ook blijken uit het gebruik. Stel bijvoorbeeld dat om wat voor reden dan ook het serienummer van een apparaat kan veranderen (er worden bijvoorbeeld onderdelen vervangen of wat dan ook), met jouw oplossing zul je dan ook gerelateerde tabellen moeten gaan omnummeren of je moet in deze tabellen constraints hangen dat daarin de waarden van foreign keys kunnen veranderen ofzo maar dat lijkt mij (als dat al kan) niet bepaald intuïtief.
De surrogate(keys) community zal je van harte verwelkomen, dit is een argument wat vaak gebruikt wordt door de voorstanders van de auto-generated keys.
In theorie is een key die unique en NOT NULL is prima geschikt als PK, dat zijn namelijk de enige voorwaarden die gesteld worden aan een PK.
Als je in MySQL een auto increment op een kolom zet, geef je daarmee alleen een default waarde aan, zonder verdere maatregelen voorkom je niet dat die kolom achteraf nog gewijzigd kan worden.
Nee dat is niet logisch, noch is het logisch om een serienummer van een apparaat te wijzigen omdat je een onderdeel vervangt.
Thomas van den Heuvel op 10/04/2015 14:34:43
Maar waarom zou je een oplossing kiezen waarbij je wellicht rekening moet houden met dit soort zaken als er een simpel alternatief is.
Het is geen alternatief, het is een extra.
Als er een business-rule is die bepaalt dat een serienummer uniek moet zijn kan je dat niet afdwingen met alleen een AI key, dan zal er daarnaast een unique constraint moeten komen op het serienummer.
Het probleem met de lengte van de index wordt dus niet mee verholpen.
Natuurlijk speelt de lengte van een PK een rol bij het maken van de meest optimale keuze, en zijn er ook nog andere factoren die daar van inloed op (zouden moeten) zijn, maar naar mijn mening moet je de verschillende opties tegen elkaar afwegen en niet zonder meer een algemene regel hebben een AI kolom in elke tabel te zetten.
