Domain: sqlite.org
Stories and comments across the archive that link to sqlite.org.
Comments · 219
-
Re:numeric package for science, DB for accouting
Can you point to a database program that is cross-platform? [ *BSD *Nix, Win*, MacOS 7.5+, Mac OS X, BeOS ]
MySQL is available cross-platform, as is R (statistics package).
As easy, or easier to use than a spreadsheet, for Joe Sixpack?
For small stuff (for a DB - 100K numbers is small for a DB) SQLite is the silver bullet. It supports basic SQL and expressions like abs, sum, like, min, max, avg and count. The available java wrapper makes it pretty cross-platform. For bigger stuff, set up mysql and phpmyadmin and show Joe only the php frontend.
SQL is very easy to learn and is very powerful for "spreadsheet"-like operations.
If you need advanced math and a spreadsheet-like visualisation use some scientific package like Origin from OriginLabs or SPSS (both expensive). Or use R - it is cross-platform, powerful, but requires some learning ... -
Re:Better than OLE?
Build an office suite with a file based database with a GUI and then you can start to attack the MS Access component of MS Office. Until then, you're replicating Star-Office and OpenOffice for some reason (and then trying to sell it for $149 USD on top of that).
If one was going to make such a thing, SQLite would be a good starting point. It has some flaws that need ironing but it is much faster than Access and is under public domain. -
Re:what about Linux
I'd like to run linux on it too. Basically I don't want to pay for a bulky Zaurus or iPAQ. People always say that linux isn't good on PDAs. Well PalmOS isn't that great either. One poorly written app and you can kiss all your data goodbye.
Linux would be interesting because you'd have access to plenty of apps. You could host the compiler on the device (if you had a big memory card). You can get keyboards for these PDAs so if you really must try out some neat idea for an algorithm while you are on the road, you can.
You could use CVS, Intermezzo or rsync to sync to a desktop. If you had it use iCalendar file format (RFC2445 you can easily integrate with MS Exchange, Apple iCal, Mozilla Calendar, OpenGroupware, or various free web calendars you can find around.
What you say, Linux doesn't do database type files in a natural way like PalmOS or WinCE? Take a look at SQLite. It's a very fast and lightweight SQL engine with some interesting extensions. It is also Public Domain, so you don't have to worry about GPL if you have some political problems with that license.
People say Linux sucks on PDAs, but honestly if you look at the work for libraries, applications and kernel features geared towards embedded Linux products it's pretty obvious that Linux would do quite nicely on a PDA. Take the AgendaVR3, Zaurus or iPAQ for example. They all do a decent job with Linux. -
Re:Why actually choose MySQL?
If you want to see some really horrible, self-serving speed analysis, check this out.
SQLite talks about how fast they are when doing the operations inside a big transaction. Well, that's wonderful, but since it's embedded that means no concurrent access. So what kind of application would do 2500 inserts in a big transaction? If you're doing a data load in PostgreSQL you just "COPY". Yet if you do a bunch of inserts with SQLite and sync on, the benchmarks show PG and Mysql to be better. I bet those numbers would be different if you turned fsynch off in postgres.
Not to mention they used postgres 7.1! Why even have the page still around? Run the tests again. -
Why don't more people use SQLite?
For the sort of simple, single-user applications that MySQL is frequently used for, I don't understand why SQLite isn't used more often.
It's fast, simple, lightweight, and completely free, with no licensing restrictions prohibiting it from being incorporated into commercial products.
Am I missing some reason why it's unsuitable for most people? -
Re:What do people do with Access?
> OSS is missing a niche here between a SQL server and a flat file database.
It has an engine that is probably comparable to Access' engine: SQLite. Seems like there should be an OSS project to build an Access-like app on top of this puppy. Anyone know of one that is starting? -
Try SQLite
MS Access has the advantage (on Windows machines anyway) of being a stand-alone database without needing a service to be installed. For a app where you don't want to have to install MySQL server and have it waste resources, you might consider SQLite. Unlike MySQL embedded, it's release under the public domain. MySQL Embedded is licensed under the GPL and has the following requirement:
... any program which includes, by linking with libmysqld, the MySQL source code must be released as free software (under a license compatible with the GPL).Although, depending on what you want to do with the software, this may not be a problem. I'm all for free and open source software, but a brother's gotta eat too.
-
SQLite home address
I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine. I downloaded it and tried the example. SQLite definitely looks like it is an answer. Thanks, that's definitely the kind of database I need. I didn't know about SQLite.
SQL 92 Features That SQLite Does Not Implement. Not many.
Very fancy, and supports every language and its sister:
- A complete database (with multiple tables and indices) is stored in a single disk file.
- ACID (Atomic, Consistent, Isolated, Durable) transactions.
- Database files can be freely shared between machines with different byte orders.
- Supports databases up to 2 terabytes (2^41 bytes) in size.
- Small memory footprint: less than 25K lines of C code.
- Two times faster than PostgreSQL and MySQL for many common operations.
- Very simple C/C++ interface requires the use of only three functions and one opaque structure.
- TCL bindings included. Bindings for many other languages available separately.
- Simple, well-commented source code.
- Automated test suite provides over 90% code coverage.
- Self-contained: no external dependencies.
- Built and tested under Linux and Windows.
- Sources are in the public domain. Use for any purpose.
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite? -
SQLite home address
I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine. I downloaded it and tried the example. SQLite definitely looks like it is an answer. Thanks, that's definitely the kind of database I need. I didn't know about SQLite.
SQL 92 Features That SQLite Does Not Implement. Not many.
Very fancy, and supports every language and its sister:
- A complete database (with multiple tables and indices) is stored in a single disk file.
- ACID (Atomic, Consistent, Isolated, Durable) transactions.
- Database files can be freely shared between machines with different byte orders.
- Supports databases up to 2 terabytes (2^41 bytes) in size.
- Small memory footprint: less than 25K lines of C code.
- Two times faster than PostgreSQL and MySQL for many common operations.
- Very simple C/C++ interface requires the use of only three functions and one opaque structure.
- TCL bindings included. Bindings for many other languages available separately.
- Simple, well-commented source code.
- Automated test suite provides over 90% code coverage.
- Self-contained: no external dependencies.
- Built and tested under Linux and Windows.
- Sources are in the public domain. Use for any purpose.
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite? -
SQLite home address
I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine. I downloaded it and tried the example. SQLite definitely looks like it is an answer. Thanks, that's definitely the kind of database I need. I didn't know about SQLite.
SQL 92 Features That SQLite Does Not Implement. Not many.
Very fancy, and supports every language and its sister:
- A complete database (with multiple tables and indices) is stored in a single disk file.
- ACID (Atomic, Consistent, Isolated, Durable) transactions.
- Database files can be freely shared between machines with different byte orders.
- Supports databases up to 2 terabytes (2^41 bytes) in size.
- Small memory footprint: less than 25K lines of C code.
- Two times faster than PostgreSQL and MySQL for many common operations.
- Very simple C/C++ interface requires the use of only three functions and one opaque structure.
- TCL bindings included. Bindings for many other languages available separately.
- Simple, well-commented source code.
- Automated test suite provides over 90% code coverage.
- Self-contained: no external dependencies.
- Built and tested under Linux and Windows.
- Sources are in the public domain. Use for any purpose.
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite? -
SQLite home address
I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine. I downloaded it and tried the example. SQLite definitely looks like it is an answer. Thanks, that's definitely the kind of database I need. I didn't know about SQLite.
SQL 92 Features That SQLite Does Not Implement. Not many.
Very fancy, and supports every language and its sister:
- A complete database (with multiple tables and indices) is stored in a single disk file.
- ACID (Atomic, Consistent, Isolated, Durable) transactions.
- Database files can be freely shared between machines with different byte orders.
- Supports databases up to 2 terabytes (2^41 bytes) in size.
- Small memory footprint: less than 25K lines of C code.
- Two times faster than PostgreSQL and MySQL for many common operations.
- Very simple C/C++ interface requires the use of only three functions and one opaque structure.
- TCL bindings included. Bindings for many other languages available separately.
- Simple, well-commented source code.
- Automated test suite provides over 90% code coverage.
- Self-contained: no external dependencies.
- Built and tested under Linux and Windows.
- Sources are in the public domain. Use for any purpose.
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite? -
SQLite home address
I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine. I downloaded it and tried the example. SQLite definitely looks like it is an answer. Thanks, that's definitely the kind of database I need. I didn't know about SQLite.
SQL 92 Features That SQLite Does Not Implement. Not many.
Very fancy, and supports every language and its sister:
- A complete database (with multiple tables and indices) is stored in a single disk file.
- ACID (Atomic, Consistent, Isolated, Durable) transactions.
- Database files can be freely shared between machines with different byte orders.
- Supports databases up to 2 terabytes (2^41 bytes) in size.
- Small memory footprint: less than 25K lines of C code.
- Two times faster than PostgreSQL and MySQL for many common operations.
- Very simple C/C++ interface requires the use of only three functions and one opaque structure.
- TCL bindings included. Bindings for many other languages available separately.
- Simple, well-commented source code.
- Automated test suite provides over 90% code coverage.
- Self-contained: no external dependencies.
- Built and tested under Linux and Windows.
- Sources are in the public domain. Use for any purpose.
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite? -
SQLite home address
I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine. I downloaded it and tried the example. SQLite definitely looks like it is an answer. Thanks, that's definitely the kind of database I need. I didn't know about SQLite.
SQL 92 Features That SQLite Does Not Implement. Not many.
Very fancy, and supports every language and its sister:
- A complete database (with multiple tables and indices) is stored in a single disk file.
- ACID (Atomic, Consistent, Isolated, Durable) transactions.
- Database files can be freely shared between machines with different byte orders.
- Supports databases up to 2 terabytes (2^41 bytes) in size.
- Small memory footprint: less than 25K lines of C code.
- Two times faster than PostgreSQL and MySQL for many common operations.
- Very simple C/C++ interface requires the use of only three functions and one opaque structure.
- TCL bindings included. Bindings for many other languages available separately.
- Simple, well-commented source code.
- Automated test suite provides over 90% code coverage.
- Self-contained: no external dependencies.
- Built and tested under Linux and Windows.
- Sources are in the public domain. Use for any purpose.
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite? -
SQLite home address
I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine. I downloaded it and tried the example. SQLite definitely looks like it is an answer. Thanks, that's definitely the kind of database I need. I didn't know about SQLite.
SQL 92 Features That SQLite Does Not Implement. Not many.
Very fancy, and supports every language and its sister:
- A complete database (with multiple tables and indices) is stored in a single disk file.
- ACID (Atomic, Consistent, Isolated, Durable) transactions.
- Database files can be freely shared between machines with different byte orders.
- Supports databases up to 2 terabytes (2^41 bytes) in size.
- Small memory footprint: less than 25K lines of C code.
- Two times faster than PostgreSQL and MySQL for many common operations.
- Very simple C/C++ interface requires the use of only three functions and one opaque structure.
- TCL bindings included. Bindings for many other languages available separately.
- Simple, well-commented source code.
- Automated test suite provides over 90% code coverage.
- Self-contained: no external dependencies.
- Built and tested under Linux and Windows.
- Sources are in the public domain. Use for any purpose.
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite? -
Re:Sql Server CE?
The Firebird embedded DLL sounds really interesting. I looked at sqlite but was put off by its almost total lack of data validation (for example, you can't even declare a column to hold integers). Which is claimed as a feature, not a bug, but for me it defeats one of the main reasons for using an RDBMS (foreign key constraints and check constraints are also not supported). Embedded Firebird might be a saner if slightly more heavyweight alternative. I wonder if there is a similar thing for Postgres?
-
free and high quality alternative
The very high quality embeddable SQLite database has several ports to
.NET -- see the web site. -
SQLite
SQLite claims to be twice as fast as both MySQL and PostgreSQL, and is more SQL92-compliant and ACID-compliant than MySQL.
Does that mean everyone should drop MySQL and PostgreSQL for SQLite? No. It means you have to evaluate your situation and choose the best tool for the job.
Personally, I've have very good luck using PostgreSQL, and probably won't ever consider using MySQL until it is truly ACID-compliant.
-
Re:SQL database without the serverActually, I've been playing with an embedded database called SQLite[sqlite.org]. It wraps the DB engine in your application, and you get info back and forth through a linked C library.
The author(s) wrote a set of Tcl bindings which make it easy for my lame ass to write noddy little applications in short order. (One line of code to load the module, one line of code to open the database file, and everything after that is retrieving data through SQL.)
-
Re:dirty secret of big databases...and another reality is the it's good enough approach; "...it might not be as good as others when wrestling with [your favourite rarely-used feature here], but what the fsck we don't need that anyway"
I even scaled down to SQLite which is good enough for 80 percent of what I need a DB for...