utexas_pjm

Your question is a tad ambiguous. Let's try this qualifier: A state can have zero cities. However, for a city to exist it must be in a state. (Which, if we generalize state to mean nation is mostly true in the real world... maybe with the exception of The Vatican?) Perhaps I was unclear, I said: A state which may have 0 - n cities (read: between zero and n cities) constitutes a classic 1 to many relationship. Think of the state as the "1" and the city as the "many". A 1 to many relationship can be sufficiently represented by two tables and a foreign key. The use of a mapping table, as you've suggested, is only necessary when you are dealing with a many to many relationship. For example this construct would be useful if we could have the case where a city A could exist in both State 1 and State 2. Unfortunately this is not the case in the example I outlined above. Yes, as they should be. Thank you for taking the time to read my post. I apologize for any ambiguities in my original post. If you feel that I am missing the point that you were trying to get across (which is always possible) please let me know. Best, Patrick

Thanks for taking the time to read my post and posting a reply. My goal is to not make any assumptions about how the object (city in this case) will be used. Caching is always an option but that to me is an implementation detail, much like my reference hack, whereas I'm looking for a more general solution. Thanks again, Patrick

I run into this situation quite often: I have two objects which exhibit a "has a" relationship. To demonstrate this consider the following trivial example involving cities and states. In this example let us assume that all cities have a state and all states have 0 - n cities. So I store these hypothetical entites in two relational db tables, cities and states, like so: cities { city_id, city_name, state_id, ... a bunch of other relevant city attributes } states { state_id, state_name, ... a bunch of other relevant state attributes } Once I have my persistence layer defined I create a mapping layer which converts objects into db relations (for storage) and db relations into objects (for display). I typically create mapping classes (which I call object-relational mappers or ORMs) for each entity. An ORM for cities might look something like this: <?php class Orm_City { /** * Load an array containing all cities from persistence. * * @return array <Entity_City> */ public static function loadAllCities() { $allCities = array (); $rs = Db_Facade::query('SELECT * FROM cities'); /* Iterate over result set row by row and map relational data to objects */ foreach($rs as $row){ /* Push resulting object on to return array */ $allCities[] = Orm_City::bindAttrbiutes($row); } return $allCities; } /** * Bind data from relational columns to object attributes. * * @return Entity_City */ public static function bindAttributes($row) { $city = new Entity_City(); $city->setCityId($row['city_id']); $city->setCityName($row['city_name']); $city->setStateId($row['state_id']); // ... etc ... return $city; } } ?> You can see from the above code that I am binding only from the city table. This means (presumably) that my Entity_City object must contain a method like this: <?php class Entity_City { // ... public function getState() { return Orm_State::loadById($this->_stateId); } // ... } ?> So every time I want to access to the city's state an additional query is run behind the scenes in the state's ORM class. This becomes terribly inefficient when a collection of cities state's need to be accessed (I end up making n + 1 queries where n is the number of cities). This also, IMO, negates one of the nice properties of relational databases, the ability to join two (or more) relations and yield a composite relation. This observation leads me to the approach below... Let's rewrite the city's ORM from above like this: <?php class Orm_City { /** * Load an array containing all cities from persistence. * * @return array <Entity_City> */ public static function loadAllCities() { $allCities = array (); $rs = Db_Facade::query('SELECT * FROM cities INNER JOIN states USING (state_id)'); /* Iterate over result set row by row and map relational data to objects */ foreach($rs as $row){ /* Push resulting object on to return array */ $allCities[] = Orm_City::bindAttrbiutes($row); } return $allCities; } /** * Bind data from relational columns to object attributes. * * @return Entity_City */ public static function bindAttributes($row) { $city = new Entity_City(); $city->setCityId($row['city_id']); $city->setCityName($row['city_name']); $city->setStateId($row['state_id']); $city->setState(Orm_State::bindAttributes($row)); // ... etc ... return $city; } } ?> Notice that I have now joined the city and state tables on state_id, my City_Entity also now has an implied setState(Entity_State $state) method which takes a Entity_State produced by the Orm_State::bindAttributes() method. <?php class Entity_City { // ... public function setState(Entity_State $state) { $this->_state = $state; } public function getState() { return $this->_state; } // ... } ?> This approach is clearly more efficient in terms of database queries, however I'm now lugging around an extra Entity_State instance with each Entity_City instance regardless of whether this data is ever accessed or not. The overhead is rather trivial in this case, but imagine the consequences with an object which is composed of 10 or more other instances. Just wanted to see how some of you guys would tackle this. I usually implement the latter approach and then feel dirty about it and try to minimize the memory overhead by using references between the related objects. I'm hoping someone might suggest an approach that will allow me to have my cake and eat it too. Best, Patrick

Are you asking if someone has created a database which anonymous users can connect to (presumably via an open port) and query? If you are, I would venture to say that the answer is no. I would think that the security liability alone would be enough to bar any attempt at such a setup. On top of that there is the fact that servers, bandwidth, and administration come at a price and I don't see a practical way to monetize such a setup in order to offset these expenses. The closest things I've seen to what you've described are web services. In the web service model there is a layer of code and some markup language between the client and the persistence layer (RDBMS), ala: http://code.google.com/apis/soapsearch/reference.html. Best, Patrick

Yes, their order of evaluation (precedences) differ.

PHP Also supports *nix shell style comments: <?php # less is more... $less = $more; ?> http://us.php.net/manual/en/language.basic-syntax.comments.php Best, Patrick

Touche' :-p You're right. In loosely typed language such as PHP the usefulness of interfaces is not as apparent as they as it may be in a strongly typed language. It is often the case that interfaces are used to solidify a design. However, implementing a common interface in PHP allows you to do things with type hinting like: <?php $db1 = new MySql(); $db2 = new MsSql(); doSomethingWithDatabase($db1); doSomethingWithDatabase($db2); function doSomethingWithDatabase(Database $db) { // do something } ?>

Interfaces are all about "encapsulation". They allow developers to be less concerned with the actual implementation of classes and shift their focus to the intended design. Let's consider a somewhat practical database example. Imagine that we've decided that our trivial database layer should have a query method and a connect method. Let's also say that we want to add support for multiple relational database managers (RDBMS) i.e., MySQL, MSSQL, SQLite, etc. We can start by conceptually defining the behavior of our database layer in an interface: <?php interface Database { public function connect($host, $db, $un, $pw); public function query($sql); } ?> We might then create a MySQL class which implements our Database interface. <?php class MySQL implements Database { public function connect($host, $db, $un, $pw) { // MySQL specific implementation } public function query($sql) { // MySQL specific implementation } } ?> In our client code we can make calls to the Database interface without knowing (or caring for that matter) how the code is being implemented, as long as the behaviors defined by the interface are being implemented. Since the Database interface is defined we can very easily create an MSSQL class which implements and the interface and substitute it for the MySQL class and not have to change any client code. I hope this was of some help. You can see an example of this in a PHP open source project I'm involved with: http://junction.googlecode.com/svn/trunk/Junction/Db/. We allow seamless switching between PDO and ADODB DB abstraction layers via the use of interfaces. Best, Patrick

The function(s) will model an FSM but in less abstract terms you'll most likely be constructing a recursive descent parser. There's a pretty good howto (complete with pseduo code) here: http://www.engr.mun.ca/~theo/Misc/exp_parsing.htm, you'll want to focus on the "The classic solution" or "Precedence climbing" sections. If you'd like to see a PHP implementation you can have a look here: http://junction.googlecode.com/svn/trunk/Junction/Expression/. While this particular example does not construct a syntax tree, it could have (and actually used to). Best, Patrick

Here's one possible solution sans regex: <?php $string = '<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/CQzUsTFqtW0"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/CQzUsTFqtW0" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>'; $doc = new DOMDocument(); $doc->loadXml($string); $params = $doc->getElementsByTagName( "param" ); foreach( $params as $param ) { if($param->getAttribute("name") == "movie"){ echo basename($param->getAttribute("value")); } } ?> Best, Patrick

<?php $pattern = '/\(.*\)/'; $replace = ''; $string = 'Abc (123 abc stuff) 1xyz'; echo preg_replace($pattern, $replace, $string) ?> Edit, here's the other one <?php $pattern = '/ID #: [0-9].* /'; $replace = ''; $string = 'ABC ID #: 123456 $123.45'; echo preg_replace($pattern, $replace, $string) ?> Best, Patrick P.S. I think what the previous poster was trying to say is that there is a regex board here where you might get a quicker response.

<?php $timestamp = strtotime( "2007-08-08 09:00:00"); $deltaTimestamp = strtotime("+15 minutes", $timestamp); print date( 'Y-m-d H:i:s', $deltaTimestamp ); ?> http://us2.php.net/strtotime Best, Patrick

The big problem here is that PHP does not support multiple inheritance. i.e., there is no PHP analog to this: class Baz : public Foo, public Bar { }; You might consider introducing a new class OrderedUserItem which extends OrdererdItem. You can then derive classes from OrderedUserItem which require a manual ordering and are related to a user. Best, Patrick

I read somewhere that using single quotes is actually slightly more efficient than using double quotes because when using double quotes the PHP engine must process the string in order to check for, and possibly evaluate, any variables which may be included in the string. I can't personally speak to the validity of this claim, but it does make sense from a theoretical standpoint. I'm quite certain that any performance hit incurred by using double quotes is negligible in most circumstances --but it is something to consider none the less.

I agree. In my experience UML is a strategic tool used in the design phase whereas unit testing is more tactical and used to facilitate implementation. I'm sure there are some agile evangelists who would disagree.