MYSQL Enum alternatief

[Knaak]

Beste Tweakers,

Ik ben momenteel bezig met een database voor een project van mijzelf. Echter loop ik nu tegen een klein probleem aan.

Ik heb een database met de tabel "products", echter wil ik deze producten 3 soorten statussen meegeven, waarvan er maar 1 per product actief kan zijn. Nu leek mij het beste om hier een ENUM veld voor te nemen en dit veld de 3 statussen te geven (active, non-active, trashed). Deze statussen veranderen in de toekomst waarschijnlijk niet, waardoor ENUM me voldoende leek.

Nu is mijn vraag dus, wat voor soort datatype zouden jullie in een soortgelijk geval gebruiken? Een eventuele look-up tabel waarin deze 3 statussen staan? Ik zoek namelijk een alternatief voor ENUM. maar ik kan geen goed alternatief vinden.

[Face_-_LeSS]

Gewoon een status tabel aanmaken en een relatie leggen tussen product en status...

(toelichting)

[ Voor 48% gewijzigd door Face_-_LeSS op 15-02-2009 19:02 ]

[Voutloos]

Kan ook, alhoewel ik voor dit geval nog niet een argument tegen ENUM gehoord heb.

[Macros]

Meestal gebruik ik Hibernate in de code laag. Dan is het makkelijk om gewoon strings/varchars te gebruiken omdat Hibernate die heel makkelijk kan mappen. Int/numbers kan ook, maar dan vind ik het minder makkelijk om te zien welke waardes in de tabel staan zonder het telkens op te zoeken welke int welke enum is.
Om te zorgen dat iemand anders dan de applicatie niet per ongeluk foute data in de tabel zet, leg ik een constraint op de kolom zodat alleen die namen van de enums gebruikt mogen worden.

[Fugitive1977]

Wat is er mis met Enum, ik gebruik dit ook voor dergelijk gevallen

[Kalentum]

Met ENUM is niets mis.

Ik zou alleen een aparte tabel gebruiken als je meer informatie aan een status wilt hangen. BV wie, wanneer waarom de status is gewijzigd.

[NMe]

rutgerw schreef op maandag 16 februari 2009 @ 13:46:
Met ENUM is niets mis.

Ik zou alleen een aparte tabel gebruiken als je meer informatie aan een status wilt hangen. BV wie, wanneer waarom de status is gewijzigd.

Ja gaat de redenen voor statuswijzigingen toch niet opslaan in een statustabel?

Ik zou overigens gewoon voor een enum gaan hier, net zo praktisch. En als het toch onwaarschijnlijk is dat het zaakje ooit verandert, wat zou je dan moeilijk doen?

[Knaak]

Danku allemaal. Het gaat mij er voornamelijk om om te zien hoe anderen hierover denken. Het is waarschijnlijk niet aan de orde dat het ENUM veld ooit veranderd zal worden. En mocht dit wel gebeuren, dan kan ik dit nog met een ALTER doen. De database zelf word niet enorm waardoor ik dit lokaal kan doen en later op de server.

Het gaat mij er gewoon om dat ik doormiddel van statussen producten "uit" kan zetten ipv ze meteen te deleten.

@rutgerw, het is dus niet mijn bedoeling om dat soort info op te slaan, daarvoor heb ik een userActions tabel.

[ripexx]

Overigens zou ik de status active/not active en trashed/deleted splitsen. Aangezien je hiermee totaal iets anders bedoeld. maar dat is ook een kwestie van smaak. In veel database ontwerpen zie je een soort softdelete systeem op bijna alle tabellen.

Wat betreft wel of geen enum, als je de gebruikers controle wil geven is het vaak/meestal handiger om een tabel te gebruiken, gaat het om een harde waarde dan kan je kiezen voor een ENUM. Vaak zie je dat een standaard database user geen rechten heeft op acties als ALTER, CREATE, DROP etc. Alleen op SELECT, INSERT en UPDATE. In sommige gevallen is zelfs een DELETE statement niet met de standaard users toegestaan, in verband met compliancy.

[BCC]

Ik zou een int opnemen en het zaak je in de businesslaag afhandelen. Maar opzich hoeft er niets mis te zijn met een ENUM. Maar wat is de reden dat je uberhaupt twijffelt over je keuze?

[curry684]

De enige goed onderbouwde reden om geen enum te gebruiken is dat niet alle DBMS'en enums ondersteunen (SQL Server notably). Zuiver normaliserend is een aparte tabel het beste, performancewise cross-compatible is een int het beste, binnen een dedicated MySQL omgeving zonder enige short-term neiging tot DB-independence is een enum fine.

[Alain]

curry684 schreef op maandag 16 februari 2009 @ 23:01:
De enige goed onderbouwde reden om geen enum te gebruiken is dat niet alle DBMS'en enums ondersteunen (SQL Server notably).

Ik denk dat het goed is om in het achterhoofd te houden dat iets wat nu een integer (of enum) kan zijn, later waarschijnlijk beter een tabel had kunnen zijn omdat de behoefte nooit minder wordt.

In dit geval gaat het misschien niet (direct) op. Maar in veel gevallen wel.

[Gomez12]

AlainS schreef op maandag 16 februari 2009 @ 23:42:
[...]


Ik denk dat het goed is om in het achterhoofd te houden dat iets wat nu een integer (of enum) kan zijn, later waarschijnlijk beter een tabel had kunnen zijn omdat de behoefte nooit minder wordt.

In dit geval gaat het misschien niet (direct) op. Maar in veel gevallen wel.

Tja, een goed uitgedachte integer is later altijd nog te gebruiken als key in een andere tabel

[NMe]

AlainS schreef op maandag 16 februari 2009 @ 23:42:
[...]


Ik denk dat het goed is om in het achterhoofd te houden dat iets wat nu een integer (of enum) kan zijn, later waarschijnlijk beter een tabel had kunnen zijn omdat de behoefte nooit minder wordt.

In dit geval gaat het misschien niet (direct) op. Maar in veel gevallen wel.

Toevallig vandaag nog een gesprek gehad met de poster boven je over prematuur optimaliseren. Als je voor 99% zeker weet dat een enumeration voldoet en in de toekomst zal blijven voldoen, dan is het niet echt handig om "omdat het netter is" overdreven te gaan lopen normaliseren. In dit geval zou je bijvoorbeeld een aparte statustabel kunnen hebben waarnaar elke andere tabel refereert om zo softdeletes makkelijker te maken, maar waarom zou je als een enum ook werkt en bovendien je queries overzichtelijker maakt?

MySQL biedt dit non-standard datatype en waar toepasbaar maak ik daar graag gebruik van.