All posts tagged ‘sql’

File Under: Software, Web Apps

Meet WebMatrix, Microsoft’s New Suite For Painless Web Development

Microsoft has unveiled a new all-in-one web development suite called WebMatrix.

It’s more than an IDE or a framework, it’s a whole suite — a web server, a SQL database, and a database-ready framework, all wrapped up into a single development environment that makes it easy to build, test and deploy some fairly complex web apps.

WebMatrix is free, and it’s available for Windows users as a beta download.

The new suite is especially geared towards developers building web apps that require local data storage. It’s pretty flexible, and you can also use it to build simple websites, then scale up to something mid-weight or incorporate a full-scale app that you could run a business on top of.

The WebMatrix suite is made up of three components: the lightweight Windows-based web server called IIS Express, SQL Server Compact Edition, a simple database server, and Razor, a new templating language based on ASP.NET. The beta version you can download today actually doesn’t have Razor, but it will be included in a future release “later this month,” according to Microsoft.

The three key technologies were previously announced by Scott Guthrie, Microsoft’s VP of its Developer Division. Now, with the launch of WebMatrix, Guthrie has introduced a few new components.

Continue Reading “Meet WebMatrix, Microsoft’s New Suite For Painless Web Development” »

File Under: Programming, Web Basics

SQL Basics: Four Reasons Never to Select All

Select errorHave you ever written a database call that went something like… select * from posts where id=3;? We probably all have, but it’s bad for several reasons. Four of them, according to a programmer that goes by pizza_milkshake.

To database administrators and advanced programmers, this may not come as news. Even many seasoned coders could use a reminder not to be lazy.

pizza_milkshake’s Four Reasons Not to Select All

  1. If you include the field names, your code is self-documenting
  2. When a field name changes, you want to know with a query error, not later
  3. Asking for more than you need is just wasting resources
  4. Without naming the fields, you can’t be certain of the order you’ll receive them

I hope these reasons are good enough to encourage your next query to not start select *.

See also: