Какая должна быть структура SQL запросов, учитывая текущего пользователя?
Имеется приложение на asp.net webforms с всякими GridView, DetailsView таблицами, соединенные с MSSQL базой. Появилась потребность в нескольких пользователях, и чтобы каждый пользователь видел только свои данные в этих таблицах. Я примерно представляю как это делается, но хотелось бы услышать замечания, вдруг я что-то себе не то выдумал :)
1) Создать таблицу юзеров.
2) Добавить в основую таблицу(к каждой записи) UserID как foreign key
3) Изменить запрос "Select * from 'table'" на "Select * from 'table' where UserID = @UserID" Послего чего параметр @UserID с# брать из CurrentSession, которая держит в себе этот айди после логина на сайт. И соответственно остальные процедуры переделать точно также на апдейты, делиты итд :)
В правильном направлении я мыслю? Или все же есть более лучше(правильные) варианты?
Направление мыслей верное, с технической точки зрения тоже. Не уверен насчет необходимости обновления апдейтов и делитов - если вы уже проверили UserId и выяснили, что запись принадлежит конкретному пользователю, и получили ее Id - то и удалять уже достаточно только по Id (за исключением, конечно, случая, когда вам нужно удалить ВСЕ записи конкретного пользователя).
Правильность этого варианта зависит от вашей задачи. Если вам достаточно знать пользователя-владельца - то все хорошо, но если вы потом захотите более сложную систему доступа к записям - например давать и другим пользователям доступ к записям пользователя A, то и схема базы также усложнится.
"например давать и другим пользователям доступ к записям пользователя A" - Это уже что-то интересненькое, надо будет тоже таким заняться, конечно после основного... Делаю приложение для приватного использования, тренируюсь и пытаюсь воплотить фантазии :)
Therapyx да что тут фантазировать, в большинстве крупных систем это есть, просто не всегда так уж заметно. Возьмите TFS или VS Online - в нем ресурсы (читайте, ваши "записи") - репозитории, баги, билд-конфигурации - распределены про team-проектам. В свою очередь, тим-проекты имеют владельца, плюс вы можете давать доступ другим юзерам с определенными правами. Это те же самые списки контроля доступа (ACL), что и например, на файловой системе (у файла также есть владелец, и те, кто могут с ним что-то делать). Да что уж там, даже в самой СУБД это есть - есть пользователи, группы (суперадмины, админы бэкапа, и т.д.), у них есть права на таблицы, вьюхи, хранимки и прочие объекты БД, плюс также как правило у объекта кто-то назначается текущим владельцем.
Направление верное.
Часто БД разрастаются, продумайте досконально работу с ID начните с типа хранимых данных и полным способом обращения к объекту в БД через вложенный запрос...
Не думаю что нужно упоминать различия в символьных типах char, varchar, text...и преимуществами varchar такими как хранимость определённой существующей длины и переносимость на иные СУБД...
Но можете и не задумываться об этом а когда придёт время и БД будет на 50к+ записей, кому-то будет не очень приятно работать с ней и не факт что это будите не вы.
Молодчина, что сказать. К сожалению не все понимают, что планирование практически всегда решает множество проблем. Про закон подлости слышали или знают на собственном опыте многие, а вот про принцип Паретто как-то через не хочу. Хотя они действуют практически на одном уровне.
Интересны цифры ваших тестов с каким-то хотя бы уточнением от автора.
Дмитрий Карпович: Да это для повседневной жизни и приватного использование делаю приложение. Там все миниатюрно, 1 Таблица где-то столбцов 8 и другая таблица Юзеров = все )) В основном там Date, Varchar70-100, Decimal(18,2), Int
Ну...тогда смотрите сами конечно, что вам нужно. Именно дата со временем вам нужна? Я конечно не знаю что у вас там за данные и для чего, даты обычно хватает за глаза. Varchar 70-100 немножко странновато, обычно не делают половинчатость (берут либо 10-50...либо сразу MAX т.е. 255), может быть вам взять максимальное значение, он ведь программно регулируемый самим сервером. Куда вам сверхточное вещественное? Вы занимаете научными расчётами и вам нужны большие точности в плоть до приведённых вами значений точности и масштаба значений?
Дмитрий Карпович: нееет :) Просто так прикинул... 1 Поле для листайтемов дроп даун листа, другая с дополнением к нему. Не думаю что 10-50 хватит, но и 255 точно не надо...)
Therapyx: Вот вы и сами ответили на "поставленный" вами вопрос. Старайтесь с самого начала придерживаться некоторого "code conventshion" и будет вам счастье =D
Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
Добрый день! Возможно, имеет смысл взять MembershipAPI из коробки и особо не париться с моделью пользователей? А мыслите, в принципе, в правильном направлении. Поддержу Станислав Макаров - если вы делаете update и delete по id записи, то и переписывать все эти запросы не надо. Возможно, использование ORM Вам упростит жизнь.
Простой
Простой
