Contemporary software engineering models include many loosely-defined layers. Database developers might help with other layers, but for the most part a database administrator’s domain is the persistence layer.

• Presentation


• Application


• Business Logic


• Persistence (also called Storage)

The Daily WTF has an article on The Mythical Business Layer makes the case for not separating the business layer and the application layer:

A good system (as in, one that’s maintainable by other people) has no choice but to duplicate, triplicate, or even-more-licate business logic. If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL in the database and have some client-side code to validate it was entered as seven digits. If the system allows data entry in other places by other means, that means more duplication of the Account_Number logic is required.

It almost goes without saying that business logic changes frequently and in unpredictable ways. The solution to this problem is not a cleverly coded business layer. Unfortunately, it’s much more boring than that. Accommodating change can only be accomplished through careful analysis and thorough testing.

I will call this merged business/application layer the “functional layer.”

The serious scaling requirements posed by most applications these days call for partitioning, clustering, sharding or some other term for “dividing up the data so it does not become the bottleneck”. Enter the “architecture layer”.

“Wait a minute,” I hear you asking. “Isn’t that just the persistence layer?”

Yes and no. To me, there’s a difference between the storage and the architecture of said storage. The database schema for storing a user profile is a persistence layer issue. Figuring out which database instance to go to is an architecture layer issue.

This is an important distinction for me. Many folks are coding the architecture layer directly into the functional layer. A “save_profile()” API function might call an ORM to deal with the persistence, or it will have MySQL (or other database) connection handling and queries. However, the database will grow, and at some point you will find yourself wanting to split the data [more].

This type of information, like the presentation layer, needs to be separate. Why should the application care whether save_profile(’Sheeri’,'hair color’,'blonde’) accesses database1 or database2? More importantly, why should there be major code changes to the functional layer if the architecture changes? Just like no functionality has changed when you change your website color from blue to red, there is no functionality change when you go from splitting data between 2 database servers to splitting among 3, or 10.

For me, the persistence layer is about how the data is stored. Which, explicitly and for the record, I also believe should be separate from the functional layer — if you store hair color and eye color in one table or 2, the functionality of the application has not changed; all that’s needed is a change in how that data is stored and retrieved.

The architecture layer is all about where the data is stored. Early forms of the architecture layer are configuration files, though most would not call that a “layer”. Database administrators should be able to change the architecture of the database system without requiring mucking about in the application’s functional code.

Thoughts?

Here are the slides and links I am using for the “Database Security Using White-Hat Google Hacking” at the 2008 MySQL Users Conference and Expo.

pdf slides

Where to Start:
http://johnny.ihackstuff.com/ghdb.php

i-hacked.com/content/view/23/42

for the impatient

Google’s Terms of Service
Google Operators

More Googlehacks to run:
Page 35 of http://www.sdissa.org/downloads/San%20Diego%20ISSA%20Google%20Hacking%20and%20Beyond%20May%202006-rhd.pdf

http://pauldotcom.com/wiki/index.php/Episode81#Tech_Segment:_Google_Queries_To_Run_Against_Your_Own_Domain

http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

Goolag

Google Hacks sofware

Google Hacks Honey Pot

www.robotstxt.org

Wikto

Nikto

Here is the video of “Database Basics”, which I presented at the February 2008 Boston MySQL User Group meeting. The presentation goes over the basics of relations, data, the Entity-Relationship Model, how to choose data types, and how to do basic CREATE statements.

You can download:

the video (Large, 500 MB, or Small, 100 MB)
and
the slides (PDF, 171 Kb).

Or just watch the video:

Hello everyone,

I think this will be a great log buffer.

Dave has been sick these past two days and as a result, we do not have a comprehensive log buffer ready the way we or a volunteer usually do. This was bound to happen to log buffer at some point and today it has happened.

So I had two choices - cancel this week’s log buffer, or try to make it great despite this adversity. Never one to accept defeat easily, I’ll go for the second option. At least if this is the lamest log buffer ever it won’t be because I didn’t try something new that had a shot at a good result.

So this week’s log buffer is as follows: If you came here to read interesting content from the database community, you probably spend some time each day learning and reading about things we would all find interesting. We are counting on each and every one of you, our faithful readers, to propose the one article you read in the last week (and preferably was written in the last week but I can’t exactly be choosy at this point can I?), and include a short paragraph as to why this article was interesting to you and why it should interest us. Do this in the comments to this post; the akismet spamfilter will tend to eat comments with URLs so please include the magic word “contribution” somewhere in your comment so I can go dig them out for approval.

Feel free to link to your own blog posts if you are proud of them. It is a carnival of the vanities, after all.

A typical log buffer gets over a thousand reads over the week it is active. I am going to call this experiment a success if there are at least 25 interesting links written by the community posted below! And if there are not, well it was worth a try and much better than saying it was canceled.

And so this will be the first log buffer truly written by the readership - join us to make it a good one!

Thanks

Paul
P.S.

Get well soon, Dave