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
