The biggest thing that I see is missing is keeping track of what the user has actually paid. Some people pay an amount more or less than the amount due, so some may have a balance due from the last invoice while others may have pre-paid for several periods ahead.
EDIT: Based upon your comment, I see this is handled seperately, great!
The other thing I see is the way you are handling the TIMESTAMP field. For example:
Paid monthly
if ( Timestamp is in past = true AND Month gone by = 0 AND Days gone by >= 20 )
then ( create a new invoice and set "Last Due Date" to time() )
Suppose I initially signed up on 1/1/2012, then Timestamp starts off with that date. Assuming I pay monthly, this will mean you generate an invoice on 1/20/2012 and set the Timestamp to 1/20/2012. Does this mean you generate an invoice every 20 days rather than once per month? In other words will you generate an invoice on 2/9/2012 (20 days after 1/20/2012)?
The point is that the next invoice should be generated based upon the end date of the current billing period, not the date the invoice was generated.
Currently you "set "Last Due Date" to time()", perhaps you want to set Last Due Date to the first day of the next billing period? So for example when generating monthly invoices on 1/20/2012 you would change 1/1/2012 (current value in DB) to 2/1/2012. You don't state which database you are using, but many have built-in functions to add 1 month, quarter, year etc.
There do seem to be PHP wrappers for OpenCV, such as OpenCV For PHP.
Now, for the recognition part, I think that the best way to go is to use Artificial Neural Networks. ANN's can be trained to identify people within images and are more suited because they can handle relatively inconsistent inputs and produce relatively stable results. There does seem to be ANN implementations in PHP, such as FANN. The implementation of an ANN's should also be quite fast (once trained, that is) and will remove the need for a database, unless you will be using it for other things and/or persist the neural network itself.
This would mean that you can write your solution entirely in PHP.
That being said, my experience with wrappers is that you do not always get all the goodies provided by the original library, so with that in mind, you could also opt to have PHP handle your front end and then, use C++ as back end, which should allow you to exploit all the power of OpenCV (which could come in handy for future add-ons).
As for communication between the two layers, I think using standard SOAP web service communication (for PHP and C/C++) will provide you with a robust solution.
Best Answer
MySQL timestamps:
Are stored in UTC
They are converted to UTC on storage and converted back to your time zone on retrieval. If you change time zone settings, the retrieved values also change.
Can be automatically initialised and updated
You can set their default value and / or auto update value to
CURRENT_TIMESTAMPHave a range of
1970-01-01 00:00:01 UTCto2038-01-19 03:14:07 UTCWhereas MySQL datetime:
What you store is what you get ™.
Have a range of
1000-01-01 00:00:00to9999-12-31 23:59:59Values outside the range may work - but only values within the range are guaranteed to work.
You can store dates where day or month is zero.
This is the MySQL way of storing birthdays! You can't do that with a
TIMESTAMP, with the only exception being the zero value of0000-00-00.You can store invalid dates, if you need them, in ALLOW_INVALID_DATES mode.
You can set default value to
NOW()in some instances, but the preferable and more natural way of automatically initialised and updated dates isTIMESTAMP.And of course there are also
DATEandTIME, which work just likeDATETIME, but of courseDATEdoesn't care for time andTIMEdoesn't care for date. All four data types work perfectly with the wide array of date and time functions, but when you are mixing data types you should be aware of conversion effects.Now, to your question: You should use
DATETIMEeverywhere. Not for technical reasons, but since you are still unclear on how MySQL works,DATETIMEis the simpler choice. This will mean that you will have to calculate the current timestamp in PHP before storing, that's as easy as:PHP's date function works like:
The
"Y-m-d H:i:s"format is the one compatible with MySQL and by leaving the second parameter empty,date()callstime()to get the current UNIX timestamp.Using a
TIMESTAMPinstead of aDATETIMEhas the added value of MySQL taking over the responsibility of deciding on the current timestamp, and you can skip the field when you are inserting / updating. But since you are already sending a query, and the code to get the current timestamp in PHP is minimal, you can safely go withDATETIMEfor everything.As for the actual code to store the PHP timestamp into the database, you should look at PHP Data Objects, and if you are still unclear, ask on StackOverflow instead. But there are almost 1.5k related questions already, make sure you go through them before asking. Just a hint, prepared statements is how the cool kids do it.