С точки зрения приложения дизайн, имеющий одну уникальную таблицу для всех комментариев, кажется, имеет смысл. В терминах кода приложения это означает, что один и тот же SQL будет повторно использоваться для всех сущностей. Это «классический способ», используемый большинством приложений, который распространяется на те же записи и контроллеры, которые используются для обработки комментариев и вложений для всех объектов.
С точки зрения SQL, второе решение может быть полезно в некоторых базах данных, таких как MySQL, чтобы получить больше Memory Cache преимуществ. Каждый комментарий / присоединение, добавленный в 1-м решении, удаляет из кэша памяти все запросы, влияющие на таблицу комментариев. В отдельных таблицах комментарий к одной сущности не делает недействительными запросы к другим сущностям. Но вам бы также потребовалось больше файловых дескрипторов и больший кеш таблиц ... поэтому, чтобы выбрать это решение, вам нужно решение, основанное на реальном, точном случае, где вы сможете сравнить преимущества в скорости доступа к базе данных. , И когда вы добавите новые сущности, вам наверняка будет скучно решение «каждая сущность, у которого есть комментарий», все можно было бы автоматизировать с помощью первого решения.