4 ms·
> I could see people who are super-cereal about types getting bunged up about it in SQLite As soon as you have more than one client authored by different peopl
by da_chicken 5y ago
> I could see people who are super-cereal about types getting bunged up about it in SQLite
As soon as you have more than one client authored by different people talking to the same data store, you, too, will care about types. In a purely embedded system where the database is simply long-term storage for itself, this may rarely become a problem. Once you're using SQLite as a microservice's data store, however, you'll quickly find that what you think is predictable and what everyone else thinks is predictable don't really match all that much.
There is a reason that most SQL RDBMSs have features like NOT NULL, UNIQUE, or support foreign key constraints. It's to prevent some other fool's application from breaking your application because they think 1.5 of something makes sense when you think it's got to be a whole number.
Can you seriously tell me that you don't see a problem with this notation in the documentation[0]:
> Note that a declared type of "FLOATING POINT" would give INTEGER affinity, not REAL affinity, due to the "INT" at the end of "POINT". And the declared type of "STRING" has an affinity of NUMERIC, not TEXT.
I really like SQLite, but I think I'd quit a project that asked me to document that kind of behavior as an acceptable consequence of the overall design.
There is a very good reason that nearly everyone prefers a data store that will emit errors instead of silently making guesses about what the user wants. Returning an error is not a crime.
[0]: https://www.sqlite.org/datatype3.html https://www.sqlite.org/datatype3.html
- at_a_remove 5y agoI mean, it appears that there are a lot of people who use SQLite and they therefore disagree with you. Each tool has appropriate uses. I am reminded of the people who say that software development cannot happen without Agile -- as if it never took place prior to 2000! It may not be your tool for your projects but tons of people here will attest to it being very useful for them in some places, and I am among them. Make of that what you will.
- da_chicken 5y agoJust because a tool is well liked and widely used does not mean that it is well-designed or immune from criticism. "But it's popular" or "but I like it" really aren't a defense of any criticism at all. At best they merely express disagreement with it, but in this case they're more or less orthogonal to it. I have and do use SQLite. That doesn't mean I'm incapable of recognizing and understanding a design flaw when I see one, nor that I'm unwilling to point one out for fear of upsetting those who simply haven't experienced it.
- at_a_remove 5y agoI would have agreed with that until you hit the "nearly everyone" bit. That's my "evidently not."
- da_chicken 5y agoOkay, but how many are using it because of the type model versus those who are using it for any other reason and just putting up with it? You can't claim every use of the software is because of every feature or quirk.
- at_a_remove 5y agoI claimed "I could see people who are super-cereal about types getting bunged up about it in SQLite" ... which seems to have been borne out. If you don't know what your data looks like because you're just wading into filthy data, being loose about your types is not the worst thing in the world. That's all. You know the progression. You get this file, claims were made about what was in the file and its structure, its data, but then you realize that these claims are ... aspirational at best. You open it up in a notepad or cat it or whatever. Yup, it's awful. Can you maybe look at it in the spreadsheet? How bad are the line endings anyway? And the next step from that is trying to pull it into SQLite, because it won't fail when I start trying to cram junk into it. I am in no way claiming that I want to use SQLite as my final database.