Last year at Pageflakes, when we were getting millions of hits per day, we were having query timeout due to lock timeout and Transaction Deadlock errors. These locks were produced from aspnet_Users and aspnet_Membership tables. Since both of these tables are very high read (almost every request causes a read on these tables) and high write (every anonymous visit creates a row on aspnet_Users), there were just way too many locks created on these tables per second. SQL Counters showed thousands of locks per second being created. Moreover, we had queries that would select thousands of rows from these tables frequently and thus produced more locks for longer period, forcing other queries to timeout and thus throw errors on the website.

If you have read my last blog post, you know why such locks happen. Basically every table when it grows up to hold millions of records and becomes popular goes through this trouble. It’s just a part of scalability problem that is common to database. But we rarely take prevention about it in our early design.

As there is a growing interest in dynamic languages, more people are running into a programming concept called Closures or Blocks. People from a C/C++/Java/C# language background don’t have closures and as a result aren’t sure what they are. Here’s a brief explanation, those who have done a decent amount of programming in languages that have them won’t find this interesting.

Closures have been around for a long time. I ran into them properly for the first time in Smalltalk where they’re called Blocks. Lisp uses them heavily. They’re also present in the Ruby scripting language – and are a major reason why many rubyists like using Ruby for scripting.

Essentially a closure is a block of code that can be passed as an argument to a function call. I’ll illustrate this with a simple example. Imagine I have a list of employee objects and I want a list of those employees who are managers, which I determine with an IsManager property. Using C#, I’d probably write it like this.

  public static IList Managers(IList emps) {
    IList result = new ArrayList();
    foreach(Employee e in emps)
      if (e.IsManager) result.Add(e);
    return result;
  }

In a language that has Closures, in this case Ruby, I’d write this.

def managers(emps)
  return emps.select {|e| e.isManager}
end

Essentially select is a method defined on the Ruby collection class. It takes a block of code, a closure, as an argument. In ruby you write that block of code between curlies (not the only way). If the block of code takes any arguments you declare those between the vertical bars. What select does is iterate through the input array, executes the block of code with each element, and returns an array of those elements for which the block evaluated as true.

Now if you’re a C programmer you probably think “I could do that with a function pointer”, if you’re a Java programmer you probably think “I could do that with an anonymous inner class”, a C#er would consider a delegate. These mechanisms are similar to closures, but there are two telling differences.

The first one is a formal difference, closures can refer to variables visible at the time they were defined. Consider this method

def highPaid(emps)
  threshold = 150
  return emps.select {|e| e.salary > threshold}
end

Notice that the code in the select block is referring to a local variable defined in the enclosing method. Many of the alternatives to closures in languages that don’t have real closures can’t do that. Closures allow you to do even more interesting stuff. Consider this function.

def paidMore(amount)
  return Proc.new {|e| e.salary > amount}
end

This function returns a closure, indeed it returns a closure whose behavior depends on the argument sent into it. I can create such a function with and assign it to a variable.

highPaid = paidMore(150)

The variable highPaid contains a block of code (called a Proc in Ruby) that will return whether a tested object has a salary greater than 150. I might use it like this.

john = Employee.new
john.salary = 200
print highPaid.call(john)

The expression highPaid.call(john) calls the e.salary > amount code I defined earlier, with the amount variable in that code bound the to the 150 I passed in when I created the proc object. Even if that 150 value went out of scope when I issue the print call, the binding still remains.

So the first crucial point about closures is that they are a block of code plus the bindings to the environment they came from. This is the formal thing that sets closures apart from function pointers and similar techniques.(Java’s anonymous inner classes can access locals – but only if they are final.)

The second difference is less of a defined formal difference, but is just as important, if not more so in practice. Languages that support closures allow you to define them with very little syntax. While this might not seem an important point, I believe it’s crucial – it’s the key to make it natural to use them frequently. Look at Lisp, Smalltalk, or Ruby code and you’ll see closures all over the place – much more frequently used than the similar structures in other languages. The ability to bind to local variables is part of that, but I think the biggest reason is that the notation to use them is simple and clear.

A good case in point is what happened when ex-Smalltalkers started in Java. Initially many people, including me, experimented with using anonymous inner classes to do many of things that we’d done with blocks in smalltalk. But the resulting code was just too messy and ugly so we gave up.

