Looking for a straight forward answer from the SQL guru's
To make a decision on which license to purchase, we were looking for the number of databases supported by a server instance of each edition (Express, Web, Standard, Enterprise) but couldn't find any useful information on the net. Any help is appreciated.
Technical answer: 32,767
Practical answer: much harder and more variables
There is no difference between editions, but performance features as the editions go up can enable your machine to practically support more dbs.
Source: https://msdn.microsoft.com/en-us/ms143432.aspx
there are four editions mainly (Express, Web, Standard, Enterprise),it support upto 524PB size except express edition(which is support 10GB).first create one database and see the size of that based on that calculate the no.of databases that particular edition support it.:)
for more:https://msdn.microsoft.com/en-us/ms143432.aspx
Related
At the risk of this question being closed, I'm going to ask it anyway since I'm quite lost, and I really need to make a decision.
I'm inclined for OpenLink Virtuoso at the moment since it's open source.
However, does Virtuoso Universal Server (commercial) have more features compared to OpenLink Virtuoso (open source) or are they [very] similar? Am I missing something if I use OpenLink Virtuoso and don't upgrade to the commercial "Virtuoso Universal Server"?
I'm sorry to ask, but the web pages are not clear enough for me. I can't get any clear cut answer from the online documentation.
This is certainly not a programming question, so really not appropriate for StackOverflow. As it's about comparisons between two products from the same company, OpenLink Software (my employer), it's most appropriate for the OpenLink Community Forum.
That said, in short, yes, Virtuoso Enterprise Edition a/k/a Commercial Edition has several features that are not in Virtuoso Open Source Edition a/k/a VOS. Significant differences include Custom Inference Rules, Attribute-Based Access Control (ABAC), Rule-Based Access Control for RDF Named Graphs, Federation/Virtualization of external SQL and RDF data sources, Replication Cluster options, Elastic/"Shared-Nothing" Cluster options, and more. We publish a useful feature comparison matrix, comparing VOS with Enterprise Edition from v5 to v8 (current).
All that said, you can start with VOS and migrate to Enterprise Edition if and when you discover a need for the Enterprise features, just by replacing the executables; the database does not need to be rebuilt. (Reverse migration is possible but takes more work, as this direction does require a dump and reload.) Similarly, you can start with a low-scale Enterprise license, and upgrade when/if you need to support more users, use more processors, add optional features, etc. You don't pay twice, as scale-upgrade licenses are priced at the difference between the existing and the new.
More details about any of the above are best gathered through the OpenLink Community Forum or by contacting our Sales team.
I am working on an enterprise level product that is designed around SQL Server Express and specifically its features (views, concurrent users, stored procedures, CASE and IF statements).
Though we don't use any advanced SQL Server features, the database size limit of 4GB in the Express edition may up being a limitation. A work-around is that customers can move to more full-featured versions of SQL Server.
The problem is that SQL Server Express deployment is not easy, and the installer size is huge. This is a major drawback for someone looking to try our product. You don't want end-users to not buy a product because the download is huge.
Does anyone have any recommendations of a database that has a smaller footprint but all the features of Express and which can be migrated to express?
Check out SQL Server Compact.
If what you really need is just a relational database, you can probably use SQL Server Compact Edition or SQLite.
It depends what you're looking for when you say "all the features of Express."
Edit after comments and edited question:
It sounds like you need Express, but I hear you about the huge installer size, which will be an issue even if you embed it in your own installer ( http://msdn.microsoft.com/en-us/library/dd981032(SQL.100).aspx).
You could also offer several trial options:
Use an existing SQL instance (small download + instructions to configure DB)
Full, self-contained trial (big download)
Demo trial (small download, single-user database; no server required)
That way companies that have running SQL/Express instances don't have to download the installer again, if they don't want it, and those who just want to see how it looks and feels can get the "demo" trial, and those who simply must have the full-fledged product are going to see and understand that the database server component is what is huge and they'll have to be a little patient for it (or call/E-mail you for a CD copy).
PostgreSQL is one of your options.
Its not smaller, around 35M packe and over 100M unpacked.
But it fits your requirements by the licensing model.
It has all the features.
You can make the deployment easy because you can preconfigure the binaries version you can supply with your own software.
Users will never need to migrate because this is powerful enough (ex. Skype uses it for its backend)
EDIT:
An interesting alternative may be Firebird (free, 7MB)
and maybe some commercial ones like NexusDB
Check this Wikipedia article: Comparison of relational database management systems.
There's more than 50 RDBMS's listed and you'll probably find something that suits your needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Has anyone used all three of these databases? What are your experiences with them? PostgreSQL looks pretty tempting for a project but I'm curious to learn more about it (We're a .NET Shop). I've also heard of quite a lot of people being satisfied with DB2.
I work in a very large organization that uses DB2 primarily on Linux (Red Hat). We have a number of large databases and have investigated moving to other RDBMS solutions, such as Oracle and SQL Server. I did a lot of work on the SQL server end of that.
We found that SQL server performs much better and requires less tuning than DB2, especially when tables frow larger than 1M records. HADR is also difficult and bulky, to say the least.
We found many differences between DB2 and SQL Server, and too many to list here. I was responsible for doing a lot of the engineering behind code conversion from one platform to another, and can't say I found anything in DB2 to be superior to SQL server, but did find many things I liked better about SQL server. Here are some off the top of my head:
Better selection data types in SQL Server, such as MONEY and SMALL MONEY.
Mixed character encoding in SQL Server. Some columns can be ANSI and others UNICODE (char and nchar, respectively). Setting this up in DB2 is neither straightforward nor easy.
Better tools in SQL server, mainly SSIS for ETL (As opposed to the insanely priced IBM Data Stage).
SQL server has more forgiving syntax. For example, you don't need semi-colons everywhere. Maybe just a personal preference but I found it much easier to code in T-SQL.
Many advanced features seem to work better in SQL server. For example, SQL server lets you do page-level compression, where DB2 is limited to row-level compression.
It was easier to tune SQL Server queries with the SQL Server IDE
There are more, but honestly I suggest that anyone who is considering one over the other should set both up and spend some time working with both systems. Right now it seems like SQL server is a better overall solution, but DB2 may one day take the crown.
Lastly, when dealing with data warehousing, SQL, SSIS, and SSAS made a much better solution than InfoSphere, DataStage, and DB2. I could write a whitepaper on it, but my suggestion here is to set it up on your own and spend a week or to playing with each solution. Microsoft's solution here was faster and cheaper than IBM's. I don't know of any other basis upon which to make a decision.
Platform shouldn't be an issue since databases generally run on their own machines, but there are always those "no microsoft!" and "no linux!" shops around. It's a shame, really. I'd recommend SQL server.
As a DB2 person, I can offer a few details about what you could expect from running DB2 for Windows and developing .NET applications for it. The following details were current as of version 9.7, which was released in June 2009.
Drivers and API support for just about any Windows programming language and IDE, including .NET and Visual Studio extensions
A no-cost, production-ready database engine (Express-C) that has no database size limit and is the least restricted when compared to Oracle Express and SQL Server Express
A self-tuning database engine for Windows that automatically handles the sizing of several memory buffers that are critical to good performance
Rock-solid support for XML as a native datatype, handled by its own dedicated query engine that is optimized for XML's hierarchical nature. Queries can access any combination of XML and tabular data with any combination of SQL and XQuery expressions
Avoid microsoft like the plague. Always push to use PostgreSql even on windows, way better support for developing applications for e.g. Java/Python and still has good support in .NET. Also of course is completely free which given the current license fees for SQL Server is nothing to be sniffed at even if you're a multi-million dollar company.
For the cost of 1 SQL Server license you are going to save £30,000 (say $40,000) or more - buy better hardware to run Postgres on and still have a net benefit.
As far as performance, really if this is such a massive issue we should not be using either DB2, SQL Server or Postgres anyway. The difference between the three is negligible for their design purposes.
Edit: On the .NET integration, actually this is really poor in SQL Server anyway, it does have more features than Postgres/DB2 admittedly but it's not really hugely advantageous over SSIS or stored procedures. I could see the main use case in my work as accessing classes and functions from a CLR .dll but then you're implementing logic in the database which may or may not be a good idea for you.
If you're a .NET shop, and are either using a small database (i.e. Sql Server Express), or have the money for the full SQL Server, use it. SQL Server will perform better than PostgreSQL for most actions, and about the same as DB2.
PostgreSQL is fantastic if you need multi-platform support, are Linux-based, or need a free product that's not Microsoft.
I haven't used DB2 in over 10 years, other than running an in-house performance test vs. other databases (where it was about the same for a transactional database as Oracle/SQL Server, where were better than MySQL, PostgreSQL, etc).
If you are a .net shop stay with SQL Server.
Using any other database platform would require non-Windows to get the best out of it. On Windows, SQL Server is king simply because MS own both OS and SQL Server (Like Oracle/Red Hat).
I think there is an upgrade/downgrade path between MySQL and DB2 because they are both pretty ANSI standards compliant.
Other than SQL Express, is there a similar pairing of free-"ish"/paid databases for SQL Server?
Another way to state the question-- of the free db engines that exist, which is the least painful to migrate T-SQL to?
Update--
Background: I'm looking for a suitable downgrade path. I wrote an app that I wanted to post to codeplex and then I realized that the likely audience might not have admin rights, wouldn't be able to cope with the administrativia of MS-SQL, etc.
There is a free version of Sybase ASE available; Sybase supports T-SQL.
One of Microsoft's big advantages with Sql Server over other offerings is that they have a complete compatible solution, no matter where you are on the size-spectrum: from simple desktop engines with SQL Server Compact Edition all the way to massive warehouses with SQL Server Enterprise Edition, you can be confident that there's an upgrade path for your data. The idea seems to be that if your data scales beyond what SQL Server Express Edition can handle, you're doing well enough in your business to afford one of the more expensive editions.
This is especially true because once you're into that scale migrating to another database is not trivial and will be expensive in it's own right. Once your system is that large and complex even simple differences between database engines can be a big deal. Fortunately for most of us, Express Edition is pretty capable.
So in most cases the next upgrade path from SQL Server is... SQL Server. If your database is big enough that a free edition won't cut it, it's big enough that we really need to know exactly what your goals are and what you are trying to accomplish to give you a good recommendation on an alternative.
MySQL is probably the closest that I've used. Postgres is special in its own way, and doesn't do a lot of what T-SQL does. SQLite is lacking too many functions to even come close.
That being said, the most pain you'll run into (I've found) is around string and column manipulations. MySQL often offers a direct translation, if not that function, at least in my experience.
One of our clients is upgrading their servers because the old machines can't handle the load of the database anymore. They have been using sql 2000 for the last 6 years and the db has grown to hold a few GB of data.
Will it be worth upgrading to 2005 or 2008? What are the major benefits of the new versions compared to 2000?
In addition to the CLR integration mentioned by Galwegian, the main pluses for me are:
there is much better XML support in 2005
Common Table Expressons
Another difference to note is that instead of the DTS packages that you would have been used to Sql 2005 uses Integration Services, which while similar is a whole different ball game.
Depending on what edition of SQL Server you are using, SQL 2005 have less restrictive hardware limitations/caps than corresponding editions in SQL2k.
For example, SQL 2000 Standard Edition won't use more than 2Gb (in practice 1.7Gb) while SQL 2005 Standard Edition is not capped (allows up to OS max).
See:
http://msdn.microsoft.com/en-us/library/aa933149(SQL.80).aspx
...and...
http://www.microsoft.com/sqlserver/2005/en/us/compare-features.aspx
So: if you're running standard edition + your SQL Server 2000 instance currently uses ~1.6Gb RAM + your server has 3Gb or more physical RAM then it is probably worth upgrading just for the benefits increased memory usage brings... (more cached table data, indexes, plans etc)
I you are planing to upgrade from SqlServer 2000 I would skip 2005 and go directly to SqlServer 2008
It has all the features of 2005 plus some extras (for example an option to pass a table variable as a parameter to stored procedure, new date types, spatial data handling,etc.)
You can refer to Advantages of MS SQL Server 2008 over MS SQL Server 2005 question for the comprehensive list of features
EDIT
I can see that the question has been updated and now SqlServer 2008 is included in the question.
MS SQL 2005 and 2008 have a lot of hyped technologies, one of them is the ability to stuff CLR code into Stored Procedures. DON'T DO THIS!
Another "feature" is the ability to expose your database as WebServices, yet again; DON'T DO THIS!
A third feature is the ability to use "notifications" from your database and into your application layer, yet again; DON'T DO THIS...!
You database is a bucket and it should "store data", period. A lot of the features Microsoft put into 2005 and 2008 I feel sure they did because they wanted to complicate the usage of O/RM libraries which abstracts away the actual database vendor so that people can change databases as they wish. Then by adding a lot of "stupid features" which goes against every single Best Practices we've learned about databases since the 70s they managed to create a new lock-in which removed the vendor locks by making people use stuff they really shouldn't use anyway...
A part from that there might be a lot of cool features in 2005 and 2008 (like one mentioned here; support!) and things like optimalizations, bugfixes and such. But be careful so you don't start using stuff that craps down your app and makes it impossible to use best practices and locks you in... :(
The main benefit is CLR integration to be honest - it allows you much more flexibility in the way you code your database, giving you the option of including procedural C# or VB.NET in your procedures instead of set-based T-SQL.
There are some new features that are useful, like service broker for example, but in performance terms you aren't going to see huge improvements in moving from 2000 to 2005. You would be much better off a) tuning your DB and b) investing in new hardware.
I think that SQL Server 2000 is no more supported by Microsoft. If I'm wrong, it will be soon...
Separation of users and schemas is another goodie. In SQL 2005, if you want schema separation by logical/functional area or similar rather than by user in your database, you can create schemas such as "hr", "sales", "accounting", "production" and then create user tables under the respective schemas.
In SQL 2000, the schema name was identical to the table owner/creator.
Online index rebuilds are a nice feature to have. I think it might only be an option in Enterprise edition though.