> More generally, instead of a boolean flag, e.g. completed, a nullable timestamp of when the state was entered, completed_at, can be much more useful. In my experience, the timestamps should almost always be entered in addition to the flag. select * from data_journal where status = 'Loading' is much easier to write and understand than select * from data_journal where started_loading_at is not null and finished_loadi…
Feels like maybe a view on top your table that adds the boolean based on the timestamp might be safer, in that by definition there's no risk of the two columns getting out of sync?
> I'm essentially a believer in You Aren't Gonna Need It — the principle that you should add features to your software — including generality and abstraction YAGNI is not a principle. It is a contextual thumb rule. A codification of expert intuition. Exceptions to thumb rules are quite the norm. Conflating thumb rules with principles is a sign of sloppy thinking. Often engineers will misuse terminology thinking that…
So what would be an example of a software design principle?
Never write a function called destroyBaghdad(). Instead name it destroyCity and pass the target as a parameter.
> I'm essentially a believer in You Aren't Gonna Need It — the principle that you should add features to your software — including generality and abstraction YAGNI is not a principle. It is a contextual thumb rule. A codification of expert intuition. Exceptions to thumb rules are quite the norm. Conflating thumb rules with principles is a sign of sloppy thinking. Often engineers will misuse terminology thinking that…
> The words you use highly influence your thought process
Given that the article is literally about exceptions to YAGNI, and explicitly calls out that there are probably more, their use of the term "principle" doesn't appear to have caused them any harm.
Relational databases add too much time overhead due to building schema or configuring orm for schema
Migrations management
Building an db model to domain model mapper and maintaining it
You waste time thinking about building an db model and focusing on that technical layer which probably eventually affecta the way you model your system
Nosql gives you modeling freedom which is handy for architects
Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…
Off topic, but I think skills are not a binary thing. They have levels. Also skills might be transferable: fe programming languages, if you know language X, language Y is just a small step away (not talking about the eco-system here), and skills might be dependent: (How can you have the skill "java" and not have some level of "OOP" ?) I have yet to see an ontology that fits reality here :(
I will play devil advocate Relational databases add too much time overhead due to building schema or configuring orm for schema Migrations management Building an db model to domain model mapper and maintaining it You waste time thinking about building an db model and focusing on that technical layer which probably eventually affecta the way you model your system Nosql gives you modeling freedom which is handy for arc…
Relational databases add too much time overhead due to building schema or configuring orm for schema
That sounds like the same sort of argument as "I'm not going to write tests because they slow me down!"
Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…
Am I missing something, or could you have achieved the same thing with a relational database using joins? Or even an array-typed column?
I will play devil advocate Relational databases add too much time overhead due to building schema or configuring orm for schema Migrations management Building an db model to domain model mapper and maintaining it You waste time thinking about building an db model and focusing on that technical layer which probably eventually affecta the way you model your system Nosql gives you modeling freedom which is handy for arc…
The effort to make a key-value store on top of a relational database is negligible.
The effort to make a relational database on top of a key-value store which is not already a relational database is great.
Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…
let's say, MySQL
There's your mistake. Using Postgres with an Array column you can just search for records where the column contains a value if you define it like "character varying(100)[]", eg
SELECT * FROM users WHERE skills && '{"databases", "sql"}';
Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…
Am I missing something, or could you have achieved the same thing with a relational database using joins? Or even an array-typed column?
That's what I wrote yes. I could also have achieved the same using the file system and plain files, or using a graph database. My point is/was: the document model seemed to us the model that fit the best for our problem: the `skills` attribute is an unbounded list (well, in practice the list was bounded to have at most 50 items) that can be filtered by. So in MongoDB, that's plain simple to implement. In MySQL, though, as you said, you have to come up with two tables (one for `user`, one for `skills`, make sure FK are in place, and then use joins for filtering... doesn't seem to me that this model fits better)