"SQLite is not designed to replace Oracle. It is designed to replace fopen()."
1–10 of 58 posts
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#2I 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.
Still, SQLite == awesome, when it is appropriate.
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#3... 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.
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#4... 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.
It's a deliberately simplified view of the problem.
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#5... 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.
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#6... 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.
replace some instances of fopen(), not every instance of fopen()
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#7Even 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.
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#8By 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).
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#9We 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.
Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."
#10I 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)