Like any term in software there is a lot of blur about the exact definition of closure. Some people say that the term only applies to an actual value that includes bindings from its environment, such as the value returned by highPaid. Others use the term ‘closure’ to refer to a programming construct that has the ability to bind to its environment. This debate, an example of the TypeInstanceHomonym, is usually carried out with the politeness and lack of pedantry that our profession is known for.

I use closures a lot in Ruby, but I don’t tend to create Procs and pass them around. Most of the time my use of closures is based around CollectionClosureMethods similar to the select method I showed earlier. Another common use is the ‘execute around method’, such as when processing a file.

File.open(filename) {|f| doSomethingWithFile(f)}

Here the open method opens the file, executes the supplied block, and then closes it. This can be a very handy idiom for things like transactions (remember to commit or rollback) or indeed anything where you have to remember to do something at the end. I use this extensively in my xml transformation routines.

Such use of closures is actually much less than what people in the Lisp and functional programming worlds do. But even with my limited uses I miss them a lot when programming in languages without them. They are one of those things that seem minor when you first come across them, but you quickly grow to like them.

Other languages: C# | Python | Boo | Lisp | JavaScript

Here is the next article i have read in nettuts.com and think really useful. I read many things about Django and it seems really cool. Although I couldn’t create a full application with it yet, i am sure it will be really nice to use Django.

This article is from Glen Stansberry who is a web developer and blogger. You can read more tips on web development at his blog Web Jackalope or follow him on Twitter.

There are quite a few great little tricks and tips one could use on their Django projects that would speed up development and save many headaches in the long run. From basic to obscure, these tips can help any skill-level of programmer become more adept with Django and all it’s glory.

Django is an excellent framework for Python. While it may not get as much ink as other popular frameworks like Rails, it is just as much a polished framework as any of the rest. It puts plenty of emphasis on the DRY principle (Don’t Repeat Yourself) in clean coding by automating many of the processes in programming.

1. Use relative paths in the configuration

For some reason, projects tend to be moved around in location from time to time. This can be an absolute bear to deal with if you don’t first plan ahead for the possibility. Rob Hudson has an excellent technique to ensure that your Django deployments can be moved around with ease, only having to edit a few lines of code in your settings files.

Rob’s post has excellent code examples for setting up your Django installation in a very flexible way.

2. Use the {% url %} tag

Instead of hardcoding individual links, try using the backwards compatible {% url %} tag to achieve the same result. This will give you the absolute URL, so that if, heaven forbid, your Django project moves the links will still remain in tact.

Essentially the {% url %} takes a view name and its parameters and does a reverse lookup to return the queried URL. If you make changes to your urls.py file, the links won’t break.

While it’s not the most advanced tip, it’s an excellent technique to use in your django projects.

3. Use Django admin for your PHP apps

Possibly one of the greatest features of Django is the user authentication system that Django has built straight into the core. It’s seriously easy to set up, and it comes packed with a robust system to authenticate users and configure other necessary settings.

This user system is so awesome that it’s even been suggested to use Django as your admin area for your PHP application. Here’s Jeff Croft on why Django is a great solution for an admin system for any application, regardless of language:

One of the core philosophies of Django is loose coupling. Besides the more alluring free-love connotation, this mean that each of the layers of Django ought to be independent of the others, such that you can choose to use only bits and pieces of it, and/or slide in other components if you prefer. Lucky you, it is incredibly simple to learn the basics of Django’s model layer, which handles database schema and object-relational mapping even if you don’t know Python. Anyone can create a database schema in Django and get the crown jewel of the framework — it’s admin interface — with very little work, even if you plan to write the application logic itself in another language.

4. Use a separate media server

Django allows you to serve static files in your development environment, but not your production environment. Why? It’s not efficient. At all. Jacobian.org gives an explanation.

Django deliberately doesn’t serve media for you, and it’s designed that way to save you from yourself. If you try to serve media from the same Apache instance that’s serving Django, you’re going to absolutely kill performance. Apache reuses processes between each request, so once a process caches all the code and libraries for Django, those stick around in memory. If you aren’t using that process to service a Django request, all the memory overhead is wasted.

By using a separate server to house and serve these static files, your performance won’t suffer. If you didn’t want to buy a server you could use Amazon S3 to house the files relatively cheaply.

