Concurrent Users and Foreign Keys
Some discipline is needed.  A location_id must always refer to a particular location, even if the name of the building changes or you make a correction to the address.

The UI must make it obvious whether to the user as to whether he is editing a "location" or creating a "new" location.

When providing the "pull down" in the UI, the id is hidden and uniquely identifies it to the rest of the data; the name, address, etc is useful for humans to know which 'location' it is.

The UI needs a straightforward way to change an even from one location to another -- in case the original association to an event was erroneous or in the case that the even is moved to a different venue.

Nothing if foolproof.

You need scripts that check for double-booking.  They should provide sufficient info to help the admin figure out whether it was a typo, a confusion of two similar location names, etc.