NYCPHP Meetup

[inforequest]

Mark Armendariz nyphp-at-enobrev.com |nyphp 04/2004| wrote:

>Looking for a professional developer's opinion...
>
How about a developer/development project director's opinion?

Based on my (somewhat cynical view of ) experience dealing with people 
who have a "good Access database" and "need someone to put it onto the web":

- they will not listen to your reasons for changing the Access database 
at this time.
- they will not learn "in real time" from your own database design/work
- they *will* likely change their own schema at some point (because they 
will learn and improve - and while it may be an improvement, it will not 
match yours)

So if these are likely, you really need to abstract your interface to 
their data and make a clear specification for what they will have to 
provide to you for updates. If you get to do this unilaterally, good for 
you. Get that spec approved in writing so everyone has an obligation to 
meet it (otherwise they may decide to change it and simply expect you to 
accommodate the changes).

Define a CSV or whatever that works for their schema now, and is solid 
for your use. Require a full dump for their export every time, so you 
don't need to worry as much about data integrity. This is a good time to 
design your app and process to be modular such that it is recoverable 
from a full data set from their end plus a diff or sync set from your 
end, with no need to have your database backup on hand (just the diff or 
sync set)..  Think ahead and require compression now, so if the file 
gets large nothing breaks.

Your apps should accomodate updates via proper table structure *on your 
side*, so that the full dump gets parsed *by you* and your own tables 
accommodate syncing your stuff with their stuff. 

Ideally, your database and process is robust enough to restart fresh on 
a new system using only 1) a full dump they provide and 2) an 
import/sync set from your side. If you achieve that, you can then 
offload archive responsibility to their admin as well, by simply 
delivering the sync set at any time for him to archive along with a copy 
of the process and a copy of his full dump CSV.

If I were you I would create some one-way hash functions to run their 
dataset which I would run prior to every import, so that any changes at 
all (historical data, field names, eve spelling and or capitalizations) 
are flagged and the generated repor tis made available to both sides. Of 
course I would make sure my archive/diff set passed those same data 
integrity checks as well ;-)