[SQL] Schema voor productregistratie en onderhoud

[Mister GT]

Hallo allen,

Voor mijn werk ben ik bezig met het opzetten van een systeem wat gebruikt gaat worden voor het registreren van het onderhoud van producten. Ik heb een schema opgezet, maar ben hier niet helemaal tevreden over. Ik denk dat het beter kan, maar zie het even niet. Bijgevoegd de relevante delen van het schema.

Het startpunt is een bezoek. Tijdens een bezoek kunnen er 2 dingen gedaan worden: het controleren van artikelen, en/of het leveren van diensten (trainingen, etc.). Mijn probleem zit in het idee dat ik denk dat deze opzet onnodig complex is. Het liefst zou ik geen onderscheid willen maken tussen deze 2 dingen, maar dat is jammer genoeg net niet mogelijk omdat bij het onderhouden van een product natuurlijk genoteerd moet worden welk product dit precies is, en welke handelingen er zijn verricht(1-to-many). Aan een dienst zit geen product gekoppeld, en hoef ik slechts te weten welke dienst er is verleend (1-to-1).

Is mijn huidige opzet wel optimaal, of kan ik het beter anders aanpakken? Mijn dank is groot.

[MAX3400]

Je denk/werk-flow is niet goed?

Ga eens terugredeneren/programmeren: hoe betaalt een debiteur zijn rekening? Wat staat er op de rekening-specificatie? Wie maakt/print die specificatie? Hoe komt de werkbon op het bureau van de administratie? Wat is een werkbon? Wat staat er op een werkbon? Hoeveel werkbonnen passen er in een bezoek? Hoeveel mensen kunnen er tegelijk op bezoek zijn?

Ik persoonlijk vind het hele diagram overbodig complex; als je eerst, op papier, de splitsing/koppeling kan gaan bedenken omtrent "klant", "produkt", "bezoek", "werkbon", ben je al een heel stuk verder?

[Douweegbertje]

Heb je niet een wat scherper plaatje?

[Mister GT]

MAX3400 schreef op woensdag 02 maart 2016 @ 12:42:
Je denk/werk-flow is niet goed?

Ga eens terugredeneren/programmeren: hoe betaalt een debiteur zijn rekening? Wat staat er op de rekening-specificatie? Wie maakt/print die specificatie? Hoe komt de werkbon op het bureau van de administratie? Wat is een werkbon? Wat staat er op een werkbon? Hoeveel werkbonnen passen er in een bezoek? Hoeveel mensen kunnen er tegelijk op bezoek zijn?

Ik persoonlijk vind het hele diagram overbodig complex; als je eerst, op papier, de splitsing/koppeling kan gaan bedenken omtrent "klant", "produkt", "bezoek", "werkbon", ben je al een heel stuk verder?

Ik heb een aantal dingen overslagen die me niet relevant leken, maar dat zijn ze blijkbaar toch wel, dus bij deze. Alle administratieve handelingen worden uitgevoerd in een reeds bestaand pakket. Hier staat alles in qua facturen, orders, pakbonnen, etc. Het systeem wat ik moet ontwerpen dient als extensie hierop.

Een voorbeeld, bij een uitgaande verzending voert de medewerker het ordernummer in. Hierna haal ik alle orderregels op en laat ik artikelen op het scherm zien waarbij informatie zoals een serienummer moet worden opgeslagen. Als alles is ingevuld wordt het pakket aangemeld bij UPS. Deze gegevens worden opgeslagen in de tabellen: order, shipment en article. Eén order kan meerdere zendingen hebben (bijv. nazendingen) en elke zending heeft een aantal verzonden artikelen.

In eerste instantie lijkt mijn schema inderdaad wellicht complex. Ik moet echter voor de handelingen die uitgevoerd kunnen worden (in serviced_article_action_type en service_action_type) weten hoe vaak deze handeling moet worden uitgevoerd (kolom "interval", bijv. elke 3 maanden), of deze terugkomend zijn (kolom "recurrent") en hoe lang deze ongeveer duurt (kolom "estimated_time"). Waarom? Op deze manier is in de toekomst onze onderhoudsplanning te automatiseren. Ik weet immers welke artikelen naar welke locatie zijn verstuurd, welke handelingen elk artikel type nodig hebben, en ook hoe vaak deze moeten gebeuren.

Hier een scherpere versie met wat toegevoegde tabellen voor wat extra context. Hier staan dus niet alle tabellen in, en ook niet elke kolom staat hier nog in.


Ik heb dus in het schema een expliciet onderscheid gemaakt tussen het onderhoud plegen aan een artikel (serviced_article, meerder artikelen kunnen worden onderhouden per bezoek) en het leveren van een dienst (bijv. training, provided_service, meerdere diensten kunnen worden geleverd per bezoek). Dit heb ik zo gedaan omdat bij het onderhouden van een artikel ik natuurlijk wil weten welk artikel dit precies is geweest (article_id kolom) terwijl dit irrelevant is voor het geven van een training.

Maar ik vraag me al een tijdje af of dit de beste manier is, of dat er een mooiere oplossing is die ik beter kan toepassen.

[Gomez12]

Mister GT schreef op woensdag 02 maart 2016 @ 12:36:
Het startpunt is een bezoek. Tijdens een bezoek kunnen er 2 dingen gedaan worden: het controleren van artikelen, en/of het leveren van diensten (trainingen, etc.).

