SQL Server Review

We're able to create an end-to-end automated BI platform, but we'd prefer hosting multidimensional OLAP instances with Tabular rather than the either/or installation.


What is most valuable?

  • Business intelligence platform
  • Analysis services (multidimensional and tabular)
  • Relational database features
  • Data extraction and transformation (integration services)

How has it helped my organization?

It provides the ability to create an end-to-end automated BI platform through data management and provisioning, transformation and publication.

Data platform development process improvement: Integrating the features of Visual Studio Team Foundation Server data projects for SQL Server development. Allows for smooth operation between development environments in conjunction with an agile process to release database changes.

What needs improvement?

Hosting multidimensional OLAP instances in conjunction with Tabular, rather than the either/or installation.

OLAP multidimensional ongoing maintenance - automated partitioning or interface for streamlining the mechanism within the cube and data layers.

Integration Services: There is a great deal of room for improvement here in that thepackages are the least extensible part of the platform. Even with the feature ofplatform variables, since these are not easily managed and deployed. Our testers have had a great deal of difficulty swapping environments, particularly where the connection information changes (underlying database name, for example). Changing servers with identical database names is less problematic.

For how long have I used the solution?

I've used it since its release in 2012 until now.

What was my experience with deployment of the solution?

No issues encountered.

What do I think about the stability of the solution?

There were some avoidable issues, primarily due to a lack of scaling in our own design.

What do I think about the scalability of the solution?

There were some avoidable issues, primarily due to a lack of scaling in our own design.

How is customer service and technical support?

Customer Service:

Online information for SQL Server is extensive.

Technical Support:

I did not have the need to contact technical support for any reason.

Which solutions did we use previously?

Open Source database and OLAP solution was found to lack stability, and required the installation of many moving parts in order to have a complete stack. These services don't always work together well, and the various online communities would frequently blame the other for issues.

How was the initial setup?

It's straightforward to install a new instance, but more complex if new features are added to an existing instance. Deployment of SQL code is efficient through Visual Studio database project development methodologies.

What about the implementation team?

I have used both in-house, and vendor teams for implementation, both with very high levels of expertise into different aspects of database development.

What was our ROI?

It's very high as the data platform is business-critical.

What's my experience with pricing, setup cost, and licensing?

I don’t concentrate on this issue, but rather the necessary features and the version required.

Which other solutions did I evaluate?

No other oprions were evaluated.

What other advice do I have?

Make sure that you have an experienced database administrator to implement the infrastructure of the solution.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
6 Comments
GaryMReal UserTOP 5POPULAR

It does in fact allow running both tabular and MDB on same server. You have to run independent installs and name the instance 2 different names. I suggest researching this further as it may not be straight forward but is in fact not a constraint.

21 August 15
Enterprise Architect with 51-200 employeesReal UserTOP 10

Sorry I should've been more clear. While this is possible, it's not ideal and from what I've seen not recommended in a production environment.

10 September 15
GaryMReal UserTOP 5POPULAR

Howard, would like to know more about why its not ideal.

It seems to me that even if you could share an instance as both tabular and MDB (remember that they are completely different technologies), it would not allow you to scale easily. In fact I would not run them both on the same server/VM as each are very memory hungry and to scale it seems it requires them on separate servers.

26 January 16
GaryMReal UserTOP 5POPULAR

BTW...Re. Integration Services...you mentioned that ..."platform variables, since these are not easily managed and deployed. Our testers have had a great deal of difficulty swapping environments, particularly where the connection information changes (underlying database name, for example). " Something was wrong with your implementation (sounds like you had developers who didn't know 2012 version) since I consider this area as of the 2012 version SSIS's strongest point - its amazingly agile. However the 2008R2 version was quite difficult as it lacked job and package parameters. All my platform parameters/variables are 100% variable and change with my environment. In fact its so flexible in this area it can be sometimes be a little challenging just to know understand which methods you want to use to control them (via job/package parms, visual studio configuration environments, and SSIS catalog environments) since they can be done in so many different ways that can complement each other.

07 July 16
Enterprise Architect with 51-200 employeesReal UserTOP 10

The problem was in expectations as to which technical aspect of the implementation should be shifting during deployment. With consistency there was no issue, but testing pushed through changes in the database that broke the package variables in an environment. We weren't able to solve it in an extremely tight deadline but we managed a workaround. Gary, have you deployed a scenario where the source data table itself is consistent but the name of the source database changes? It was an odd situation but it caused package failures consistently.

07 July 16
GaryMReal UserTOP 5POPULAR

Howard, yes our database name/server name changes across the environments. We manage this via visual studio configuration environments when creating the ispac or doing deployment from VS but that's just for initial setting defaults to show up within the jobs so we don't have to manually worry about them getting set correctly in the job parameters. The trick is making project parameters (package also works if in the driving package) do all the work for you in the connections by using a simple expression to set the connection values at runtime using those parameters. If your problem is that staff hard coded connections with no parameter override then that's a pretty serious staffing competency issue rather than technical problem.

07 July 16
Guest
Sign Up with Email