More popular online shopping sites get orders of around 4 per second at peak times. IE Christmas. 2008/9/14 Tom Shaw <php.coder@xxxxxxxxx> > That's cool thanks. I agree with you too it's mankind's folly. But > regarding > the db question, I got the idea from CakePHP which solves the problem of > having to prefix your columns ie user_name etc etc. I think you can use > another built in php database function num_fields() and hook into the meta > data and then you would have to manually build the information into array. > I'm not sure but I'm going to hack around with it a little and see what > happens. > > Thanks Thomas > > -----Original Message----- > From: Jochem Maas [mailto:jochem@xxxxxxxxxxxxx] > Sent: Sunday, September 14, 2008 4:50 AM > To: Tom Shaw > Cc: 'PHP General' > Subject: Re: 2 Questions. > > Tom Shaw schreef: > > -----Original Message----- > > From: Tom Shaw [mailto:php.coder@xxxxxxxxx] > > Sent: Saturday, September 13, 2008 9:52 PM > > To: 'Jochem Maas' > > Subject: RE: 2 Questions. > > > > iamjochem wrote: > > > >>> My second question is I've designed a very simple Postgres database > >> wrapper. > >>> The methods are exactly what you would assume to see in any db wrapper > a > >>> pg_query, pg_fetch_array. My question is in the db wrapper, is there an > >> easy > >>> way to always include the table name as an index in all my > pg_fetch_array > >>> returned results? The reason I ask is when designing my tables I'm > >> delegated > >>> to prefixing my column names i.e. users_name instead of just name or > >>> forum_posts instead of just posts to make sure there's no collision. > >>> > >> have your simple wrapper do something like: > >> > >> $sql = "SELECT foo AS {$tablename}_foo FROM {$tablename} WHERE 1"; > >> > >> with regard to generating the query. if your wrapper doesn't generate > the > >> SQL then you'll have to parse the given SQL and rewrite it ... good luck > >> with that. > > > > I'm not sure if my wrapper is a good place for the sql but I bet it's > worth > > investigating further. I like the web site iamjokem. Im not sure if > that's > a > > jokem too but I couldn't figure it out... > > it's jochem not jokem, so technically there's no joke. but you could say > the > 'site' > is my answer to the social grid. or maybe a reaction to all the twitter > like > nonsense, > or maybe just the fact that everyone seems to think the answer is out > there, > when really the only answer is 'in here' > > take the red pill/door. it's the only choice ;-) > > ...... > > generating SQL is pretty easy, give a function a list of fields as an array > and a > table name (you can then build the function out to include order by and > where clause > generation. here is a very simple concept function (I wouldn't bother using > it > as is): > > function genSQL($fields, $table, $where, $order) > { > $fnames = array(); > foreach ($fields as $f) > $fnames[] = $tablename.'_'.$f; > > return 'SELECT '.join(', ', $fnames)." FROM $tablename $where > $order"; > } > > > >> I should have mentioned that I use a *normalized* database wharehousing > >> pattern where each row represents a distinct item being purchased. There > >> could be fifty rows corresponding to a single order transaction like > what > >> you would see in something like an itunes music purchase. So using the > > auto > >> increment id would not work to differentiate between orders. Another > user > >> mentioned microtime. > > > > whoa, race car hey? let's have a race. > > > > normalized smormalized. every order related system I've looked at, built > or > > worked with made a clear distinction between an **order** and an > > **orderline**, > > all you seem to have is an order line ... who do they belong to? are you > > replicating the customer details and shipping address in each row? (if so > > I hardly call that normalized) > > > > use generators or sequences or 'auto increment ids' or whatever your DB > > calls > > it, dump the timestamp/microtime nonsense, and rework you DB schema to > > incorporate order **and** orderline entities ... and use a required > foreign > > key > > in each orderline to reference the relevant order. > > > > with regard to iTunes store, steve jobs can go shove it ... but I'll > wadger > > my soul that the guys that built it know the difference between an order > > and an order line and that they use both concepts. > > > so you understand your DB model was wrong/incomplete? and that timestamps > of any granularity should not be used as UIDs? > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Luke Slater