Waarom is het controleren van artikelen geen dienst?

Mijn probleem zit in het idee dat ik denk dat deze opzet onnodig complex is. Het liefst zou ik geen onderscheid willen maken tussen deze 2 dingen, maar dat is jammer genoeg net niet mogelijk omdat bij het onderhouden van een product natuurlijk genoteerd moet worden welk product dit precies is, en welke handelingen er zijn verricht(1-to-many). Aan een dienst zit geen product gekoppeld, en hoef ik slechts te weten welke dienst er is verleend (1-to-1).

Dus als je straks de aanwezigen wilt hebben bij een training dan is dat ook geen dienst meer, want dat vereist wat aparte opslag? En als inhouse en bij de klant trainingen geeft, dan zijn dat ook 2 verschillende dingen als je bij wilt houden welke auto er gebruikt wordt om naar de klant toe te gaan?

En om te bepalen of iemand zijn visits wel goed invult moet je dus eigenlijk de diensten die gedaan zijn optellen bij de artikelen die gefixed zijn en dan heb je de totaaltijd?
Bij een dienst zit iemand dus nooit stil iets te overdenken en bij een artikelcontrole is het echt 100% lopende bandwerk, er zit geen seconde tussen 2 artikelen pakken?

En hoe wil je in deze opzet omgaan met artikelen die uit de oude doos komen als de controlleur bij de klant zit? Een controleur mag meer tijd controleren dan er voor een visit staat?

Ik zou zeggen artikelcontrole is een dienst, dan heb je ook gelijk je administratie recht. Want je visits zijn dan de aangevraagde tijd door de klant en de provided service is de daadwerkelijke tijd / te factureren tijd ook al factureer je artikelcontroles tegen nul toch wil je het wel bijgehouden hebben.

Maarja, ik vermoed ook dat een service_action_type hetzelfde is als een article_service_action_type, want in principe heb je bijna nooit dat er echt service_types per artikel zijn, wel per artikelgroepen oid, maar dat past gewoon nog steeds in service_action_types.

[Mister GT]

Waarom is het controleren van artikelen geen dienst?

Heel goed punt. Nadat ik dit schema had gemaakt kwam dit punt ook bij mezelf op. Dit is precies een van de redenen waarom ik dit topic heb gemaakt.

Dus als je straks de aanwezigen wilt hebben bij een training dan is dat ook geen dienst meer, want dat vereist wat aparte opslag? En als inhouse en bij de klant trainingen geeft, dan zijn dat ook 2 verschillende dingen als je bij wilt houden welke auto er gebruikt wordt om naar de klant toe te gaan?

En om te bepalen of iemand zijn visits wel goed invult moet je dus eigenlijk de diensten die gedaan zijn optellen bij de artikelen die gefixed zijn en dan heb je de totaaltijd?
Bij een dienst zit iemand dus nooit stil iets te overdenken en bij een artikelcontrole is het echt 100% lopende bandwerk, er zit geen seconde tussen 2 artikelen pakken?

En hoe wil je in deze opzet omgaan met artikelen die uit de oude doos komen als de controlleur bij de klant zit? Een controleur mag meer tijd controleren dan er voor een visit staat?

De waarden in required_time zijn uiteraard aannames en dienen slechts ter indicatie. Bij het maken van de planning zal gekijken naar de duur van het vorige bezoek, alsmede nieuwe/verwijderde artikelen op die specifieke locatie. Dit stukje is echter iets wat later pas echt van toepassing wordt. Ik wil eerst de basis goed hebben.

Ik zou zeggen artikelcontrole is een dienst, dan heb je ook gelijk je administratie recht. Want je visits zijn dan de aangevraagde tijd door de klant en de provided service is de daadwerkelijke tijd / te factureren tijd ook al factureer je artikelcontroles tegen nul toch wil je het wel bijgehouden hebben.

Een visit wordt in principe ingevuld nadat de medewerker op locatie is geweest en de benodigde diensten heeft geleverd. In eerste instantie moet de medewerker dit via en computer invullen, later worden hier ook mobiele apps aan toegevoegd. Het veld appointment_id verwijst naar de afspraak zoals deze door de planningsafdeling is gemaakt. In een visit staan dus de daadwerkelijke waarden zoals deze gerealiseerd zijn.

Maarja, ik vermoed ook dat een service_action_type hetzelfde is als een article_service_action_type, want in principe heb je bijna nooit dat er echt service_types per artikel zijn, wel per artikelgroepen oid, maar dat past gewoon nog steeds in service_action_types.

Ja, deze zijn bijna gelijk inderdaad. Het enige verschil in de huidige opzet is dus dat een article_service slaat op een artikel, waar een service_action geen gerelateerd artikel heeft.


Maar nu blijft mijn vraag, hoe kan ik dit correct opslaan? Ik heb wel een idee, in onderstaand schema, maar vraag me af of dat de bedoeling is. Op deze manier koppel ik een aantal eigenschappen aan een bepaalde operatie soort (operation_type -> operation_property_type), welke vervolgens een waarde kunnen krijgen per operatie (visit_operation -> visit_operation_property). Heel flexibel, maar ook vrij omslachtig lijkt me.