I'm building an app that will grab a content from some CMS, and save it in the phone.
Usually I do that using IsolatedStorageSettings. Is there any reason why would I use the SQLlite instead?
Why you need to use SQLite; MS doesn't have direct support to SQLite. You can use SQLCE for your application instead. Simply the usage of Isolated Storage is not appreciable if you are using a huge chunk of structured data. Still you decide to use ISO for storing i am sure definitely you will face issue in future. Probably the areas like Tombstoning, FAS etc where yo may take a lots of time for saving your data to files
Related
I am developing Windows 8.1 Universal Application and I use Sqlite and Sqlite-Net to store the data. Now I need to add ability to store PDF files (1 Mb - 50 Mb) files in my application.
What is the best solution in this case? Store files in the Sqlite or store them into separate folder? Which folder will be better to use in this case?
Unless you are going to be storing relational data and that you need to run queries (and it sounds like you aren't), I would suggest using the local storage. It isn't really that difficult to use.
Now, as far as performance. Reading the disk on the app is not going to be fast. That being said, any solution you use is going to be saved to disk in the end; so I don't think you will notice much of a difference if you go with DB or local storage in terms of performance.
A good option would be to store the files on the SD Card/Removable Devices if available, this way all the valuable phone's internal memory will not be used up.
My friend asked me to make a registration software for his blood donation camp. He told me that he can't host an ASP.NET or PHP page.
Also that since they'll be running the software in many systems, which may not be interconnected, they may not be able to use a Database server.
Is there a way to store/read data from an MS-Excel or MS-Access file instead of any other database?
Also that I wish to make the front end using HTML & JavaScript/JQuery.
As you problem is little bit twicky. Since your app will run on various machine so you want to develop standalone app in Html / Jquery. Also you cannot use db server bcoz of lack of connectivity. So in such scenario i will suggest you to go for Win Form app with a lightweight db like MS Access and Sqlite. Which ever you prefer. Since you are keeping Network aside so i suggest you to not use HTML/Jquery to use access or Excel as it looks logical very easy to use interop with excel but implementation is quite messy. In that time you can finalize the winform app with any of the database with lots of ease.
I'm working on a AIR desktop client which will basically be used to search for pictures. For now, the search will only be performed on the picture filename, but I'd like to add a tagging system.
I would like the search to be very fast, but I'm not sure SQLite is responsive and fast enought.
Do you have any alternatives to store and retrieve datas locally within a AIR application ?
Thanks !
SQLite is very fast. On typical (small-scale) usage, it's faster than most other databases. When we switched to SQLite we found a 4x performance gain on our typical queries with our real schema and a production data set.
Besides, in AIR, you don't have many options. Anything you implement directly in AS3 or integrate with via the new native process integration (which requires launching a separate process and communicating via std i/o) would be MUCH slower.
I think you're right, the fact that SQLite does not provide foreign keys and such does not make it slower?
If I have a "picture" table (with id, name, path and collection) and a "tag" one (with picture_id, name), I'd like my query to be very responsive...
I'm about to build a new personal blog/portfolio site (which will be written in ASP.NET), and I'm going to run it against a SQLite database. There are a few reasons for this:
The site will not be getting a lot
of traffic, and from what I've read,
SQLite is able to support quite a
lot of concurrent users for reading
anyway
I can back up all the content
easily, just by downloading the db
over FTP
I don't have to pay my hosting
company every month for a huge
SQL2008 database that I'm hardly
using
So, should I go for it, or is this a crazy idea?
I'm not so sure about #2 (what happens if SQLite makes changes to the file while the FTP program is reading it?) but other than that, there is no reason to prefer one DB over the other (unless one of those DBs just can't do what you need).
[EDIT] Use an online backup to create the file for FTP download. That will make sure the file content is intact.
Even better, add a page (with password) to your site which creates the file at the press of a button, so your browser can download it.
It's just fine for a low traffic site as long as it's mostly read traffic. If it were me, I'd use SQL Compact Edition instead (same benefits as Sqlite- single file, no server), just because I'm a LINQ-head and the LINQ providers are "in the box" for it, but Sqlite has a decent LINQ library and managed support as well. Make sure your hosting company allows unmanaged code, or that you use the managed port of Sqlite (don't know its current stability though).
SQLite can handle this easily - go for it.
You should check, but I think that the Express version of SQL 2008 is free of charge.
Anyway, I've been working with SQLite from .NET environment, and it works quite fine (but I haven't done any load test).
And if you're not decided yet, you still can use a LINQ provider which will allow you later to switch from one database to another without rewriting your SQL code (I think to DbLinq, for example).
If you plan to backup you database, you must ensure first that it is not used at the moment.
SQLite answer this for you:
http://sqlite.org/whentouse.html
low-medium volume = okay,
high volume = don't use it
in your case its a-ok to use sqlite
Generally, yes.
But you should be aware of the fact that SQLite does not support everything that you might be used to from a 'real' DBMS. E.g. there are no constraints like foreign keys, unique indexes and the like, and AFAIK some (more advanced) datatypes are not available.
You should check for the various limitations here and here. If you can get along with that there's no reason to not use SQLite.
A rule of thumb is that if the site can run on one server
then SQLite is sufficient. That is what the creator of
SQLite, D. Richard Hipp, said at approximately 13 min
30 secs into episode 26 of the FLOSS Weekly
podcast.
Direct audio link (MP3 file, 24 MB, 51 min 15 sec).
I'd say no. First off, I don't know who you are using for a provider, but with my provider (goDaddy), it's pretty cheap at $2.99 a month or so. I get 1 sql server db and 10 mysql dbs.
I don't know how much cheaper this can get.
Secondly, why risk it? Most provider plans include at least MySQL database. You can hook up with that.
In general, SQLite isn't meant for a high-traffic website, but it can do quite well on websites getting 100,000 hits/day or less. The SQLite org website gets more than 500,000 hits/day, and generates 2 million or more DB interactions/day ... all handled by SQLite.
Here are some things that will dramatically speed up SQLite's performance:
Index your tables
Use transactions for multiple commands instead of executing one at a time.
Learn about write-ahead logging
Do a Google search on each of the above with SQLite ... your DB performance will improve dramatically.
An SQLite DB can actually be faster than a MySQL, PostGRE, MS SQL Server DB, or other hosted server-based DBs for 2 reasons:
1). SQLite is usually stored on the same machine as the website, rather than a separate server machine, eliminating round trip network latency response times.
2.) For smaller read/write requests, the SQLite engine is executing far less code, which can also be faster.
For a smaller website, a smaller DB engine like SQLite could actually be faster and more efficient.
Are you using any SQL functionality? SUM, AVG, SORT BY, etc, if yes go use SQLite. If not, just use plain txt files to store your data. Also make sure that the database is outside the httpdocs folder or it is not web accessible.
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.