I have a questions regarding databases for ASP.Net 4.0 MVC3 (or 4 Beta).
I'm fairly new to the ASP.net MVC environment, and usage of databases in general.
It's stated that the SQL Server Compact is a local database storage. What does this exactly mean? If I were to use this for my web app, would users be able to "access" this database (e.g. register, login), or would I be the only one with access since the file (.sdf) is "local" and is only in my hard disk?
Let's say I'm coding a library management system which would require storage of alot of stuff in the DB. Would it be better to just use the SQL Server Compact that comes with Visual Studio or should I switch to MySQL or some other databases?
I'm asking because I wanna clear everything up before I step into the world of ASP.Net (and since I'll be dealing with DBs alot in future).
The "local" is relative to where the application code runs, not where the user is. If you're using ASP.NET MVC, the application code runs on the server, to the database has to be on the same server. All users using the web application can use it though since the access is done by the application.
I'd use SQL Server Express for that, version 2008 R2 does have a limit of 10GB per database (not including FILESTREAM data AFAIR) but that is already a lot of data. It's free but uses the same engine as the full SQL Server products, but it has some limitations on database size (as mentioned) and resource usage (parallel processing and memory), for many application it is still a perfect solution though.
No, in this case "local" means that it's contained within the package of the web site itself. You'll want to deploy the database file along with the website (but take care not to overwrite it in future subsequent deployments), of course. But the idea is that the database is a file that you put on the server, not a service installed on the server.
Define "a lot of stuff." I doubt you're going to exceed the capacity of SQL Server Compact, or absolutely require features it doesn't provide. You'll want to compare all of the features available in the various databases. (Size limits, native data types, ease of integration, ease of management and deployment, stored procedures, etc.) Chances are any database will work for you, but you'll have to define your needs in more terms than just "a lot of stuff."
1)
SQL SErver Compact edition is a light weight free, embedded, database engine that enables easy database storage. That means you dont need to install any software in a computer for this database to work. you can simply copy the dll of SQL Server compact edition and put in your bin directory and start using it. No additional setup or security permissions are required for it to run.SQL Server CE Stores database as a files on disk. The file extension will be .sdf You can store SQL CE database files within the \App_Data folder of your ASP.NET Web application
Here is how it looks like in a project.
You can do the same things you did with a standard sql server express instance with SQL CE too. So your users would be able to access the data ( thru your application).
2) SQL Server CE would handle this up to an extend. If you have so much data coming in, you probably want to try something bigger like SQL Server express edition etc.. But the migration is easily doable because it is a miniature version of the real SQL Server Database.
If you are in a shread hosting environment and dont have the ability to install / get access to SQL Server instance, you can go with SQL Server CE as it is file based.
This is a good reading to start with : http://weblogs.asp.net/scottgu/archive/2010/06/30/new-embedded-database-support-with-asp-net.aspx
Related
A colleague I work with recently told me that SQL Express and MS Access were essentially the same thing; that does not seem to be an accurate statement. I know you can convert Access to a SQL DB and maybe under the covers they are similar, but I would assume that the SQL DB engine and what is used to run access are not the same. Not only that, but the SQL statement syntax, etc. I know are not the same.
I am mainly trying to understand so that I am more informed about the versions.
Um, no, not the same.
First off, I need to clear up some terminology. MS Access is a Rapid Application Development (RAD) tool that allows you to quickly build forms and reports that are bound to relational data. It comes with a file-based database engine (Jet/ACE).
Access the RAD tool can be used with many different backend databases (Jet, SQL Server, any db that supports ODBC, etc). I have to assume your colleague was specifically commenting on Jet/ACE, ie the database engine that MS Access uses.
I think the single biggest difference between the Jet/ACE database engine and MS SQL Server Express is that Jet/ACE is file-based and SQL Server Express uses a client/server model. This means that SQL Server Express requires a running service to provide access to the datastore. This can complicate deployment in some scenarios.
SQL Server Express is really just a throttled-back version of SQL Server: max database size of 4GB (10GB in 2008R2), only uses a single physical CPU, etc. These limitations are imposed to prevent large organizations from using the freely available Express edition in place of a full-blown SQL Server install. The upshot to this is that SQL Server Express offers a truly seamless upgrade path to SQL Server. It is also (generally speaking) a more robust and fully featured database management system then Jet/ACE.
Similarities
relational database management systems
written by Microsoft
Differences
MS Access
File based
free distributable runtime (2007 or later)
RAD tools (form/report designer)
uses Jet SQL
max file size 2GB
SQL Server Express
Client/Server model
free
no RAD tools
uses Transact-SQL
max database size 4GB (10GB for SSE R2), max one physical CPU
I think what your colleague had in mind was SQL Server CE, which is a super-lightweight embedded database, which is still (IMO) far superior to Access in database-management aspect. SQL Express cannot even be compared with Access without offending the former.
Here are the datasheets for both products so you can see some hard facts on the difference between the two databases.
Access:
http://office.microsoft.com/en-us/access-help/access-specifications-HP005186808.aspx
SQL (Express is listed on the far right column):
http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx
The comment I have always read is that Access is great for single user single access database use, the minute you scale beyond a single user look elsewhere. While that may be a "bit" of a stretch, Access really does not do well in a multi-user environment. From experience we've had a client who has ignored and ignored our requests to migrate a backend database from Access to SQL, and there have been numerous occasions where we have had to restore from backups, or take the Access database offline due to corruption.
They are two completely different technologies with two different target markets. The database engines are indeed different, as you mention T-SQL is different than Access SQL.
You can "scale up" an Access database to SQL by creating an SSIS package or other tool to do the import, but this takes the Access schema and data and migrates it to a true SQL database. It does more than just attach the Access database or the like.
Anytime you need a "real" database I'd highly recommend looking at any of the SQL versions that are available over Access.
Just remember that with MS-Access you don't have size limitations if you play your cards right. There is no reason, for example, not to have many 2 to 4 Gig tables each contained singularly in their own database. Your ODBC applications can open a connection to multiple MS-Access databases and query the single table in each. So you can have a database containing trillions of records, stored in multiple MDB files. One company I went to work for was using a single MS-Access database to run a issue tracking system done in MS-Access forms. They could only use it one person at a time because of sharing issues that would lock MS-Access up. I wrote a Win32 Perl native Windows GUI user-interface to the database that was better at field/record validation, and my ODBC code was able to manage the connection for simultaneous user access. I managed the opening and reading and writing and closing of the database for each user through my Perl program. I did not leave the database open. I did not maintain a persistent connection for each user, but instead only maintained a connection long enough to retrieve a record for edit. Then I closed the connection until it was time to write the record back to the database. Also, I wrote my own record locking program logic by maintaining a user login table that contained the record id of the record a user was currently editing, then erased that entry when no longer editing that record. When another user went to edit the same record, the program checked if that record was currently open for edit by another user. The system worked flawlessly. MS-Access never locked up via ODBC and multi-user access. I even embedded the password to the database in my compiled Perl program so that no one could get to the data in the Access database other than through my Perl program.
I have a two-part application, where there is a central database that is edited, and then at certain times, the data is released and distributed as its own application. I would like to use a standalone database for the central database (MySQL, Postgres, Oracle, SQL Server, etc.) and then have a reliable export to an embedded database (probably SQLite) for distribution.
What tools/processes are available for such an export, or is it a practice to be avoided?
EDIT: A couple of additional pieces of information. The distributed application should be able to run without having to connect to another server (ex: your spellchecker still works even you don't have internet), and I don't want to install a full DB server for read-only access to the data.
If you really only want your clients to have read-access to the offline data it should not be that difficult to update your client-data manually.
A good practice would be to use the same product for the server database and the client database. You wouldn't have to write SQL-Statements twice since they use the same SOL-Dialect and same features.
Firebird for example offers a server
and an embedded version.
Also Microsoft offers their MS SQL Server
as a mobile version (compact edition) and there are
also Synchronization services
provided by Microsoft (good blog
describing sync services in visual
studio:
http://keithelder.net/blog/archive/2007/09/23/Sync-Services-for-SQL-Server-Compact-Edition-3.5-in-Visual.aspx)
MySQL has a product which is called "MySQLMobile" but I never actually used it.
I can also recommend SQLite as an embedded database since it is very easy to use.
Depending on your bandwidth and data amount you could even download the whole database and delete the old one. (in Firebird for example only copy the database files and it will also work with the mobile version) Very easy - BUT you have to know if it will work for your scenario. If you have more data you will need something more flexible and sophisticated, only updating the data that really changed.
There are actually two related questions:
is it possible or advisable to use a full blown stand-alone SQL server for SharePoint Services WSS3.0 instead of the supplied windows internal database it comes with? The client I am working for is asking to utilize their existent SQL server for all WSS content databases to possibly minimize admin effort and improve performance.
As well, would you advise to install WSS on one physical server and the content database on another server? Any gain in performace? Practicality? ect. The default is WSS and all of its databases are installed on the same single server. We don't really need a farm setup of MOSS, because the WSS capabilities are enough for our needs.
Thanks,
Val
Yes, when you create the site check the installation to be a "Web Front End" It will then prompt you to select a location for the SQL database. Just point it to which server you want.
I would definitely recommend putting it on a non-Sql Express instance. The express version only scales to 4 gig, limits the maximum number of connections etc. If your client is going to do much with it at all, you will eventually hit that limit. Full blown sql server has other advantages too, like help with backups etc.
Yes and yes.
Keeping the SQL and WSS servers separate saves resources on both, and neither are light weight applications. It also allows you to easily begin clustered/distributed environment in the event your usage increases, as well as following a least privledge principle, keeping product patches separate, etc.
As an addendum, you say you don't need a MOSS farm because WSS fits your needs, but be aware that it's just as easy to setup a distributed WSS environment as is MOSS; MOSS only adds capabilities to the application. It's usually a good idea to have at least two WFE's in the farm, if for nothing else than redundancy in case of failure.
Yes you can use a 'full blown' SQL Server instead of the the free and limited SQL Server Express that is delivered with Windows SharePoint Services 3.0 (wss 3.0)
It's even better to separate the database and the actual website! More scalable (if you upgrade to MOSS), easier to manage and less security risks.
I Want Implement a Software by C#.net.I want Use a DataBase Manager Software like Access or SqlLite or etc.My Program Saved Many Data in Local Machine.
I Do Not Want Publish or Move Data to Other Pcs
What DataBase Manager Software Must be Choose?
Not Different DataBase is Free or have a price.
what is the Best DataBase Manager Software to Save many Data in Local Machine?
For sure you are looking for a free database so for that you can use many databases like mysql ,postgresql , and sql server msde or access
but we still have other scenario, if you are going to distribute this application to other pcs so you have to think about deployment and in this case you can eliminate the mysql , postgresql because they depend on servers but msde (it's also server ) is much easier and you can found alot of tutorials how to deploy it with your project
It depends on how much you are expert in database and for what reason you are using it? are you going to need complex queries or it just a storage place for the data ?
if it's complex query i will go for msde for sql server if it's only for saving information may be i will go for access or even xml
Well if you are developing in C# consider using the MSSql Compact Edition. This allows you to create a local database and use it much like SqlLight. However, the support is much better, especially when you using Visual Studio. There you can find it as LocalDatabase under Data when you adding a new item. (Not 100% sure whether it is present on all versions of VS though).
Firefox has an SQLite Manager add-on.
I think the best choice depends on your needs, for example if you must synchronize data with sql server for me the best choise was sql express.
I would vote for SQL Express. You get essentially a scaled down SQL Server that is capable of working with quite a bit of data. SQL Express plays well with Visual Studio and you will be able to take advantage of the System.Data.SqlClient and related namespaces which come with the .NET framework out of the box. They are also better than the Odbc namespaces. Finally, there is a LOT of online support for SQL Express and, as far as I know, SQL Express's flavor of SQL (T-SQL) is the same as that of SQL Server. So should you one day need the flexibility of running with either or (local database, or server database) you will have it. Also, SQL Express is fairly commonly used in the microsoft world so you should be able to find lots of examples, if need by.
TurboDB for .NET from dataweb is a good solution, if you want a powerful engine with stored procedures and professional support from the manufacturer:
http://www.dataweb.de/en/products/dotnet_database.html
What is currently the best solution for WPF applications which are meant to be used on one computer where various users log into them and use them to get/save information locally? Here's how I see the options:
MDF would seem to be the best choice since I assume you can lock it down quite well so that even though users can access the .mdf file, they still couldn't access the data in it except through the application itself. I assume the .MDF file would have to exist separately from the application so would deploy the .exe and the .mdf file. Oh, if you use an .MDF file, does the user need SQL Server installed to use it as is indicated in this stackoverflow question?
I would think SDF wouldn't be recommended since it has quite a bit of limitations and used mainly for mobile storage.
XML might be appropriate if security didn't matter, e.g. a small one-user application to save data that locally that he wouldn't secure anyway, and this file would be easily accessed by other applications/websites on the computer.
SQLite might be a choice but from what I know the APIs for .NET for this database aren't that robust yet, are they?
.mdb Access might be a choice if you needed users to also edit/view the data or generate reports with Access.
there is also IsolatedStorage but I believe this has serious limitations, doesn't it, e.g. not able to access it from other applications?
perhaps using a cloud service might be feasible and quite straight-forward nowadays, would have to investigate
Would appreciate any feedback or ideas.
SQL Server Compact edition is also an option - http://www.microsoft.com/Sqlserver/2005/en/us/compact.aspx
Deployment is pretty easy using ClickOnce or by copying the engine dlls to the application directory.
I would choose SQLite. You can get the ADO.NET Compatible driver here:
System.Data.SQLite
I'd say SQLite. It's incredibly light-weight and easy to use, and the API is fine. You could always use DbLinq as ORM.
SQL Server Compact edition is my choice because of the following benefits:
A small runtime library that you can distribute with your app
Compatible with Linq to Sql (search "SqlMetal.exe")
Integrated design experience with Visual Studio 2008
It's a nice all rounder as a lightweight solution for a .NET app.
http://www.microsoft.com/Sqlserver/2008/en/us/compact.aspx
MDF does seem to be the most flexible solution but user need to have SQL server express installed to use it.
How do you plan on executing CRUD processes? If you are wanting to use Linq to SQL you are kinda limited offically it only supports SQL 2005, Sql 2008 and Sql Compact.
Also, does the application need to be disconnect, partially, fully connected to the internet? That may put some weight on your decision.
IMO, I would start with SQL Server Compact edition and if that was too limiting move to sql server express. (.MDF)