Therapyx
@Therapyx
Data Science

Какая должна быть структура SQL запросов, учитывая текущего пользователя?

Имеется приложение на asp.net webforms с всякими GridView, DetailsView таблицами, соединенные с MSSQL базой. Появилась потребность в нескольких пользователях, и чтобы каждый пользователь видел только свои данные в этих таблицах. Я примерно представляю как это делается, но хотелось бы услышать замечания, вдруг я что-то себе не то выдумал :)
1) Создать таблицу юзеров.
2) Добавить в основую таблицу(к каждой записи) UserID как foreign key
3) Изменить запрос "Select * from 'table'" на "Select * from 'table' where UserID = @UserID" Послего чего параметр @UserID с# брать из CurrentSession, которая держит в себе этот айди после логина на сайт. И соответственно остальные процедуры переделать точно также на апдейты, делиты итд :)

В правильном направлении я мыслю? Или все же есть более лучше(правильные) варианты?
  • Вопрос задан
  • 342 просмотра
Пригласить эксперта
Ответы на вопрос 4
index0h
@index0h
PHP, Golang. https://github.com/index0h
Мыслишь в правильном направлении. Но для начала рекомендую почитать по больше про реляционные БД и принципы построения таблиц/запросов.
Ответ написан
Nipheris
@Nipheris Куратор тега C#
Направление мыслей верное, с технической точки зрения тоже. Не уверен насчет необходимости обновления апдейтов и делитов - если вы уже проверили UserId и выяснили, что запись принадлежит конкретному пользователю, и получили ее Id - то и удалять уже достаточно только по Id (за исключением, конечно, случая, когда вам нужно удалить ВСЕ записи конкретного пользователя).
Правильность этого варианта зависит от вашей задачи. Если вам достаточно знать пользователя-владельца - то все хорошо, но если вы потом захотите более сложную систему доступа к записям - например давать и другим пользователям доступ к записям пользователя A, то и схема базы также усложнится.
Ответ написан
@Demonikaliysis
Начинающий разработчик
Направление верное.
Часто БД разрастаются, продумайте досконально работу с ID начните с типа хранимых данных и полным способом обращения к объекту в БД через вложенный запрос...
Не думаю что нужно упоминать различия в символьных типах char, varchar, text...и преимуществами varchar такими как хранимость определённой существующей длины и переносимость на иные СУБД...
Но можете и не задумываться об этом а когда придёт время и БД будет на 50к+ записей, кому-то будет не очень приятно работать с ней и не факт что это будите не вы.

В общем вы меня поняли :)
Ответ написан
Valeriy1991
@Valeriy1991
Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
Добрый день! Возможно, имеет смысл взять MembershipAPI из коробки и особо не париться с моделью пользователей? А мыслите, в принципе, в правильном направлении. Поддержу Станислав Макаров - если вы делаете update и delete по id записи, то и переписывать все эти запросы не надо. Возможно, использование ORM Вам упростит жизнь.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы