… or, why is deleting a database an internal DEVONthink menu command, anyway? You don’t use FileMaker’s interface to delete FileMaker databases … or Together … or MacJournal … or …
So, deletion should be a file system action (in Finder) and if DEVONthink cannot find a database file then DEVONthink disappears the database from the sidebar.
Now that we are talking about it, I think the default dialogue for the left side of the interface is the problem. It is the same for everything there, but that is not appropriate for some of the items, and it behaves oddly.
For example, clicking on a database brings up the option to empty trash. But, clicking on the empty space, where it would seem slightly more appropriate (maybe you are drunk and missed the trash can), has the option grayed out.
Maybe the solution is really simple (in theory).
This way, the dialogue is the same, you don’t have to customize the dialogue for every item, and the problem of accidentally hitting delete is solved. You’d have to travel all the way down to the bottom of the dialogue, past the grayed-out “empty trash” in order to do it.
Some good suggestions here. My original idea of putting it in the middle of the “Favourites” (or “Favourites” as the American English has it 
) was that if it was there it would not cause much harm if the one either side, “Add to Favourites” & “Remove from Favotitres”, was clicked in error.
Something has just hit me that may or may not be an idea; recently Bluefrog posted an excellent script to close all databases and quit which he suggested putting in the toolbar, I use it a lot and wondered if a similar script just to close a selected database that you could put in the toolbar would work?
(Embarrasing admission: I have tried to come to grips with writing scripts and have got so frustrated with it, so if someone else could write one I would love it!)
The safety popup and the fact that the DB gets moved to the OS Trash should be good enough protection for most cases.
Generally, though, I wonder about what goes into a contextual menu. That mechanism was presumably invented to give very quick, on the spot access to menu items that (1) need to be accessed frequently and/or (2) depend on the local context, i.e. the cell chosen in a spreadsheet.
Except for the scenario of testing things out, deleting a database is a rare event with rather deep consequences. The contextual menu does not look like the right place to offer such options. You’d do this typically through the File menu.
Example: Preview lets you remove individual pages from a multipage pdf document. If you highlight a single thumbnail, the contextual menu does not give you the “delete” option, and you have to go to “Edit > Delete”. I use this feature a lot, and I often wish there was a contextual option. I wonder whether Apple found that too dangerous. Maybe not, because there is not protection against a completely unprotected “delete” keyboard action, which is arguably more dangerous.
Until fairly recently, DEVONthink Pro and Pro Office did not include an option to delete a database from within the application. To delete a database, the user had to go to the Finder and move the database file to the Trash.
Adding the option to delete a database from within the application gives the user more power, including the potential to use that power by mistake. 
As inadvertent deletion of a database can have huge negative consequences, I would favor removal of the option to delete a database from within the application. While the UI should generally favor making things easy for the user, this is an example of a case where the UI should make it harder to do something.
My argument against deleting delete from the contextual menu would be that you would be making the app less accessible to non-technical folks (the vast majority of people out there), because they won’t even be able to find their Library (thank you Apple), much less their DT database. It’s totally understandable and not something we ought to expect users to learn, because I am sure they have more important things to be doing.
FINDER
OK. So, we delete delete from the contextual menu, as proposed, but that leaves us with the potential problem of non-tech savvy users. How about in the main menu (where it currently resides, but only lights up if you have a database highlighted), make it function just as the “open database” option does by taking you to the database location and letting you delete it using Finder.
THE PROBLEM
The argument against this change (and against the proposal to remove delete from the app entirely and expect users to delete databases via Finder) is that renaming a database within DEVONthink does not change the name in Finder, so there is bound to be confusion and the very real potential for mistakenly deleted databases. You’d have to also keep the database names on the drive matching the names displayed in DT, but I think this is a good idea anyhow, even though I imagine it will be a lot more work than my proposal to just move “delete” and gray it out when it is unnecessary.
Or not do it at all from within the application.
I suspect the population of renamers is rather small … and why would someone delete a database in Finder without knowing what it is?
Although one can change the name of a database in Database Properties, this doesn’t change the name of the database filename in the Finder.
However, the filename continues to be displayed in Database Properties in the Path to the database, and is also displayed under, e.g., Open Databases when one hovers the cursor over the database Name.
Yes, exactly. It was kind of of a rhetorical question. In other words, the “delete database” has no business of being in a contextual menu. It’s generally a rarely used command.
I would argue for putting this command in a “safe” location in the menu. Even “File” might be not the place. Maybe in “Tools”, together with databased maintenance commands. In a wider sense, deleting is a form of maintenance.
I would not want to force the general user to go the route of deleting the database in the Finder. While in the case of DT, this is technically perfectly fine, we keep telling users not to meddle with database issues directly via the Finder (with the exception of indexed files). So it makes sense to let DT take care of all DB maintenance issues. For example (just hypothetically), if you delete the database externally, and the DB program has some internal information on that DB stored somewhere else, corruption issues could arise.
My vote would now be “not in contextual menu” and “in Tools menu”
The Tools Menu seems a good idea.
I can’t really say how many people rename their databases. It is squirreled away in database properties, so that probably makes it less likely.
I’m really thinking about frictionless design, though: users are empowered to accomplish tasks (putting it into an accessible menu) without needing to look in a manual, learn what a path is, etc. But, we also don’t want them to cause irreparable harm or make the app hopelessly bloated with unnecessary stuff.
Perhaps the command does need to leave the contextual menu. But I do think the current way that it is set up in the file menu leaves something to be desired. I don’t think it is obvious that you have to select a database, go to File, and then click Delete Database. The contextual menu seems far more accessible. Alternatively, or in addition to adjustments to the contextual menu, I’d like to see Delete made to behave like other commands if it is in the File menu. I am thinking of potential trouble with a change that borrows from an existing pattern in DT: opening of a database.
If we do make it behave like “open database,” or take it out of DT entirely, then either solution leaves us with Finder, and this is where the database names matter, because it is potentially confusing. I figure it is better to design these kinds of potential problems out of the app rather than relying on people not to do stupid things.
Assuming one of those two solutions is implemented, would it be worth the effort? There is no benefit (that I can see) to having the names out of alignment, though I can imagine a change to make sure the names stay the same inside and outside the app might take a lot of work, and it might not be worth the effort. Only the DT folks can speak to that.
In the end, it seems to me that the simplest solution is still to move the command to the bottom of the list, tweak the way that things are grayed out, and save any major overhauls for a rewrite of the app in the future. This gives users control over the app, without having to leave the app, and it solves the concern originally raised here about accidentally pressing it.
ROFL! Nice. 