In a new post to his site site Joseph Silber shows you how, when using Eloquent in a Laravel application, to decouple your application from your database by removing hard-coded class names on polymorphic relationships.

Polymorphic relations let you set up a relationship between many different model types, without the need for extra tables. This works by storing the "morphable type" (explained below) in the database, in addition to the morphable type's ID.

By default, the morphable type stored in the database is the model's full class name. While this works, it tightly couples your database to your PHP application. Let's look at how we can instruct Eloquent to use more generic values for these morphable types.

He starts in with a "short refresher" on polymorphic relationships and what Eloquent models look like for a simple customer-to-address relationship. He then talks some about the "morph" type and how Eloquent stores the name of the relating model directly in the record (like AppCustomer or AppWarehouse). He shows how to customize the morph type to map the types to values in a morphMap setting to remove the need for those hard-coded class names. He wraps up the post answering the question many ask: "why doesn't Eloquent do this automatically?"

Jeff Madsen has some helpful hints for the Laravel (or just Eloquent) developers out there when it comes to models. In this new post to his Medium site he looks at using custom pivot table models (and choosing the right technique to use them).

Laravel is “opinionated”, but that usually just means that there are a lot of defaults set up that push you toward a certain style. Over the years I have found very few cases where you can’t easily override these; more often than not, it is simply a case of adding another function call when you instantiate something.

As I thought about the way I would normally code around Mark’s problem, and then searched and found the more direct answer from the docs, it occurred to me that this was a perfect example.

He starts with the more "standard" way of working with pivot tables in Laravel (code example include) using the updateExistingPivot method. He talks about the difference between writing the code and designing the code, making it more maintainable and well-architected. He talks about moving the logic into a service class but points out a few issues with that approach as well. Finally, in his last option, he covers the special "Pivot" model included with Eloquent and shows it in use.

Paul Jones has a post to his site looking at SQL schema naming conventions and some of his own thoughts on the matter. There's a lot of different camps of thought around naming, much less database ones, and he makes a few suggestions learned from his experience over time.

Several weeks ago I asked on Twitter for SQL schema naming conventions from DBA professionals. (I’m always interested in the generally-accepted practices of related professions; when I can, I try to make my work as compatible with theirs as possible.)

I got back only a handful of responses, representing MySQL, PostgreSQL, and DB2 administrators, really not enough for a statistically useful sample. Even so, I’m going to present their anonymized responses here, because they led me to work I had not previously considered at length.

He asked about things like singular vs plural names, primary key choices and naming of association tables. The uses the rest of the post sharing the responses he got from his questions with a good range of responses representing both sides of each question. He wraps up the post looking at what these answers mean to the average developer and the answers that Joe Celko and Simon Holywell have to say on the matter.

In a post to the Knp University blog they show you some of the fun you can have with the Symfony Console component in a single file including a few lesser known (and lesser used) features.

One of the best parts of using Symfony's Console component is all the output control you have to the CLI: colors, tables, progress bars etc. Usually, you create a command to do this. But what you may not know is that you can get to all this goodness in a single, flat PHP file.

They walk you through the creation of a ConsoleOutput object with a simple writeln output of a formatted method. They briefly mention the handling for changing up the output (OutputFormatter and OutputFormatterStyle) before getting into something a bit more complex - table layouts. They end the post with an interesting "hidden" feature inside the component, the Symfony track progress bar (animated gif included to show the end result).

If you've ever worked with the Symfony Console component and wanted to enhance the experience with some additional functionality, check out the latest tutorial from the SitePoint PHP blog: Symfony2 Console: Getting Started with Console Helpers.

In this tutorial, I’ll share my experiences and we’ll give some extra love to the console helpers, which provide us with a large collection of handy functions. There are a lot of reasons to create console commands in your projects: sending emails, exporting/importing data, creating users, and so on. [...] By the end of this post, we want to be able to create a basic console command to generate some output – any output will do – only the way to getting there is important. Near the end, we’ll discover some console helpers in order to create some nice interactions between users and the interface.

