NYCPHP Meetup

[Andy Pearson]

I think most mom and pop biz use a shared hosting provider, so their site
would be stitting on a server with 100 copies of Wordpress or whatever;
therefore those 100 installs need to be optimized.

On Tue, Mar 8, 2011 at 1:09 PM, Gary Mort <garyamort at gmail.com> wrote:

> On 3/7/2011 2:41 PM, Paul A Houle wrote:
>
>>  On 3/5/2011 1:27 PM, Gary Mort wrote:
>>
>>> I am no longer convinced that the cpu cycles saved by using a numeric id
>>> are sufficient to justify doing so with todays computers.  By the time you
>>> get to an app that is sizable enough to be looking to shave those few
>>> microseconds, your going to be dealing with a large number of ways to save
>>> space....and your likely going to want to stick the user mapping data into a
>>> cache in memory somewhere anyway, so the time saved is not that big of a
>>> deal.
>>>
>>>     It's not cpu cycles that matter here,  but I/O bandwidth,  seek time,
>>  and RAM for cache on your  database server.  Although MySQL in an
>> impressive product,  it's remarkably easy to put enough data into a database
>> that you'll have performance problems,  particularly if you're importing
>> data from public sources or if you develop a successful community site.
>>
>
>
> I highly doubt that unless you are Facebook, Google, or Amazon that you can
> put enough "user records" into your database for this to matter.  Note, I am
> specifically referring to the user table - not any other bit of data but
> where you need to identify a user uniquely.
>
> I see no point in placing the added burden of using integer identifiers for
> userids on all applications in order to accomodate "but what if someone has
> hundreds of thousands of users or more!" - if they have hundreds of
> thousands of users, they can afford customizing - why should everyone else
> pay for those few people's convenience?
>
> What do I mean by "pay"?
>
> Take any mysql application used by a mom and pop store.   For whatever
> reason, there is no canned report to retrieve some aspect of data from a
> table[could be the order table, could be the payment table, or here is one
> that often occurs, the SHOPPING cart table to see how many abandoned
> shopping carts there are].
>
> There are a plethora of tools that the owner of the data can use to view
> the data, Navicat, PHPMyAdmin, export it to CSV and look in excel, etc.
> And the data tends to be very nicely laid out so it the primary bits are
> understandable.....and then you come to "what actual person did this?" - and
> it all breaks down.  Sitting there is some number....  Now suddenly from
> viewing an individual table[which is easy] the person needs to join and link
> the data to another table.   So he has to pay a programmer everytime he
> wants a report to figure out these linkages.
>
> So all the little websites of the world pay a premium just so that open
> source applications can say their "scalable" and that the few big businesses
> which could have afforded to pay to tune the system don't have to.
>
> That to me is a poor business decision.  Making many other people pay so
> that your code can be "scalable" and "good coding practices" and "well
> engineered" is not the sign of a good coder - it's the sign of an artistic
> one.
>
> So, what happens if you do it the other way around?  What if you put the
> users name in every one of those records and used that as the key?
>
> Well, performance for those little sites doesn't take any significant hit.
>  On the rare occassion that someone wants to change their name, you do have
> to either go and change it in every existing table - or you have to maintain
> some sort of history table that you can link through so the program can say:
> This order was placed on December 15th at 2:00pm and at that time, the
> userid garyamort referred to the user who is garyamort today.
>
> Again, for the mom and pop's of the world, take the hit and update it in
> all tables.
>
> It's a different paradigm.  Throwing "art" out the window and replacing it
> by practicality.  Of course, it also means "know your market".  If you are
> coding a specific app for a specific person who is planning on growing
> exponentially, then designing something for him which has to be changed
> later is a poor choice.  But if your making an app for tens of thousands of
> people to use - make simplicity for the end user the driving force.   Do
> stupid ass things that would never scale....and then note what they are and
> how you change it[if you scale past 10,000 users convert all usernames to
> integer keys and always use the aliases table.... here is the high level
> overview on how to do it.  if your not a coder, make it your business model
> to be able to afford to pay for a coder when you reach that point.]
>
> The key point, for me, is it should not be so difficult for me to change an
> application so email addresses can be used instead of usernames.  Or to make
> it possible for multiple usernames to use the same email address.  Or to
> change the rules on usernames to allow different charectors.   And truely,
> it is easy to make that change for the one bit of core code....it's tracking
> down all those other bits of code that worked on the assumption of those
> rules...merely because those where the rules....that I find troublesome....
>   and it bothers me greatly to charge for this coding time because I am
> basically fixing the mistaken design decisions made by people who are
> applying rules by rote.  "Always use an auto-incrementing primary id"
>
>
>
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation
>



-- 
Regards,
Andy Pearson

Grafixwerks Design
Where technology and creativity meet
www.grafixwerks.com

andy at grafixwerks.com
office: 718-874-6381
mobile: 347-743-0716

http://www.linkedin.com/in/grafixwerks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110308/fbe18d0d/attachment.html>