On the TutsPlus.com site they've posted a tutorial for those new to PHP and MySQL out there sharing the basics of CRUD operations using the built-in language functionality ("CRUD" stands for "Create, Read, Update, Delete").

In this article, we're going to explore how you could use a MySQL database to perform CRUD (create, read, update, and delete) operations with PHP. If you want to get your hands dirty with database connectivity in PHP, this article is a great starting point.

If you are just getting started with PHP, you probably realize that database connectivity is an essential feature that you'll need to get familiar with sooner or later. In most cases, a database is the backbone of any web application and holds the data of the application. So, as a PHP developer, you'll need to know how to deal with database operations.

In this article, we'll keep things simple and explore how to use the core mysqli functions. In upcoming articles of this series, we'll explore a couple of other ways to handle database connectivity.

They then walk you through some of the basics of:

• creating the connection to the database
• selecting information from the database
• inserting and updating records
• how to pull the record information
• deleting records from the database tables

Each item on the list comes with plenty of explanation and example code to get you on the right path to learn these basic concepts.

In a new post to his site Frederick Vanbrabant tackles the integration operation segregation principle. While the term sounds intimidating, it's just a long way to say something you probably already do: refactor code into smaller testable chunks.

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and me were discussing some code that we refactored earlier . Not so long in the conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim.

Now I’m going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

He starts with some simple code for a "calculator" class with a calculate method to handle the pricing of a rental car. He includes the test for the class/method as well, using a mock object and several expects calls to handle the method calls. The test ends up being larger than is probably good, so he looks into refactoring the original code to abstract out some of the functionality and make it more testable. In the process this also makes the code easier to follow and, while there is more of it, more maintainable and flexible in the end.

On the Twilio blog they've posted an article from Matt Stauffer looking at the combination of Google Sheets and PHP to perform some of the normal CRUD (create, read, update, delete) operations via the Google Sheets API.

Have you ever needed to pull some data from a Google Spreadsheet? My default in the past would be to export the data and upload it to the app directly, but it turns out it’s not very difficult to read directly from Google Spreadsheets using the Google Drive API.

In this tutorial, we’ll read, write, update, and delete data from a Google Spreadsheet with just a few lines of PHP.

He clones an example spreadsheet to use in the tutorial and shows how to prepare it for programatic access (basically exposing it for use). He then gets to work using the google/apiclient and asimlqt/php-google-spreadsheet-client packages to connect to and work with the API. He includes the code to:

• connect to the API and get a usable token
• pull data from the sheet by title
• update individual cells data
• updating entire rows
• deleting rows
• insert new rows

You'll need to be a bit familiar with how the Google API Console works to get things set up, but there's an animation that helps walk you through some of it.

The SitePoint PHP blog has posted a new tutorial focusing on the Atlas ORM, a recent addition to the wide range of database ORMs in the PHP ecosystem, focusing on being a mapping of your persistence model.

By definition, a Data Mapper moves data between objects and a database and isolates them from one another. With a Data Mapper, the in memory objects don’t even need to know that a database exists. It does not need to know the SQL interface or database schema; it doesn’t even need the domain layer to know it exists!

This might lead us to thinking that, in Atlas, the persistence layer is totally disconnected from the database, but that is not quite what happens. [...] An Atlas Record is passive; not an active record. Unlike most ORMs, its objects represent the persistence model, not the domain model. Think of it as representing how the data is stored and not as real world representations.

The tutorial goes on to talk about some of the background behind the package being developed and some of its core principles. They then walk you through the installation of the package, doing a bit of related database setup and the code to perform some basic CRUD (create, read, update, delete) operations on the tables. This is followed by a few more practical examples and a few caveats for the library's use.

In a recent post Freek Lijten shares a simplified version of a solution he came up with to separate models and their logic between the fetch and save operations.

Basically I am wondering how storing data and retrieving data are different and how you should / could model this. Since we need different information while storing and retrieving information it makes sense to model those actions in different ways. The how is still bothering me and in this post I give a possible solution. I truly hope I can get some reactions and thoughts of other people in on how they would solve these kind of problems.

He introduces the basic structure of the application he's working with and how the concept of "documents" ties in. Then he gets into the problem: the differences in data required for the save versus locate and load. His solution is to split out the different pieces (relations) of the document into separate value objects. These objects then only contain the handling to get only the relations needed on the load. He doesn't like the solution, however, because of the amount of overhead it introduces.

Brian Swan continues his look at using the oData data feeds from PHP with this new look at creating some of the basic CRUD (create, read, update, delete) operations via the oData SDK for PHP.

This week I will go one step farther and look at how to perform CREATE, UPDATE, and DELETE operations (CRUD operations) with the generated classes. Of course, this means that I need access to a read-write service, so before writing PHP code for CRUD operations, I’ll walk you through the steps for creating a service that implements the OData protocol.

He shows how to create the oData service (with a few screenshots), making the proxy classes for the connection and using methods like "AddObject", "UpdateObject" and "DeleteObject" to work directly with the data feed.

In a new post to his blog Abhinav Singh shows you how to create a simple application that uses the memcached atomic increment command to help prevent concurrency issues.

Memcached provide atomic increment and decrement commands to manipulate integer (key,value) pairs. However special care should be taken to ensure application performance and possible race conditions while using memcached. In this blog post, I will first build a facebook style "like" application using atomic increment command of memcached. Also, I will discuss various technical difficulty one would face while ensuring atomicity in this application. Finally, I will demo how to ensure atomicity over a requested process using custom locks in memcached.

Example code is included to show how you can take a normal "store to memcached" example and modify it with the increment method to resolve issues that might come up from one or more scripts trying to get at the same values. He also includes an example of using locking to provide a similar effect.

IBM developerWorks has this new tutorial they recently posted looking at making a semantic CRUD (create, read, update, delete) application that uses MySQL and SPARQL.

Create, Read, Update, and Delete (CRUD) operations are the most basic database operations, but they are also the most crucial. CRUD operations are typically done using the Structured Query Language (SQL) on relational database systems. As the Web is becoming more and more data-oriented, there is a need to shift from SQL-based CRUD operations to semantic Web-based CRUD operations. Learn how to use PHP to perform CRUD operations over the semantic Web.

They include the SQL code for both sides (MySQL/SPARQL) on each of the CRUD steps. They take these and show how to plug them in to a PHP SQL call and briefly mention abstraction and a few reasons why you might want to move to SPARQL.