Действительно ли возможно перечислить все внешние ключи в базе данных?
Читайте спецификация W3C. (это - CSS 2.1, найдите соответствующую версию для своего предположения о браузерах)
редактирование: соответствующий абзац следует:
В CSS, идентификаторы (включая имена элементов, классы и идентификаторы в селекторах) могут содержать только символы [a-z0-9] и символы U+00A1 ISO 10646 и выше плюс дефис (-) и подчеркивание (_); они не могут запустить с цифры или дефиса, сопровождаемого цифрой. Идентификаторы могут также содержать оставленные символы и любой символ ISO 10646 как цифровой код (см. следующий объект). Например, идентификатор "B& W?" может быть записан как "B\& W \?" или "B\26 W\3F".
редактирование 2: как @mipadi указывает в ответе Триптиха, существует этот протест , также на той же веб-странице:
В CSS, идентификаторы могут начаться с '-' (тире) или '_' (подчеркивание). Ключевые слова и имена свойства, начинающиеся '-' или '_', резервируются для определенных для поставщика расширений. Такие определенные для поставщика расширения должны иметь один из следующих форматов:
'-' + vendor identifier + '-' + meaningful name '_' + vendor identifier + '-' + meaningful nameПример (примеры):
, Например, если организация XYZ добавила свойство для описания цвета границы на Восточной стороне дисплея, они могли бы назвать его-xyz-border-east-color.
Другие известные примеры:
-moz-box-sizing -moz-border-radius -wap-accesskeyначальный тире или подчеркивание, как гарантируют, никогда не не будут использоваться в свойстве или ключевом слове никаким текущим или будущим уровнем CSS. Таким образом типичные реализации CSS не могут распознать такие свойства и могут проигнорировать их согласно правилам для обработки ошибок анализа. Однако, потому что начальный тире или подчеркивание являются частью грамматики, лица, осуществляющие внедрение CSS 2.1 должны всегда быть в состоянии использовать приспосабливающий CSS синтаксический анализатор, поддерживают ли они какие-либо определенные для поставщика расширения.
Авторы должны избежать определенных для поставщика расширений
2 ответа
Я использую этот оператор, кажется, он работает довольно хорошо.
SELECT RC.CONSTRAINT_NAME FK_Name
, KF.TABLE_SCHEMA FK_Schema
, KF.TABLE_NAME FK_Table
, KF.COLUMN_NAME FK_Column
, RC.UNIQUE_CONSTRAINT_NAME PK_Name
, KP.TABLE_SCHEMA PK_Schema
, KP.TABLE_NAME PK_Table
, KP.COLUMN_NAME PK_Column
, RC.MATCH_OPTION MatchOption
, RC.UPDATE_RULE UpdateRule
, RC.DELETE_RULE DeleteRule
FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS RC
JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE KF ON RC.CONSTRAINT_NAME = KF.CONSTRAINT_NAME
JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE KP ON RC.UNIQUE_CONSTRAINT_NAME = KP.CONSTRAINT_NAME
Теоретически это сложно. Реляционная модель позволяет любому полю соотноситься с любым другим полем. Какие из них фактически используются, определяется всеми возможными операторами SELECT, которые могут быть использованы.
Практически это зависит от того, сколько таблиц содержит определения FK. Если кто-то потрудился тщательно определить все ссылки FK - а операторы SELECT придерживаются этих правил - вы можете запросить их.
Однако, поскольку оператор SELECT может присоединяться к чему угодно, нет никакой гарантии, что у вас есть все FK, если у вас также нет всех операторов SELECT.
Редактировать .
SELECT f.name AS ForeignKey,
OBJECT_NAME(f.parent_object_id) AS TableName,
COL_NAME(fc.parent_object_id, fc.parent_column_id) AS ColumnName,
OBJECT_NAME (f.referenced_object_id) AS ReferenceTableName,
COL_NAME(fc.referenced_object_id, fc.referenced_column_id) AS ReferenceColumnName
FROM sys.foreign_keys AS f
INNER JOIN sys.foreign_key_columns AS fc
ON f.OBJECT_ID = fc.constraint_object_id
Может сработать для вас.