6 ms·

Stop trying to categorize things. Period. Recognize categories as a sometimes-useful shortcut for talking about somewhat-average (within that category) things,

by feoren 3y ago

Stop trying to categorize things. Period. Recognize categories as a sometimes-useful shortcut for talking about somewhat-average (within that category) things, and that they're absolutely useless for everything else. When you stop worrying about whether something is or is not a fish or planet or alive, you will not miss it. You will be surprised at how rarely you actually need to worry about what category something is in. This applies directly to database designs and why almost every database is awful unmaintainable garbage. If you have a table per category of thing, your database is terrible; but know you're in good company, as 99.9% of database developers make this simple and completely avoidable mistake. Unfortunately our laws also like to categorize things, which does sometimes make it unavoidable in software dealing with those laws. > Fish generally live in the water, breathe through gills, have tails and fins, possess a certain hydrodynamic shape, lay eggs, and are in a certain part of the phylogenetic tree. This is not true (somewhat saved by "generally"). Either you're describing physical characteristics, or you're describing phylogeny; not both. Phylogenetically, whales are fish, and so are you. (This rests on the idea that only monophyletic groups are at all meaningful in genetics; nothing ever stops being in the "fish" tree, if such a tree even exists. Cats are felines and mammals and lizards and fish. Unless you believe there is no such thing as a fish at all, which is also a solution.) > A fish is a creature phylogenetically related to various other fish, and with certain defining anatomical features. Take a shark, pretty universally recognized as a kind of fish. If the argument is "whales are closer, phylogenetically, to humans and cats than to sharks, therefore they are mammals", then you should know: so are salmon. Salmon are closer, phylogenetically, to humans and cats than to sharks. The point not being that you should call whales fish, but rather being: fuck categories. > When terms are not defined directly by God, we need our own methods of dividing them into categories. No, we really, genuinely, honestly, do not need any methods of dividing things into categories. We really don't. I realize that the author does kinda get to a weaker version of this with talk about fuzzy borders and the goals of the category. The transgender discussion is pretty good, with his criticism of the fallacious argument: > If a man thinks he’s a woman, then we might (empathetically) wish he were a woman, other people might demand we call him a woman, and we might be much more popular if we say he’s a woman. But if we’re going to be rationalists who focus on believing what’s actually true, then we’ve got to call him a man and take the consequences. I go much harder anti-category and say: this argument is fallacious on its face because it asserts that belonging to the category "man" is even theoretically a factual thing. It's not, just as belonging to any category is not. Any argument that it is either True or False that object X belongs to category Y is immediately fallacious and should be completely discarded.

