itle might be a little bit incorrect. :) Anyway, I'm building a software where employees input time they worked per day (work hours) and employer pays for this time. Payment is done outside this system, so employer just confirms (checkbox or something like this) which work hours are paid. So the question is - what is the best way (both UI and data storage wise) to implement this?At the moment I have this idea:Employee selects week and manually (with some Javascript helpers, like fill the same time for all days) inputs work hours in every day of the week. Employer confirms payment the same way employee inputs data (selects week, confirms each day). Data is saved in DB as unix timestamp (one day per table row). Problem is 14 inputs (7 days * (hours from + hours to input), yet this approach seems kinda easy to implement.Maybe I'm overlooking something and this can be done differently and better? Maybe someone has any example of already working software? 
Time tracking and payment registration architecture
web development;development process;user interface
You said yet this approach seems kinda easy to implement, which leads me to ask: Why make things complicated?  Code to the business requirements of your application.How you treat the data in the database should be independent of the input view for the employees.Create a common object to go between the UI and the DB interface. As your data storage requirements change, you can update the database accordingly without having to alter the view since the UI and the DB interface still speak in the same common object.  Likewise for the UI - it can change independent of the DB now.Your initial DB structure will probably mirror the common object, which is okay.You won't really know the best solution to your scenario until you start building it and making it work.  It sounds like you have some ideas for coding it up.  If your ideas appear to meet your requirements then start with that and adjust the design as necessary.  