if you don't need to access the data between data capture and uploading the just write it to flat files. whether you choose to do that as terse minimalist csv or human readable is up to you. a potential advantage of writing it in a human readable format is that it coudl easily become part of a formal legalistic document set if the attendance is going to be used for disciplinary purposes. if you make the directory where you write the files to be read only for approved users with only one user allowed to create files (the applications capturing the data), no users allowed to edit or delete files with te exception say of sys admin or a named useraccount then you have the beginnings of a good audit trail.
if a file goes missing in the update its still sitting on whatever device the data capture was recorded in.
heck if you wanted to you could write two flat files, one with minmialist 'terse' just the data, one formatted.
as to your batch processes that dependzs on what computers you are running the data capture on. I'd do it as a timed process (windows scheduler or cron) that pumped the data up the line well before the 02:00 deadline into a single directory that your applciationt hat stuffs the data into MySQL knows about. file naming would be important (probably could do that by creatign the file name out of the computer name, date or date and time if you coudl have multiple files from on device in any one day.
can't see why you'd need to transfer user ids back to the data capture computers, unless you feel the need to validate a card swipe. personally I'd jsut record the barcode, make certain its the right type for the application and validate on trying to pump ther data into the MySQL db. bear in mind the barcode itself should have enough validation around it to ensure the correct value is scanned.
as to how your MySQL process runs thats up to you. but I fit were me I'd accept all data into a holding table in the db. then draw valid data from the holding table into the system proper leaving the unvaildated data in that holding tank for manual processing, or split the incoming data into valid (straight to system), and invalid straight to holding table. build in some form of audit trail withint he db so that you know what happened to a specific record so it can be traced back to a specific batch.. that means not deleting data. again if this data is used for legalistic purposes you need to think about the security implications
Im nto certain Id want to use barcodes if this is legailstic as barcodes are easy to fake. the fact that someone wafted a barcode in front of a scanner doesn't neccessarily prove that they have attended (it could be cloned card, it could be someone impersonating the individual. RFID chips are trickier to fake.
I'd rather be riding on the Tiger 800 or the Norton