The relationship tables have the entity names in alphabetical order. Most of the time, that makes sense and doesn't really cause a problem. For URLs though it's rather annoying, because URLs are weird and work differently from normal entities (URL entities don't have a name column, for example). The result is that every time someone wants to write generic code that fetches URLs for whichever entity type you pass in, they have to include something to handle the reversed order of l_url_work. I have this problem a lot and I've seen other people have to do the same thing, e.g. https://github.com/murdos/musicbrainz-bot/blob/master/wp_wikidata_links.py#L44

The best thing I can think of (without completely changing how we handle URLs) is to provide a view for l_work_url which returns all the same columns, just with entity0 and entity1 switched. While people could in theory add these manually on their own servers, any code written to use that view won't work on another server unless someone has also added the view there too, which means you still have to write an exception in your code for l_url_work if you want your code to be portable. That's why I think it would be better for it to be a standard view provided by us, so that people have the choice.

Are there any reasons why we shouldn't do it? The main issue I can see is that the values in the link_type table will be back to front if you join from l_work_url rather than l_url_work, but I'm not sure how much of a problem that would be in practice.