5. Use the Debugger Toolbar

Debugging tools for any language are invaluable. They speed up development by spotting errors in your code and potential pitfalls that might happen. Rob Hudson has recently released the django debug toolbar to help with debugging code, and it could greatly help any developer.

The toolbar itself is a piece of middleware that instantiates each panel object on request, and performs processing and rendering as the response is being written back to the browser. In this way it is essentially a set of middleware classes (the panels) grouped together to display a single toolbar. Each panel subclasses a base panel class and overrides a few methods to render the toolbar.

6. Use Django Unit Testing

Unit testing is a great way to ensure that your changes to the code that it works as expected and doesn’t break any older code to maintain backwards compatibility. A great feature in Django is that it’s incredibly easy to write unit tests. Django offers the ability to use the doctest or unittest straight out of the box.

Django’s documentation offers a great tutorial and some sample code on how to set up unit tests to keep your code running smoothly and spot any nasty bugs.

7. Use a Cheatsheet

Is cheating wrong? I hope not. This nifty 2-page cheatsheet contains some golden nuggets within arm’s reach that one might have to dig around the Django documentation to find.

The cheatsheet features these helpful topics:

Templates

• Template tags and their options
• Template filters and their options
• Date formatting syntax quick reference

Models

• Fields and their options
• Common field options
• Meta class options
• ModelAdmin options

Forms

• Fields and their options
• Common field options
• Standard error_messages keys

We all know time spent looking at documentation is time spent not solving the world’s problems through code. And no good programmer wants that.

8. Utilize django-chunks

Django-chunks is essentially a way to create blocks of reused code in your templates. Except creating the blocks is made even easier by using Django’s rich text editor.

Well it essentially allows someone to define “chunks” (I had wanted to call it blocks, but that would be very confusing for obvious reasons) of content in your template that can be directly edited from the awesome Django admin interface. Throwing a rich text editor control on top of it make it even easier.

By replicating bits of reusable code, django-chunks ensures that pieces of the layout can quickly and easily be changed if need be. While django-chunks is really only a model and template tag, it can greatly speed up development by replicating processes.

9. Utilize Memcache

If performance is going to be an issue with your Django-powered application, you’ll want to install some sort of caching. While Django offers many options for caching, the best by far is memcached. Installing and using memcached is fairly easy with Django if you use the cmemcache module. Once the module is installed, you just change a single configuration option, and your Django pages will be served lighting fast.

10. Stop hacking scripts together and just use Django

If you still don’t fully understand Django’s power after reading this article, there’s a logical reasoning for using Django in your next project: You save time hacking together designs with different sets of software. Jeff Croft explains why creating a project in Django is much more efficient than trying to hack together scripts.

Now, if you’re used to building sites using a blogging app (WordPress, TXP, etc.) as a CMS, you’re used to getting all that for free. But you’re also getting a lot of things built-in that maybe you don’t want (unless, of course, you’re building a blog). The limitation I ran across in using a blogging app for my personal site is that I wanted it to be more than just a blog. As soon as I tried to hack a blog into a photo gallery, or a links feed, or a statistics database, a game of Sudoku, or whatever else I could think of, things started to get crufty. I also built a website in which I tried to use a discussion forums app (vBulletin) as a CMS, and that had the same results. It worked — sort of — but it wasn’t extensible, was very hackish, and just generally was inelegant. With Django, you get all of these things and none of the limitations of a blogging app.

Django allows you to expand your website into literally any direction without having to worry about hacking the design or making sure the scripts and databases are compatible. It just works.

Resource: nettuts.com

If that is true, then is this a sign that the once mighty relational database finally has a chink in its armor? Is this a sign that relational databases have had their day and will decline over time? In this post, we’ll look at the current trend of moving away from relational databases in certain situations and what this means for the future of the relational database.

Relational databases have been around for over 30 years. During this time, several so-called revolutions flared up briefly, all of which were supposed to spell the end of the relational database. All of those revolutions fizzled out, of course, and none even made a dent in the dominance of relational databases.

The Problem with Relational Databases

