[nycphp-talk] DB Differences
Tim Gales
tgales at tgaconnect.com
Fri Jun 18 07:13:06 EDT 2004
Mark Armendariz writes:
>
> Looking for a professional developer's opinion...
>
> I'm working on a gig where I'll be importing data on a
> nightly basis from an already existing access database (mdb).
> Their setup is Access / CF Express. I'm, of course, working
> on a LAMPhp server as I usually do. Eventually I'll also be
> exporting back to that database.
>
> Now, looking over the db, I don't agree with the overall
> design. It's not normalized very well. I can't necessarily
> tell him to change it, 1 - because that's not what I'm hired
> to do, 2 - because it's his app and he'll write it how he
> pleases. But, I can't see myself replicating their structure
> to run my application.
>
> Obviously this will cause more headaches in the sync functions.
>
> So, would you replicate his db and grin and bare it all, or
> would you format it the way you feel is 'right' and efficient
> and holy and just deal with the data conversion with every
> import / export?
Is your (sub)system the 'dog' or the 'tail' and which of the
two systems should do the 'wagging'?
Is this a 'webification' of something which has a good
'track record' in terms of volume? Do you feel that
the volume of your system, in terms of users and/or transactions,
is likely to increase past the size of the 'tried and true'
system -- and to the point where incurring anomalies in
the transactions will be more probable than that in the other
system because of the poor schema?
The above is just food for thought.
I would venture to say that the mismatch between your understanding
and your client's understanding of database design will be more
likely to cause 'headaches in the sync functions' than the
mismatch between the two database schemas.
Access has some data analysis routine that you can
run on a database. (Sorry, I forget specifically how
you run it -- you go down one of the 'menu mazes' that
Microsoft developers are fond of including in their products)
You could play with some data in a test mdb and
see what the 'data analyzer' suggests.
As I recall the process gives some suggestions on
how to improve a database's schema and gives
examples of data normalization and why those
normalizations are important.
I am a little fuzzy about to what degree the 'analysis'
is affected by the data in the tables, but I seem to
recall that there is a fairly strong relationship.
A possible tack you could take is to 'stack the
deck' in a test mdb database -- that is, put data
into the test database which will make the analyzer
thing suggest what you feel is the right move.
And then show this to the client -- and even
let him play with the analyzer a bit.
This might bring his understanding to more
clearly match yours.
It is my experience that it is most difficult, if
not impossible, to 'teach' someone something;
the most you can do is provide an environment
for people to 'put the pieces together' for
themselves and hope for the best.
T. Gales & Associates
'Helping People Connect with Technology'
http://www.tgaconnect.com
More information about the talk
mailing list