Bug-Tracking database design

[CodeCaster]

Modbreak:

Dit topic is afgesplitst van De Devschuur Coffee Corner

Er mailt een vriend van me, die nu ook stage loopt, of ik zijn databaseontwerp even na wil kijken. Het betreft een soort bugtrackingsysteem. Ja, er zijn er al zo veel, maar je moet je stagiairs toch op de één of andere manier aan het werk houden

Willen jullie eens op mijn ontwerp schieten, of mag dat niet in de koffiehoek? Mijn motivatie bij het ontwerp: een user voert work uit aan een feature die voor een version van een project wordt gerealiseerd.


Klopt wel, toch?

[ Voor 7% gewijzigd door Woy op 16-12-2009 10:24 ]

[Woy]

Voor een Bug Tracking systeem mis ik eigenlijk een tabel Bug/Issue

Maar verder is het eigenlijk niet de bedoeling om dit soort dingen hier in de coffee corner te gaan behandelen. Als je een iets uitgebreidere post typt, kun je natuurlijk perfect in SEA een topic openen.

[D-Raven]

In dit model MOET een Feature een Version referentie hebben wil het onder een project ingedeeld kunnen worden. Wat je vaak ziet bij het creeeren van nieuwe features in zo'n systeem als deze is dat het wellicht nog niet helemaal duidelijk is voor welke versie deze uitgeleverd gaat worden enzo. Tenminste, dat is mijn ervaring.

[CodeCaster]

@Woy: een feature is natuurlijk ook een bug Vandaar ook het (boolean) veld bug bij de features. Maar laat maar zitten dan, het is mijn project niet en ik geloof het verder wel. Het was zelfs een opdracht voor twee MBO'ers die hij onder zich heeft, en dat ontwerp ziet er toch uit ...

[ Voor 54% gewijzigd door CodeCaster op 16-12-2009 10:41 ]

[whoami]

CodeCaster schreef op woensdag 16 december 2009 @ 10:11:
@Woy: een feature is natuurlijk ook een bug Vandaar ook het (boolean) veld bug bij de features. Maar laat maar zitten dan, het is mijn project niet en ik geloof het verder wel. Het was zelfs een opdracht voor twee MBO'ers die hij onder zich heeft, en dat ontwerp ziet er toch uit ...

Ik zou een tabel issue maken met een column die het type van de issue aangeeft (geen boolean, maar een enum waarmee je kan zeggen of het een bug, feature-request, etc... is).

[Woy]

Ik zie bij je user tabel ook een field "deleted". Waarom heb je die alleen in je User tabel? Kunnen andere dingen niet verwijderd worden?

[CodeCaster]

D-Raven schreef op woensdag 16 december 2009 @ 10:10:
In dit model MOET een Feature een Version referentie hebben wil het onder een project ingedeeld kunnen worden. Wat je vaak ziet bij het creeeren van nieuwe features in zo'n systeem als deze is dat het wellicht nog niet helemaal duidelijk is voor welke versie deze uitgeleverd gaat worden enzo. Tenminste, dat is mijn ervaring.

Interessant punt, bedankt Je zou natuurlijk versie 0.0.0.0 als "wishlist" aan kunnen maken per project, voor features waarvan nog niet is bepaald in welke versie ze gerealiseerd moeten worden. Is er een manier om een optionele referentiële integriteit af te dwingen? Dus óf er moet een geldig project_id óf een geldige version_id ingevuld zijn?

whoami schreef op woensdag 16 december 2009 @ 10:16:
[...]
Ik zou een tabel issue maken met een column die het type van de issue aangeeft (geen boolean, maar een enum waarmee je kan zeggen of het een bug, feature-request, etc... is).

Issue is inderdaad generieker dan feature, en een enum biedt meer mogelijkheden dan een boolean.

Woy schreef op woensdag 16 december 2009 @ 10:29:
Ik zie bij je user tabel ook een field "deleted". Waarom heb je die alleen in je User tabel? Kunnen andere dingen niet verwijderd worden?

Uiteraard. Vergeten over te nemen, ik heb me gebaseerd op het oorspronkelijke ontwerp, waar ook enkel bij de gebruikerstabel een deleted-veld was geplaatst.

[ Voor 14% gewijzigd door CodeCaster op 16-12-2009 10:41 ]

[whoami]

Woy schreef op woensdag 16 december 2009 @ 10:29:
Ik zie bij je user tabel ook een field "deleted". Waarom heb je die alleen in je User tabel? Kunnen andere dingen niet verwijderd worden?

