Originally posted by d000hg
View Post
Pluggability of the underlying engine is a low-level feature; I've found that the average SQL Server dev doesn't even realise that such things are going on under the hood (although the good ones do). The majority of MySQL devs similarly stick with the defaults, but tend to have at least some idea of the options. (I've been asked about them on a phone interview, happily admitted that I couldn't remember as I just look these things up when necessary, and was then told that it wasn't important anyway and got the gig )
Still, there are some benefits that come therefrom; for example, I would assume that SQL Server offers something similar to the memory-resident engine (whatever it's called), but it's hidden a bit deeper. It sounds like your ERD tool is exposing too many details for what you need - if it doesn't have a set of sensible defaults and hide the unnecessary gubbins until you need it, a change request for the UI may be in order
Incidentally, if you have any MySQL data for which it's appropriate, the memory-resident storage engine offers blistering performance at the expense of a bit of configuration and a lot of memory. Maybe we should be using that for CUK's internal index tables; then TPD wouldn't bog things down any more
Leave a comment: