Every database has indexes…but should they? In this episode, lets consider a different proposition.
What if the indexes you have on your database are a mistake…A bug… An implementation error. Give me 30 minutes to convince you of a whole new mindset when it comes to indexes on your database. Enjoy!
I look forward to your thoughts on this one.
Very helpful and informative
Thanks for this great episode
thanks for taking the time to give the feedback
Hey,
Thanks for making the great podcast! Cannot leave my comments on podbean as I don’t have an account there.
At 23:40 you said:
> where bitmap indexes are really coming into their own is when you are combining multiple columns each with a low number of distinct values.
Oracle is equally capable of doing BITMAP AND/OR for B*Tree indexes with no issues.
Bitmap indexes really shine in these scenarios since they are really small, thanks to their structure: https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/indexes-and-index-organized-tables.html#GUID-AB4829E0-C1B7-4554-9ECB-7CCB7A992FE9 which you are probably going to talk about in your next podcast.
The size is crucial because:
1) it is more likely the indexes will be cached;
2) we can build more bitmap indexes than B*Tree ones due to bitmap indexes’ less storage footprint;
BR,
Mikhail.
Hi Connor,
Every episode has been really interesting, keep up the good work!
Isn’t it a bit strange that the db has so many methods for protecting/managing data, but so few (any?) for managing code? Is version control inside the db a bad idea?
Kind regards
Tomas
EBR gives some semblance of that versioning of code. It is sad that the take-up hasn’t been high.
I’ve been using EBR a bit, and it’s really good. For versioning alone I wouldn’t recommend it though.
I’ve set up a small table and a schema trigger to copy the to-be-compiled code. Sometimes a bad change that seemed good can be undone thanks to undo in the editor, but if you’ve closed it…