Схема, Владелец для объектов в SQL MS
Некоторое понимание, сумма и магия молнии:
>>> i = [[[1, 2, 3], [4, 5, 6]], [[1, 2, 3], [7, 8, 9]], [[1, 2, 3], [10, 11, 12]]]
>>> q = [x[1] for x in i]
>>> [sum(i) for i in zip(*q)]
[21, 24, 27]
Чтобы получить среднее значение, разделите на длину:
>>> [sum(i)/len(i) for i in zip(*q)]
[7.0, 8.0, 9.0]
5 ответов
Использование схем исключительно выгодно, когда у Вас есть проблемы безопасности.
, Если у Вас есть несколько приложений, которые получают доступ к базе данных, Вы не могли бы хотеть предоставлять доступ отдела Логистики к записям Человеческих ресурсов. Таким образом, Вы помещаете все свои таблицы Human Resources в схему часа и только предоставляете доступ к нему для пользователей в роли часа.
Шесть месяцев в будущем, Логистика теперь должна знать внутренние представительские расходы, таким образом, они могут отправить все эти палитры синих перьев корректным людям местоположения. Можно затем создать хранимую процедуру, которая выполняется как пользователь, который имеет разрешение просмотреть схему часа, а также схему логистики. Пользователи Логистики никогда не должны знать то, что продолжается в HR, и все же они все еще получают свои данные.
можно также использовать схемы, путь cfeduke предложил и просто использует их для вещей группы в обозревателе объектов. Если Вы делаете это, просто осторожны, потому что Вы могли бы закончить тем, что создали Человека. Адрес и Компания. Адрес, когда Вам действительно просто нужен единственный dbo. Адрес (я не пробиваю Ваш пример, cfeduke, просто с помощью него, чтобы проиллюстрировать, что обе таблицы адресов могли бы быть тем же, или они могли бы отличаться и что YMMV).
В SQL 2000 Схемы, где эквивалентный пользователям базы данных, в SQL 2005 каждая схема является отличным пространством имен, которое существует независимо от пользователя базы данных, который создал его.
я использую схемы, когда я должен сделать функции или модули, которые будут, возможно, использоваться позже в других проектах, таким образом, я смогу изолировать объекты базы данных, которые используются модулем.
Я использовал схемы в прошлом виде подобных пространств имен, таким образом, у Вас могло быть несколько объектов под названием Адрес ([Person].[Address], [Company].[Address]). Преимуществом для этого является визуальная организация в Studio управления SQL, можно получить то же самое путем подвергания всего одной схеме и именования таблиц с единственным идентификатором (т.е. [dbo].[PersonAddress]).
я также использовал их для разработчика по сравнению с разработкой разработчика до выполнения SQL Server Developer Edition на всех наших dev машинах (назад, когда у нас была централизованная база данных разработки ранее в моей карьере).
Организация
В dev среде, производственная копия объектов является dbo, но разработчики могут разработать в их собственных схемах. Затем код может сослаться на копию напоминания или их изменения очень просто. Используя псевдонимы может сделать эту технику еще более простой.
<час>кроме того, производственная база данных могла бы поддерживать многочисленные системы или подсистемы. Можно использовать отличные схемы для хранения тех объектов сгруппированными.
Эта статья объясняет это хорошо, включая изменения от SQL Server 2000 до 2005.