[Mysql] id of display id

[ZeroXT]

Hoi Tweakers,

In een applicatie moet ik een keus maken tussen het weergeven van id's aan klanten. De applicatie heeft ondersteuning voor meerdere klanten. Elke klant kan meerdere producten toevoegen.

Keuze 1:
Mysql database met daarin een "customer" table welke een "id" column heeft van het type "int" en auto-increment.

Klant ziet dat wanneer hij/zij een product aanmaakt, het product id wordt verhoogd. Dit hoeft niet perse met één verhoogd te worden omdat andere klanten ook hun eigen producten kunnen toevoegen waarbij het tellertje ook wordt verhoogd.

De klant kan dus "gaten" in de product id's en de applicatie zou een "404 niet gevonden pagina" moeten tonen op moment dat de klant een product id wil bereiken (bijvoorbeeld in de URL (product/edit/{product_id})) welke niet van hem/haar is.

Keuze 2:
Mysql database met daarin een "customer" table welke een "id" column heeft van het type "int" en auto-increment. Daarnaast een column "display_id" welke automatisch wordt verhoogd aan de hand van de laatst toegevoegde "display_id". Hierdoor zal de klant geen "gaten" in zijn/haar product id's zien en hoeft de applicatie niet af te vangen of een product wel of niet van de klant is tijdens het benaderen van het product in bijvoorbeeld de URL (product/edit/{product_id}). Nadeel hiervan is dat grote bulk import lastiger wordt. Bij elke product insert zou namelijk een trigger geschreven moeten worden die de laatste id ophaalt en verhoogd o.i.d

Keuze 3:
Een unieke waarde als display_id gebruiken waardoor het voor de klant niet meer uitmaakt hoe de "id" eruit ziet. Ook hier is het nadeel dat grote bulk import lastiger is omdat (zover ik weet) die unieke waarde in de applicatie gegenereerd moet worden.

De vraag aan jullie is wat de beste keus zou zijn en/of er nog andere keuzes zijn .

[Matis]

Data "verzinnen" vind ik altijd gevaarlijk. Is het misschien een idee het customer ID als prefix te gebruiken bij het product ID? Dit natuurlijk alleen in de presentatie laag.

Ik weet niet of het je klanten interesseert of er gaten in hun IDs zitten.

[ Voor 32% gewijzigd door Matis op 01-11-2017 08:33 ]

[xleeuwx]

ZeroXT schreef op woensdag 1 november 2017 @ 08:25:
Hoi Tweakers,

In een applicatie moet ik een keus maken tussen het weergeven van id's aan klanten. De applicatie heeft ondersteuning voor meerdere klanten. Elke klant kan meerdere producten toevoegen.

Keuze 1:
Mysql database met daarin een "customer" table welke een "id" column heeft van het type "int" en auto-increment.

Klant ziet dat wanneer hij/zij een product aanmaakt, het product id wordt verhoogd. Dit hoeft niet perse met één verhoogd te worden omdat andere klanten ook hun eigen producten kunnen toevoegen waarbij het tellertje ook wordt verhoogd.

De klant kan dus "gaten" in de product id's en de applicatie zou een "404 niet gevonden pagina" moeten tonen op moment dat de klant een product id wil bereiken (bijvoorbeeld in de URL (product/edit/{product_id})) welke niet van hem/haar is.

Keuze 2:
Mysql database met daarin een "customer" table welke een "id" column heeft van het type "int" en auto-increment. Daarnaast een column "display_id" welke automatisch wordt verhoogd aan de hand van de laatst toegevoegde "display_id". Hierdoor zal de klant geen "gaten" in zijn/haar product id's zien en hoeft de applicatie niet af te vangen of een product wel of niet van de klant is tijdens het benaderen van het product in bijvoorbeeld de URL (product/edit/{product_id}). Nadeel hiervan is dat grote bulk import lastiger wordt. Bij elke product insert zou namelijk een trigger geschreven moeten worden die de laatste id ophaalt en verhoogd o.i.d

Keuze 3:
Een unieke waarde als display_id gebruiken waardoor het voor de klant niet meer uitmaakt hoe de "id" eruit ziet. Ook hier is het nadeel dat grote bulk import lastiger is omdat (zover ik weet) die unieke waarde in de applicatie gegenereerd moet worden.

De vraag aan jullie is wat de beste keus zou zijn en/of er nog andere keuzes zijn .

Ik zou het met een guid oplossen, deze is gewoon uniek voor elke id of met een extra tabel.

Optie 1:
Je zou een koppel tabl kunnen maken waarin staat id | customerID | productID. zodoende heb je gelijk je access control om te kijken of de klant wel bij het product hoort. Persoonlijk vind ik het wel te veel overhead voor zoiets simpels.

Optie 2:
De guid of uuid is een extra veld in je tabel waar je een uniek gegenereerde string in opslaat, deze kan je automatische laten aanmaken door MySQL of met PHP genereren.


guid
https://dev.mysql.com/doc...ctions.html#function_uuid

guid_short
https://dev.mysql.com/doc....html#function_uuid-short

[ Voor 6% gewijzigd door xleeuwx op 01-11-2017 08:38 ]

[emnich]

Vooropgesteld dat je je m.i. helemaal niet druk moet maken over een id in de url (tenzij het om beveiliging gaat) kan je optie 2 automatisch laten doen zodat het geen probleem is met bulk imports.

Maak een primary key aan op customer_id en product_id waarbij product_id auto_increment is.

MySql zal dan per customer_id een eigen increment doen voor product_id.

Dat gezegd hebbende, gaten krijg je altijd in je tabel en je zal altijd moeten controleren of een product wel van een klant is.

[Harrie_]

Ik sluit me aan bij bovenstaande reacties. Je kunt het inderdaad oplossen met een guid/uuid maar ik begrijp uit je verhaal dat de klant is ingelogd. Het is dus niet zo dat elke willekeurige gebruiker naar de site kan surfen en kan lopen enumeraten. In dat geval lijkt me meer dan afdoende om bij het ophalen van je ID te checken of de bijbehorende klant dezelfde is als de ingelogde gebruiker.

That said... als je bij het inloggen een $_SESSION['klantid'] zet dan kun je toch in al je queries WHERE klant_id = ".$_SESSION['klantid']." kwijt? Dan heb je toch in één klap voor het hele systeem, niet alleen voor de producten, afgedekt dat een klant alleen maar bij de eigen data kan?

[ Voor 28% gewijzigd door Harrie_ op 01-11-2017 09:32 ]

[Hydra]

Waarom is het uberhaupt relevant wat de gebruiker ziet kwa ID?

Tegenwoordig m.i. gewoon een UUID gebruiken. Is ook makkelijker te schalen als je later naar een niet-relationele back-end over gaat stappen voor bepaalde delen bijvoorbeeld. Enumereren is hoe dan ook niet mogelijk. Niet dat je het niet moet beveiligen natuurlijk, maar 'defence in depth' is m.i. altijd een goed idee.

[DJMaze]

ZeroXT schreef op woensdag 1 november 2017 @ 08:25:
De klant kan dus "gaten" in de product id's en de applicatie zou een "404 niet gevonden pagina" moeten tonen op moment dat de klant een product id wil bereiken (bijvoorbeeld in de URL (product/edit/{product_id})) welke niet van hem/haar is.

Dat gebeurt toch ook als de klant een product "verwijdert"?

[winkbrace]

Gaten in de id range zijn geen probleem, maar ik zou in dit geval ook een GUID of UUID gebruiken als id voor je applicatie.

En een gewone auto-increment INT als id voor de foreign key koppelingen tussen tabellen in mysql.