SQL много таблиц с одним и тем же столбцом (столбцами) - экспорт в отдельную таблицу и JOIN на каждый запрос?

Question

Я разрабатываю довольно большое приложение, которое, вероятно, будет иметь около 50-100 таблиц в целом.

Я считаю, что почти в каждой таблице могут использоваться столбцы «удалено», «отметка времени», «идентификатор_пользователя», «рабочее пространство».

Теперь было бы лучше не избавляться от этой практики.все эти столбцы и просто создать 3 таблицы с теми именами, которые связаны как с row_id и table_id всех других таблиц 50-100?Затем при каждом запросе я просто присоединяюсь к этим таблицам?

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

Что общегоподход к этому?Безусловно, экспорт логики во внешние таблицы выглядит скорее как нормализованный подход, однако производительность может снизиться, если в каждом запросе так много JOINS (поскольку существующая структура данных довольно сложна, будет уже много соединений и т. Д.).).

Answer 1

Это действительно зависит от того, что вы планируете делать с данными.

Планируете ли вы выполнять много запросов, используя только данные в этих столбцах (удаленные флаги, все метки временных меток и т. Д.), Не просматриваяна другие данные, содержащиеся в данной строке?

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

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

Например, для меня не имеет смысла включать удаленный флаг в объединенную таблицу - вы хотите иметь возможность фильтрации по столбцу, чтобы узнать, следует ли что-то рассматривать как удаленный.

С другой стороны, информация аудита (дата создания, дата изменения, дата удаления, кто удалил, последний доступ и т. Д. И т. Д.) - все это похоже на тип данных, которые могут храниться в другомэр столЧасто вам захочется просто посмотреть информацию аудита, а не заботиться о конкретной строке.

Answer 2

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

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

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

Является ли это хорошо или не очень хорошая вещь довольно спорный вопрос. Это способ реализации баз данных. Вы можете сами предложить свои предложения для существующих баз данных или внедрить собственную систему баз данных.