TehShrike 3y ago
Maybe I'm misunderstanding the use of "category" or "thing" here, but it would be difficult for me to make useful business software for my clients if I didn't have one table for "sales orders" and another for "purchase orders".
- feoren 3y ago
  No, it wouldn't. They have a lot in common. What various statements do you want to make about "sales orders"? What various statements do you want to make about "purchase orders"? My guess is that a lot of those statements are the same. In fact, a lot of the statements, e.g. "when was this record last modified?", are statements you want to make about all sorts of things. If you list out everything you might ever want to know about a PurchaseOrder, and everything you might ever want to know about a SalesOrder, and you just fucking JAM all that shit in each table (or a combinatorial explosion of child and association tables), you end up with two giant tables that are kinda-the-same-but-kinda different; you end up with a bad database. A database with a table called SalesOrder(s) and another called PurchaseOrder(s) is a bad database. That is exactly my point. Everybody makes this mistake. They only get away with it because they're tackling simple, easy problems (badly). Everyone seems to think that one record is one noun. No! One record is one statement. One table is not a list of instances of one distinct noun; it's a list of instances of one kind of statement you want to make. This is much closer to a "pure" relational model (e.g. as espoused by Codd, as hinted at in Out of the Tar Pit) than constantly making the exact categories-are-hard-boundaries mistake discussed in TFA. Most people have started recognizing the problems with "class Cat : class Animal", but then they do this exact thing in their databases, reintroducing all the same problems.
  - BoiledCabbage 3y ago
    Yes Out of the Tar Pit is wonderful, but I don't believe it actually argues what you appear to be claiming it argues. It is arguing a different (and more important point). Or put more specifically, one could argue that a SalesOrder and a PurchaseOrder are the same thing, because fundamentally they are with a different perspective. But one cannot argue that a Teacher and a Student are the same thing. As a result having a table for Teachers and a separate table for Students is a good thing. And that would be categorization. Are you arguing that Students and Teachers should be stored in the same table when modeling a DB? If so, then you are arguing for categorization. But even then, that's not the heat of the issue. More detailed there are 3 arguments that in my opinion you are muddling together: 1. Some things are the same thing but viewed from the perspective of two different users, these should be modeled as the same thing (PurchaseOrder vs SalesOrder). [I agree with this specific case, but there aren't a ton of these] 2. You should model events in a system and not nouns/entities [The Out of the Tarpit argument, which I also agree with and is the direction of ideal coding if performance were no object, and you can easily do queries / derived models on top of it.] 3. You shouldn't categorize things. [This argument I don't understand as I see generalization and categorization as the essence of software modeling, but am open to an explanation. A StudentEnrolled event table should be categorized separately from a ClassLectureGiven event table, and those are categories.]

by feoren 3y ago

TehShrike 3y ago

Maybe I'm misunderstanding the use of "category" or "thing" here, but it would be difficult for me to make useful business software for my clients if I didn't have one table for "sales orders" and another for "purchase orders".

feoren 3y ago
No, it wouldn't. They have a lot in common. What various statements do you want to make about "sales orders"? What various statements do you want to make about "purchase orders"? My guess is that a lot of those statements are the same. In fact, a lot of the statements, e.g. "when was this record last modified?", are statements you want to make about all sorts of things. If you list out everything you might ever want to know about a PurchaseOrder, and everything you might ever want to know about a SalesOrder, and you just fucking JAM all that shit in each table (or a combinatorial explosion of child and association tables), you end up with two giant tables that are kinda-the-same-but-kinda different; you end up with a bad database. A database with a table called SalesOrder(s) and another called PurchaseOrder(s) is a bad database. That is exactly my point. Everybody makes this mistake. They only get away with it because they're tackling simple, easy problems (badly). Everyone seems to think that one record is one noun. No! One record is one statement. One table is not a list of instances of one distinct noun; it's a list of instances of one kind of statement you want to make. This is much closer to a "pure" relational model (e.g. as espoused by Codd, as hinted at in Out of the Tar Pit) than constantly making the exact categories-are-hard-boundaries mistake discussed in TFA. Most people have started recognizing the problems with "class Cat : class Animal", but then they do this exact thing in their databases, reintroducing all the same problems.
- BoiledCabbage 3y ago
  Yes Out of the Tar Pit is wonderful, but I don't believe it actually argues what you appear to be claiming it argues. It is arguing a different (and more important point). Or put more specifically, one could argue that a SalesOrder and a PurchaseOrder are the same thing, because fundamentally they are with a different perspective. But one cannot argue that a Teacher and a Student are the same thing. As a result having a table for Teachers and a separate table for Students is a good thing. And that would be categorization. Are you arguing that Students and Teachers should be stored in the same table when modeling a DB? If so, then you are arguing for categorization. But even then, that's not the heat of the issue. More detailed there are 3 arguments that in my opinion you are muddling together: 1. Some things are the same thing but viewed from the perspective of two different users, these should be modeled as the same thing (PurchaseOrder vs SalesOrder). [I agree with this specific case, but there aren't a ton of these] 2. You should model events in a system and not nouns/entities [The Out of the Tarpit argument, which I also agree with and is the direction of ideal coding if performance were no object, and you can easily do queries / derived models on top of it.] 3. You shouldn't categorize things. [This argument I don't understand as I see generalization and categorization as the essence of software modeling, but am open to an explanation. A StudentEnrolled event table should be categorized separately from a ClassLectureGiven event table, and those are categories.]