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

Странная идея - атрибуты с одинаковым назначением от разных сущностей пихать в какую-то общую сущность...

miksoftalexeyvgПлохой способ - больше места для данных, намного тяжелее запросы.Это справочные данные, вряд ли они будут использоваться для, например, фильтрации. Так что насчет "тяжелее запросы" не соглашусь. А в ряде случаев, когда эти данные не нужны даже для отображения, так и легче.Согласен, конечно важно, как эти данные будут использоваться...

Не важноalexeyvg
Плохой способ - больше места для данных, намного тяжелее запросы.

А чем он плох? добавится один джоин по кластерному индексу. Тут конечно может быть проблема с созданием оптимальных запросов, поскольку один джоин в запросе может кардинально поменять политику выборки. Это есть - по крайней мере в MS SQL.Зависит от использования этих полей.

Если нужно показывать поля постоянно - добавится просто джойн. Это-же не повышает производительность?

А вот если в запросах будет, например, фильтр для учёта прав, или что-то вроде показа записей их создателю первыми, то такое разделение просто поставит всё раком (например, в постраничных выборках без фильтров).

Не важноalexeyvg
Странная идея - атрибуты с одинаковым назначением от разных сущностей пихать в какую-то общую сущность...

Я думаю что это нормально - как в ООП. Общие вещи в базовый класс.Это для ООП нормально. И то - нормально в наследовании, а здесь-же нету наследования.

В ООП ведь при создании объекта класса-наследника не создаётся объект, в котором в качестве члена присутствует объект класса-родителя?

Для РСУБД так делают, но не по принципу наличия одинаковых имён полей :-) , а выделяя именно общую сужность.

Т.е. можно выделить сущность "документ" из сущностей вида "документ типа ХХХ", сделать "документ" отдельной таблицей и перенести туда какие-то общие атрибуты.
ПРи этом действия могут быть сделаны над общей и над производными таблицами как по отдельности, так и вместе.

У вас же не предполагается использование таблицы с датами отдельно, как самостоятельной сущности? Это ключевая вещь при таком выборе. Просто искать группы полей с одинаковыми именами и выносить - неправильно.

Не важноmiksoft
А вот что мне кажется плохим - какая недоделанная "историчность" - апдейтить запись могут много раз, а сохранится только самый последний.

Тут нужно немного пояснить. База делается как бэ в соответствии с базой одного CRM (MS Dynamics) Там как раз ведутся две колонки - создавший и последний обновивший. Промежуточные неважны.Если не важны - вопросов нет.

Обычно как раз в поисках виноватого эти данные очень даже важны. :-)

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

Не важноТут еще фишка есть такая как ОРМ. И с добавлением еще одной таблицы префоманс генереного запроса, теоретически, может просесть.
Вот я и думаю - стоит ли затевать такой "рефакторинг" базы или по старинке делать колонки в каждой таблицеНу вот, вы даже беспокоитесь, не слишком ли сложно будет клиенту прочитать :-) А делать джойн по ключу - это по вашему ничего не стоит.

АнатоЛой"Хочу отфильтровать все документы/отчёты/настройки, которые я создавал в этом месяце" - не пойдёт?Серверу придётся сделать 2 отфильтрованных списка ID документов, а потом уже вычислить по ним пересечение. Это тяжёлая операция. Конечно, "тяжесть" проявится, если данных много, на тыще записей не заметите.

АнатоЛойНормальная идея - это анализировать такие совпадения. А вот сразу пихать в общую - таки, странная, да... :)Ну так вот я и анализирую.

У вас, собственно, два аргумента:
1. вам так нравится
2. в ООП так делают

Я говорил, что вынесение части полей в общую сущность можно в том случае, если это именно самостоятельная сущность, с которой работает ваша система.

Например, есть таблица Документ, есть много таблиц ДокументТипаХХХ.

Система много работает только с таблицей Документ и с общими атрибутами для всех типов документов, которые вынесены в эту таблицу.
А вот уже при проведении какой-то проводки или для расчётов по конкретному типу документа обращаемся к остальным таблицам.

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

У вас, судя по описанию, таких вариантов нету.

АнатоЛойalexeyvg, я так понял, что всё описанное направлено ТС? А то я как раз целиком с вашими выкладками согласен :)Да-да, конечно - не совсем внятно написал...