SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Four Years Later


Four Years Later

Author
Message
Richard Warr
Richard Warr
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2786 Visits: 1987
fificito (10/16/2013)
Speaking about the company I work for (for the last 8 years), we are very careful about "cloud". The CEO is very protective of the data we generate, and for a good reason, I think. So, I don't see us ever going "cloud" on someone else's servers, but we are, at the moment, migrating all of our infrastructure to a "cloud"- like solution on our own premises.


I hear that a lot. But who's to say that "someone else's servers" aren't a lot more secure than yours?

_____________________________________________________________________
MCSA SQL Server 2012
Steve Jones
Steve Jones
SSC Guru
SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

Group: Administrators
Points: 61817 Visits: 19099
chrisn-585491 (10/16/2013)
Sigh! Four years and folks are still trying the upsell the cloud. Maybe the NSA is offering an additional bonus? :-P

Most of us who've been in this business awhile understand the benefits of various technical and business solutions. The "cloud" or service providers work better in some circumstances and for a sub-set of institutions. We still have the same issues we had four years ago: bandwidth, service, accountability and security.

And security is a much larger elephant considering the events of the last year. It's apparent that an insider or an government agency can totally damage an organization. Why do you want yet another company and their employees/contractors to have access to your data by outsourcing it? You're increasing the liability and attack surface.


Perhaps the NSA is, but not to me.

You have good arguments here, but those apply to some domains and not others. I would argue there are a good domain of services and businesses that don't capture PII, medical, financial, etc. information. They provide a simple service, like a grocery list or a mapping tool, or a game. In many cases, the issues with the cloud aren't as important as the scale and reach.

The issues you brought up are important, but not necessarily an issue for some domains of services.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Steve Jones
Steve Jones
SSC Guru
SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

Group: Administrators
Points: 61817 Visits: 19099
Nevyn (10/16/2013)
Its possible that smaller businesses developing new systems from scratch are thinking cloud first, or starting to.

But I haven't seen any sort of groundswell to move existing database implementations to the cloud. The pace of change for those sorts of things is far slower, and often cost driven. Also, many small and medium businesses buy off the shelf software and then customize around it. And I have not yet seen many vendors of core business software (HR systems, GL) pushing implementations using cloud databases.

It likely will come, but it seems to me that businesses have a much slower adoption of technological trends than consumers do.


I'd agree here. It's hard and complex (and $$$) to "move" an existing application to the cloud. however for new work, it can be worth looking at.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Anders Pedersen
Anders Pedersen
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1778 Visits: 883
It's entering the vocabulary.

Mine at least.

But then I was also slow to accept putting SQL on virtual machines, but have slowly over the last 2 years become a believer in it, at least from a disaster management perspective, if not from an operational perspective.

I expect I will come around to the "cloud" sooner or later. I do see some very cool and promising things with Azure, but security is most likely the thing that will stop this from happening to me. That and having been burnt by SQL 2000 SP4 I do not really want to have my databases hosted on a SQL Server I have no control over the patch level (or when it patches).

I am ready to start to play with it myself for some personal projects, just to make sure I have a clue what to do if my company ever decides to do it...
smgilbert101
smgilbert101
SSC Rookie
SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)

Group: General Forum Members
Points: 42 Visits: 121
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 (a smart design keeps those results cached). Generally speaking, it is not ideal in regards to end user queries and it is a reality that can be addressed by policies. Regardless of policy, it is always going to happen for as long as we provide non technical staff with tools that require technical training.

Now, take that scenario to the cloud. Can those services fully integrate with one another from a data perspective. In my experience, the answer is sometimes. In terms of development costs, software licensing costs, hosting costs, et al. The ROI for public cloud solutions isn't always as robust as they are in internally hosted private cloud environments. In many cases, public cloud offerings are not an option at all until the cloud service fully aligns with the features offered in the internally hosted version of the product. My internal bandwidth is exponentially greater and faster than my bandwidth to cloud services. Changing that requires spending more dollars on bigger circuits that are much more expensive that the VM's I host internally.

And don't get me started on security or lack thereof in the cloud world...
Joshua M Perry
Joshua M Perry
Mr or Mrs. 500
Mr or Mrs. 500 (568 reputation)Mr or Mrs. 500 (568 reputation)Mr or Mrs. 500 (568 reputation)Mr or Mrs. 500 (568 reputation)Mr or Mrs. 500 (568 reputation)Mr or Mrs. 500 (568 reputation)Mr or Mrs. 500 (568 reputation)Mr or Mrs. 500 (568 reputation)

Group: General Forum Members
Points: 568 Visits: 549
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
Gary Varga
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16166 Visits: 6532
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
smgilbert101
SSC Rookie
SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)SSC Rookie (42 reputation)

Group: General Forum Members
Points: 42 Visits: 121
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
Nevyn
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1506 Visits: 3149
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
jcb
SSCrazy
SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)

Group: General Forum Members
Points: 2870 Visits: 993
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 :-D
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search