The following is a much of a memory tool for me as a commentary....
I love SQL Server. I've been working with SQL Server since version 6.5 and am in my second large production environment. I consider myself to be very well versed in SQL Server DB admin and development. On a scale of 1 to 10 with 10 being a total guru I'd place myself at about a 7.5. However, I am now being cross-trained in UDB and although I hate to say it I can see why other RDBMS DBAs sneer at SQL Server DBAs.
You can do most of the necessary database administration tasks in SQL Server without having a comprehensive understanding of how a database works. From what I've seen so far in UDB there is more detailed control and information available of the lower level subsystems in the DBMS. As I understand it you can pretty easily set up UDB to run on the defaults just like most people do with SQL Server. Maybe I just don't know as much about SQL Server as I think I do but when you start looking at the file handling options there seems to be much more flexibility in UDB.
I suspect this is basically a cultural difference. While UDB will run on a Windows platform most of the places I've been exposed to it the platform has been UNIX. We also have DB2 on the mainframe but I'm not even getting into that dinosaur. According to IBM, up until a year or so ago we still had one type of IBM server that was literally the last of it's kind in North America. It was so old it used the floppies that were the size of vinyl records and it actually had several slots in the case that were designed to hold clipboards. We had a party when we retired it. Anyway, where was I? Oh yeah, cultural differences.
This is how a UDB project works at my company. Most new UDB projects are not placed on their own server but added to an existing instance. (I'm going to mangle together terminology from both systems. Please excuse me.) First, they way UDB is set up here, they install an instance of the database server which has a default tablespace. (Tablespaces are roughly analogous to file groups in SQL Server.) The database(s) for the project are then placed on that instance and diferentiated from one another by the catalog owner. (You know, just like they say NOT to do in SQL Server.) Each database can have it's own tablespace(s). The tablespaces can either be SMS (system managed space) which is a directory managed by the OS containing separate files for each table and index or it can be DMS. (Database Managed Space) Our UNIX boxes are all connected to a SAN so when we use DMS as we do in production we have the UNIX SA "carve out" a file system, then assign the tablespace to take up as much or as little of the available space in that file system. Within that tablespace you have the option of making either one big or multiple files. (Containers? Again, sorry. This is all new to me.) That file or files then contains multiple database objects. All of these options can be changed "on the fly" and the logs or data rebalanced across the altered tablespaces. Plus there seems to be a lot more information logged automatically relating to performance issues.
This is how it works here when we set up a new SQL server for a project. First, the project team wants a separate server for each project. This has it's advantages and it makes things simpler but is very expensive in many ways. After all the analysis of disk, memory, processors, clustering, etc. has been worked through, a certain group within the organization builds the hardware and installs the OS. In order to take advantage of separating data/log/index files and filegroups you must have separate physical locations for those files and groups to reside. Guess what? This particular group has flatly refused to do anything other than a single RAID 5 array. Oh, they'll partition the array into multiple drives but they don't want to use anything other than RAID 5 because if a drive goes bad then someone would actually have to come into the data center and physically swap out the drive. (It's not the actual technical staff who are the problem it's a bit higher up.) Also, they don't like to do multiple arrays because then you have to have multiple drive controllers and two RAID 5 arrays take up more drive slots per total usable space than does a single array. Yes, you can hook a SQL Server up to a SAN but in order to do that you have to get someone to shell out the money for the fiber NIC the fiber connection to the server. So basically, if you wanted to try gaining performance through the file subsystem then you are just screwed.
If you look at it from a surface viewpoint, UDB and other non-SQL Server DBAs have to be much more knowledgable of how the subsystems in their database servers work even to just set it up. However, I don't really think this is true. I believe the perception all relates back to the OS culture. The 'IX people, as I like to call them, have had to pay a lot more attention to the OS subsystems than Windows people. Anybody (Except my wife who steadfastly refuses to learn anything about computers because "that's why she married me.") can create directories and decide where to place them on a Windows system and you don't have to care about where the actual physical disks are located You just pay attention to the share/drive letter. The "safe" attitude with Windows based products has always been "Let windows do it because if you start trying to tell Windows how to do things you get worse performance." I'm sure this is due in part to the management tools in Windows basically being metaphors for the actual control files and registry whereas in the 'IX world you usually edit the direct configuration files.
So what this all basically works out to in terms of administration and use is this: Windows was designed to be more friendly and tolerant of the niave user/administrator. 'IX was designed with the assumption that you already knew the nitty gritty details and if you didn't then you had to be smart enough to figure it out for yourself. Because admins in the Windows world usually aren't required to know all of the specifics of the registry, executable and config files (for most things) these details tend to be learned later in their professional development.
So, I ask you this: Which is better? (Look out! Carpenter analogy!) The business office just bought a house and wants a handrail put on the stairs.
The 'IXers have been hooking pieces of wood together for years. They've learned that if you use glue, clamps, drill holes and pound in wooden pegs as fasteners, the joints are very strong and durable. In order do do this they had to figure out how to use a bunch of different tools, take justifiable pride in their knowledge and will firmly stand behind the project, loudly proclaiming "These two pieces of wood will never come apart!"
The Windows crowd just grabs a cordless drill and a couple drywall screw and zips them together. What did we need to know in order to accomplish this? How to hold a screw and pull a trigger. Can we claim the same amount of durability? Probably not. Do we take a lot of pride in the work we just did? Probably not, any idiot can drive in a screw. Did we put a lot of thought into screw placement, the type of wood? No. Do we know how the guts of the drill works? Eh, sort of. Could we have done the job much more comprehensivly? Yes. Can we proclaim loudly "You now have a handrail!"? Yes.
In most cases you have to look at what the business office asked for when/why they want it and how much they want to pay.