11–20 of 58 posts
... 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.
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...
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).
For any small/medium site it's great.
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).
So does that become S-Q-L-ite or S-Q-Lite, you think?
This isn't necessarily authoritative or well researched, but it appears that S-Q-L-Lite is correct: http://blog.cleverly.com/permalinks/247.html
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).. For any small/medium site it's great.
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).. For any small/medium site it's great.
Agreed. And the database can grow surprisingly large (multi GB with many millions of rows) and it still performs quite well.
At the time, I attributed it to SQLite, but now I'm wondering if it was Rails or (more likely) my inexperience at optimizing performance of the app at that time.
It was about three years ago, though, so I am sure performance in SQLite (and Rails, too, for that matter) has also likely improved a lot during that time.
Earlier quoted context omitted.
So does that become S-Q-L-ite or S-Q-Lite, you think?
Good point. I was going for SQL-Lite. But being wrong (and hearing enough people say "lie-nux" [and to be clear, I am not mocking ... we read things and form our own pronunciation because we often don't hear them said] ...) I decided to google it. This isn't necessarily authoritative or well researched, but it appears that S-Q-L-Lite is correct: http://blog.cleverly.com/permalinks/247.html
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)"?
Windows CIFS shares are fine and always have been AFAIK.