Four Years Later

Question

Four Years Later

Viewing 7 posts - 16 through 21 (of 21 total)

You must be logged in to reply to this topic. Login to reply

Joshua M Perry SSCrazy Points: 2676 More actions · Answer 1

My company is a large global enterprise and we're using things like flash storage arrays and putting everything in a VM, but with the main asset of the business being intellectual property, the data will NEVER go in the cloud. There's already enough distrust internally with audits and non-disclosure agreements and such. We have certainly embraced the private cloud idea and replicate data to other continents like the big cloud storage vendors, but there will always be at least a small level of distrust because of the intellectual property.

Joshua Perry
http://www.greenarrow.net

Gary Varga SSC Guru Points: 82166 More actions · Answer 2

smgilbert101 (10/16/2013)
SELECT * FROM can be acceptable and a normal requirement (think data warehousing, integration and application services). A common example is selects all states and provinces to generate a list for a form prompt...

In my opinion no. If you want to select all items then you are talking about rows not columns i.e. no WHERE clause not all columns.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!

smgilbert101 SSC Journeyman Points: 84 More actions · Answer 3

In the example above, the columns are State_PK, StateName I want ALL rows, ALL columns; name for the display value, key for the where clause in the next (and more important) query. The point was that care should be taken with the word "never". The old stand by "it depends" will likely be a more accurate statement. While I got the point of the original statement, it is likely to cause a very spirited debate because it is, in a very anal sense, an incorrect statement. I cannot count the number of times where I've seen such a response create barriers to solutions to real world problems because the statement was misunderstood by the receiver.

It was a word of caution to fellow database professionals and a reminder that we exist to provide a service and we support the needs of other people and other systems. We need to think about the unique challenges of each problem and apply our knowledge to create the best possible solution to that challenge. After all, without those people we wouldn't have the toys we have. 😉

Nevyn SSChampion Points: 14210 More actions · Answer 4

Not sure that is a good example, smgilbert101. You want all rows, but you want specific columns.

You may have a use for all the columns that currently exist, but if a column gets added down the line, your select * will pick up something you don't need and maybe can't handle.

There probably are cases that can be found where "select *" makes sense, but you have to try hard to find one.

jcb SSCertifiable Points: 6574 More actions · Answer 5

Cloud is still hype and I recommend everybody to take a look in things like node.js

Off course it demands depends first on the business model and its more appealing for scenarios like low server side processing with a large number of users.

The average web bandwidth is a major factor. If your users don't got a good bandwidth they ill not consume a lot of web services lowering the demand for clouds.

Its a great solution for all those small applications we are doing to connect people and if you are developing web applications chances are you ill build something in the cloud in next years.

A new (MS SQL) forum solution for example 😀

andrew gothard SSChampion Points: 12315 More actions · Answer 6

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.

vliet SSCommitted Points: 1998 More actions · Answer 7

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.