Forum Moderators: coopster
I'm in the process of a major ordering system upgrade, and part of my design criteria was dealing with a connection to a remote server that may or may not be there.
I decided to design with the intention of the remote database not being available, and wrote my checkout system so that it inserts all required information to an 'order queue' database on the web server. This database is to be checked regularly by a retrieval script on the remote server, which then moves all the information from the public webserver to our local server.
At the time, it seemed like a fairly simple way to do it -- all my info is stored in the same sort of tables as they would be after they're retrieved..
but..
my caffeine-rusted brain just shot an idea at me that I'm willing to consider, and I'm kicking myself for not thinking of it earlier.
I figured that instead of storing all the information in the same sort of tables, I could simply just store the php object serialization(s) in a table. Then I could have the same sort of retrieval script download it, decrypt it, and put the data where it needs to go -- and in the process, reduce the amount of processing required to 'import' an order.
My reason for posting all this is to basically fish out some opinions on these two separate approaches.
I can:
a) Stick with what I have
b) Explore this new idea
c) Explore any other ideas that other posters might have.
So, any ideas? Have any of you ever designed an order queuing/retrieval system that worked like a charm, or sunk like a brick? What would you do? What should I not do?
Thanks in advance,
ixos
