Bijhouden van uitgevoerde taken in SQL

[.Vii]

Mijn vraag

Momenteel ben ik een applicatie aan het (her) ontwikkelen welke voorziet in de doorstroom en tussen punt om diverse andere systemen van informatie te voorzien daarnaast zorgt deze applicatie voor het centrale punt waar de informatie over een specifiek object van al deze applicaties beschikbaar is.

Nu komt het voor dat deze applicatie background jobs uitvoert om bepaalde taken uit te voeren. Deze taken kunnen varieren van een intern proces van de applicatie zelf tot het wachten tot een andere applicatie iets heeft uitgevoerd om vervolgens door te gaan naar het volgende proces.

En dat laatste zit ik een momenteel een beetje mee.

Ik ben nu een proces aan het schrijven welke een 1000 tal documenten ontvangt doorstuurt naar een externe applicatie (die doet er vervolgens wat mee) en ik vervolgens van al deze 1000 documenten en seintje moet krijgen "Ja akkoord we kunnen door".

Nu wil ik dit vast leggen dat dat seintje is gegeven en dat alle 1000 documenten ook daadwerkelijk het seintje hebben gekregen. Echter kan het ook voorkomen dat het niet gelukt is uiteraard wil ik dit signaal ook gelogd hebben. (Zodat ik weet dat ik niet door kan naar de volgende stap)


Relevante software en hardware die ik gebruik
PHP 7+
Laravel 5.7
Windows (Requirement)
Apache
Microsoft SQL (2008 r2, yeah I know outdated)

Wat ik al gevonden of geprobeerd heb

Ik zelf dacht er aan om een volgende SQL tabel aan te maken:

events
- id (auto increment, integer)
- event (naam van event, varchar(200))
- event_ref_id (dit ID kan refereren naar verschillende objecten binnen de database, integer en een soort van flexibele foreign key)
- event_result (bit)
- event_message (varchar(200))

Nu kan het zijn dat ik later meer wil gaan loggen dan alleen of de ping naar deze externe applicatie is gelukt voor het betreffende document maar ook dat bijvoorbeeld de metadata extractie is gelukt voor het betreffende document.

Hiervoor heb ik de kolom "event" gemaakt zodat ik hierop kan splitsen.

De documenten waar ik het over heb komen samen in een "documentenset" welke gecombineerd bijvoorbeeld geprint moeten worden. Dit wil ik later ook gaan loggen of het combineren is gelukt. Hierdoor heb ik de kolom "event_ref_id" gemaakt vanwege dat deze kolom referenties naar verschillende tabellen in mijn database kan hebben (waar bij het versturen naar de applicatie zoals in mijn voorbeeld het id van het document bevat zal het bij het samenvoegen naar een documentenset het id van de documentenset bevatten).

Mijn vraag is, is dit een logische keus om dit zo te doen?
De tabel kan vrij snel vrij groot worden (Nu met de juiste indexxen op event en event_ref_id het een stuk sneller zal maken). Echter misschien als jullie dit verhaal lezen dat jullie denken, nou dit kan je beter zo of zo doen.

[armageddon_2k1]

Ben je niet bezig het "logging" wiel opnieuw uit te vinden? Ik zou dan naar een logging server gaan waar je goed in kan zoeken en vanuit meerdere talen naar kan loggen.

[Onbekend]

Normaal is SQL wel geschikt voor het bijhouden van duizenden regels, en zoals je aangeeft zou je extra indexen op andere kolommen kunnen aanmaken om de boel te versnellen.

Ik zou in ieder geval een datum/tijd of timestamp kolom opnemen zodat je weet wanneer een document was verstuurd.
Daarnaast gebruik je varchar i.p.v. nvarchar waardoor je geen bijzondere talen ondersteunt zoals Hebreeuws, Thais, Chinees en Japans.

[aawe mwan]

.Vii schreef op zondag 7 oktober 2018 @ 08:33:
Ik ben nu een proces aan het schrijven welke een 1000 tal documenten ontvangt doorstuurt naar een externe applicatie (die doet er vervolgens wat mee) en ik vervolgens van al deze 1000 documenten en seintje moet krijgen "Ja akkoord we kunnen door".

Tip: kijk eens of dat wat je aan het maken bent, niet gewoon "Managed FileTransfer" is.
Daarvoor bestaan namelijk al heel goede standaardapplicaties.