Even though RDBMS have provided database users with the best mix of simplicity, robustness, flexibility, performance, scalability, and compatibility, their performance in each of these areas is not necessarily better than that of an alternate solution pursuing one of these benefits in isolation. This has not been much of a problem so far because the universal dominance of RDBMS has outweighed the need to push any of these boundaries. Nonetheless, if you really had a need that couldn’t be answered by a generic relational database, alternatives have always been around to fill those niches.

Today, we are in a slightly different situation. For an increasing number of applications, one of these benefits is becoming more and more critical; and while still considered a niche, it is rapidly becoming mainstream, so much so that for an increasing number of database users this requirement is beginning to eclipse others in importance. That benefit is scalability. As more and more applications are launched in environments that have massive workloads, such as web services, their scalability requirements can, first of all, change very quickly and, secondly, grow very large. The first scenario can be difficult to manage if you have a relational database sitting on a single in-house server. For example, if your load triples overnight, how quickly can you upgrade your hardware? The second scenario can be too difficult to manage with a relational database in general.

Relational databases scale well, but usually only when that scaling happens on a single server node. When the capacity of that single node is reached, you need to scale out and distribute that load across multiple server nodes. This is when the complexity of relational databases starts to rub against their potential to scale. Try scaling to hundreds or thousands of nodes, rather than a few, and the complexities become overwhelming, and the characteristics that make RDBMS so appealing drastically reduce their viability as platforms for large distributed systems.

For cloud services to be viable, vendors have had to address this limitation, because a cloud platform without a scalable data store is not much of a platform at all. So, to provide customers with a scalable place to store application data, vendors had only one real option. They had to implement a new type of database system that focuses on scalability, at the expense of the other benefits that come with relational databases.

Resource: ReadWriteWeb.com

Having worked at Google and now working in my own business, I’ve noticed that some days I’m just a rockstar at getting everything done, and others I can barely get a few lines of code out, or accomplish anything on my todo list.  Of course, now that I’m in a really small business, every single day counts, for each person in the business.

After looking back and trying to figure out what separates one day from the next, here are some commonalities I’ve noticed.  All of these are obvious with a little bit of thought, and I’m certainly not the first one to come up with these ideas.  But a reminder of them can go a long way. Also, some of these only apply when you’re in Marathon mode (like when you’re trying to be effective over the course of a year or two), and not in Sprint mode (like when you have a major, major deadline in 2 weeks).

1. Limit News Intake to twice a day, Including Google Reader & News Sites
Straight from the four hour workweek.  Let’s be real: Your minute-to-minute life isn’t affected by anything you read in your blogs unless you’re a news reporter.  Reading the news is an enjoyable way to procrastinate under the veil of being important.  I have 2 times of the day when I read news: google reader in the morning, and news in the evening.  Anything more is a distraction which lowers my effectiveness.

2. Leave Yourself a Place to Start (or: Leave work with something small broken)
Programming effectively (at least, for me) requires me to have a lot in my brain at one time – which I ‘load’ when I start, and which rapidly dissipates when I get distracted or stop.  That means that getting started and ‘into the zone’ is the hardest part.  What makes it easier to get started is if I have a simple task to complete that gets me in the zone.

So, any time I stop (lunch, or in the evening), I intentionally break something so I can get right back and fix it – when I get back to work, I’m not only anxious to fix it, but I’m in the zone after I’m done fixing it.

There was a famous sculptor (or ten) who, before he’d leave for the night, would smash a sizable dent into his sculpture – so in the morning, he’d know where to start.  Many programmers I know have a problem with this – but seriously.  Try it a few times, and see if it gets you up and running faster, more consistently.

3. Draw it Out & Research First
I can’t really explain it, but I’m so much more productive whenever I use a pen and paper to draw out what I need to do.  I don’t know if it gives me time to sort out all the details in my mind, or if it’s just giving me a road map so I don’t get distracted.  But paper and pen is my favorite, whether it’s a flow chart or a UI mockup.  I know others love their whiteboards.  But for some reason, doing it in OmniGraffle or PPT just doesn’t have the same effect.

Also, if I know I’m going to need some algorithms that require knowledge I don’t currently have, I spend 30 minutes researching the answers to them.  That way I don’t get distracted or have to redo anything.

4. Architect Your Perfect Distraction-Eliminating Work Environment
Unfortunately in big companies, you don’t necessarily have control over your designated workspace.  However, you can probably control your home work environment, or find an area at the office building that you can make your own.  My work environment includes:

