NoodlesWIU
asked on
Perl Script as a service
Hi all, looking for a little direction if you could point me the right way or offer some insight. Here's a little background info on the project.
I am developing a registration web portal for the parents in our district to register their students. the system is using IIS 7, MySQL, and Perl. We have a main Oracle based student database that the registration portal will pull data from using ODBC to keep a localized database of everything for registration so parents can manipulate it all they want without every changing anything on our main student database. When all is said and done, they will simply modify and data that needs to be changed, print out the PDF forms that we will serve up to them from the data they provided, and bring them into registration. Once we are satisfied with all the data, we can use it as an import back to our main database saving us loads of data entry time.
My question is this. Since they are two seperate systems, and if I have a new student who wants to register, I first must create that student in our main database so they exist, and either have an admin log into the registration web portal and offer the admin a method to import that student, or second option, have a constantly running script running in the background of the server without user intervention that will constantly do a query on both databases to see if there are any new students by comparing the lists between the two databases. If there is, then the script would have a subroutine to create the record, and the whole process would start all over again.
Is the later option a bad idea? I mean crap, I could always run it as a scheduled task to go off every 30 seconds. But I guess this may be bad form? Just because we CAN do something, doesn't mean we SHOULD, right?
I am developing a registration web portal for the parents in our district to register their students. the system is using IIS 7, MySQL, and Perl. We have a main Oracle based student database that the registration portal will pull data from using ODBC to keep a localized database of everything for registration so parents can manipulate it all they want without every changing anything on our main student database. When all is said and done, they will simply modify and data that needs to be changed, print out the PDF forms that we will serve up to them from the data they provided, and bring them into registration. Once we are satisfied with all the data, we can use it as an import back to our main database saving us loads of data entry time.
My question is this. Since they are two seperate systems, and if I have a new student who wants to register, I first must create that student in our main database so they exist, and either have an admin log into the registration web portal and offer the admin a method to import that student, or second option, have a constantly running script running in the background of the server without user intervention that will constantly do a query on both databases to see if there are any new students by comparing the lists between the two databases. If there is, then the script would have a subroutine to create the record, and the whole process would start all over again.
Is the later option a bad idea? I mean crap, I could always run it as a scheduled task to go off every 30 seconds. But I guess this may be bad form? Just because we CAN do something, doesn't mean we SHOULD, right?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@fishmonger - Actually, our leadership team wants new students to prove residency first and have us input a few key pieces of data on the student in our Main DB as they don't trust parents to input there "legal" name. Some love to hyphenate and change it every other year which sometimes causes us to duplicate a student record because we search for the student in our DB and if it's not the same name we can't find it and create a new student. So our portal will not allow "them" to change the name, DOB, grade level without showing documentation first. So new students will come in during registration, provide birth certificate and we'll key it in and generate an account in the portal for them to fill in the rest by sending them down the hall to our lab to complete and print.
And don't get me started on having them come in. It's an ongoing battle I have with them. So baby steps. They were all paper prior to this year because their hang up is every year proving residency for all students, new and returning.
If all goes smoothly this year, I'm hoping I can get them to ditch the paper and just pull the forms from the database at their leisure.
But the having to prove residency every year for all students throws a monkey wrench into the whole efficiency of it.
And don't get me started on having them come in. It's an ongoing battle I have with them. So baby steps. They were all paper prior to this year because their hang up is every year proving residency for all students, new and returning.
If all goes smoothly this year, I'm hoping I can get them to ditch the paper and just pull the forms from the database at their leisure.
But the having to prove residency every year for all students throws a monkey wrench into the whole efficiency of it.
Ok, I understand that you need to work within constraints outside of your control.
But at this point I'm not sure what you're needing from us.
Can you refine your question?
But at this point I'm not sure what you're needing from us.
Can you refine your question?
If a currently registered student needs to make some changes to their registration, they need to use your web portal to generate a pdf form which they need to bring into the registration office for review and approval. If it's a new (unregistered) student, they can use your web portal to register themselves without coming into the office or have their submitted registration info reviewed prior to adding them to the database as a registered student.
If that's the case, then IMO you are doing it backwards.
IMO, the only time a student should be required to go to the office would be if they are required to physically sign some paperwork in the presence of a staff member.
New registration requests submitted through your public web portal should place the registration info in a "Registration_Request" table. Then a staff member could use their admin web interface to accept the registration and when submitted would add the new student to the oracle db and possibly remove it from the request table or update a status field.
If you can access each db from the opposite server, then this can all be handled within the web portal code without the need of any script executed every 30 seconds as a scheduled task.