Need to learn more about Cache

If you're looking for Cache in particular (rather than MUMPS) you may want to check out Intersystem's news group -- http://groups.google.com/group/intersystems-public-cache

I've been using Cache for about 7 years, DSM (M for OpenVMS) for a few years prior to that, and traditional relational databases going back over 20 years-- wow... I'm getting old.  I'm a big fan of Cache.  If not for the licensing costs, it would be my platform and backend of choice for nearly all my projects.  I'm forced to fall back and develop around traditional relational databases rather than cache because of the cost-- the reduced development time and the fact that I enjoy developing in Cache don't (in my case, typically) justify Cache's price.

MUMPS is a data-centric language-- a language whose primary purpose is to provide access to a persistent data store.  It's code and data tightly integrated which lends itself naturally to object-oriented design.  That's where Cache takes M.  Cache provides a framework for object-oriented programming under M.  And, while it's true that you don't have to know or use M to work with Cache, working with Cache Basic feels klunky and unnatural compared to working with Cache ObjectScript (basically a macro-preprocesser over the top of M).  For our developers that don't know M, the SQL interface does give them a fighting chance at working with the data, but they're at a severe disadvantage when it comes to doing any true development under Cache on the back-end.  Knowing MUMPS definitely helps if you do decide to go with Cache.  

The SQL support has been getting better with each release but IMO doesn't really compare to the support you find in a typical relational database.  To me it still feels like it was layered on top as an afterthought.  I may be slightly prejudiced against it because the early versions were buggy and all too often I seemed to find myself pulling my hair out and programming around bugs.  I haven't felt that way in years though.  I don't know if it's that's because I don't use the SQL as much as when I first started with the system or whether it's because they've fixed the bugs.  Probably a mix of both.

If you're going to develop in C#, are planning on just using the dotnet ADO providers to interface to Cache, and are going to treat Cache as if it was just a typical relational database, then I'd say stick with a traditional relational database and skip Cache.  Cache will work.  But using that way is a waste and my guess is that you'll find yourself asking why you decided to go with it.  From personal experience, the developers that we have that don't know Cache wish they weren't stuck dealing with it.  Those of us that do know it, wish we used it more.  If you have the time and inclination to actually learn and develop in Cache then you'll probably find Cache more than worth it.  If you don't have the time to have your programmers learn it or the resources to hire or bring in someone that does, my advice would be to skip it.