Even though SQLite isn't designed to replace Oracle, I'm certain there's plenty of companies that have purchased expensive Oracle licenses for projects where SQLite would have worked perfectly well. I've often used it for web-based custom CMS's of one kind or another where many people would have used MySQL and the client would never know the difference. I'm sure many people have used Oracle for web-based internal tools like this with less than a million rows of data.
Regardless of how much fun lamenting the assumed technical incompetence of enterprise software development can be, I strongly doubt that this has ever happened. Oracle is very expensive, and SQLite is very limited outside its clearly delineated use cases.
Oracle versus PostgreSQL or possibly MySQL -- maybe. But don't think Oracle sells snake juice; their reporting tools, for instance, are top-notch and way beyond what the open source world can provide.
I first used SQLite because I thought (in C++) "Man, instead of writing crazy datastructures, I wish I could just use SQL on a spot in memory" SQLite came up in my Google search, and ta da!
Of course, this was back in 2003 or so, and that project never turned into anything more than a fancy wrapper over SQLite and Lua.
SQlite is a gem; when we develop web sites for clients, we first try to use sqlite, and if not we use MySQL and PostGres; we only use mssql, oracle when the customer has already a legacy database. What about you?
We use SQLite exactly for that. At some point we were generating +50000 shader (.hlsl) files for 3 different platforms (so much due to various techsets and techniques).
Loading them back from the tools/game took a long time, for that reason they were put in small SQLite db - which is a little bit more complex than this "CREATE TABLE files (key, value)"
This sped up us significantly. We might be using this idea for more and more small files lying around.
I use SQLite exclusively in my projects, I love it. Easy to use, easy to backup (1 file), doesn't rely on a SQL database running, no security concern with username/password for the database engine (altho make sure your database file isn't web accessible)..
Wow, more projects should have a page similar to this one. Upvoted because it’s good to keep in mind when thinking of sqlite and when documenting your own project.
By the use of "an", I learned that I have been pronouncing SQLite wrong. The maintainers clearly prefer the spelling out of SQL in the title.
I've always been on the "sequel" side of pronouncing SQL (hey, it's no worse than "scuzzy" for SCSI), which morphed SQLite into "Sequelite". I never realized how bizarre that sounded (almost more like a material than a database).
Just in case anyone cares because I did the research on this a few weeks ago (including watching its creator say it numerous times) it's S-Q-L-Lite. Yeah, that seems like a duplication of the L but there you have it.
I suppose it depends on your definition of "simplicity". My go-to simplified data storage container is Berkeley DB. (Little did I realize Oracle recently shipped a Berkeley DB with SQLite inside it... heh)
Can anyone say when Oracle is justified? I have yet to encounter a problem the postgres or mysql didn't support but alas I have not worked on everything.
Support. You can properly find some solution to your issue with postgres online. Oracle can send an Oracle certified engineer who can solve your problem.
Consistency. Your enterprise depends on terabytes of hyper valuable information (Wallmart with their sales data), can you guarantee that you won't end up with corruption issues? Or that the next version will work with your system too?
That said as long as you make less than 20 mil/year, Oracle isn't likely to be the best solution.
Just a quick question: which engine do you use for your MySQL system?
When the ERP application you are installing has in it's specs
- Supported database: Oracle
I am sure a crack Postgres guy can bash and file that sucker to work. But the vendor will not support the result, and some places, some situations, that really counts for a great deal.
Oracle isn't selling databases. They're selling database support. Similar to how IBM operates - they make good stuff, but you're really not paying for the hardware. If you were, they'd be outrageously expensive compared to something built more simply - see Backblaze, for an example: http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-h... .
I love the example that this provides with respect to the conflation of "Storage" with "FileSystem", while data may indeed be stored on a filesystem somewhere, the habitual thinking that appends " to file" to the phrase "I need to save these data" seems unintentionally limiting to me.
Instead of trying to answer questions like "what should our file format look like?" It seems more interesting and valuable to ask first, "what storage is most appropriate", the answer may be REST, database, file, /dev/null, or any abstraction over one or more of these. You may then find that questions about file format, or structure simply disappear, it is the role of the storage mechanism chosen to efficently store and recover the data, use the hard work that the team that built that solution invested, and apply your own hard work to solving your own problems.
With cloud and mobile being added to the set of common target platforms (however ill-defined), I hear/read people asking "how do I read/write a file" increasingly often, when on those platforms (and many other) the concept of a file (at the application layer) may not be useful at all...
Can anyone provide more info when the site says "...the file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows)"?
... because the only use for file I/O in applications is structured tables of data? What about audio/video, documents, graphs, log-structured data, object caches, unstructured flat files, etc? Don't get me wrong, SQLite is awesome, but this is a classic example of the relational database world's pervasive attitude that they are the superior solution for any data storage problem.
Wow. Not only did you manage to completely miss the point of that statement, but you cast it up as a hasty strawman to boot. I'm quite impressed.
The choice of fopen() and Oracle was meant to convey simplicity: SQLite solves problems on the simple end of the difficulty spectrum -- problems you would normally solve with fopen(). It is not for problems at the complex end, like Oracle. It's a simplified expression; reading it literally is foolish.
[+] [-] techtalsky|14 years ago|reply
[+] [-] apl|14 years ago|reply
Oracle versus PostgreSQL or possibly MySQL -- maybe. But don't think Oracle sells snake juice; their reporting tools, for instance, are top-notch and way beyond what the open source world can provide.
[+] [-] larrik|14 years ago|reply
Of course, this was back in 2003 or so, and that project never turned into anything more than a fancy wrapper over SQLite and Lua.
Still, SQLite == awesome, when it is appropriate.
[+] [-] diminish|14 years ago|reply
[+] [-] malkia|14 years ago|reply
Loading them back from the tools/game took a long time, for that reason they were put in small SQLite db - which is a little bit more complex than this "CREATE TABLE files (key, value)"
This sped up us significantly. We might be using this idea for more and more small files lying around.
[+] [-] dendory|14 years ago|reply
For any small/medium site it's great.
[+] [-] DNeb|14 years ago|reply
[+] [-] alanh|14 years ago|reply
[+] [-] reduxredacted|14 years ago|reply
I've always been on the "sequel" side of pronouncing SQL (hey, it's no worse than "scuzzy" for SCSI), which morphed SQLite into "Sequelite". I never realized how bizarre that sounded (almost more like a material than a database).
[+] [-] petercooper|14 years ago|reply
[+] [-] kelnos|14 years ago|reply
[+] [-] ebzlo|14 years ago|reply
[+] [-] alastairpat|14 years ago|reply
I'm Australian and always spell out acronyms when speaking them - saying something like 'sequel' or 'scuzzy' just sounds weird to me.
[+] [-] peterwwillis|14 years ago|reply
[+] [-] derrickpetzold|14 years ago|reply
[+] [-] tomjen3|14 years ago|reply
Consistency. Your enterprise depends on terabytes of hyper valuable information (Wallmart with their sales data), can you guarantee that you won't end up with corruption issues? Or that the next version will work with your system too?
That said as long as you make less than 20 mil/year, Oracle isn't likely to be the best solution.
Just a quick question: which engine do you use for your MySQL system?
[+] [-] bdunbar|14 years ago|reply
When the ERP application you are installing has in it's specs
- Supported database: Oracle
I am sure a crack Postgres guy can bash and file that sucker to work. But the vendor will not support the result, and some places, some situations, that really counts for a great deal.
[+] [-] Groxx|14 years ago|reply
Oracle isn't selling databases. They're selling database support. Similar to how IBM operates - they make good stuff, but you're really not paying for the hardware. If you were, they'd be outrageously expensive compared to something built more simply - see Backblaze, for an example: http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-h... .
[+] [-] jodrellblank|14 years ago|reply
(I too wonder what technical marvels it can perform which justify the cost).
[+] [-] pacaro|14 years ago|reply
Instead of trying to answer questions like "what should our file format look like?" It seems more interesting and valuable to ask first, "what storage is most appropriate", the answer may be REST, database, file, /dev/null, or any abstraction over one or more of these. You may then find that questions about file format, or structure simply disappear, it is the role of the storage mechanism chosen to efficently store and recover the data, use the hard work that the team that built that solution invested, and apply your own hard work to solving your own problems.
With cloud and mobile being added to the set of common target platforms (however ill-defined), I hear/read people asking "how do I read/write a file" increasingly often, when on those platforms (and many other) the concept of a file (at the application layer) may not be useful at all...
[+] [-] smharris65|14 years ago|reply
[+] [-] grandpa|14 years ago|reply
Windows CIFS shares are fine and always have been AFAIK.
[+] [-] alleri|14 years ago|reply
[+] [-] rbranson|14 years ago|reply
[+] [-] owenmarshall|14 years ago|reply
The choice of fopen() and Oracle was meant to convey simplicity: SQLite solves problems on the simple end of the difficulty spectrum -- problems you would normally solve with fopen(). It is not for problems at the complex end, like Oracle. It's a simplified expression; reading it literally is foolish.
[+] [-] andylei|14 years ago|reply
[+] [-] dchest|14 years ago|reply
[+] [-] william42|14 years ago|reply