* Big computer monitor, big desk (for when I want to work at a desk)
* A recliner chair (for when I want to work in a relaxing posture)
* Conducive Work Music (my mood is a bit different each day, but I have to know the song well, otherwise I end up listening to the words!)
* Good sound system
* Well-Lit with natural light
* Wide-open space
* Very few people (or no one) walking by
* Well ventilated, preferably with outside air
* Modern feel
* Calm pets I get along with

5. Eliminate IM during productive hours
Other people don’t usually spend the time to think whether or not something is urgent AND important when they IM you.  Chances are if they think about it for 15 seconds after their initial impulse to IM you, most IMs can be done over email, and can be answered in non-productive hours.

The same goes for you.  Before you ask someone on IM for something, see if it’s actually urgent and important.  If it’s not, send them an email and ask for the answer by the end of the day, or week.  Then you won’t get distracted, either.

6. Only Respond to Emergency Emails during productive hours
This goes hand in hand with the tip above.  You can lose a few hours just in the context switching between programming and doing other things.  If you can, make a label, with a rule to filter out emergency emails and bring them to your attention.  Otherwise, answer all other types of emails after productive hours.

7. Limit Meetings to once a week (or less)!
I saw this at the big company I worked at the most, but if your team runs effectively, and is an effective size, you should only have to have meetings once a week, to get everyone back on the same track.  If you have meetings more than once a week, there’s most likely a serious problem with how your project is managed, or how your team is structured.

In our small team, we meet once a week to prioritize the next 3 features being built – mostly because each feature takes a week to build (or two).

8. Get out, and be social every 2 weeks
It might just be me, but I think it’s universal – I need human contact other than my work friends at least every two weeks, and go somewhere other than home and work.  Otherwise something inside me starts to get distracted easily.  I have a need to talk about myself to friends, and listen to my friends; and doing so regularly keeps me from getting too antsy & feeing couped up.  I’m sure the rest of you experience some similar phenomenon, perhaps on a different timescale.  Tailor your routine to your own emotional needs!

And on a related note, even playing video games on weekends doesn’t really keep me from feeling antsy – I really have to leave my normal environment and interact with other people.

9. Take evenings off most days
This is worse at a startup – the inertia of working 24×7, as well as anxiety (or being anxious and excited) can keep you glued to doing work for far too long.  I’ve found that if I take evenings off, I’m more likely to need less sleep, and less likely to get caught up in reading the news or getting distracted on IM.  Each evening, unless there’s a problem, I’ll take at least a few hours to enjoy the companionship of my girlfriend, pets, some TV, or a book – and just let my brain unwind and refresh.  I think you’ll find your creativity improve, too.

10. Get 20 minutes of exercise in the morning, 3 times a week – but use that time!
I don’t know about you, but I used to think exercise was a complete waste of time – but I knew it was important.  However, what I’ve found is that when I exercise regularly, I need less sleep – which is crucial in a startup!  I also bring along a great podcast I can listen to on an iPod.  Typically they’re a perfect length – 30-40 minutes, and I can get in my exercise while I’m getting a new perspective on things.

I suggest: Stanford Technology Ventures Podcasts (my favorite),  Ruby on Rails Envy (and other technical podcasts)

Bonus. Make/Use Better Tools
This isn’t concrete enough to be an actual method (plus, 11 just isn’t a good number), but I’ve found it incredibly valuable.

The best time savers from a coding perspective for ThriveSmart is when we’ve made plugins out of repetitive code – or when we’ve found plugins for things we thought we’d have to do ourselves.   Take a look: can you write any tools that would automate parts of your life or drudge tasks?  Perhaps you can even outsource parts of your life, like in 4 hour workweek.  Just something to revisit every few months, to see if you can work smarter, instead of harder!

Original post: matthewpaulmoore.com

PHPBench.com was constructed as a way to open people’s eyes to the fact that not every PHP code snippet will run at the same speed. You may be surprised at the results that this page generates, but that is ok. This page was also created so that you would be able to find discovery in these statistics and then maybe re-run these tests in your own server environment to play around with this idea yourself, by using the code examples (these code examples are automatically generated and as the code in my .php files change, so do they).

You should take a look to see basic differences of using those functions and what you are doing right / wrong.

