У Вас может быть 2 таблицы с идентичной структурой в хорошей схеме DB?

С точки зрения моделирования E/R я не вижу в этом проблемы, пока они представляют две семантически разные сущности.

С точки зрения реализации, это зависит от того, как вы планируете запрашивать эти данные:

• Если вы планируете запрашивать эти таблицы независимо друг от друга, сохранение их отдельно - хороший выбор
• Если вы планируете запрашивать эти таблицы вместе (возможно, с помощью операции UNION или JOIN), вам следует рассмотреть возможность хранения их в одной таблице со столбцом дискриминатора для различения их типа

При рассмотрении вопроса о том, стоит ли объединять их в одну таблицу, вам также следует принять во внимание другие факторы, такие как:

• Объем данных, хранящихся в каждой таблице
• Скорость роста данных в каждой таблице
• Соотношение операций чтения/записи, выполняемых в каждой таблице

Крис Дейт и Дэйв Макговеран формализовали "Принцип ортогонального проектирования". Грубо говоря, он означает, что при проектировании базы данных следует избегать возможности допускать один и тот же кортеж в двух разных реляторах. Цель состоит в том, чтобы избежать определенных типов избыточности и двусмысленности, которые могут возникнуть в результате.

Возможно, это не всегда практически осуществимо, и не всегда ясно, когда именно нарушается принцип. Однако я считаю, что это хорошее руководящее правило, хотя бы потому, что оно позволяет избежать проблемы дублирования логики в коде доступа к данным или ограничениях, т.е. это хороший DRY принцип. Избегайте наличия таблиц с потенциально пересекающимися значениями, если нет ограничений базы данных, которые предотвращают дублирование между ними.

Это зависит от контекста - что такое View и что такое Download ? Подразумевает ли Download View (как еще это было бы загружено)?

Возможно , что у вас есть четко определенные, отдельные концепции, но это запах, который я хотел бы исследовать дальше. Кажется вероятным, что просмотр и загрузка каким-то образом связаны, но ваша модель ничего не показывает.

Вы хотите сказать, что обе таблицы имеют первичный ключ item_id? В этом случае поля имеют одно и то же имя, но не имеют одинакового значения. Один - это view_id, а другой - download_id. Вы должны соответственно переименовывать свои поля, чтобы избежать такого рода недоразумений.

Эти таблицы одинаковы СЕЙЧАС, но в будущем схема может измениться. Если они представляют две разные концепции, то хорошо бы держать их отдельно. Что если вы хотите иметь внешний ключ из другой таблицы к таблице загрузок, но не к таблице представлений, если бы они были одной и той же таблицей, вы не смогли бы этого сделать.

Я думаю, что ответ должен быть "это зависит". Как заметил кто-то другой, если схема одной или обеих таблиц, скорее всего, будет меняться, то нет. Я могу придумать и другие случаи (упрощение модели безопасности путем предоставления доступа приложениям/пользователям к одной или другой таблице).

Сказав это, я работаю с унаследованной БД, где это является проблемой. У нас есть несколько одинаковых таблиц для счетов-фактур клиентов. Данные фактически перемещаются между ними на разных этапах жизненного цикла обработки. Это создает сложную путаницу при попытке доступа к данным. Эта проблема была бы легко решена с помощью флага состояния в исходной схеме, но теперь у нас есть более 20 лет кода, написанного для многотабличной версии.

Короткий ответ: зависит от того, почему это одна и та же схема :).