11–20 of 24 posts
I would disagree on the fact that a table without a primary key is a critical problem. There are multiple reasons for tables not having primary keys. Log tables are one example. Excessive sequential scans is also not a problem for small tables.
I would disagree on the fact that a table without a primary key is a critical problem. There are multiple reasons for tables not having primary keys. Log tables are one example. Excessive sequential scans is also not a problem for small tables.
Log tables with pkey on date can be searched faster in typical log table use of "tell me what happened in this time range", tho of course you have to make it unique
2) Even if you did really want that B-tree, you can still have it and not have to have to awkwardly make it unique if you don't make it a "primary" key.
Is this a typo? I would think that 10MB seems ridiculously small for a threshold here.
I would disagree on the fact that a table without a primary key is a critical problem. There are multiple reasons for tables not having primary keys. Log tables are one example. Excessive sequential scans is also not a problem for small tables.
Their are many good reasons to always have a primary key, even if it is just an automatic serial number, but the one that hit me personally is that it is surprisingly difficult to deduplicate a relational database. When I was first learning SQL I was pretty firmly in the "use natural keys" department. And when the natural key was every single column I would go "whats the point?" shrug and have no primary key. Until I…
I would disagree on the fact that a table without a primary key is a critical problem. There are multiple reasons for tables not having primary keys. Log tables are one example. Excessive sequential scans is also not a problem for small tables.
Log tables with pkey on date can be searched faster in typical log table use of "tell me what happened in this time range", tho of course you have to make it unique
I would disagree on the fact that a table without a primary key is a critical problem. There are multiple reasons for tables not having primary keys. Log tables are one example. Excessive sequential scans is also not a problem for small tables.
Why are indexes on foreign keys required? If I'm doing a join, it's going to select the primary key of the other table, how will an index on the foreign key help?
https://dev.to/jbranchaud/beware-the-missing-foreign-key-ind...
Again, another thing we learnt the hard way. All FKs now require a index for us.
I would disagree on the fact that a table without a primary key is a critical problem. There are multiple reasons for tables not having primary keys. Log tables are one example. Excessive sequential scans is also not a problem for small tables.
Logical replication requires a primary key. We found that out the bad way. It _is_ a critical problem.
Sure, that still boils down, in most cases, to having a PK (replica identity is normally not a good idea), but there are cases where this would not be the case.
I would disagree on the fact that a table without a primary key is a critical problem. There are multiple reasons for tables not having primary keys. Log tables are one example. Excessive sequential scans is also not a problem for small tables.
Their are many good reasons to always have a primary key, even if it is just an automatic serial number, but the one that hit me personally is that it is surprisingly difficult to deduplicate a relational database. When I was first learning SQL I was pretty firmly in the "use natural keys" department. And when the natural key was every single column I would go "whats the point?" shrug and have no primary key. Until I…
(1, 'bob', 'bob@bobco.com')
(2, 'bob', 'bob@bobco.com')