What are the maximum number of tables that you can have in:
SQL CE4
SQL 2008 R2 Express
Numbers here http://msdn.microsoft.com/en-us/library/ms143432.aspx I guess is for SQL Server 2008, but are they valid for Express and what about SQL CE4?
The sum of the number of all objects in a database cannot exceed 2,147,483,647
BTW. Sorry for duplicating questions, but it seems to me Stackoverflow is providing answers more quickly.
No word about CE, but Express is normal SQL Server + database size and memory / processr limitations.... If you can fit yoru tables into the size, the normal SQL Server limity apply.
SQL Server Compact 3.5 limitations here:
http://msdn.microsoft.com/en-us/library/ms172451%28v=SQL.105%29.aspx but that only points out 1024 columns per table and no specific table limitation.
SQL Server Express is the same as normal SQL Server as TomTom points out, it's just limited by memory, processor and database size, the limits of SQL Server Express edition are:
Constrained to a single CPU
1GB RAM
10GB database size (4GB in versions before SQL 2008 R2 Express)
Otherwise express edition is standard, this is to allow databases to be moved to and from SQL Server Standard to SQL Server Express, which helps in system development. So for SQL Express it's still The sum of the number of all objects in a database cannot exceed 2,147,483,647
As I said in a comment, if you're doing anything that gets close to hitting these numbers you should really look at your DB design process, if they're being automatically generated then consider not partitioning into so many tables.
By this I mean that you should be selecting your SQL Server version based on other requirements, if suppose SQL CE is limited to 256 tables (not saying that it does since I can find no such thing, and it's much more likely to be at least past 1024), and say you need 500 tables. Then either look at denormalizing some of your tables, or at that point you really need to upgrade to including SQL Express with your program (this just complicates your software deployment process, and not a lot more).
I don't have SQL CE avail atm, but the easiest way would be to just have a test go run off and generate 10k create table statements, with each table having 20+ columns. If your requirements are greater than that then just use numbers that you know.
Lastly, there's SQLite which you haven't asked about, again there's no documentation on this but I suspect it's likely 64k+ you're limited to only 64 tables in a join though.
For SQLCe4, I got the response:
There is no limit on number of tables, but we do have a limit of 4GB
file size.
Related
I've decided to develop VB.net Application With SQL server Express 2008, but Microsoft says:
They limit 4 GB Size per DB!
So I'm developing my app for Single user Desktop pc, so what should I do when the DB reached the Maximum size?
When the DB size reached to maximum size, is it a good thing to create a new DB and allow my vb.net application to work with both DBs?
in regards to the 4GB limit of your free version of SQL Server, your options as I see them:
1) purge old data as it becomes unnecessary
2) hack application to use multiple databases (would this even work on a single pc?)
3) hack your application to move items to data files as necessary and out of the DB
4) pay for the proper version of SQL Server
5) go to MySql or something similar
SQL Server 2008 R2 Express size limit was increased to 10 GB, so if your just starting a new project you should use 2008 R2.
Nothing wrong to attempt for free tools. I suggest that you redesign your application to use multiple databases.
1) Create a new table for storing multiple databases setting data
2) Things to store in that table include: total databases, connection string for each database, and so on.
Consider storing each table in a separate database (where appropriate)
If you expect to exceed 4GB (are you sure?) then some options might include...
archive older data into a separate database
don't use sql-server express -- use a standard version that can grow.
I'm looking for the benefits of upgrading from SQL Server 2000 to 2008.
I was wondering:
What database features can we leverage with 2008 that we can't now?
What new TSQL features can we look forward to using?
What performance benefits can we expect to see?
What else will make management go for it?
And the converse:
What problems can we expect to encounter?
What other problems have people found when migrating?
Why fix something that isn't (technically) broken?
We work in a Java shop, so any .NET / CLR stuff won't rock our world. We also use Eclipse as our main development so any integration with Visual Studio won't be a plus. We do use SQL Server Management Studio however.
Some background:
Our main database machine is a 32bit Dell Intel Xeon MP CPU 2.0GHz, 40MB of RAM with Physical Address Extension running Windows Server 2003 Enterprise Edition. We will not be changing our hardware. Our databases in total are under a TB with some having more than 200 tables. But they are busy and during busy times we see 60-80% CPU utilisation.
Apart form the fact that SQL Server 2000 is coming close to end of life, why should we upgrade?
Any and all contributions are appreciated!
Besides all the features MatthewPK mentions, I also really like:
Common Table Expressions (CTE) (which I find extremely helpful) - see Using Common Table Expressions, SQL Server CTE Basics or SQL Server 2005 Common Table Expressions for more details
Ranking functions like ROW_NUMBER, RANK, DENSE_RANK and NTILE - see Ranking Functions (on MSDN) or New Ranking Functions in SQL Server 2005 for more details
OUTPUT clause in SQL statements to output information about e.g. rows you've deleted with the DELETE statement, or updated with your MERGE statement - see the SQL Server Books Online for more details.
I'm taking care of an old SQL Server 2000 solution, and boy, how many times have I missed those features!
There are a number of reasons to make the migration, I'm sure.
My favorites are:
New DATE datatype (no more having to format strings to compare timestamped dates)
New Spatial Data types (geometry, geography)
New MERGE statement is great for upserts or any other "if exists" type logic
FILESTREAM gets you out of the blob problems (enforced DB integrity on filesystem directories!)
IMHO, from a developer's perspective, the most important upgrade is the TVP
The only shortfall I've personally encountered is that I had to rewrite my DTS packages to SSIS packages (but I think SSIS is great... just more work)
From a purely practical perspective, the most compelling advantages for me are several powerfull TSQL commands that are not available in 2000, e.g. PIVOT/UNPIVOT, and the addition of the intelligent syntax expansion to the 2008 Management Studio that made working with this tool substantially more productive.
We ported a database server from SQLServer 2005 to SQLServer 2008 (SP1). The new server has more Processors (4 Quadcore versus 1 Quadcore ) and more memory (4GB versus 64GB).
Processors are 2.1Ghz(new) versus 2.0Ghz(old).
The new OS is Windows Server 2008 and the old is Windows Server 2003.
The databases were transfered via backup/restore and run in native SQL Server 2008 mode (not in SQLServer 2005 compatability mode ).
Some queries on the new server run slower than before. These queries use indexed views. The queryplan looks the same on both systems.
Most of the queries perform equal.
My task is now to decide if we have a problem with our SQLServer installation, if the we have a problem with the database or if this is an expexted result.
I first want to compare performance of both
Sytems
SQLServer installations.
Is there an easy way to do this?
Has anybody had comparabele results on new SQLServer installations?
Before you check your hardware/OS, make sure you:
update statistics
rebuild all indexes
and then run your tests again. Also, are the editions of SQL Server identical? There are differences in how you have to write queries against indexed views based on the edition (Standard vs. Enterprise) of SQL Server.
Also, confirm that your indexed views are still indexed properly by selecting 1 row from them and observing the query plan. You should see only one table in the resulting plan.
The easiest way to collect performance of both systems is to run a PAL, and collect the approriate data.
PAL has extra counter sets for SQL Server. It will collect and analyse the data, and let you know where you have an issue.
PAL can be found here
http://www.codeplex.com/PAL
Also an important issu is to location of the filegroups. How is the underlying storrage system defined? It usually has a huge impact on the SQL Server. (You should talk about spindels here, and not raw size...) Make sure your database files are not sharing the resources with anyone else
What is the difference between using SQL Express .mdf file and an actual SQL Server DB? Why wouldn't I use .mdf file for everything? Is there a size or performance limitation that would prompt me to use SQL Server DB? I currently use actual SQL Server DB's for every project I work on so I am just curious to know if an .mdf file might be more cost-effective.
SQL Express runs only one scheduler, so can use basically only one processor. It imposes a hard limit of 4GB on database size. It won't use more than 1 GB of RAM. And many features are license restricted, like certain replication scenarios. See here a full comparisson.
SQL Server Express has features deliberately removed to make it less useful. For instance, databases are limited to 4 GB in size, and it can only use 1 GB of RAM. I recommend you look into FOSS databases like PostgreSQL and MySQL, which don't limit you like this.
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.