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 <garyam...@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 a...@grafixwerks.com office: 718-874-6381 mobile: 347-743-0716 http://www.linkedin.com/in/grafixwerks
_______________________________________________ New York PHP Users Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/Show-Participation
