I tend to recommend keeping the derive_pll_clocks command in my .sdc, but never keep derive_clocks. The only downside with derive_pll_clocks is that you get stuck with the long clock name it uses. But you quickly get to recognizing them, and the benefits of having derive_pll_clocks generally outweighs this one downside.
But most importantly, once you have an .sdc file, never let TimeQuest overwrite it. It should be your file that you enter constraints into. If you ever have TimeQuest write out .sdc constraints, write them to a junk.sdc file and then cut and paste into your file.
If you like the TQ GUI for entering constraints, note that when you have your .sdc file open, you can go to Edit -> Enter Constraint, and access the same constraint GUIs, it just enters the text into your .sdc file directly. (I don't mind it entering a constraint, just not overwriting the whole thing.)
PLL outputs are always generated clocks. The inputs are not always base clocks. You could have a PLL feed another PLL, so the second PLL's output is a generated clock whose source is the output of the first PLL, i.e. another generated clock.
If sclk is a register in your design used as a clock, you will want to apply a generated_clock to it. Ripple clocks always need this. Derive_clocks will assign a base clock to the register which is generally wrong(but it can't assign a generated clock to it either, since it has no idea if that register creates a divide_by 2, divide_by 4, or whatever frequency. So you need to manually do this since you know what the new clock will be.)