Это общий вопрос о дизайне базы данных. Каковы преимущества использования синонимов в разработке баз данных на простом представлении? Каковы основные соображения, которые следует учитывать при выборе между ними?
Пример view:
CREATE VIEW Users AS
SELECT * FROM IdentitySystem.dbo.Users
И эквивалентный синоним:
CREATE SYNONYM Users
FOR IdentitySystem.dbo.LCTs
Это разные вещи. Синоним - это псевдоним для объекта напрямую, представление представляет собой конструкцию над одной или несколькими таблицами.
Некоторые причины использования представления:
Может потребоваться отфильтровать, соединить или иным образом перейти к структуре и семантике набора результатов
Возможно, потребуется предоставить устаревшую поддержку базовой структуры, которая изменилась, но имеет зависимости, которые вы не хотите перерабатывать.
Может обеспечить безопасность, когда часть содержимого таблицы должна быть видна классу пользователей, но не всем. Это может включать удаление столбцов с конфиденциальной информацией или фильтрацию подмножества записей.
Желательно инкапсулировать некоторую бизнес-логику в форме, доступной пользователям для целей отчетности.
Возможно, вы захотите объединить данные из нескольких источников.
... Плюс еще много.
Причины использования синонима:
Вы можете захотеть создать псевдоним объекта в другой базе данных, где вы не можете (или не хотите) жестко кодировать ссылку на конкретную базу данных.
Вы можете перенаправить на источник, который изменяется со временем, например, в таблицу архива.
Вы хотите что-то псевдонизировать таким образом, чтобы не влиять на оптимизатор запросов.
... Плюс еще много.
Есть много соображений. Короче говоря, используйте инструмент, который лучше всего подходит для каждой ситуации.
С точки зрения, я могу
С синонимом я могу:
Вероятнее всего, это можно сделать с помощью синонимов. В проектах наших (Oracle database) приложений мы используем схему "владелец" для всех объектов базы данных (таблицы, представления, триггеры и т.д.), И мы предоставляем привилегии этим объектам другому "приложению", пользователи. В каждой из "пользовательских" пользовательских схем мы создаем синонимы для ссылки на объекты "владелец".
НТН
В основном представление представляет собой простой/сложный оператор "select". По сути вы используете представление как маску и показываете только те значения столбцов, которые вам полезны. Вы используете представление с намерением не показывать дополнительную информацию конечному пользователю.
В то время как синоним является альтернативным именем для объектов базы данных.
Я использую синонимы для совместного использования объектов из других баз данных, поэтому, когда я использую .NET Framework Entity Framework, я могу использовать один ObjectContext для доступа ко всем требуемым данным из многих баз данных.
Вывод столбца из представления устанавливается во время создания. Поэтому, если вы добавите столбец в основной вид, он не будет отображаться до тех пор, пока вы не измените представление. Не так с синонимом. Подумайте об этом, как простое имя замените в своем tsql, как правило, чтобы скрыть сложность.
Пожалуйста, поправьте меня, если я ошибаюсь, но я думаю, что я вижу другое использование синонимов (по крайней мере, в Progress OpenEdge), которые я не вижу нигде в документах, что может сделать его еще более безопасным, чем представление. Синтаксис инструкции DML SELECT позволяет использовать таблицу, представление или синоним, но операторы INSERT, UPDATE и DELETE допускают только таблицу или представление. Некоторые представления, если они соответствуют определенным критериям, обеспечивают обновляемый, вставляемый и удаляемый доступ к данным. Синоним кажется хорошим способом предоставления доступа к данным только для чтения, без необходимости связываться с предоставлением (или отрицанием) привилегий в представлениях.
Я надеюсь, что это может помочь кому-то, я взглянул на эту статью, и я нашел причину использования представления вместо синонима.
Когда вы используете сервер Sql как сервер Db и SAS в качестве клиента. Если вы используете синоним, он не будет распознан в вашей библиотеке SAS. Мне нужно было создать представление.
Он не оптимизирован, но по крайней мере Windows sas с Sql-сервером не самый лучший:)