P: Allow Catalog to be stored on a networked drive.

And about SQL being old. There is yet to be a replacement for it. There are a bunch of object database projects out there and some very advanced ideas for future DBMS models but SQL is still the current valid one. It is (relatively) old but still current, not obsolete.

GUI has nothing to do with catalog storage. All we are talking about is taking the data that is stored on the lrcat file and allow it to be stored in a remote SQL server, one that will allow for more advanced management of that data. The GUI would stay exactly the same.

Right, thanks for the move...

About merging Bridge with LR. Bridge looks like it will stay alive as LR does not allow managing assets from other CS products and it is photographer centric and may not suit other creative designers but Bridge's sharing capabilities rely solely on sharing capabilities of the network and file system. Hardly a good solution for concurrent updates and performance. I say performance because bridge needs to scan files to grab the metadata. It caches the information but cannot compete with proper SQL engines for searches on a large volume of data. Concurrent updates because files systems do not have built-in support for concurrent updates, whereas SQL servers are pretty good at it...

Agreed, storage technologies have nothing to do with the topic...

I posted this the other week, http://www.squarebox.com/

I've put a few ideas into this software and I put it in a various facilities, SQL based whatever flavour, but it's very complex. LR could quite easily go this route, but for me, it's Pro's are the fact it's a simple GUI that is easy to follow

True, although is that the message a software company wants to put out?

it may be old tech but very much alive. plus all developers are familiar with it...

which is why I don't think full SQL will ever be written into LR, it's old tech and Adobe are looking at new trends

With no order at all in seems haha 🙂 I feels like I was just dropped in a mine field 😉 Indeed, a drink is in order...

Almost all databases run on SQL engines, aside from legacy systems too big to rewrite that run on hierarchical DBMS' on mainframes. Even then, some now run on DB2, SQL on mainframe. Large assets are still mainly kept on file systems because they are too big to be effectively "managed" by an SQL engine (and there is not real point). There are many advantages for LR to use a relative database but in it's current incarnation, I don't really see the advantage. LR could store the whole catalog in a flat or XML file and the result would be the same (aside from the fact that managing the memory to store a large catalog would be problematic). But SQL does open the door to effective sharing of the data that is in the catalog and LR does not allow it because it uses SQL lite...

SQL is is old and very common tech. No implementation issues here, with such a simple system as LR.

yes, and like SQL i can easily follow multiple threads without getting confused. Mongo however DOES have this documented issue as it is non linear lol
It's more like "mind mapping database software" random and odd.

Spinning hard drives last longer when they remain spinning, ssd drives should NEVER be used as system drives in a "non tech" environment because of the much reduced read write reliability over time, and the fact the "average" user stuffs all their data on the one single partition these days and risks losing ALL of it far quicker.

All computers should have an internal backup drive for speed, and an external for redundancy. And hopefully an internal alternate drive for data.

LR still needs collaboration and a work around for "home use" can be freefilesync.

Topic replies vs comment replies is the issue...
If you find a comment to reply to, keep to that comment's idea thread

leaping to another comment thread to continue the points is what's causing the issue so let's recap :

LR needs some form of collaboration / multimachine use.
Other ideas came forth about merging LR and Bridge.
Hard drive usage is not at issue
Database implementation is easiest if kept in the same vein the originating engine is built upon.