Есть ли способ использовать наследование в базе данных (особенно в SQL Server 2005)?
Предположим, у меня есть несколько полей типа Создано на, Сделано, которые я хочу добавить ко всем своим объектам. Я ищу альтернативный способ вместо добавления этих полей в каждую таблицу.
Если это единственная цель, я согласен. Но вопрос наследования db - хороший вопрос
Реализовано: stackoverflow.com/questions/386652/…


Вы можете создать шаблон на панели шаблонов в Management Studio. А затем используйте этот шаблон каждый раз, когда хотите создать новую таблицу.
В противном случае вы можете сохранить поля CreatedOn и CreatedBy в таблице журнала аудита, ссылаясь на исходную таблицу и идентификатор.
В противном случае сделайте это вручную.
шаблоны не являются наследованием
PostgreSQL имеет эту функцию. Просто добавьте это в конец определения вашей таблицы:
INHERITS FROM (tablename[, othertable...])
Дочерняя таблица будет иметь все столбцы своей родительской, и изменения в родительской таблице изменят дочернюю. Кроме того, все в дочерней таблице будет появляться в запросах к родительской таблице (по умолчанию). К сожалению, индексы не пересекают родительскую / дочернюю границу, что также означает, что вы не можете убедиться, что определенные столбцы уникальны как для родительского, так и для дочернего элемента.
Насколько я знаю, эта функция используется не очень часто.
я думал, что вопрос сказал «конкретно в SQL Server 2005»?
В SQL Server 2005 нет такой вещи, как наследование между таблицами, и, как отмечали другие, вы можете получить помощь по добавлению необходимых столбцов в таблицы при их создании, но это не будет наследованием, как вы знать это.
Думайте об этом больше как о шаблоне для файлов исходного кода.
Как упоминает GateKiller, вы можете создать таблицу, содержащую общие данные, и ссылаться на нее с помощью внешнего ключа, но вам придется либо иметь контрольные перехватчики, триггеры, либо выполнять обновление вручную.
Итог: ручная работа.
старайтесь не ссылаться на другие сообщения, потому что они вышли из строя из-за голосования.
Вы можете использовать инструмент моделирования данных, такой как ER / Studio или ERWin. Оба инструмента имеют столбцы домена, где вы можете определить шаблон столбца, который можно применить к любой таблице. При изменении домена меняются и связанные столбцы. В ER / Studio также есть шаблоны триггеров, которые можно создать и применить к любой таблице. Вот как мы обновляем наши столбцы LastUpdatedBy и LastUpdatedDate без необходимости создавать и поддерживать сотни сценариев триггеров.
Если вы действительно создадите таблицу аудита, у вас будет по одной строке для каждой строки в каждой таблице, которая использует таблицу аудита. Это могло стать беспорядком. На мой взгляд, вам лучше поместить столбцы аудита в каждую таблицу. Вы также можете поместить столбец с отметкой времени во все свои таблицы. Никогда не знаешь, когда параллелизм станет проблемой. Наши столбцы аудита БД, которые мы помещаем в каждую таблицу: CreatedDt, LastUpdatedBy, LastUpdatedDt и Timestamp.
Надеюсь это поможет.
У нас есть SProc, который добавляет столбцы аудита в данную таблицу и (необязательно) создает таблицу истории и связанные с ней триггеры для отслеживания изменений значения. К сожалению, политика компании означает, что я не могу поделиться, но этого действительно нетрудно добиться.
Если вы используете GUID, вы можете создать таблицу CreateHistory с GUID столбцов, CreatedOn, CreatedBy. Для заполнения таблицы вам все равно придется создать триггер для каждой таблицы или обработать его в логике приложения.
если все, что у вас есть, это GUID, как узнать, из какой таблицы он взят?
Вы НЕ хотите использовать для этого наследование! Когда таблица B, C и D наследуется от таблицы A, это означает, что запрос таблицы A даст вам записи из B, C и D. Теперь рассмотрим ...
УДАЛИТЬ ИЗ;
Вместо наследования используйте LIKE ...
CREATE TABLE blah (
blah_id serial PRIMARY KEY
, something text NOT NULL
, LIKE template_table INCLUDING DEFALUTS
);
Рамеш - я бы реализовал это, используя отношения супертипа и подтипа в моей модели 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 имеет отношение внешнего ключа к Object. когда вы создаете строку SubObject, вы должны сначала создать строку Object и использовать Id в обеих строках
Я думаю, что ваш вопрос было бы более уместно сформулировать как «Каковы рекомендуемые способы проведения аудита в базе данных?»