You may have been using relational databases in your PHP applications for a long time (PHP loves MySQL after all) but you might not have ever dug deep enough to understand how those databases work internally. In this detailed tutorial from Coding Geek they dive way in and cover everything from the basics out to complex sorting, management components and query handling.

When it comes to relational databases, I can’t help thinking that something is missing. They’re used everywhere. [...] you can google by yourself “how does a relational database work” to see how few results there are. [...] Are relational databases too old and too boring to be explained outside of university courses, research papers and books?

As a developer, I HATE using something I don’t understand. And, if databases have been used for 40 years, there must be a reason. [...] Over the years, I’ve spent hundreds of hours to really understand these weird black boxes I use every day. Relational Databases are very interesting because they’re based on useful and reusable concepts. If understanding a database interests you but you’ve never had the time or the will to dig into this wide subject, you should like this article.

He covers a wide range of topics during the post:

• O(1)) vs O(n2) (or how data sets are handled based on size)
• Array, Tree and Hash table
• Global overview (structure of the database system and its pieces)
• Query manager
• Statistics (and optimizing storage of the data)
• Data manager
• Deadlock
• Logging

Each of these topics comes with a lot of explanation, examples of how the internals are functioning as well as diagrams to help make a bit more sense. If you've ever really wanted to know how that database you use functions, this is definitely the article to check out.

In a new post to his blog Ilia Alshanetsky takes a look at PHP's output buffering feature and some interesting things he found when testing some recent code (hint: it has to do with PHP's "interesting" management of the buffer).

While profiling our application I came across a a rather strange memory usage by the ob_start() function. We do use ob_start() quite a bit to defer output of data, which is a common thing in many applications. What was unusual is that 16 calls to ob_start() up chewing through almost 700kb of memory, given that the data being buffered rarely exceeds 1-2kb, this was quite unusual.

Through a bit more testing he found that, if a buffer provided for content isn't enough, PHP automatically bumps it up by 10kb each time - a waste of resources if you only need a small subset of that. He includes a small patch he made to the PHP core API that allows for defining a custom buffer size and, if it's not enough, bumps up the buffer size by 1kb instead of 10kb.

Kevin Schroeder has a quick tip for anyone using phpcloud.com and having trouble with git and "remote end hung up" error messages.

If you are using phpcloud.com and are experiencing errors with git [...] and you are trying to push large files (not sure what is defined as "large") you may need to change some git settings.

He points out two settings - one for Windows and the other for Linux - that increase the buffer size to handle larger files that might be included in your repository.

New from the SitePoint blog, there's an article from Craig Buckler about using buffer flushing to increase the load times of your applications and websites.

Output buffering makes this process quicker and more efficient. The buffer is essentially a big memory-resident string. When text is output, it's appended to the buffer rather than returned to the browser immediately. The buffer is then "flushed", i.e. its contents are transmitted and the string is reset pending further output.

He notes the instances where the buffer would be flushed - end of page, exceeds number of bytes allowed or a manual flush is called - and code snippet example of a simple flushing setup. He also asks for some feedback on this method, so be sure to look at the comments for more thoughts from the community.

In a new post to his blog today Gonzalo Ayuso talks about video streaming and PHP. Well, okay, not so much using PHP for playing the video, more for the security and streaming around the streaming feeds.

For example we want to show videos only to registered users based on our authentication system. Imagine we’re using sessions for validate users. That's means we cannot put the media in a public folder and point our media player to those files. We can obfuscate the file name but it'll remain public. In this small tutorial We're going to see how to implement it with PHP.

Since the video stream he wants to deal with is a live one (and not a single video file that can be read all at once) he shows how to use the output buffering functions in PHP to output small chunks of the data at a time with the correct headers attached.

Brian Moon has a new post to his blog today looking at something it's common for web applications to use, ob_start, and what about HTTP headers makes it work to prevent the infamous "headers already sent" message.

HTTP is the communication protocol that happens between your web server and the user's browser. Without too much detail, this is broken into two pieces of data: headers and the body. The body is the HTML you send. But, before the body is sent, the HTTP headers are sent.

He includes a sample raw HTTP response for a page and how the ob_start function works to buffer the output of the resulting page to save the header information until the buffer is echoed or cleaned out. There is a down side he mentions, though - there's no partial buffering built in so it's an all or nothing short.

Kae Verens has posted a quick tutorial about serving up files by routing them through a "fetch" script, pulling their contents in one side and back out the other.

One thing I need to do while building the multi-user version of webme is to convert it so file references such as /f/photos/an_image.jpg get transparently converted so they serve correctly, even though the actual file may be located somewhere entirely else.

There's two steps involved - rewriting the URL request for the types of files you'd like to pull through the script (using some mod_rewrite magic in Apache) and make the script to do the actual work. Source for that is included too. Not only can something like this help you keep things organized but it also allows for extra security if you need to store the files outside of the webserver's document root.

This new tutorial from DevShed introduces something that could make a pretty profound impact on your application if used correctly - output buffering.

Output control (or output buffering) allows you to write and execute your scripts normally but send data to the web browser at selected times. The main benefit of this system is that you can call the header(), setcookie() and session_start() functions at any place in your scripts without having to worry about the "headers already sent" error message.

They start with the basics - the functions and what they do - then move on to an example, a login form, that uses the buffering to capture errors and html to be flushed and echoed at the end.

Even more good news for mysqlnd users out there - according to this new post on the Internet Super Hero blog, some of the tuning options it enables can help you save 40% of the memory you were using before.

mysqlnd saves memory. It consumes half as much memory as libmysql. This is what we have been convinced of. This is what we taught you. Then I tried to test it and made Andrey get nervous for a few hours… Meanwhile he is fine again and we can announce: mysqlnd saves memory, not only in theory, we tested it - we can proof it, can we?

The proof comes in the form of a few "tricks" and some of the settings that the software can use to optimize buffer sizes. Benchmarks (and the code to run them) are also included to show what the differences are between mysqlnd and libmysql.

Even more good news for mysqlnd users out there - according to this new post on the Internet Super Hero blog, some of the tuning options it enables can help you save 40% of the memory you were using before.

mysqlnd saves memory. It consumes half as much memory as libmysql. This is what we have been convinced of. This is what we taught you. Then I tried to test it and made Andrey get nervous for a few hours… Meanwhile he is fine again and we can announce: mysqlnd saves memory, not only in theory, we tested it - we can proof it, can we?

The proof comes in the form of a few "tricks" and some of the settings that the software can use to optimize buffer sizes. Benchmarks (and the code to run them) are also included to show what the differences are between mysqlnd and libmysql.