He starts by helping you get the component installed via Composer and creating the first simple command line script (a ConsoleApplication). He shows how to add in a basic "hello world" command (conveniently named "BasicCommand") and the result when executed. With this in place, he starts in on three helpers:

• Question Helper
• Table class
• Progress Bar

Each includes the code needed to implement it and the resulting output. You can find out more about the component in the Symfony2 documentation.

On NetTuts.com there's a new post for those new to WordPress (or just wanting to figure out more about the internals of the tool) showing how some of the data is structured and how to work with it.

Most WordPress users never come into direct contact with the database and may not even be aware that it's constantly working to populate their site. When WordPress serves up any kind of page, be that the home page, a single post or page or an archive, it's accessing the database to bring up content that editors and administrators have added to the site. In this series of tutorials I'll look in detail at different aspects of the WordPress database.

This post is the first in the series and provides an overview of the database and what kinds of information each one contains. They talk about content types and provide the table structure and relations in a handy graphical form (an ERD). They then go through each of the tables and describe what the data is including link tables, joining the content in different places.

In a new post to his blog Lee Davis describes the enum conundrum - what's the right solution for effectively using ENUM-type fields in your data?

So a user signs up and I want to store a status that reflects their account, or at least an identifier representing that status. Their account could be active, disabled (temporarily), pending approval or maybe deleted. Should I use an enum? I’ve heard they’re evil. Maybe having a reference table with statuses would be better? But now I have to manage a separate table just for that one snippet of data, is that overkill? Could I maybe use that status table for other entities? Or, could I instead just use an integer and reference it on the code level? What is the right solution?

He presents three of the most common situations he's seen for people using enums in the application:

• "I used enums all over the place" (maintenance between code and DB values)
• "use a reference table"
• "I could use a class constant to represent the enum" (enforced in the app)

Of the three, he suggests the third as the option with the most advantages. Not only does it make it simpler to get the allowed values for the field, but you're also more flexible in the kinds of validation you can do on the values.

Gonzalo Ayuso has followed up his previous post about creating a simple SQL wrapper with PDO in PHP with this new post, a "part two" looking at improving it a bit with a new class to represent the tables.

In one of our last post we built a simple SQL wrapper with PHP. Now we are going to improve it a little bit. We area going to use a class Table instead of the table name. Why? Simple. We want to create triggers. OK we can create triggers directly in the database but sometimes our triggers need to perform operations outside the database, such as call a REST webservice, filesystem’s logs or things like that.

He includes the updated code with the new "Table" class with methods that let you set up pre- and post-action hooks on each of the types (insert, delete, update) along with the rest of the library, there ready for the copy & pasting.

On the Liip blog there's a recent post looking at table inheritance with Doctrine, the popular PHP ORM tool. In the post, Daniel Barsotti talks about a database model that needed some updating due to their searching needs.

Our first idea, and it was not that bad, Drupal does just the same, was to have a database table with the common fields, a field containing the type of item (it's either an event or a blog post) and a data field where we serialized the corresponding PHP object. This approach was ok until we had to filter or search LabLog items based on fields that were contained in the serialized data.

To resolve the issue they turned to multiple table inheritance, relating the LabLogItem to both a BlogPost and Event. They also show how it could be modeled with a single table, but opt for the multiple method. Included in the post is the Doctrine-based code showing how to create the parent entity for the LabLogItem and the two child entities for the blog post and event. There's also a brief snippet showing how to use them with the EntityManager.

Rob Allen has a tip for the Zend Framework users out there using the Zend_Db module to connect to their database resources - how to do a one to many join with the help of Zend_Db_Table_Select (easier than it sounds).

Let's say that you want to set up a one-to-many relationship between two tables: Artists and Albums because you've refactored my ZF1 tutorial. [...] Assuming you're using Zend_Db_Table, the easiest way is to turn off the integrity check and do a join in a mapper or table method.

He includes a few lines of source to illustrate, calling the "setIntegrityCheck" value to "false" to tell ZF not to worry about the additional join value over to the artists table. The result is a new column value with the artist's name instead of just the ID.