In a new post on his blog Timothy Boronczyk has a recommendation for developers working in PHP with databases that have a "fetch object" method - use it correctly or avoid it all together.

Lately I'm finding a lot of instances of the mysql_fetch_object() function being used in a particular codebase I help maintain. Unfortunately, I've yet to see it used correctly. It always seems to be used to retrieve a stdClass object from a query result where mysql_fetch_array() or mysql_fetch_assoc() would be the more appropriate choice.

Most of his complaint is that, despite pulling out the data as an object, most scripts continue to use it like you would an array, looping over it. There's extra overhead generated from the object creation that could cause issues, especially with large return data sets.

The best advice I can offer is to educate yourself and others how the function should be used so its abuse isn't perpetuated. Then, be cautious when using mysql_fetch_object() correctly and understand the process it follows to create and return an object. If not for yourself, then do it for the kittens.

Dan Horrigan has a new post to his blog talking about the value of null - a quick summary about when and where null should be used. Null's a value too, after all...

Let me start off by saying this article is about PHP and PHP alone. Other languages handle this sort of thing differently (and better). In PHP many people (and a few frameworks) return FALSE from methods when the requested value does not exist. However, I am here to tell you that if you do this, you are doing it wrong. Plain and Simple.

In his opinion, "false" is definitely not the same thing as "null" because "null" is technically the absence of a value, not a "not true" value like "false" is. He illustrates with a simple use case of a class that has methods returning various values.

On the CodeForest site there's a recent tutorial that offers a different option for those dealing with an application that has the possibility for rapid change in its database structure - a key/value table in a standard relational database (no, not NoSQL).

Key/value approach in database design could come in handy when we need to store some arbitrary data about another table. For example, we have a users table that holds our user data. Everything is working fine, but some day our client decides that he wants to collect 2 telephone numbers, sex of the user, date of birth... If we try to predefine all the potential wishes of the customer in our table, it would be awkward and our table would grow horizontally beyond reason.

He compares the traditional "users" table with each column a defined type of data against a key/value table where each record holds both the value and a key relating to its contents. While this technique can be flexible, it can also be abused if it gets out of control. Bill Karwin warns in the comments about it and links to two resources on its use.

Chris Roane has a new post to his blog asking an interesting question - should PHP programmers/developers spend the time to go to college?

A common debate in our field is whether or not a college education is worth it when becoming a PHP programmer. People will throw statistics in how much more money you can make with a college degree. But is the cost of college (time + tuition) for a four year degree better than the benefits of having four years of experience in the web programming field?

He qualifies it with the fact that not all college educations are created equal and that it depends on the student as to what they get out of it. He breaks it up into a few different sections with reasoning in each:

• The Benefits of Going to College
• The Cost of Going to College
• The Benefits of a PHP Programmer Not Going to College
• The Negative Aspects of a PHP Programmer Skipping College

On his MontanaProgrammer.com blog Chris Roane looks at the value of a PHP programmer and what you might look for when considering which developers could make the most difference.

Over the years I have come across PHP programmers from different backgrounds. I've seen some do very well, and others fall flat on their faces. One unique element about PHP programmers is that they vary in quality more than most other programming professions.

He mentions traits to consider like speed of coding, reliability, experience, humility and be able to accurately estimate time to finish work. He give the example of three different developers - each with their own skills and experience levels and asks which of these might be the best. The trick is, "best" is very subjective to the needs of the company that wants the code written.

A new version of the Rediska library has been released today, version 0.2.1. Rediska is a PHP client for Redia, a key/value database system (written in C) that's similar to memcache.

It can be used like memcached, in front of a traditional database, or on its own thanks to the fact that the in-memory datasets are not volatile but instead persisted on disk. One of the cool features is that you can store not only strings, but lists and sets supporting atomic operations to push/pop elements.

The library includes multiple server support, content hashing, keys as objects and full Zend Framework integration. You can find out more about the project on its site or just download the latest version.

DevShed continues their look at filtering in PHP5 applications with this third part covering checks on boolean values.

As I said before, the filter extension can be used for more than validating integers, since it provides the required functionality to checking other data types. Thus, in the next few lines I'm going to discuss how to use the extension for validating Boolean values.

They give a few lines of example code to show how different values (like "1" versus 1 and "true" versus true) are affected by PHP's dynamic typing.

Davey Shafik has taken a look at return values and keeping them standard when handing them back from the results of a database query.

In #phpc we recently had a discussion about function return values; specifically from database queries. I'm going to go on a (admittedly, rather sturdy looking) limb and say this applies to pretty much any function that returns from a data resource, not just a database .

His personal preference is to return the results data if there's matching information but to return a false value if there is an error/not results were found. He includes a snippet of example code to show the structure he's talking about. Some of the comments on the post mention things like exception handling, other similar methods other developers use and the use of nulls.

In this new post to his blog, Brian Moon compares two things that, on the outside, might seem a lot alike but do have their differences under the hood - a null value and the isset function.

I am working with a newcomer to PHP and he asked me about setting a variable to null and how to check that. He had found some example or information that showed that setting a varaible equal to null would unset the variable. So, he was unclear if he could then reliably check if the variable was equal to null. Having avoided null like the plague in my years of PHP, I was not sure. So, I mocked up a quick script to see what the states of a variable are in relation to null.

His test verified that a variable, set equal to null will be found to be equal to null, will be set (isset) and will be found empty by PHP's empty

Sameer has posted his "easy way" to validate user input coming in over a POST request:

Validating POST data from a form is a common requirement for a developer. If the number of form fields are few than the validation is a small matter. But the case is different when the form contains more than 15 or 20 fields and some of the fields are mandatory. The following code will give you an idea of how to easily validate mandatory fields, whatever the number of fields.

His method prefixes the form fields with a certain string (in his case "c_") and uses that to loop through and act as a hook to check only the form values that were submitted (and nothing else that happens to be in the $_POST array). Any number of checks could be added on to this simple example including type checks, length and validating off of another field - like a password confirm match.