NYCPHP Meetup

[Jim Hendricks]

Don't forget about the other side of the coin.  I know as a programmer I
tend to only think of the technical ramifications, but you also need to look
at the business ramifications ( ie. what will make you the most amount that
the customer is willing to bear )

So, let's think of a straight sync.  It will take you longer to create the
queries/post query parser to obtain the data for your screens.  Multipy that
by how many queries.  And of course time is money.

Then a translating sync.  It will take longer to write the sync, but the
queries will be real easy and no need for post query parsing.

Let's assume the longer time of the two is with a straight sync.  So, if you
can get approval for the time estimate for the straight sync, you can then
safely choose either method, if you go with the programmers ideal and
translate the sync, you may win out and come in under budget which either
saves the client money( always good PR ) on an hourly, or makes you more
money on a fixed.

Then say the client won't go for the longer time frame.  You can then
suggest that a programming ideal can lead to a shorter time( that is of
course if the translating is less dev time ) and thus save them money, but
it may come at the expense of a more complicated sync and therefore may be
more costly to maintain.

Now flip it, translating takes longer, but the client is willing to bear the
cost, you can either stick with the plan and have the knowledge that the
program is the best you can produce, or you can short cut, do the straight
sync and dirty programming and either come out the under budget hero or a
little richer.

But if the client won't bear the longer translating cost, you go the
straight and dirty and know that although the program is not one you will
present as "see what I can do", it is one which you were more sensitive to
your client and win a few business brownie points.

Hope this helps,
Jim

----- Original Message ----- 
From: "Mark Armendariz" <nyphp at enobrev.com>
To: "'NYPHP Talk'" <talk at lists.nyphp.org>
Sent: Friday, June 18, 2004 7:50 AM
Subject: RE: [nycphp-talk] DB Differences


>
>  > 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'
>
> Ok, details required :)
>
> It's a grading system written in access, being used by teachers via cf
> express.  So current usage is about 5 - 10 people.  The web version will
be
> accessed by a couple hundred parents.  Obviously not any feat in traffic,
> but the design is always important.
>
> I'm actually in no position to change the 'parent' db (the access db), as
> it's an application completely in use that I have no say in the
maintenance
> of.  I definitely would, and the improvements I have in mind are strictly
> based on general experience in db efficiency and .. Well.. nice queries.
>
> Here's an example table
> Grade_id
> Stud_id
> S_first_name
> S_last_name
> Criteria_num (number of criterias used for this grade)
> Crit_1_name
> Crit_1_value
> Crit_1_percentage
> Crit_2_name
> Crit_2_value
> Crit_2_percentage
> Crit_3_name
> Crit_3_value
> Crit_3_percentage
> ... (up to 12)
>
> All the math I'll be doing with this setup will require me to grab all the
> data and do some string manipulation for column names.  If I made a
criteria
> table with a grade_id (fk), I could do all the math in the query and knock
> out 5 steps as well as keep everything far more efficient.  Also, having a
> student name here and in a students table makes it easier to lose track of
> one or the other.  Every change requires a change in 2 places.
>
> > 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.
>
> Well, this is the primary dilemma.  Do I design the db 'my way' and make
the
> sync really nasty, while potentially offending the original developer -
> while building a nice and easy to maintain site, or do I do it his way
> trying to keep up with overlapping records and workarounds.
>
> After typing all this out, I'm pretty sure I'll end up doing the db my
way,
> I was just wondering about the opinions of other pros out there.  If
> anything I know the way I design my systems is tried and true enough for
> these guys to seek me out in the first place.  Once the clock strikes 4am
> such decisions can get a bit fuzzier.  So thank you all, if at least for
> receiving this...
>
> Thanks for the thought out reply, Tim, and I'll make sure to mention the
db
> analyzer to my client.  Good thinkin!
>
> Mark
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk