4 ms·
Things I Wished More Developers Knew About Databases
- xupybd 6y agoUsing GUIDs for ID makes the db less friendly to query. Writing down an ID of a row is much harder when it's a GUID. I know it's not normal for people to be directly working with the DB but it is a little bit of developer ergonomics.
- redis_mlc 6y agoIt's an intermediate-level article, which means half-right and half-wrong. The GUIDs paragraph is mostly wrong. - there are a few different layouts for GUIDs, depending on need - MySQL int is 4 bytes, bigint is 8 bytes, guids are 16 bytes. Space is important in schemas, more than you know. - if you're not using SSD, then GUIDs will write slowly since they are random, thus causing seeks - GUIDs however are useful when you need an id that is visible to the user, since they're not sequential.
- skyde 6y agoi recall reading that guid cause write to be spread to many B-tree pages. This cause most page to be mostly empty (fragmented) wasting space and slowing query. Also once pages start to fill the majority of insert would cause page split instead of having an amortized cost... Ideally you should use pseudo-sequential ID. By having an counter per partition and using <Counter>+<partition key> as your table primary key
- indentit 6y agoRegarding the two operators being on call at once due to "write skewing" > In the situation above, there will be a write skew if two of the transactions successfully commit. Even though no dirty read or data loss happened, the integrity of data is lost because there are two people assigned to be oncall. Wouldn't it make more sense to have a separate table/single row to store it so the earlier mentioned row versioning checks could be used? Plus one could instead store the history of how the on call operator has changed instead of just having an "oncall now" boolean field against each operator.