5 ms·
My latest favorite fun fact about SQLite is that it is not only my favorite SQL database, but also my favorite NoSql database. Since 2024, all my new database
by TekMol 2y ago
My latest favorite fun fact about SQLite is that it is not only my favorite SQL database, but also my favorite NoSql database.
Since 2024, all my new database tables have only one column. Everything just goes into one single JSON column, which I always call "data".
SELECT
cities.data->>'name' city_name,
countries.data->>'name' country_name
FROM cities
JOIN countries
ON countries.data->'id' = cities.data->'country_id'
I looked around a bit if some NoSql database would make this easier. But it turned out no, even now that I only use Json everywhere, SQLite is still the best tool.
- rafram 2y agoBut why?
- advisedwang 2y agoTo get the worst of both worlds
- TekMol 2y agoMultiple reasons. Let me start with one: Flexibility. I can add a new attribute the very moment I create a new row. When I want to add "not_available_before: 2026" to a car, I can do that right away. No need to alter the table and add a new column.
- rafram 2y agoThat just seems like it encourages bad practices. There’s nothing but upside to tracking your schema changes.
- MrLeap 2y agoCognitive overhead is a cost!
- TekMol 2y agoWhat do you mean by "tracking"? So far, we have not talked about tracking anything. Only about how to add a new field. I just named a downside of the columns approach: It slows things down. Being able to add add fields faster leads to faster experimentation and development.
- Althorion 2y agoI mean, sometime along the way you’re going to have something that consumes the data (otherwise, why bother keeping it in the first place), and that something will have certain expectations about the way things are structured. It will probably become a good idea then to have some clue as to what structure used to be at one point or the other, and for that you’d want to keep track as to what got added/removed and when. If it’s a very early stage in the development, and you don’t expect any of the current data to survive to the final version, I guess that’s fine. But when you have an actual running product that has to keep running, dealing with the multiple versions of the data scheme is a pain, and dealing with the multiple untracked versions of the data scheme is a pain squared.
- TekMol 2y agoHow does "have some clue as to what structure used to be at one point or the other" relate to the topic of columns vs json fields?
- Althorion 2y agoIt is what they meant by ‘tracking’, which is what you’ve asked about.
- TekMol 2y agoI have the feeling you both are confusing your development workflow around database structure with the structure itself. You seem to think that using columns somehow results in some type of automatic "tracking" (versioning?) of something.
- RadiozRadioz 2y ago> Since 2024 So you have only just started doing this
- breakingcups 2y agoWell, they did say "latest". 2024 has also been going for 364 days now.
- timewizard 2y agoHave you used indexes on any of these tables? I see that it can be done but I'm curious as to how that plays out. Any hints?
- actuallyalys 2y agoI’m curious what the reasoning behind having no id or key column. Do you use indexed expressions to index JSON fields? Do you use Rowid for certain queries? Or do you not bother with indexes? My understanding is that NoSQL databases still have indexes and it seems like using SQLite as you demonstrate could be worse in that regard.
- TekMol 2y agoreasoning behind having no id or key column The entries in the data column already have an id field. What would be an upside of having another id in a column? It seems that only complicates things and has the potential for invalid states (different id in the id column than in the json field). So far I have not used indexes because things are fast enough as they are. I would expect that when I need more speed, I can easily add indexes on expressions. Why do you expect SQLite indexes on expressions to be worse than what NoSQL databases do for indexing?
- actuallyalys 2y agoI wouldn’t suggest duplicating the id field, but moving from the data field. > Why do you expect SQLite indexes on expressions to be worse than what NoSQL databases do for indexing? I don’t have a concrete reason. It’s just that indexes on expressions are not intended as the main index for a SQLite database to my knowledge. Having thought about it more and read the page on expression indexes more thoroughly[0], I think it’s probably unlikely to be a noticeable downside. The only remaining downside is that the item being indexed might be outright missing, but it sounds like that’s basically a feature in your case, as you’re opting for flexibility. [0]: https://sqlite.org/expridx.html https://sqlite.org/expridx.html
- TekMol 2y agoWhat do you mean by "the item being indexed might be outright missing"? What is "item" here?
- rob137 2y agoWhat are the most obvious downsides to this approach?