Sameer Borate has a new post to his site that shares how he converted a RETS database to MySQL with the help of a PHP library, PHPRETS.

A recent project of mine entailed replicating a RETS database on a local MySQL database server. The client had a new real-estate mobile search app in development and wanted to have a local copy of the RETS database for search queries instead of a remote RETS server. [...] Replicating RETS data rather than using the live version is slightly complex, however. In order to replicate the RETS data into your own local database, a series of processes are needed in order to make sure the data you have is both updated and in sync with the server.

He breaks it down into three main steps with some sample code for each:

• Grabbing the complete database once
• Keeping the data in sync
• Ensuring the cron job is executed on regular intervals

On Mike Dalisay's site there's a recent post showing how to use the Phpass tool to salt, hash and store passowrd data in your application.

I think the main reason why we have to hash passwords is to prevent passwords from being stolen or compromised. You see, even if someone steal your database, they will never read your actual or cleartext password. I know that some PHP frameworks or CMS already provide this functionality, but I believe that it is important for us to know how its implementation can be made.

His sample application stores the user data in a MySQL database and does the salting+hashing at the time of the request. It uses a hard-coded salt and a value of 8 for the hashing/stretching. Screenshots of each page in the example application are also included.

On PHPBuilder.com today there's a quick tutorial showing you how to build an RSS aggregator that can pull in RSS content and drop it into a MySQL table.

RSS stands for Really Simple Syndication. It is a Web format that allows website owners to distribute their latest and frequently updated content in a standardized way. RSS feed is actually an XML document that can be easily read by using RSS reader software or built-in functions in programming languages, such as PHP or Java. In this article, the focus will be on building a RSS aggregator in PHP.

They introduce the basics of an RSS feed - a specially formatted XML document with values for individual posts (like "title" and "link". They provide the SQL structure for the "article" and "feed" tables and the code to pull out each "feed" record, parse it and drop that into the "article" table for later consumption. They show two different methods for getting the content - one using file_get_contents and another using cURL.

On the "Learn Computer" site there's a recent post that wonders if the web development standard of the LAMP (Linux, Apache, MySQL and PHP) stack is "still strong" and will still stand up with new technologies.

This year in tech (like almost every other year) has been filled with buzzwords. Many of them this year, however, are based around big data processing and web content: NoSQL, Hadoop, BigTable - the list goes on. With all the fuss around these new technologies, one might be tempted into thinking that these are the technologies of the future, and that from now on our servers and websites will be built upon, leaving technologies like LAMP in the dust.

They talk about some of the things the LAMP stack doesn't do well like difficulties with scalability on both the web server and database side. There's also mention of the things that it does do well, like getting things up and running quickly and with a solid structure.

That being the case, the LAMP stack is still going very strong, and it's definitely still extremely viable in small and medium-sized deployments; there are no signs of it waning in that regard, and I'd expect it to be a standard deployment for many companies and organizations for quite some time to come.

PHPMaster.com has posted the second part of their "avoid the original MySQL extension" tutorial series (part one is here). In this new part, they share more about another alternative - the PDO extension.

The PDO extension supports twelve drivers, enabling it to connect to a variety of relational databases without the developer having to learn a number of different APIs. It does this by abstracting the database interaction calls behind a common interface, enabling the developer to utilize a consistent interface for different databases. This of course gives it a major advantage over both the MySQL and MySQLi extensions who are limited to only one database.

Included in the post are examples of some of the basics - connecting, executing queries, getting the results - as well as more compelx things like binding parameters and transaction support. There's also a bit about changing the default behavior of the PDO object through config options. He finishes off the article talking some about some of the issues that could come from using an abstraction layer like this and the need to still write good, compatible SQL depending on the database.

On PHPMaster.com today there's a new post, the first in a series, about avoiding the original MySQL extension in favor of what mysqli has to offer. The cover some of the basics of the extension and include code showing its use.

Experienced developers eschew the original MySQL extension because of its abandoned status in PHP. Nascent web developers, however, may be completely oblivious to its dormant past and dying future. [...] It is therefore the intention of this two-part article to raise awareness among developers who still use the MySQL extension, inform them of its problems, and to help them switch over to an alternative extension.

They start with a brief look at the "what's wrong" with the MySQL extension (including its upcoming deprecation). The article then gets into the basics of MySQLi and how to do things like make a connection and run a few queries. There's also a bit about prepared statements and the built-in ability to do "multi-queries" (complete with rollbacks).

On PHPClasses.org today they've posted the latest episode of their "Lately in PHP" podcast, Episode #32, "Zend Optimizer+ Cache in PHP 5.5 and MySQL 5.6 Performance Improvements".

MySQL 5.6 speed improvements and how it affects PHP applications was one of the main topics discussed by Manuel Lemos and Ernani Joppert on the episode 32 of the Lately in PHP podcast. They also commented on the eventual adoption of the Zend Optimizer+ as the PHP code caching extension that may be shipping with PHP 5.5 as alternative to APC, the implications of this to the PHP community.

They also talk some about the switch of OpenSuSE/Fedora Linux to MariaDB MySQL, TDD in the Zurmo PHP Open Source CRM and using HTML5 animations. You can listen to this latest episode either through the in-page player, by downloading the mp3 directly or watch the video of the recording on YouTbue.

PHPClasses.org has released their latest episode of their "Lately in PHP" podcast series. This episode (#31) talks some about some of the changes happening in versions in PHP in the upcoming months.

As PHP 5.5 is getting ready to be released in the next months, the end of line for PHP 5.3 is being planned, while the original MySQL extension is being deprecated in PHP 5.5 to be killed in a later version.

You can listen to this latest episode either through the in-page player, by downloading the mp3 or you can watch the video of the recorded Google Hangout of the taping.

Andrew Podner has a new post for those wanting to find out more about the Lithium framework and using models to work with your database.

Today I want to provide a tutorial on how to do some basic interaction with a database in Lithium, and I am going to rely on MySQL as a database for the purposes of this tutorial, although you have other options like MongoDB, as an example.

His example script uses the idea of "blog posts" stored in a MySQL table and code snippets are included showing how to:

• Create the model class based off of the core Lithium one
• Select all of the records from the table
• Filter down the returned values with "magic finder" methods (like "findAllByStatus")

You can find out more about the framework in the project's documentation section of their site.

On the Websanova.com site there's a recent post about doing timezones the right way when working with them in PHP and storing them in your (MySQL) database.

Timezones are actually a very trivial concept but they seem to be overlooked and over complicated. [...] Rather than storing a timezone with each date it's better to just accept a standard time to store all your dates with, thus doing the conversion to that standard time before storing the value in the database. It doesn't really matter what time we store it as, but it's generally a good idea to just use UTC+00:00.

They talk a little about what the UTC timezone is for those that may not know and show how to set it as the default timezone for your PHP application (with date_default_timezone_set or updating your php.ini). They also include the MySQL configuration option to set its default timezone and and example SELECT statement for extracting the data back out.