Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

Four Years Later Expand / Collapse
Author
Message
Posted Thursday, October 17, 2013 5:17 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 8:48 AM
Points: 300, Visits: 3,364
Gary Varga (10/16/2013)
vliet (10/16/2013)
I live in the Netherlands (some of you may call it Holland) and I do believe we have a superb internet connectivity. By now most parts of our beloved country have a 4G super fast mobile network allowing to work nearly everywhere with a bandwidth that allows HD television on a tablet. Even here companies are quite reluctant to move their business into the cloud. If you look at the technical possibilities the are no barriers, take for example the cloud based BI solution offered by Birst.

But it requires a whole different way of thinking to view a database as a service and not as a resource. In most cases using a connection with limited bandwidth for INSERT and UPDATE statements will not slow down the application enough to be noticeable. However for queries using SELECT it is a completely different story. Most developers will only replace the notorious SELECT * FROM ... with a set of named columns when the expected number of rows is really huge. Sucking all the data into the application server and then decide what to use is so common that some applications even need a database service on the same server to avoid the network overhead. Sometimes you cannot blame the developer, the ORM might access data 'one object at a time' thereby generating loads of tiny SELECT requests for all columns of a single table row. For queries the YAGNI design rule (You Ain't Gonna Need It) clearly does not apply.

As soon as each SELECT request is kept as small as possible the amount of data an application needs becomes manageable. Then it might be possible to move de database into the cloud because the extra overhead does not significantly slow down the application. That requires a different approach to data access for both the developer and the ORM he uses, with Linq (from Microsoft) as a good example that it is possible to offer such a bandwidth efficient framework for data access to the developer. Even with Linq it is still up to the developer to limit the request to the columns used; the compiler has not yet capabilities to determine which columns are used and thus limit the request to these columns. Making an application 'cloud ready' might require some effort, making that application 'cloud database ready' certainly does!


SELECT * FROM

is never acceptable. The application will usually only deal with columns it expects anyway so it is simply a waste and poor, lazy practice. I have yet so see an application that does something with unexpected data nor continues with a subset of what was expected.


"But it's easier/quicker to type man ... ". The excuse for hundreds of inane and unprofessional development practices from thousands of complete muppets


I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Post #1505612
Posted Thursday, October 17, 2013 9:23 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, September 9, 2014 1:39 AM
Points: 67, Visits: 429
With most persistence frameworks or query facilities (like Linq) it is very easy to fetch complete objects and then access only a few properties of these objects in a for each loop. Although this is technically speaking not a SELECT * FROM ... the query will also retrieve all columns of the affected rows.

These queries will render your application 'not cloud database ready'. Another common database access pattern found in today's applications is retrieving a set of IDs and then perform a separate SELECT request to fetch each associated row from the underlying table. Often each request is carefully weighed when accessing a remote web service, but the same is not true for requests to the database. This approach severly limits the feasibility to use a database in the cloud. That is not necessarily a bad thing, it is just something to keep in mind when we are talking about moving databases to the cloud.
Post #1505776
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse