Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
Даю юзеру права на вьюху. Только SELECT. Права на таблицы тоже нужны?
9 ноя 13, 17:51    [15102758]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
aleks2
Guest
Нет.
9 ноя 13, 18:14    [15102826]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
aleks2
Нет.
Я тоже так думал. Однако, неисповедимы пути Господни. Неиллюзорное ощущение, что всё было хорошо, пока вьюха и таблицы в одной схеме были. Стоило добавить таблицу из другой схемы, как что-то пошло не так.
9 ноя 13, 18:22    [15102847]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
aleks2
Guest
Dmitry V. Liseev
aleks2
Нет.
Я тоже так думал. Однако, неисповедимы пути Господни. Неиллюзорное ощущение, что всё было хорошо, пока вьюха и таблицы в одной схеме были. Стоило добавить таблицу из другой схемы, как что-то пошло не так.

Извиняй, это документировано.

Сразу надо предупреждать.
9 ноя 13, 18:24    [15102851]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
Сходу в буках инфы не нашёл. Пришлось накостылячить в проекте.
9 ноя 13, 18:25    [15102853]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
aleks2
Dmitry V. Liseev
пропущено...
Я тоже так думал. Однако, неисповедимы пути Господни. Неиллюзорное ощущение, что всё было хорошо, пока вьюха и таблицы в одной схеме были. Стоило добавить таблицу из другой схемы, как что-то пошло не так.

Извиняй, это документировано.

Сразу надо предупреждать.
Какие есть теперь варианты, кроме того, чтобы давать права также и на всю таблицу?
9 ноя 13, 18:34    [15102868]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
aleks2
Guest
1. процедура c with execute as.
2. экранировка таблицы другой схемы вьюхой этой схемы.
3. хрен его знает.
9 ноя 13, 18:38    [15102877]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
aleks2
1. процедура c with execute as.
2. экранировка таблицы другой схемы вьюхой этой схемы.
3. хрен его знает.
Спасибо, я так и предполагал. SCRUM методология, мать её. Технология порождения инвалидов на костылях.
9 ноя 13, 19:29    [15102995]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
invm
Member

Откуда: Москва
Сообщений: 9845
Dmitry V. Liseev
Стоило добавить таблицу из другой схемы, как что-то пошло не так.
У схем должен быть один и тот же владелец.
9 ноя 13, 19:33    [15103002]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
invm
Dmitry V. Liseev
Стоило добавить таблицу из другой схемы, как что-то пошло не так.
У схем должен быть один и тот же владелец.
Что-то боязно теперь менять владельца у схемы dbo. Как бы ещё чего не посыпалось.
9 ноя 13, 19:46    [15103039]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
invm
Member

Откуда: Москва
Сообщений: 9845
Dmitry V. Liseev
Что-то боязно теперь менять владельца у схемы dbo
Владельца схемы dbo изменить нельзя. А вот сделать dbo владельцем ваших собственных схем вполне можно.
9 ноя 13, 20:23    [15103148]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
invm
Dmitry V. Liseev
Что-то боязно теперь менять владельца у схемы dbo
Владельца схемы dbo изменить нельзя. А вот сделать dbo владельцем ваших собственных схем вполне можно.
Вот как раз это и боязно. Систему никто не проектировал. Схемы и таблицы создавались от балды. Ибо скрам. Теперь огребаю.
9 ноя 13, 20:35    [15103191]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Dmitry V. Liseev
Схемы и таблицы создавались от балды. Ибо скрам.
Сочувстую. И я с этого тоже фигею. Называть что-то тем что не является. Но мода - она для стада, априори.
Планировки они такие же части в скрами как и всё остальное и тоже делится и тоже можно многое заранее определить не зная окончательной картины.

Dmitry V. Liseev
Вот как раз это и боязно.
Это как раз решение то что вы и просите - дать права на конкретные объекты системы и не имея никаких последствий. А вот вынужденно раздавая права на таблицы - вот этого и стоит боятся, явно делая лазейки.

Разные владельцы схем нужно когда системы независимы. И делается цепочка владений, а не раздача первоначальному пользователю на все схемы. Т.е. вы должны давать права схеме dbo на другие схемы.
Т.е. у пользователя останется право только на вьюху.
10 ноя 13, 03:19    [15104137]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
В скраме планирование делается только на один спринт. Отсутствует стадия сбора требований и проектирования системы.
10 ноя 13, 10:00    [15104199]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31993
Dmitry V. Liseev
invm
пропущено...
Владельца схемы dbo изменить нельзя. А вот сделать dbo владельцем ваших собственных схем вполне можно.
Вот как раз это и боязно. Систему никто не проектировал. Схемы и таблицы создавались от балды. Ибо скрам. Теперь огребаю.
Ну при чём тут "скрам"? Чайник в сиквеле спроектировал систему на основе ошибочных предположений о работе MSSQL. Так можно накосячить и при выделенных полгода на проектирование базы.
Зато потери от ошибки будут небольшие. Без скрама было бы затрачено несколько человеко-лет на программирование, основанное на неправильном проекте, а тут ррраз - и не работает. Потеря всего лишь нескольких человеко-недель.
А проектировать базу нужно специалисту по базе, независимо от методологии управления проектом.
10 ноя 13, 12:29    [15104372]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
alexeyvg
Dmitry V. Liseev
пропущено...
Вот как раз это и боязно. Систему никто не проектировал. Схемы и таблицы создавались от балды. Ибо скрам. Теперь огребаю.
Ну при чём тут "скрам"? Чайник в сиквеле спроектировал систему на основе ошибочных предположений о работе MSSQL. Так можно накосячить и при выделенных полгода на проектирование базы.
Зато потери от ошибки будут небольшие. Без скрама было бы затрачено несколько человеко-лет на программирование, основанное на неправильном проекте, а тут ррраз - и не работает. Потеря всего лишь нескольких человеко-недель.
А проектировать базу нужно специалисту по базе, независимо от методологии управления проектом.
Я же сказал, база не проектировалась. Вообще. Нет никакого проекта. Это и есть скрам. Специалист по базе не нужен в этом случае. Достаточно чайника.
10 ноя 13, 16:03    [15104831]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Dmitry V. Liseev
Нет никакого проекта. Это и есть скрам. Специалист по базе не нужен в этом случае. Достаточно чайника.
Угу, и называется он "Скрам Лисеева".
Думаю автор скрума, услышав это сделал бы себе сеппуку.
10 ноя 13, 17:15    [15104989]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31993
Mnior
Dmitry V. Liseev
Нет никакого проекта. Это и есть скрам. Специалист по базе не нужен в этом случае. Достаточно чайника.
Угу, и называется он "Скрам Лисеева".
Думаю автор скрума, услышав это сделал бы себе сеппуку.
Ага, хорошее название :-)

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

Прямо представляю, как в учебниках по скраму написано - базу должен проектирвоать специалист по дизайну, дизайн сайтов - программист CUDA, а веб страницы программирует только специалист по MSSQL :-)

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

Я понимаю, в скрам-проекте может быть проект базы неполный, фрагментированный, не на все случаи, а только для выполнения функциональности текущего спринта - это может быть.
Но если проектировщик, например, спроектировал логику в MSSQL на функциях с учётом того, что внутри функций будут обновляться таблицы - то при чём тут скрам? Просто чайник делал, руководителя всего этого безобразия нужно выгнать, а не валить всё "на скрам".
10 ноя 13, 19:03    [15105231]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
alexeyvg, тонко
10 ноя 13, 19:30    [15105334]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
alexeyvg
Mnior
пропущено...
Угу, и называется он "Скрам Лисеева".
Думаю автор скрума, услышав это сделал бы себе сеппуку.
Ага, хорошее название :-)

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

Прямо представляю, как в учебниках по скраму написано - базу должен проектирвоать специалист по дизайну, дизайн сайтов - программист CUDA, а веб страницы программирует только специалист по MSSQL :-)

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

Я понимаю, в скрам-проекте может быть проект базы неполный, фрагментированный, не на все случаи, а только для выполнения функциональности текущего спринта - это может быть.
Но если проектировщик, например, спроектировал логику в MSSQL на функциях с учётом того, что внутри функций будут обновляться таблицы - то при чём тут скрам? Просто чайник делал, руководителя всего этого безобразия нужно выгнать, а не валить всё "на скрам".
Ну так если в первых спринтах разграничения доступа к системе и вьюшек вообще не предполагается, то как надо было проектировать систему? Научите всех, а я послушаю.
10 ноя 13, 20:46    [15105485]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5489
И кстати, в первых спринтах внутри функций таблицы также не требовалось обновлять. А потом вдруг потребовалось. Беда?
10 ноя 13, 22:46    [15105803]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31993
Dmitry V. Liseev
Ну так если в первых спринтах разграничения доступа к системе и вьюшек вообще не предполагается, то как надо было проектировать систему? Научите всех, а я послушаю.
Dmitry V. Liseev
И кстати, в первых спринтах внутри функций таблицы также не требовалось обновлять. А потом вдруг потребовалось. Беда?
Так это издержки методологии, с этим никто не спорит.

Повышение удовлетворенности клиентов конечным результатом за счёт многократного увеличения цены.
Много раз переделываем, но зато клиент полностью контролирует процесс и в итоге получает то, что хочет.

Вы просто неправильно оцениваете это.
Клиент хочет заплатить за "попробовать вот так" - заплатил, получил. Потом говорит - неее, передумал, хочу вот этак, башляю! Заплатил, сделали. В чём проблема?

