There are a few legitimate downsides to using SQLite. First off, the type system. It’s bad. Luckily, as of a month ago, you can use strict typing instead, which somewhat improves the situation.
That’s a terribly weak argument. No details, no rationale, not objective evidence, no insightz nothing. “It’s bad.” That’s the full extent of the analysis.
SQLite doesn’t associate types with the table, it associates them with the individual value. So your database design might define the price of a product as an integer (in cents, same as banks use), but you will be able to store a floating point value there. You could even store a half hour long video file in the price value of a product.
It’s a “feature, not a bug” but essentially it forces the developer to do all of their own type checking outside of the database, on every single read and write operation. This comes with a performance penalty and also introduces scope for major bugs (e.g. a product being sold for $0.99c might be stored as 0.99 instead of 99. And maybe 0.99 gets rounded own to zero somewhere else in your custom type system. That’s a real bug I’ve seen - wasn’t in SQLite but in another tool that allowed integers and floats to be used interchangeably, and it’s one of the reason I’ve avoided SQLite.
A recently added STRICT setting blocks that feature from being used. The database is able to, for example, only do type checking on writes (because it knows the type will have been checked on every write) and it can be written once, tested thoroughly, and never touched. Reducing the scope for bugs.
From the article:
That’s a terribly weak argument. No details, no rationale, not objective evidence, no insightz nothing. “It’s bad.” That’s the full extent of the analysis.
Quite weak.
SQLite doesn’t associate types with the table, it associates them with the individual value. So your database design might define the price of a product as an integer (in cents, same as banks use), but you will be able to store a floating point value there. You could even store a half hour long video file in the price value of a product.
It’s a “feature, not a bug” but essentially it forces the developer to do all of their own type checking outside of the database, on every single read and write operation. This comes with a performance penalty and also introduces scope for major bugs (e.g. a product being sold for $0.99c might be stored as 0.99 instead of 99. And maybe 0.99 gets rounded own to zero somewhere else in your custom type system. That’s a real bug I’ve seen - wasn’t in SQLite but in another tool that allowed integers and floats to be used interchangeably, and it’s one of the reason I’ve avoided SQLite.
A recently added STRICT setting blocks that feature from being used. The database is able to, for example, only do type checking on writes (because it knows the type will have been checked on every write) and it can be written once, tested thoroughly, and never touched. Reducing the scope for bugs.