I have 2 questions for which I need help.
1)
I have developed an application where in I store the files(doc,xls,etc) in database. I have used LINQ to perform insert,update and delete. I have used MS SQL. Now, the requirement is that of using MySql. Can I use LINQ wit MySql. I searchd and found that LINQ only supports MS SQL and access. If it is decided that MySql should be usued, I dont want to go back to the traditional 3tier architecture. Can NHibernate can be used with MySql?
2)
How do the blade servers perform when it has to manage a data of 500gb+ data(documents). The RAM is about 12GB. Please nedd sugggestions that if such a huge amount of data is there, is it better not to store the data(documents) in database and store it in drives on the server instead.Because I have seen that if the data is stored in database(binary format) the size does increase.
Ok, here we go
1) It is not possible to communicate with an MySQL-Database via Linq To Sql, like you mentioned it is only build for MSSQL and Access. Prefer using the EntityFramework to communicate with variable databases. It is nearly the same to work with like Linq To Sql. You can easily develop your application using an MSSQL-Database and switch to a MySQL-Database after deployment by just changing your ConnectionString and installing the MySQL-EntityFramework-Connector.
These links may be helpfull to you:
Codeproject.com - An Introduction to Entity Framework for Absolute Beginners
Stackoverflow.com - Using MySQL with Entity Framework
2) I would advise you to store your data on physical drives and set references to the stored file in your database. This is because the heavy amount of data transferred while requesting one of your documents will slow down your database for other querys that normally just would take milliseconds to be executed.
Recently I was reviewing Couchbase as a NoSQL document database. It looks amazing the way it handles fail overs and how you can easily add a new DB server. I found out the way you can define the views is like CouchDB. So I thought Couchbase is using the same mechanism for its persistence layer as CouchDB.
When I looked at their website some days ago in the features section they've mentioned the following statement:
Couchbase uses SQLite, which is proven, reliable and widely deployed, as its persistence layer.
As long as I know SQLite is a fantastic database for phone or small databases but it's not designed for hundreds of millions of records and it's not scalable. Today when I checked their website again I found out that there is no sign of SQLite in their features page anymore.
So my question is, what does exactly Couchbase uses as it's persistence layer. Is it SQLite? If not, does it use the same mechanism as CouchDB or it's a totally different approach?
Here is the link to the cached version of features page where it stated Couchbase uses SQLite as its persistence layer and here is the new features page.
Couchbase < 2.0 uses SQLite. They simply renamed Membase when the companies merged.
The new CouchBase 2.0 uses CouchDB instead of SQLite.
Well, sort of: http://www.couchbase.com/couchbase-vs-couchdb
The team leveraged certain aspects of Apache CouchDB code to replace
the Membase storage backend and add indexing and querying. Substantial
portions were rewritten, however, to provide the performance and
resource utilization that the team felt was required. The result is
that while Couchbase is heavily influenced by Apache CouchDB, it is
meaningfully different.
I want to develop a PHP application. And I don't want to use MySQL for my application. And I will need full-text search feature for my application. I want to know that which database is best for my needs, Flat file or SQLite database for full-text search. Please suggest me some advantages and disadvantages for both databases.
If you have to ask, sqlite is better. It works and is fast.
The advantage of using a flat-file over it is that you have no dependencies on sqlite. The disadvantages of using it is that you don't have any indexes built in, so all queries will be slower. It will take a lot of effort to develop it and make sure it is bug free.
Foreword: I am not trying to write an alternative either to Subversion or to any other versioning system.
I wonder if SQLite has what it takes to replace the usual repositories of versioning systems by a single-file database file where different versions are stored as BLOBs?
Fossil is a version control system implemented in SQLite. It uses a single database, storing the versions as BLOBs.
Not all version control systems use the filesystem.
In fact, one such distributed version control system, Monotone, already uses SQLite for storage. The FAQ Why an embedded SQL database, instead of Berkeley DB? gives some rational for this choice. The FAQ doesn't address "why not filesystem storage" though.
Even SVN, at least historically, supports an alternate BDB repository data-store. While this is not SQLite it is easy to imagine that SQLite can function as a "super" BDB that supports SQL as an interface. (Actually, BDB can even be used as an SQLite back-end, for a fee :-)
Keep in mind that, no matter where the data (diffs/deltas) is stored it all ends up as some form of "BLOB" -- BDB value, data in a file, or BLOB column in a[n SQLite] database.
Happy coding
I don't know how authoritative this is but I found this:
http://www.sqlite.org/cvstrac/wiki?p=PerformanceConsiderations
and it doesn't seem good to have a lot of connections to sqlite. This seems to be bad for the web and most applications that have more than a few users. I'm having a hard time thinking of what sqlite would be used for when you don't need that many connections. Every program I can think of needs users, lots of them sometimes, so what would I use a database for that doesn't allow that many connections? I thought about prototypes but why would I use that when I can just connect to a larger database? Embedded apps maybe?
Thank you.
EDIT: Thanks everyone. I look at the page recommended below but an confused about something:
Under appropriate uses for sqlite it has:
Situations Where SQLite Works Well
•Websites
SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.
Situations Where Another RDBMS May Work Better
•Client/Server Applications
If you have many client programs accessing a common database over a network, you should consider using a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.
A good rule of thumb is that you should avoid using SQLite in situations where the same database will be accessed simultaneously from many computers over a network filesystem.
The Question:
I'm going to show my ignorance here but what is the difference between these two?
This is answered well by sqlite itself : Appropriate use of sqlite
Another way to look at SQLite is this:
SQLite is not designed to replace Oracle. It is designed to replace fopen().
It's good for situations where you don't have access to a "real" database and still want the power of a relational db. For example, Firefox stores a bunch of information about your settings/history/etc in an SQLite database. You can't expect everyone that runs firefox to have MySQL or postgre installed on their machine.
It's also perfectly capable of running relatively-low traffic, read-heavy websites. The performance of it is overall very good, it's more than the large majority of websites need for their traffic levels.
It's often used for embedded applications.
It can be very handy to use a database like storage when you have no access to a database service. So SQLite is used since it's just a file you store somewhere.
I also find that using SQLite is good for getting a prototype application together pretty quickly without the overhead of having a seperate DB server or bogging a development environment with an instance of MySQL/Oracle/Whatever.
Also easy to pick up and move the database to a different machine if you need to.
The iPhone uses it for call history, SMS messages, contacts, and other type of data. Like Ólafur Waage said, good for embedded applications on mobile device because it's lightweight. I have used it also on stand alone applications. Easy to use and available on most platforms.
Think about simple client or desktop apps that could make use of a db, like as a poor example, an address book. Rather than bundling a huge db engine like mysql or postgre with your deliverable, sqlite is very lightweight and easy to include with your finished app.
This FLOSS Weekly podcast episode talks with the creator of SQLite and covers among other things goes over the type of things you would use it for. Everything from file systems for mobile phones to smallish web sites.
In the simplest terms, SQLite is a public-domain software package that provides a
relational database management system, or RDBMS. Relational database systems are
used to store user-defined records in large tables. In addition to data storage and management,
a database engine can process complex query commands that combine data
from multiple tables to generate reports and data summaries. Other popular RDBMS
products include Oracle Database, IBM’s DB2, and Microsoft’s SQL Server on the
commercial side, with MySQL and PostgreSQL being popular open source products.
The “Lite” in SQLite does not refer to its capabilities. Rather, SQLite is lightweight
when it comes to setup complexity, administrative overhead, and resource usage.
For detail info and solution about SQLite visit the link below:
http://blog.developeronhire.com/what-is-sqlite-sqlite/
Thank you.
What the above two answers say. Expanding slightly on Chad Birch's answer, its teh calls to the SQLite db, and a rather poor implementation of sync() that causes FF3 to be so slow in linux.