Ну и к тому же не сходится у вас:
Dmitry V. Liseev
Неиллюзорное ощущение, что всё было хорошо, пока вьюха и таблицы в одной схеме были. Стоило добавить таблицу из другой схемы, как что-то пошло не так.
То есть всё таки проектировали и планировали разграничение прав на основе вьюх, и планировали использование разных схем, но не знали, что так сделать нельзя?
Повторю: заниматься разными частями проекта должны квалифицированные специалисты по соответствующим технологиям, "ибо скрам" (с), как впрочем и при любой другой методологии.

Если вначале "внутри функций таблицы также не требовалось обновлять", то специалист и должен сказать - можно делать на функциях, но обновлять в них данные будет нельзя.

Потом, скрам и подобные методики без долгого процесса проектирования предполагают некое видение вперёд, которое у профессионалов обязательно должно быть, как минимум на основании опыта нескольких предыдущих проектов. А если нету ни одного человека с опытом предыдущих проектов в выбранных технологиях, то это опять же не проблема скрама, а некомпетентность руководителя проекта.
11 ноя 13, 00:50    [15106304]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
К alexeyvg, даже и добавить нечего.

Чем меньше понимание каков будет конечный продукт, тем вероятнее нарушение предположений. На которых может строится эффективность системы, к примеру. Поэтому оптимизация (среднего и нижнего уровня - мясцо) должна быть отложена на позднюю стадию, и/или мирится с тем что придётся переделывать - что вполне нормально.

alexeyvg
То есть всё таки проектировали и планировали разграничение прав на основе вьюх, и планировали использование разных схем, но не знали, что так сделать нельзя?
А тут можно по подробнее? А то я проблемы не вижу.
Или вы о взаимодействии клиента через процедуры(-прокладки)?

Сдаётся мне, alexeyvg, что возможно вы проигнорировали сказанную мной глупость:
Mnior
И делается цепочка владений, а не раздача первоначальному пользователю на все схемы.
Т.е. вы должны давать права схеме dbo на другие схемы. Т.е. у пользователя останется право только на вьюху.
11 ноя 13, 06:18    [15106560]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31993
Mnior
alexeyvg
То есть всё таки проектировали и планировали разграничение прав на основе вьюх, и планировали использование разных схем, но не знали, что так сделать нельзя?
А тут можно по подробнее? А то я проблемы не вижу.
Да, вы правы, я просто не вникал в техническую проблему, не читал продолжение дискуссии, перейдя на новую ветвь про методики разработки :-)

Это собственно подтверждает.
Dmitry V. Liseev
invm
А вот сделать dbo владельцем ваших собственных схем вполне можно.
Вот как раз это и боязно. Систему никто не проектировал. Схемы и таблицы создавались от балды. Ибо скрам. Теперь огребаю.
Вот и нужно спросить у специалиста, можно это делать или нет.
11 ноя 13, 09:20    [15106843]     Ответить | Цитировать Сообщить модератору
 Re: Права на вьюху и на таблицы  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
alexeyvg
Да, вы правы, я просто не вникал в техническую проблему, не читал продолжение дискуссии, перейдя на новую ветвь про методики разработки :-)
А жаль, я уж думал вы мне пинка дадите, и кстати тут как раз по тематике методики разработки.

Я же явно глупость сморизил. Сказал что цепочка владения это A-B, B-C, C-D и таким образом получаем A-D.
Так в скуле не работает, к сожалению:
+ Test
USE tempdb
GO
CREATE USER [Test] FOR LOGIN [test]
CREATE USER [Test1] WITHOUT LOGIN
CREATE USER [Test2] WITHOUT LOGIN
GO
CREATE SCHEMA Test1 AUTHORIZATION Test1 CREATE TABLE Test (ID Int IDENTITY PRIMARY KEY)
GO
CREATE SCHEMA Test2 AUTHORIZATION Test2 CREATE VIEW Test WITH SCHEMABINDING, VIEW_METADATA AS SELECT ID FROM Test1.Test WITH CHECK OPTION
GO
CREATE PROC Test2.spTest WITH EXECUTE AS OWNER AS SELECT ID FROM [Test2].[Test]
GO
GRANT SELECT ON [Test1].[Test]   TO [Test2]
GRANT SELECT ON [Test2].[Test]   TO [Test]
GRANT EXEC   ON [Test2].[spTest] TO [Test]
GO -- Login as test
SELECT * FROM Test2.Test -- The SELECT permission was denied on the object 'Test', database 'tempdb', schema 'Test1'.
SELECT * FROM Test1.Test -- The SELECT permission was denied on the object 'Test', database 'tempdb', schema 'Test1'.
EXEC Test2.spTest -- (0 row(s) affected)
GO
DROP  PROC Test2.spTest; DROP VIEW [Test2].[Test]; DROP TABLE [Test1].[Test];
DROP SCHEMA Test2; DROP SCHEMA Test1; DROP USER Test2; DROP USER Test1; DROP USER Test;
И вопрос, пачему?

Да-да, опять глубокий анализ :) ...
11 ноя 13, 19:00    [15111265]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить