:strip_icc():strip_exif()/u/80798/crop5aa902e5a190d_cropped.jpeg?f=community)
Ik ben bezig met het verder ontwikkelen van een databaseapplicatie waarin het mogelijk is om process-flows in bij te houden. Deze process-flows worden runs genoemd welke op zichzelf bestaan uit een onbepaald aantal steps. Wanneer een run geopend wordt ziet dat er vereenvoudigd ongeveer zo uit:
Runs worden soms op meerdere substraten gedaan die in dit systeem dus parts worden genoemd. In deze tabel stelt de kolom parts dus voor op welk stukje het proces precies is uitgevoerd. Op zichzelf is niet natuurlijk niet zo spannend, ik het daarvoor namelijk een table 'Parts' in de database met de volgende structuur. Hierin is de listing zoals hierboven aangegeven ook al ingevuld.
Wanneer nu de run wordt opgevraagd haal ik met 1 query de volledige stap-info binnen van alle parts in de run en met een beetje PHP scripting zorg ik dat de juiste cellen in de run gevold worden met het juiste getal.
Het verzoek is nu gekomen om een part later nog een keer te splitsen in een part, schematisch zou dat er dan als volgt uitzien:
Dit is natuurlijk op te lossen door een extra rij in de Parts tabel toe te voegen "Parent" waarbij de parent eventueel 0 is voor een eerste splitsing en de de waarde van een PartId heeft voor een latere splitsing.
De listing hierboven zou dan worden:
Ik ben nu echter al een aantal dagen mijn kop gek aan het maken met het zoeken naar een efficient script om deze tabel zo snel en goed mogelijk op het scherm te krijgen. Een run kan soms uit 50 stappen bestaan dus ik moet het aantal query's beperken. Ik wil dan ook voor de parts liefst maar 1 query gebruiken. Ik kan natuurlijk op basis van een multi-level idee wel een script maken die alles in 1 keer uit de database haalt maar ik krijg het maar niet goed voor elkaar om bijvoorbeeld voor de eerste stap efficient uit te rekenen wat de colspan moet zijn indien die part later geplitst worden, of voor latere stappen hoe ik moet bepalen welke cel overgeslagen moet worden.
Uiteraard vraag ik geen compleet script, maar met een zetje in de goede richting zou ik al erg geholpen zijn. Hoe zouden jullie zoiets aanpakken? Alle hulp is welkom!
Een online demo van het systeem is beschikbaar (http://demo.solodb.net), via http://demo.solodb.net/run/view/1/page/1 kun je zien hoe dat opdelen in parts in de praktijk werkt.
| StepId | parts | process | equipment | ||
|---|---|---|---|---|---|
| 1 | a | b | c | acid clean | wetbench |
| 2 | a | c | water rinse | wetbench | |
| 3 | a | c | dry | wetbench | |
Runs worden soms op meerdere substraten gedaan die in dit systeem dus parts worden genoemd. In deze tabel stelt de kolom parts dus voor op welk stukje het proces precies is uitgevoerd. Op zichzelf is niet natuurlijk niet zo spannend, ik het daarvoor namelijk een table 'Parts' in de database met de volgende structuur. Hierin is de listing zoals hierboven aangegeven ook al ingevuld.
| Parts | ||
|---|---|---|
| PartId | FkStepId | PartNumber |
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 1 | 3 |
| 4 | 2 | 1 |
| 5 | 2 | 3 |
| 6 | 3 | 1 |
| 7 | 3 | 2 |
Wanneer nu de run wordt opgevraagd haal ik met 1 query de volledige stap-info binnen van alle parts in de run en met een beetje PHP scripting zorg ik dat de juiste cellen in de run gevold worden met het juiste getal.
Het verzoek is nu gekomen om een part later nog een keer te splitsen in een part, schematisch zou dat er dan als volgt uitzien:
| StepId | parts | process | equipment | |||
|---|---|---|---|---|---|---|
| 1 | a | b | c | acid clean | wetbench | |
| 2 | a | c | water rinse | wetbench | ||
| 3 | a1 | a2 | c | dry | wetbench | |
Dit is natuurlijk op te lossen door een extra rij in de Parts tabel toe te voegen "Parent" waarbij de parent eventueel 0 is voor een eerste splitsing en de de waarde van een PartId heeft voor een latere splitsing.
De listing hierboven zou dan worden:
| Parts | |||
|---|---|---|---|
| PartId | FkStepId | PartNumber | Parent |
| 1 | 1 | 1 | 0 |
| 2 | 1 | 2 | 0 |
| 3 | 1 | 3 | 0 |
| 4 | 2 | 1 | 0 |
| 5 | 2 | 3 | 0 |
| 6 | 3 | 1 | 4 |
| 7 | 3 | 2 | 4 |
| 8 | 3 | 3 | 0 |
Ik ben nu echter al een aantal dagen mijn kop gek aan het maken met het zoeken naar een efficient script om deze tabel zo snel en goed mogelijk op het scherm te krijgen. Een run kan soms uit 50 stappen bestaan dus ik moet het aantal query's beperken. Ik wil dan ook voor de parts liefst maar 1 query gebruiken. Ik kan natuurlijk op basis van een multi-level idee wel een script maken die alles in 1 keer uit de database haalt maar ik krijg het maar niet goed voor elkaar om bijvoorbeeld voor de eerste stap efficient uit te rekenen wat de colspan moet zijn indien die part later geplitst worden, of voor latere stappen hoe ik moet bepalen welke cel overgeslagen moet worden.
Uiteraard vraag ik geen compleet script, maar met een zetje in de goede richting zou ik al erg geholpen zijn. Hoe zouden jullie zoiets aanpakken? Alle hulp is welkom!
Een online demo van het systeem is beschikbaar (http://demo.solodb.net), via http://demo.solodb.net/run/view/1/page/1 kun je zien hoe dat opdelen in parts in de praktijk werkt.
Solo Database: Online electronic logbook and database system for research applications
:strip_exif()/u/3398/rh.gif?f=community)
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)