Наследование в базе данных?

PostgreSQL имеет эту функцию. Просто добавьте это в конец своего определения таблицы:

INHERITS FROM (tablename[, othertable...])

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

Насколько я знаю, это не функция, использованная очень часто.

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

Приводя это к сбою, Вы могли сохранить поля CreatedOn и CreatedBy в таблице Журнала аудита, ссылающейся на исходную таблицу и идентификатор.

Сбой этого, сделайте это вручную.

Вы могли использовать инструмент моделирования данных, такой как ER/Studio или ERWin. Оба инструмента имеют доменные столбцы, где можно определить шаблон столбца, что можно обратиться к любой таблице. Когда доменные изменения так делают связанные столбцы. ER/Studio также имеет триггерные шаблоны, которые можно создать и обратиться к любой таблице. Это - то, как мы обновляем наши столбцы LastUpdatedBy и LastUpdatedDate, не имея необходимость создавать и поддерживать сотни сценариев триггера.

Если бы Вы действительно составляете контрольную таблицу, Вы поссорились бы для каждой строки в каждой таблице, которая использует контрольную таблицу. Это могло стать грязным. По-моему, Вы - более обеспеченное помещение контрольных столбцов в каждой таблице. Также можно хотеть поместить столбец метки времени во все таблицы. Вы никогда не знаете, когда параллелизм становится проблемой. Наши столбцы аудита DB, что мы вставляем каждую таблицу: CreatedDt, LastUpdatedBy, LastUpdatedDt и Метка времени.

Надеюсь, это поможет.

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

Вы НЕ хотите использовать наследование, чтобы сделать это! Когда таблица B, C и D наследовались таблице A, которая означает, что запросы таблицы A дадут Вам записи от B, C и D. Теперь рассмотрите...

УДАЛИТЕ ИЗ a;

Вместо наследования используйте КАК вместо этого...

CREATE TABLE blah (
    blah_id     serial       PRIMARY KEY
    , something text         NOT NULL
    , LIKE template_table    INCLUDING DEFALUTS
);

Ramesh - Я реализовал бы этот супертип использования и отношения подтипа в моей модели E-R. Существует несколько различных физических опций, которые Вы имеете реализации отношений также.

в отображении O-R наследование отображается на родительскую таблицу, где родительские и дочерние таблицы используют тот же идентификатор

например,

create table Object (
    Id int NOT NULL --primary key, auto-increment
    Name varchar(32)
)
create table SubObject (
    Id int NOT NULL  --primary key and also foreign key to Object
    Description varchar(32)
)

SubObject имеет отношения внешнего ключа к Объекту. при создании строки SubObject необходимо сначала создать Объектную строку и использовать идентификатор в обеих строках

При использовании GUID, Вы могли бы составить таблицу CreateHistory со столбцами GUID, CreatedOn, CreatedBy. Для заполнения таблицы необходимо было бы все еще создать триггер для каждой таблицы или обработать его в прикладной логике.