Could anyone help me in assessing where DT stands (in terms of functionalities, strengths… even weaknesses, if the topic is allowed! 
) with regard to relational database management systems? (The context of use that I have in mind is primarily that of an individual researcher in the social sciences, who needs to organize his/her data in as powerful a way as possible, but may also want to move on to database sharing for collaborative work, or online publishing of databases.)
I have used for 15 years for my own work a relational database management system (4D) in which I even learned to program a bit, but my setup is now getting somewhat outdated, and after some extensive experimenting with DTPO 2.0, I am considering giving it now a very serious try. I also try to provide the graduate students in my department with some guidance, not quite but almost like the proverbial blind man leading the blind. The above question in particular remains somewhat puzzling to me, even after quite some time spent googling on the Web. One of the things that strikes me is that the more-geeky-than-I world of programmers or creators of large online data repositories seems to be talking exclusively in terms of relational databases based on languages like SQL or Ruby; but in circles in which DT (or other comparable freeform database software) are discussed, these topics seem to disappear from the radar screen — it’s almost like two distinct worlds, speaking two different languages.
Sorry for the long post, and thanks for any insight.
If you want to bring it down to single terms, it is the difference beween numeric vs. semantic relations, mathematical vs associative, hierarchical vs. web or if you want to go into philosophy: between male vs. female principle, ying and yung, logos or mythos 
Relational databases need a key and defined relations to make connections and therefor are good in things that follow a clear and a determined workflow like managing customers, bills, invoices, products, bibliography, etc. The databases are hierarchical.
DTP and other freeform approaches don’t depend on a certain structure. They are more like a web that evolves. Structure that develops out of content. It’s flowing.
Before using DTP I used a relational FileMaker Database for my writing stuff. And I did a lot of programming to get the connections between my notes to work or maintain a free order (not based on any sorting criteria). And finding things was cumbersome.
In DTP that’s easy: with (wiki)links the web of connections evolves by itself, searching is powerful, fast and easy. I can drag files wherever I want them and the UI is much more flexible.
There are some things that where easier in FileMaker and need some programing and wand waving to work in DTP: searching or sorting results after a custom date (not the file-date, but some content-related date) or dealing with structured meta data like bibliographic data (but I think there are some improvements coming up here with Version 2.0 final (or 2.x).
All in all DTPs freeform approach works much more effective for me than the classical relational database approach (and I think for everyone who deals with text and non structured data).
Johannes
Relational databases need structure. DEVONthink needs nothing of the sort. It’s more like a file system with great indexing and a fair degree of AI than it is a relational database. And that’s fine… I don’t want to have to define indexes, worry about how I’d join things, or spend time wondering if there was a good way to optimize it by putting stuff in 3NF
@ Johannes: Thanks for a well-written answer; it’s probably the best description I’ve ever seen that makes a comparison between a relational DB and other forms of collecting and managing data. Well done!
-Tod