I fine some disagreement in the "DB Expert" comments. I think using more DB's will attract more "use", not "DB Experts". In most shops, in which they are large enough to have a sole, full-time DBA, and perhaps even a DBO...the decision to make a CMS or new application is a "group" effort. Thus, when we go into a meeting for a new application, it's a joint effort of everyone being presented with the problems, the DBA presenting the schema and sproc's (DBA's like abstraction layers too :) ), and then the developers providing looking at how they are going ot access and manipulate the data. This presents a 'groud-up'/bare-bones approach. If Drupal used more DB's, this would allow a lot of the frame-work to be used by the develper, and the DBA could still create their own underlying schema in which Drupal could query. So, that in turn, I think will open up Drupal to more "shops". A true DB-Expert these days is far beyond Drupal (as a general 'challenge' anyway), and more concerned and having "fun" with new native XML table-types, Geo-Spatial datatypes/tables, clustering, replication, etc. So in summary, I think the we should look at this as opening up Drupal to more "shops"/"uses", rather than "DB-Experts". Also, about the abstraction layer removing the "ugly mess" below. This is nice...and not so nice sometimes. I think of it like a car. I like that all I have to do is turn my car on, and it runs fine. I doubt any F1 team would like a car where all they had to do was turn the car on and didn't have to worry about camber, PSI, gear-selection, etc. Now, most schema items are trivial, and the detailed mess is fine as abstracted...but there are going to be times where people want the mess. Bring me the mess..sometimes :). I know in my last project I was saved my MS-SQL offering "locking hints" where I could tell the DB what type of lock I wanted it to acquire in my query. Locking is usually abstracted in MySQL (offering only table lock and row locking, and mostly done automatically for you by the RDMS). Michael Favia wrote:
Derek Wright wrote:
i don't think the DB experts are just floating around out there, waiting for The Right CMS(tm) to show up that does everything they ever wanted with all their DB ideas so they can finally get their hands dirty doing interesting work. they're going to come to Drupal for all sorts of random reasons, and may or may not put their DB expertise to use making Drupal better...
Agreed. With my only concern being that a DB expert will first look at the state of our storage mechanisms as his primary judgment of the overall quality of the system (because it is what he knows) and might unfairly deduce that the other fields of CS arent taken seriously either. Assuming such an assumption is valid concerning DB management with regards to RI and schema abstraction, etc. This isnt something I agree with but it is just a point worth considering IMO. Demonstrating our willingness and /attempt/ to do things /right/ by them opens a lot of doors to individuals who might be wiling to improve it.
To bring this back to your experience: You saw a good project trying to do things right (CVS + contribs) but needing help getting it done properly so you opted to help. Olive branches are powerful things.