The database should already know what indexes you need just by looking at how you access the data. Explicitly choosing indexes is explicitly making a choice off time-space tradeoffs, and you have to do it at a very low level: which columns do you build indexes on? How many do you build?
It really isn't that far off from choosing the layout of a struct in C and having to know how it's packed and aligned.
>Knowing what indexes you need and why is far from being some kind of esoteric specialized knowledge of database internals.
I'll concede that, but the issue still exists. Does your database have DROP TABLE IF EXISTS or not? Some do, some don't. If it doesn't, how do you achieve the same functionality? A given database offers thousands of operations, and the syntax, performance, and semantics of each varies by quite a bit.
My point is, you have to learn the specifics of the database you're using to do general purpose data storage stuff.
It really isn't that far off from choosing the layout of a struct in C and having to know how it's packed and aligned.
>Knowing what indexes you need and why is far from being some kind of esoteric specialized knowledge of database internals.
I'll concede that, but the issue still exists. Does your database have DROP TABLE IF EXISTS or not? Some do, some don't. If it doesn't, how do you achieve the same functionality? A given database offers thousands of operations, and the syntax, performance, and semantics of each varies by quite a bit.
My point is, you have to learn the specifics of the database you're using to do general purpose data storage stuff.