3 ms·

There's a ton of places where foreign keys are used wrong - deletion is acceptable, and good error handling for that case is the right thing to build anyway. T

There's a ton of places where foreign keys are used wrong - deletion is acceptable, and good error handling for that case is the right thing to build anyway. That's one of the key arguments that nonconsistency advocates are arguing for. If you build a music playlist, the behavior of the program if the mp3 files referenced within should be to skip that track, not to crash. I've heard too many people arguing that they should be allowed to emit nasal demons if there's a data error, and they're wrong even in many well structured and tightly integrated datasets, but especially wrong in "web-scale" datasets

bcrosby95 4y ago
Deletion is acceptable, and if you have everything in a consistent system they will both exist or not. "Nonconsistency advocacy" doesn't make a lot of sense to me here. Are you advocating not relying on consistency in systems that guarantee consistency? That is a waste of time. Are you advocating eschewing consistent systems? Well, then you have more work, so only if I need to. And yes, you should handle data errors here because inconsistency is consistent with the system you've chosen.
- GauntletWizard 4y ago
  My point is: Removing a music track from the list of playable tracks is not a good reason to remove it from playlists. Having dangling pointers there, and handling them appropriately is the right thing to do. This is true in a ton of cases where neither soft-delete or cascading delete make sense. Rarely, if ever, have I actually encountered the latter.
  - ddulaney 4y ago
    Hmm... That's an interesting example. It definitely makes sense to enable features like that. However, I'm not sure it's a place where you want to abandon foreign-key consistency. To display the song on the playlist (greyed-out, Spotify-style) you need its name and info, and you probably want to keep artist and album links valid as well. It sounds like this is actually a perfect use-case for a soft-delete: keep the song metadata in the songs table and mark it as nonplayable. This keeps the artist page, album page, and any links to the song itself valid, just greyed out when you get there.

bcrosby95 4y ago

Deletion is acceptable, and if you have everything in a consistent system they will both exist or not. "Nonconsistency advocacy" doesn't make a lot of sense to me here. Are you advocating not relying on consistency in systems that guarantee consistency? That is a waste of time. Are you advocating eschewing consistent systems? Well, then you have more work, so only if I need to. And yes, you should handle data errors here because inconsistency is consistent with the system you've chosen.

GauntletWizard 4y ago
My point is: Removing a music track from the list of playable tracks is not a good reason to remove it from playlists. Having dangling pointers there, and handling them appropriately is the right thing to do. This is true in a ton of cases where neither soft-delete or cascading delete make sense. Rarely, if ever, have I actually encountered the latter.
- ddulaney 4y ago
  Hmm... That's an interesting example. It definitely makes sense to enable features like that. However, I'm not sure it's a place where you want to abandon foreign-key consistency. To display the song on the playlist (greyed-out, Spotify-style) you need its name and info, and you probably want to keep artist and album links valid as well. It sounds like this is actually a perfect use-case for a soft-delete: keep the song metadata in the songs table and mark it as nonplayable. This keeps the artist page, album page, and any links to the song itself valid, just greyed out when you get there.