Misschien is dat omdat je een user enkel 'logisch' kunt verwijderen, zodat het uitgevoerde werk / reports van een user niet mee verwijderd worden, en kan je de andere dingen wel 'hard' verwijderen ?

[CodeCaster]

whoami schreef op woensdag 16 december 2009 @ 12:44:
[...]

Misschien is dat omdat je een user enkel 'logisch' kunt verwijderen, zodat het uitgevoerde werk / reports van een user niet mee verwijderd worden, en kan je de andere dingen wel 'hard' verwijderen ?

Wanneer een issue onterecht blijkt, of een aantal werk-uren foutief zijn ingevoerd moeten deze toch op de één of andere manier onzichtbaar gemaakt kunnen worden. Uiteindelijk wil je deze zaken, hoewel niet meer bruikbaar, wel bewaren lijkt me?

[whoami]

CodeCaster schreef op woensdag 16 december 2009 @ 12:57:
[...]

Wanneer een issue onterecht blijkt, of een aantal werk-uren foutief zijn ingevoerd moeten deze toch op de één of andere manier onzichtbaar gemaakt kunnen worden. Uiteindelijk wil je deze zaken, hoewel niet meer bruikbaar, wel bewaren lijkt me?

Waarom ? Of je dat wilt of niet, hangt af van de requirements.

[CodeCaster]

En die heb ik niet, want het is mijn opdracht niet

Maar voor allebei de mogelijkheden (deleted-veld of hard verwijderen) is wel wat te zeggen.

[Herko_ter_Horst]

Kijk eens naar bestaande issuetrackingsystemen (Trac, Jira, Bugzilla) en welke mogelijkheden die bieden. Vaak zie je de database- c.q. opslagstructuur wel redelijke terug in de interface.

[RobIII]

Ik heb hier, toevallig hoor, nog een schema liggen van een bugtrack systeem dat we bij een oud werkgever van me gebruikten. De DB stamt echter al, letterlijk, uit de vorige eeuw en er zijn wel een aantal zaken die ik persoonlijk anders aan had gepakt (zoals een aantal tabbelletjes om RBAC te faciliteren, een change/history/log tabel, en de naamgeving van zaken) maar misschien doe je aan de hand hiervan nog wat ideeën op; ik post het dan ook zéér zeker niet om er iets van te leren (of om 't 1-op-1 over te nemen ) maar puur ter "inspiratie" (ende vermaeck )

[ Voor 7% gewijzigd door RobIII op 16-12-2009 23:32 ]

[CH4OS]

Waarom zou je bij een user tabel eigenlijk een veld deleted toe willen voegen? Gooi diegene dan gewoon uit de tabel, is die ook deleted. Of hernoem dan die deleted naar ban of zo, dat lijkt mij dan weer logischer.

EDIT: Ah, ik zie dat Whoami er eigenlijk al antwoord op geeft, laat mijn vraag dus maar zitten.

[ Voor 29% gewijzigd door CH4OS op 16-12-2009 23:39 ]

[CodeCaster]

Herko_ter_Horst schreef op woensdag 16 december 2009 @ 22:56:
Kijk eens naar bestaande issuetrackingsystemen (Trac, Jira, Bugzilla) en welke mogelijkheden die bieden. Vaak zie je de database- c.q. opslagstructuur wel redelijke terug in de interface.

Overkill voor de wensen Er hoeft geen SVN-koppeling of Wiki aan te hangen, en daarnaast is Trac danwel Bugzilla voor zover ik weet meer ingericht voor juist één project? Het principe feature-(milestone-)version-project wordt verder overal wel gehandhaafd.

@RobIII: ziet er ... uitgebreid uit.

GJtje schreef op woensdag 16 december 2009 @ 23:37:
Waarom zou je bij een user tabel eigenlijk een veld deleted toe willen voegen? Gooi diegene dan gewoon uit de tabel, is die ook deleted. Of hernoem dan die deleted naar ban of zo, dat lijkt mij dan weer logischer.

En dan alle projecten die 'ie aanmaakte, alle bugs die 'ie filede en alle uren die 'ie werkte ook weggooien?

[ Voor 41% gewijzigd door CodeCaster op 16-12-2009 23:50 ]

[RobIII]

CodeCaster schreef op woensdag 16 december 2009 @ 23:42:

@RobIII: ziet er ... uitgebreid uit.

Uitgebreid? Dit is KARIG man!

[CodeCaster]

Ik had het ook meer over de resolutie van de afbeelding.

[whoami]

* whoami haat prefixen in tablenames & columnnames.
/offtopic.