I am not anti databases - they are the fundamental building blocks of any high volume, searchable data storage mechanism. What I am “anti” is badly designed and used databases.
When I started using RDBMSs over thirty years ago, I learnt (and used) the principles of SPOD and the use of referential integrity to minimise possible duplication or spelling errors.
At present, I am able to delete the database whenever I want and PL will rebuild it as needed. Why? because DxO don’t have a SPOD design - they duplicate data in DOP files, mainly using the database as an indexing mechanism for speed of searching. That is, until you want to search a folder that hasn’t yet been indexed - a procedure that can take some considerable time.
Indeed but DxO have decided to conflate image editing data with metadata in the same database.
Now, we have image editing data in two places - DOP and DB; and metadata in, at least, three possible places - DOP, DB, XMP and image files. This violates the SPOD rule in all sorts of ways and, as @platypus has pointed out on many occasions, there is no way of managing errors that can occur when image files are moved outside of PL.
I notice that there is a reconciliation icon for when metadata conflicts occur but there is no indication as to what the conflict is before having to choose between updating the database from an image or the image from the database. Conflict resolution is much more complex than that and needs a small dialog to show what the problem is, in case automatic resolution leads to inadvertant data loss.
I do not delete the database for metadata purposes because all my metadata is stored in the original image file and the macOS Spotlight metadata database/index. I could care less about the DxO database for that purpose.
What I do delete the database for is to resolve differences and conflicts that occur when moving already edited images from one location to another on disk(s), which PL tries to make sense of but, frequently, makes a total mess of (see my support of @platypus request for database management)
As is your prerogative. Some folks use them, some don’t.
And I am sorry but you have never used my app and, therefore, haven’t realised it is 100% compatible with industry standards. Until recently, there were problems with PL not being 100% compatible with those standards, just as some other apps are also non-compliant. But, all credit to DxO, they have now added a preference option to cope with such compatibility (or not). My app manages keywords, their hierarchies and dictionaries - the latter being something that DxO has yet to tackle.
I could ramble on more but, suffice to reiterate, I am not anti database - heck I even designed a complete ORM (object relational model) to provide translation between object classes and SQL tables, complete with the ability to auto-update the database structure where the object model changed, allow users to change what data they wanted to store by using a UI, with no knowledge of how RDBMSs work.
You do realise that most people reading these forums are not DBAs or systems analysts? They are photographers who just want to manage their photos. How that gets done should be a black box, not something they have to deep dive into the internals of when something goes awry.
To the best of my knowledge, DxO will more than likely be using Apple’s Core Data ORM with SQLite as a backend. Fiddling with the raw database is highly likely to upset the various automatic relationship management routines that form part of the ORM - something you do at your own risk but certainly not for the faint-hearted photographer who has difficulty reading voluminous, unstructured, posts.
Nope, because I have never used Lightroom.
Well, I’m sorry but you have that totally wrong. I certainly believe that the DOP files should be the master for image editing data, because they can travel with the image files in the same way that XMP sidecars can travel for metadata purposes. That is, unless DxO can better manage the database for moving edited files which have DOPs.
The problem is that DxO have decided to triplicate metadata in XMP and DOP sidecars and the database when it is only truly necessary to hold the editing in DOP files only and the metadata in XMP files only.
As I have explained before, my app uses the macOS-provided Spotlight database, which is far more efficient at indexing and maintaining metadata than any third-party database because it is integrated in the OS and every time you touch a file, it is automatically updated. Add to that the fact that I embed metadata directly in RAW files and I really have no need for a management app, apart from actually getting the metadata not the RAW files - macOS looks after everything else.
must be a side effect of my growing software and developer’s excused allergy. Need to get that under control.
, we need to work on your communication strategy 
