191–200 of 214 posts
"By this I mean, if you need a database at all, you should jump to having a relational one straight away, and default to a relational schema, even if your earliest set of requirements could be served by a “document database” or some basic flat-file system. Most data is relational by nature, and a non-relational database is a very bad default for almost all applications." That is terrible advice. Relational databases…
Earlier quoted context omitted.
“You aren't gonna need it” is ordinary colloquial British English. “I aren't…” is not.
You're not gonna need it I'm not gonna need it You aren't gonna need it I amn't gonna need it You ain't gonna need it I ain't gonna need it
"By this I mean, if you need a database at all, you should jump to having a relational one straight away, and default to a relational schema, even if your earliest set of requirements could be served by a “document database” or some basic flat-file system. Most data is relational by nature, and a non-relational database is a very bad default for almost all applications." That is terrible advice. Relational databases…
sqlite is lightweight, cheap, easy and faster than fopen :) https://www.sqlite.org/fasterthanfs.html
I have seen many projects get bogged down in complications around interfaces to third party software. Where the 3rd party software solved some simple problem that could easily be solved in a few dozen lines of code.
Databases are one of the main offenders. But command line processing is probably the worst offender I see.
Simple problems should use simple problems. Most data storage problems are simple. How much code is in sqlite? I do not know. But opening a flat file, gulping in the contents, linearly searching for the blob of data you want is simple, often fast enough, can be implemented in the time it takes to find, download, install,... some package from a third party.
As I said: make an interface (probably three lines of code) and put the simplest thing possible behind it. (That simplest thing will not be sqlite). If requirements expand, put something more capable behind the interface.
Another thing:
Most data is not relational. I have seen systems that put apache log files into SQL databases. I imagine there might be sensible uses for that, but I cannot think of any.
Golly, KISS is not some random acronym written by fools. It is a fundamental principal of software design
"Go straight to relational database" is not a sensible principal of anything. It is bad advice.
The good thing about YAGNI is that you can treat it as dogma and you'll be fine. Sometimes you'll be wrong, but it's always going to be easy to recover from mistakes. Doesn't matter how much experience you have, YAGNI is always a net positive.
Author's recommendations on the other hand require a lot of caution. Take logging for example. It's quite a slippery slope: how much logging is enough?
Just a few INFO statements here and there? Or multiple levels? Centralized logging? Structured logging? Alerts? What about retention? GDPR?
Good logging requires thinking.
You can always add more logging when necessary. But you cannot unadd the logging noise you accidentally introduced (well technically you can, but noone does it).
Zero-one-many: if 1% of your users needs two addresses, then 0.01% will need more than two. You can just say no to those. You avoided one level of abstraction by slightly upsetting 0.01% of your users. In most cases that's a good thing: unlike MAU, complexity piles up and grows non-linearly.
Versioning: in most cases if you don't control both ends of the API, versioning is a requirement, YAGNI doesn't apply here. And when you do, versioning is a huge process change that rarely pays off.
Earlier quoted context omitted.
Counterpoint: https://brandur.org/soft-deletion HN discussion: https://news.ycombinator.com/item?id=32156009
Relatedly, I've worked with systems that would maintain a "deleted" or "archived" table for every normal table, with an identical schema. I nowadays prefer it over a deleted_at field for many of the same reasons as the article. I also nowadays don't care much for created_at or updated_at; IMO it's preferable to maintain an actual transaction log (which is something I'd add to the YPGNI list, given how invaluable that…
Earlier quoted context omitted.
I'm far more partial to the "deleted" table that simply removes the deleted entries from one table into another. Slightly more hassle on the recovery side (in the rare event), way less risk on the read side, and covers the 90% use case where most of the time its more useful for things like debugging. Only rarely in my career have I seen soft deleted data get restored, but you don't lose that this way, you simply miti…
Our current system uses soft deletes, and I wish we had done a "deleted" table. The biggest downside to soft deletes for us is that it ruins the default indexes cause every query has a !IsDeleted where clause added to it.
Earlier quoted context omitted.
I'm far more partial to the "deleted" table that simply removes the deleted entries from one table into another. Slightly more hassle on the recovery side (in the rare event), way less risk on the read side, and covers the 90% use case where most of the time its more useful for things like debugging. Only rarely in my career have I seen soft deleted data get restored, but you don't lose that this way, you simply miti…
> I'm far more partial to the "deleted" table that simply removes the deleted entries from one table into another Or you could use a system versioned temporal table (or the equivalent in non-MSSQL databases), then the DB does the work for you, and allows recovery of UPDATEs too. Not sure exactly what the performance implications are.
Earlier quoted context omitted.
> I'm far more partial to the "deleted" table that simply removes the deleted entries from one table into another Or you could use a system versioned temporal table (or the equivalent in non-MSSQL databases), then the DB does the work for you, and allows recovery of UPDATEs too. Not sure exactly what the performance implications are.
Temporal tables can get pretty bloated when the table sees a lot of updates since they essentially save a copy of the row every time it's modified. You could of course add a reaper system to only keep the last N versions, or only versions less than N days old, etc. Unfortunately IIRC there's no built in support to do that automatically.
Earlier quoted context omitted.
Relatedly, I've worked with systems that would maintain a "deleted" or "archived" table for every normal table, with an identical schema. I nowadays prefer it over a deleted_at field for many of the same reasons as the article. I also nowadays don't care much for created_at or updated_at; IMO it's preferable to maintain an actual transaction log (which is something I'd add to the YPGNI list, given how invaluable that…
How about using YEGNI for “you’re eventually gonna need it”? Not exactly the same as “probably”, but more pronounceable.
Earlier quoted context omitted.
I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plu…
> I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text. In django (python), the key is just the English text (with…
What happens when you need to make a change in the english version? Do you just search/replace through all the translations?
Does django do anything to make this easier, or does it work with any i18n library?