Choosing the Wrong Database
Not all databases are created equal — which means before you do anything with a database, you have to pick the appropriate database. Time and again I’ve seen Access databases groaning to bear the load of huge data sets that would have been child’s play for SQL Server, or harried users trying to pay for and set up SQL Server to hold a few hundred rows of data. Broadly speaking, there are three tiers of databases in the market these days: desktop and embedded databases suitable for smaller tasks, “Express” versions of the major players that are good up to a few gigabytes of data, and the truly enterprise databases like SQL Server, Oracle, and DB2 that can handle just about anything you can throw at them. Before you do anything else, you need to make some realistic estimates about the amount of data that you’ll be storing and pick the appropriate product to do the storage.

Choosing Too Many Databases
APIs such as ODBC, JDBC, and OLE DB have promoted the notion of database independence – the idea that you can write your application code in such a manner that you can plug any database at all in for data storage. Well, yes, but there are compromises. I’ve seen a lot of teams go down the rat hole of database independence, writing layers to translate all of their SQL statements to some lowest common denominator dialect that every conceivable database will support, and at the same time giving up on advanced features available in any particular database. The notion seems to be that some client in the future might want to switch to Oracle or DB2 or FoxPro or whatever, so it’s best to be prepared now. On the contrary: when you’re starting out with a new product, pick your storage engine and write to it. If your product is good, people will install the database you specify, and you won’t be wasting untold man-hours supporting “just in case”scenarios that you’ll probably never need.

Know Your Data
If I had a dollar for every time it turned out that some customer numbers had seven digits instead of six, or that the registrar’s office really did allow students to register without a social security number due to privacy concerns and so the column has to be made nullable – well, I’d have a lot of dollars. Database design can’t be done in a vacuum, away from the business rules. It’s critical that you get the input of the actual users of the data, and hammer on them to find out for sure how big each column needs to be, what rules apply to it, what types of data it will hold, who can update it, and so on. Otherwise, you’re setting yourself up for costly rework down the line. You’ll learn to dread sentences starting with “Well, it looks fine, except…”

It’s Just Like Excel, Right?
There’s a tendency, especially among managers of smaller shops, to assume that any developer knows how to set up a database. Frankly, this perplexes me. You wouldn’t assume that any given developer knows how to code in C# or set up a Web Service, so why is it that we’re all supposed to be database pros? The end result is that too many databases are designed by people who have never even heard the term normalization, never mind developed any understanding of the various normal forms. I can’t tell you how many times I’ve found everything shoved into one big table with hideous update anomalies and performance issues as a result. If you’re in this situation yourself, and you’re over your head, demand training – or start job-hunting. Efficient database design is something you need to learn, not discoverby trial and error.

Third Normal Form is Not the Holy Grail
On the other hand, a little knowledge really can be a dangerous thing. I’ve seen databases that were normalized to death by well-meaning developers who insisted on putting everything in lookup tables. I recall one memorable instance in which “yes” and “no” were relegated to tblAnswers, where they could be referred to by an AnswerID foreign key from other tables. Yes, you need to know the normalization rules, but you also need to develop the skill to know when to stop normalizing, and when denormalization for performanceactually makes sense.

What a Great Place to Hide Application Logic!
Stored procedures and triggers are a wonderful thing. When you’ve got multiple clients accessing a database, they can be a great way to make sure consistent data processing takes place. But they can also turn into an ugly black box in which application logic hides, unknown to Web and thick client developers, generally unseen and unreviewed. Too often database code isn’t subject to the same standards of design, test, and code review that we demand for the rest of our applications. When you’re tempted to put code in the database, take a moment to askyourself whether it really belongs there.

Who Needs Backups?
Who needs backups? You do. Presumably you’re storing data in a database because it’s important enough to hang on to. Somehow, though, I end up walking into situations where “nobody got around to it” on a regular basis, and valuable data is lost forever because hardware, hackers, or just plain mistakes munged the database and there wasn’t any backup. Your backup plan (including things like frequency, type of backup, and how often you’re going to take backups off-site) needs tobe in place at the start of the development cycle, not at the end.

