This. I hate VSCode as an IDE and is the reason why I have not used Cursor. I wish Jetbrains actually had some brains to build a better coding agent inside their IDEs (which I think are one of the best out there), but for now Im stuck with codex/cc + Jetbrains IDE
LinkedIn doesn't have any redressal mechanisms for anything. Someone I knew went through a lot of abuse by a LI user and kept making new accounts to harass. LinkedIn's response - "We did not find anything that violates our ToC". No wonder it has become a cesspool of spam, fraud and abusers.
Can you please elaborate on the differences? They are practically interchangeable, but conceptually there might be another layer on top of entities and relationships for somewhat richer semantics (like describing a relation, or additional annotations on the entity)
One example is that in ER cardinality is specified on the relation. In SQL cardinality is implemented and can be largely reversed to ER by looking at where foreign keys are.
Many to many will lead to an extra table (which can have additional properties, requiring this table to be modelled as an entity), one to many leads to the inclusion of a foreign key to another unique key (referring all columns of that key, _id is an implementation decision, compound primary keys are possible). One to one can be implemented in multiple ways, like one to many with a uniqueness constraint by the referring table or even by merging entities to a single table.
The raw SQL can be revealing but when entities have merged into one table it’s harder to tell what is what, unless a certain set of columns appears over different tables.
Aside from what else is mentioned in the sibling comment, inheritance is another big one. Inheritance is not explicit in SQL and in fact, when going from ER to SQL, there are multiple choices you can make about how to materialize the inheritance hierarchy.
Another is that in ER diagrams, relationships themselves can have attributes. Personally I think it tends to make more sense to convert relationships to entities in this case most of the time, but it can be useful.
Finally, relationships in ER diagrams can be N-ary and connect more than two entities while foreign keys in SQL always reference one other table. Of course you can have multiple foreign keys on a table to represent this, but not without some loss of semantics.
Works when there is always an active price. Having an explicit end date allows certain rows to be inactive automatically after validity period. Think of seasonal categories/products etc which dont exist after a specific period
And even if you don't have seasonal products, you still need an end date to mark when you stop selling a product; otherwise you have to do something hacky like defining "<price> = NULL means we stopped selling the product after <valid_from>" and inserting an extra record.
I think the end date should be nullable though, but valid_to is NOT NULL in the starting example... later in the article, when showing the "new way" using date ranges, it inserts a row with an open-ended range, which is more what I'd expect.
Yeah, but now this is implicit information (no price == marker row) and duplicate the entire row. And it is baking in "price" as the special field. This may not be just one field for another temporal entity
How would you do it? The speed of light being what it is, and tail latencies being large unless you over provision wildly, you keep facing hundreds of milliseconds of reconciliation time, if you want guaranteed synchronous result.
I said it in another thread. Yes, of course we cannot match the local store interactivity. What I mean is coast to coast RTT is 65-80ms. And the server can be optimized to return back basic operations (adding a comment, a new ticket, reading one back etc) can be done within tens of milliseconds, keeping the entire thing under 100ms coast-to-coast. If one can colocate servers with users, it becomes even less. I'd rather to server side "reconciliation" than do both (because serverside thing doesnt go away even with localstore, it is just deferred).
Writing an eventually consistent database is hard, it maybe fine for Linear's use cases, but not knowing if my updates made it to the server (aka my team),is problematic. The sync lags have created untold problems in other projects I have worked for, so I always go for a synchronous solution. All the fancy stuff comes out only if it's absolutely needed. I'd rather optimize my server to be blazing fast, and have the user "suffer" network latency.
reply