Is using SQL Express in a production environment a reasonable choice?
I looked at Microsoft's comparison chart:
https://www.microsoft.com/en-us/sql-server/sql-server-2019-comparison
I would be using SQL Express with a small to mid-sized web site. I don't believe I would exceed the 4GB database size limit. Is SQL Express typically supported in shared hosting environments? Is there something I'm missing that would make SQL Express an unreasonable choice?
I know many people using SQL Express for production and it works well, the biggest limiting factor is the absence of SQL Agent for automated backups. To automate backups you have to either take a VM image (if on a VPS) or use windows scheduler or some other technology.
The only other major limiting factor is the ram limitation, but for a small site I have not really noticed that being too much of an actual issue.
Many cheap hosting companies uses SQL Express. And I know from personal experience that SQL Express is a viable solution for most things.
"Most things" includes a large project in a production environment.
One thing to ask might be - if your needs outweigh the capabilities of SQL Server Express, will you be able to afford a commercial version?
I think the one of the ideas of SQL Server Express is that you could host your site on it and once you outgrow it (need more than 4GB, etc.) you will buy a commercial version, especially now that you're locked in to using it. But if your site will outgrow it sooner than the income coming in will be able to buy a commercial version, this could be a problem (and possibly a database design flaw if your site is consuming more data/disk space than it needs to)
SQL Express is a great choice if you don't mind the memory and processor limitations. The database size limitation is not as much of an issue now that in 2008 R2 they up'd the limit to 10gb. I think the other limitations are still the same though.
There's a maximum of 5 concurrent connections for SQL Express. If you have more than 5 concurrent connections performance will drop severely.
Alos, you have to consider that SQL Agent is not included so if you want to schedule backups or maintenance tasks you have to use windows scheduler.
Other that this, it's a perfect solution for small databases.
Related
We are in the process of rethinking our development environment. At the moment, we all have Elitebook notebooks which are not as fast as we'd like. We're thinking of virtualizing our development environment to a central VM server.
Our developers work in Visual Studio and use SQL Server as a database. We also have a few SharePoint developers who need a 64bit Win2k8 machine for SharePoint 2010. These are already virtual machines with their own local SQL Server installation.
Every developer's machine or VM has SQL Server installed. This requires resources from all boxes, and is challenging when working with a team on a project. Therefore we're looking into the possibility of centralizing the resources into a single DB server. That box would have to run multiple SQL Server instances (each Sharepoint developer needs a separate one to begin with). We also have the need for an older SQL Server 2005 and SQL Server 2000 installation for backwards compatibility. Besides the SQL Server box, the plan consists of a VM session for each developer with the development tools installed. So a developer could just RDP into the development environment, have his own image and make use of the centralized DB server. Test servers will also be virtualized in the same environment.
I'm looking for some tips and best practices on this matter. For instance:
What's the number of SQL Server instances a normal box can take? And if we upscale virtualized cores / memory; is that enough to add new instances? I don't expect heavy usage in dev.
What's the downside on centralizing the SQL Server instances as opposed to keeping a local instance on every development box?
How should this be integrated in a DTAP strategy?
Just some thoughts:
The number of instances is hardware dependent; I'm not sure if there's a mathematical formula to help calculate how many instances you can run on a VMbox, but it sounds like you're going to need a beast of a machine to run multiple instances per developer PLUS development tools (I can barely get SSMS and Visual Studio to play nice on my laptop). Better hardware = more cost.
Developing on a terminal system may have some advantages, but I can think of a few disadvantages as well:
network latency. If your developers work remotely at all, they'll
need a fast internet connection in order to do anything. If the dev
environments stay on their laptops, they could work disconnected.
instance interdependence. Although SQL Server instances are
completely seperate, sometimes you gotta reboot the server. You'll
need to coordinate that with all of your developers (may not be a big
deal if there's only a handful of you).
redundancy/maintenance. If one developer's machine is down, you
lose a person-day (is that even a word?) of productivity; if the
server goes down, your company is paying for a holiday for everyone
:)
Have you priced out what it would cost to upgrade your individual workstations so that you could compare costs on building out a centralized infrastructure?
Again, these are just some challenges that I think you should consider; there are probably ways to offset them, but they may factor in to your decision.
I would centralize the database servers as best as you can. Having all the dev's work off of centralized database instances should make migrating changes between environments MUCH easier. That alone is worth the effort.
For the SharePoint development environment, I'd highly recommend investing in a few books to make sure you go down the right path. You should be able to have all the dev's working off the same development instances for that too. Here is a good book on the subject, I'm sure there are others: SharePoint 2010 Development
As far as making the developer machines VM's too, I would seek the input of the development staff first and foremost and seriously consider Stuart's pros & cons.
I am considering the migration for 4 reasons:
1) SQLSERVER installation is a nightmare, expecially for 1-user software (Even if typically I have 3-20 users, sometimes I sell my software to single users: it is incredible to have troubles installing the DB, while installing the applicatino means copying an exe...). (note my max installation is 100 users, but there is no an upper limit). Software installs in 10 seconds, SQLServer in 1 hour. Firebird installation is much easier.
2) SQLSERVER runs on windows server only
3) My customers have all the express edition
4) i am not using any advanced feature, I am now starting using filestream, but the main reason for this is that Express edition has 4/10GB db size limit
So these are all Pros of moving to Firebird.
Which are the cons?
I can also plan to support both platforms, but this will backfire I fear.
MSSQL server is faster and better optimized for large databases and complex queries, especially if administered properly, while Firebird alows you to run without any administration and just forget about it. Although this penalty affects very small percentage of people using it, before complete migration I suggest you to first just migrate data and then test speed of most complex query on both systems. If speed satisfies you then you are good to go.
I don't see any besides need to thoroughly test all of your existing code for compatability issues.
Firebird is wonderful for server installations or single user installations.
It has an embedded version that is suitable for single user scenarios and you do not have to install anything.
It uses the same database file for both server and embedded database so you can easy go from single user to multi user and vice versa.
I have embedded Firebird 2.5 today in my freeware Software. It's great, and there had never been connection problems. I used multiple processes to do both insert and read long operations simultaneously and it all gone correct as was expected. I am waiting for Firebird 3.0. I recommend Firebird when you don't want to trust on other commercial database software.
If there is only one user you can use Sqlite which is even easier to manage than Firebird.
We have been using sql server 2005 during development and have had no real issues.
Now at the time of the release, it has been suggested we go with SQL server 2008. The installation of it is a bit of a nightmare with all the configuration options and I am sure this will confuse the customers (even with documentation). Powershell etc had to be installed together some other apps before it could install, as well as some windows updates.
Should we just release with SQL server 2005 (if I am not wrong the installation was easier) or would it be better to go with 2008 (and just accept the installation issues)?
JD
If you've developed and tested on 2005, then stay with 2005 to avoid complications, but I would upgrade everything to 2008 at some point.
Based on the information provided, stick to 2005.
Migrate to 2008 after you've been able to run the application in a test environment, thoroughly test it, and check documentation to be sure things line up.
I'm always wwary of making last-minute changes to an application before release. If you decide to switch to SQL 2008 will your team have time to fully regression test your application? I wouldn't just assume that everything will work fine.
If you have the time for full regression testing then the question is, what does SQL 2008 offer to you? Obviously there's no critical technical reason - no function that is in SQL 2008 that isn't in 2005 but which you absolutely must have. Do you think that your customers will care one way or another? Do you have customer that already have 2008 servers and want to leverage that? Will it help your sales to be on the "latest and greatest" version?
Those are just some of the questions to ask.
You can always save the switch to 2008 for a future upgrade.
The install/config issues shouldn't really be the primary focus, because those are one-time things and a well-written guide can address the vast majority of the issues you encounter.
Here's what I would consider making my decision:
Testing - Everything should work fine out of the box, but you're responsible either way. Better the devil you know than the devil you don't. There is a time and a place for upgrades, and right before a release isn't it.
Licensing - Remember that newer software often comes with a higher price tag, and you don't want to be forcing more expensive software on your users without some tangible of benefit.
All in all, I would stay away from upgrading for upgrade's sake. Stick with what you know, until there is a legitimate gain from upgrading.
In a few years time new customers will not be willing to run with SQL Server 2005, so you will have to support SQL Server 2008 at some point.
My experience is it can be very hard to get current customers to update to a new version of a database server when you wish them to take an upgrade of your software, so you will most likely be forced to support SQL Server 2005 for a long time if you allow your customers to use it now.
So do you wish to?
Have some pain now getting SQL Server 2008 working
Or, have the cost of testing and supporting both SQL Server 2008 and SQL Server 2005 every time you do a new release for many years to come
You have to decide if a small delay in releasing is worth it to save the ongoing cost...
This is hard, as time-to-market is often more important in the real world then ongoing maintenance costs. After all if you don’t hit the market window, you have no ongoing maintenance costs!
Will this delay your release? Will it delay it enough to cost money?
I wouldn't worry too much about the installation complication. Your customers will experience the same (or worse) when they have to upgrade to 2008, which they will eventually because you won't stick with 2005 forever. I'd be more concerned about how it affects your project and sales. That would be the trade-off that I would focus on.
I have a VPS with Windows Server 2008 R2, 1 GB RAM with Dual Processor Quad Core 2 CORES.
My sample application is running slower than my current website on shared hosting, when I asked the reason the says following reason:
"SQL Server Express tends to be slower compared to SQL Server Web edition. This is due to the limitations imposed in SQL Server Express which is basically meant for only development environment. We have observed significant amount of improvements with SQL Server Web edition for production web facing applications on VM's. Hence, this can be something that you might consider."
Is this logic just because they want to sale the Web edition database or there is really some performance benefit. I googled and I didn't find anything like that between different versions.
Any help on this from experts?
This is due to the limitations imposed
in SQL Server Express which is
basically meant for only development
environment.
That is absolutely wrong.
SQL Express is used in many, many, many production environments, where it can be a great tool.
SQL Express is not throttled in terms of the number of queries per second it can process. However, as others have said in their answers here, it is limited by RAM (1GB), DB size (4GB) and CPUs (1). If your DB is between 1GB and 4GB, you could easily notice a performance difference vs. SQL Web for scenarios where everything fits into memory on one, but not on the other.
Having said that, there are a bunch of other configuration / setup / design options that can have a much larger impact; the details depend on your data, schema, access patterns, etc.
hope that help:
[link text][1]http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx
I'm starting a new project here (Windows Forms). What's the best option today for a small (free as in beer) DBMS?
I've used SQL Server Express on the past projects, but time and time again I hear people saying that the product from Oracle is faster and more powerful.
It will be used in a small company (around 20 users) and will not reach the 4 GB limit any time soon :)
I don't want to start a flame war on my first post, so please point me to some link showing a good (and actual) comparison between the 2 products, if possible.
PS: I've heard about IBM DB2 Express too, but I coudn't find any information about it. (Marketing material from IBM doesn't count :) )
I would go for the SQL Server Express solution, unless you absolutely have to use a feature in Oracle that SQL Server does not have and you have no usable workaround.
Example of Oracle's strengths:
Analytical Functions in Oracle ROCK!
PL/SQL is better than T-SQL.
If you're going to scale up the system to 1,000's of users all updating the same small dataset
You scale upto multi-TB databases,
You need to scale to need big numbers of CPU's in your server (over 8).
need instant failover (RAC)
you really cannot afford to lose a transaction.
Maybe you can tell, I'm a big Oracle fan! But I think that Oracle Express is a commercial reaction to SQL Server Express and I don't think Oracle really deep deep down likes it.
You know with SQL Server that there is an upgrade path (SQL Server 2008 is soon) plus service packs.
SQL Express is also more "install and forget" than Oracle.
and it will integrate better with your IDE (if your using .NET)
In terms of speed, both are going to be lighting quick with such a small dataset size.
It would be hard to argue either way given the needs you outlined, that either would shine over the other.
What I will say is this:
You say you are already familar with SSExpress, then that is a good reason to stick with it
IMHO the tools with SSExpress are superior and easier to use than the Oracle equivalent
That said, I have much more experience with SS than Oracle so YMMV.
Sorry, no link, but one advice. Because we support Oracle and SQL Server, I know that getting fixes for the 'normal' Oracle database, is not something what I call fun. You have to pay for it, and if you have no tool which updates your Oracle system for you, it's a pain in the a.., if you ask me. Check out how the Oracle XE is supported with updates/fixes. I don't know, I only use the 'normal' Oracle (Developer) database.
I think it's great to rethink things every once in a while and that it's very smart to consider alternative products when you are at a junction to do so.
If you are comfortable optimizing systems and are dba level in skills, I'd consider PostgreSQL. I do not consider myself a dba and have middling database skills and find SQL Server Express extremely easy to use. Also, I've had products exceed the limits of SQL Server Express - the transition to SQL Server Standard/Enterprise is seemless.
I realize that this doesn't matter at a technical level, but Larry Ellison buys jets and prostitutes with his profit. Bill Gates is solving problems of immense importance to humanity with his. All things being equal, I always prefer to give my money to Bill Gates.
Is this any use:
https://web.archive.org/web/1/http://downloads.techrepublic%2ecom%2ecom/5138-9592-6028761.html
NB Registration is required
Both of KiwiBastard's points are very good and I completely agree with him.
If you really want a free alternative that is similar to MS SQL and supports growth should you need it, you could have a look at MySQL or PostgreSQL. SQLite also seems a good choice.
Surely you can afford an old Linux server if you work in a company with 20 employees.
100% SQL Express, more easy to install and maintain than Oracle.
IMHO the major problem with SQL Server, has for a long time been, no multi-version read consistency. Fortunately this has been corrected since SQL Server 2005 with the snapshot isolation level.
If your looking for a good RDBMS for a small project requring minimal knowledge for maintenance, SQL Server Express Edition is a good pick. The SQL Server Express Edition UI is much easier to understand than RMAN or the "easier"-to-use backup scripts included with Oracle Database XE which requires offlining your database.
Oracle Database XE is on my *** list. They recently released an ODBC driver for Linux that wasn't compiled properly (ld returns missing symbols for required ODBC functions) to be at all usable (10.2.0.4). With this kind of lack of attention to any reasonable amount of QA even for a 'free' product I would think twice about going down that road.
For DB2 Express-C see:
"DB2 Express-C™ is the free version of one of the most advanced
database management systems in the world. Why pay when you can have
all you need for free? DB2 Express-C is free to develop, deploy and
distribute.
It is a fast, secure, reliable, and amazingly scalable dataserver,
ideal for most startups and small/medium sized businesses. DB2
Express-C 9.7 is available on Linux, Unix, Windows, and now Mac OS X
as well! It also enables developers to easily handle XML through the
native storage technology called pureXML™. Whether you develop in
Java, .Net, Ruby, Python, Perl or pretty much any other programming
language out there, DB2 can be your technological advantage."