Yes, You Need Version Control
Speaking of backups, you need to worry about schema changes to your database as well as data changes, and you need to keep track of those schema changes in such a way that you can recreate the database at any point in time. That’s right, if you want to do a really professional job of building software you need to extend version control to your database design. It doesn’t do much good to be able to recover version 0.784.5 of the software to test out a customer bug if you can’t also produce the corresponding database. If your database developers are cheerfully writing stored procedures and tweaking table designswithout leaving any trace of their work, you’ve got a problem.

Use the Tools
Modern databases offer a lot more than just a series of buckets that you can toss your data into. They also come with a substantial variety of tools to make it easier to manage that data. For example, SQL Server makes it  easy to inspect the plan of attack that the server is using for your queries, and even includes wizards to tell you what indexes would make your queries more efficient for the actual load you’ve been throwing at your server. I’ve had great success running these tools on client databases and speeding things up, or lowering CPU usage by a factor of two – but the fact is, they shouldn’t have had to call in a consultant to tell them to use the stuff in the box. If you don’t know what tools and utilities come with your database, and what they can do for you, then you’re paying for value that you’renot receiving.

Don’t Assume Everything is a Nail Just Because You Have a Really Big Hammer
Databases have a tendency to take over all data storage for an application. I’ve seen applications that tried to build an entire metadata-driven user interface, and then stored that metadata along with user preferences in the same database that was holding the business data. This is a good way to complicate your life and kill performance; some data really does belong in local files, not in a client-server databaseacross the network. When you’re storing data, you need to evaluate the different places you can put it (database, registry, plain text files, XML files…) and pick the appropriate spot for each piece of data. Don’t just automatically shove it into a database just because you have a connection string handy. These days, there’s probably more of a tendency to overuse XML files than relational databases, but the principle still holds.

About the Author
Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the Senior Technology Partner for Adaptive Strategy, a Washington State consulting firm. When he’s not writing code, Mike putters in the garden on his farm in eastern Washington state.

Resource: developer.com

Now let’s look at the examples:

1)Rewriting product.php?id=12 to product-12.html

It is a simple redirection in which .php extension
is hidden from the browser’s address bar and dynamic url (containing
“?” character) is converted into a static URL.

RewriteEngine on

RewriteRule ^product-([0-9]+)\.html$ product.php?id=$1

2) Rewriting product.php?id=12 to product/ipod-nano/12.html

SEO expert always suggest to display the main keyword in the URL. In
the following URL rewriting technique you can display the name of the
product in URL.

RewriteEngine on

RewriteRule ^product/([a-zA-Z0-9_-]+)/([0-9]+)\.html$ product.php?id=$2

3) Redirecting non www URL to www URL

If you type yahoo.com in browser it will be
redirected to www.yahoo.com. If you want to do same with your website
then put the following code to .htaccess file. What is benefit of this
kind of redirection?? Please check the post about SEO friendly redirect (301) redirect in php and .htaccess.

RewriteEngine On

RewriteCond %{HTTP_HOST} ^optimaxwebsolutions\.com$

RewriteRule (.*) http://www.optimaxwebsolutions.com/$1 [R=301,L]

4) Rewriting yoursite.com/user.php?username=xyz to yoursite.com/xyz

Have you checked zorpia.com.If you type
http://zorpia.com/roshanbh233 in browser you can see my profile over
there. If you want to do the same kind of redirection i.e
http://yoursite.com/xyz to http://yoursite.com/user.php?username=xyz
then you can add the following code to the .htaccess file.

RewriteEngine On

RewriteRule ^([a-zA-Z0-9_-]+)$ user.php?username=$1

RewriteRule ^([a-zA-Z0-9_-]+)/$ user.php?username=$1

5) Redirecting the domain to a new subfolder of inside public_html.

Suppose the you’ve redeveloped your site and all the
new development reside inside the “new” folder of inside root
folder.Then the new development of the website can be accessed like
“test.com/new”. Now moving these files to the root folder can be a
hectic process so you can create the following code inside the
.htaccess file and place it under the root folder of the website. In
result, www.test.com point out to the files inside “new” folder.

RewriteEngine On

RewriteCond %{HTTP_HOST} ^test\.com$ [OR]

RewriteCond %{HTTP_HOST} ^www\.test\.com$

RewriteCond %{REQUEST_URI} !^/new/

RewriteRule (.*) /new/$1

Resource: Roshan’s Blog

To read full article by Logan Mortimer visit nettuts.com

Technorati Tags: python, django, web development, mvc pattern