|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
11.11.2008, 17:36:05
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
есть 2 таблицы, связанные между собой связью 1-ко-многим (1-ко-М) Т1_Менеджер - даные про менеджеров, делающие закупки товаров. Менеджеры распределены по районам. Т2_Товар - данные о товарах связь Т1_Менеджер 1-ко-М Т2_товар теперь нужно зделать авторизацию. я сначала добавил Т3_Авторизация (логин, пароль, ФИО менеджера). связь получилась T3 1-к-1 Т1 1-ко-М Т2, тк в своём районе только 1 менеджер, другой не может.. идёт привязка района к паролю и логину: при вводе пароля и логина появляются данные этого менеджера, которому присвоен пароль и логин. тк связь 1-к-1 есть, я поля из Т3 (логин, пароль, ФИО) перенёс в Т1. получилось 2 таблицы Т1_Менеджер 1-ко-М Т2_Товар. правильно ли я сделал ?? если нет, как сделать правильно?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.11.2008, 18:19:02
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
Коллега, Не забывайте что аффторизация стоИт обособлено. Она работает как бы сверху. Вы не можете гарантировать жёсткость связей потому как они не безусловны. Смотрите - зачем Вам фамилия менеджера если авторизация не удовлетворена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.11.2008, 18:22:55
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
В большинстве приложений Баз Данных авторизация это доступ к группе объектов базы а не к собственно данным. С бизнес точки зрения - не менеджер управляет доступом, а администратор. На менеджера тоже должен быть наложен контроль ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.11.2008, 18:27:43
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
seeerg_23 пишет: > связь Т1_Менеджер 1-ко-М Т2_товар Сомневаюсь, что два менеджера не могут продавать один и тот же товар (или покупать, что там у вас). Так что должно быть N:M. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 10:32:05
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
Mr MarmeladВ большинстве приложений Баз Данных авторизация это доступ к группе объектов базы а не к собственно данным. С бизнес точки зрения - не менеджер управляет доступом, а администратор. На менеджера тоже должен быть наложен контроль а если менеджер и является администратором.....?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 10:34:47
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
MasterZiv seeerg_23 пишет: > связь Т1_Менеджер 1-ко-М Т2_товар Сомневаюсь, что два менеджера не могут продавать один и тот же товар (или покупать, что там у вас). Так что должно быть N:M. один и тот же товар могут заказывать, продавать. но не могут в чужих районах. каждый район закреплён за менеджером (или наоборот). поэтому у меня и была связь 1-к-1: 1 менеджер, 1 район, 1 пароль и логин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 10:38:12
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
seeerg_23 пишет: один и тот же товар могут заказывать, продавать. но не могут в чужих > районах. каждый район закреплён за менеджером (или наоборот). поэтому у > меня и была связь 1-к-1: 1 менеджер, 1 район, 1 пароль и логин. А если он заболеет ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 10:38:38
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
выскажите свои мнения, скажите как правильно??? и что неправильно у меня??? кто и как бы сделал, только поподробнее, плз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 17:05:14
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
Коллега ещё раз повторюсь - авторизацию рекоммендуется не мешать с бизнес логикой. Она стоит обособлено. Функционально это зажигание. Вам же всё равно на каком топливе ездит Ваш авто. А может и вообще это троллейбус. А вот ключ зажигания есть у всех. А посему - все логины, пассворды, имена лиц допущенных к ведению той или иной активности НЕ МОГУТ быть смешаны с закупками. Один менеджер может ( а порой и не должен знать ) что делает другой. А то что у одного (или более) есть привелегии видеть всё... Ну и что. У одного да - и он = Админ. У другого нет - и он <> Админ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 17:19:30
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
Кстати а доступ к данным по мере авторизации обеспечивается в SQL командами GRANT и REVOKE / DENY. Уж не знаю какой БД Вы занимаетесь но во всех мало мальски коммерческих приложениях этот вопрос более менее решён. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 17:25:01
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
Mr MarmeladКоллега ещё раз повторюсь - авторизацию рекоммендуется не мешать с бизнес логикой. Она стоит обособлено. Функционально это зажигание. Вам же всё равно на каком топливе ездит Ваш авто. А может и вообще это троллейбус. А вот ключ зажигания есть у всех. А посему - все логины, пассворды, имена лиц допущенных к ведению той или иной активности НЕ МОГУТ быть смешаны с закупками. Один менеджер может ( а порой и не должен знать ) что делает другой. А то что у одного (или более) есть привелегии видеть всё... Ну и что. У одного да - и он = Админ. У другого нет - и он <> Админ. вот именно, что не должен он знать, что делает другой менеджер, для этого у меня в запросе район прикреплён к паролю и логину. те при авторизации, менеджер видит данные ТОЛЬКО своего района!!! where (((login=@login) and (parol=@parol) and (rayon='Кукуевский')) or ((login=@login) and (parol=@parol) and (rayon='Жужуевский'))) если не в этой таблице хранить данные авторизации, тогда где?? и какая связь дожна быть?? либо как это ещё организовать?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 17:29:09
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
Подождите Коллега, Вы действительно каждый раз будете спрашивать и логин и пароль или где это Вы планируете их хранить на время работы ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 17:33:14
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
Я не всевидящий и не представляю Вашу систему. Но наверное в ней есть какой то интерфейс, логично? И авторизация уже где то случилась - на подходе к месту логики. По вашему получается что Вы всегда ключаете зажигание и глушите мотор на каждом светофоре? Хммм. неинтересное решение Коллега. Надо что то менять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 17:40:01
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
Обычно решение авторизации стоИт на самом входе - доступе в систему. юзер получает авторизацию и попадает только в те уголочки систему к которым у него есть доступ. GRANT имеет следующую структуру Для какой то группы сформированных менеджеров Вы можете разрешить SELECT, кому-то разрешить UPDATE, и уж очень ограниченному количеству лиц разрешить DELETE. Это нормальная практика. Но она не решается на уровне запроса - уж поверьте мне, старику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 18:15:48
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
Ну вот я собрал малюсенькую авторизационную структурку для Вас, коллега. Просто чтоб помочь Вам в понимании. Смотрите у авторизации три таблички - users, rights, user_rights. Все Ваши юзеры будут членами таблички users со своими титулами менеджеров или продавцов - или что там у Вас ещё. Они - в этом самом первом приближении - не буду за Вас делать всю работу - будут иметь ещё и роли, ну скажем 'admin', 'grantor', 'enduser' . Теперь посмотрите на табличку rights. Там мы внесём значение Ваших гипотетических запросов - я не буду зашифровывать слишком - просто для удобства: 1. Смотреть все регионы 2. Заносить все регионы 3. Удалять все регионы 4. Смотреть продажи Кукуево 5. Вносить продажи Кукуево 6. Удалять продажи Кукуево 7. Смотреть продажи Жужуево 8. Вносить продажи Жужуево 9. Удалять продажи Жужуево Ну а теперь в табличке user_rights мы замэпаем юзера Joe Dump - продавец - enduser = 8 (вносить продажи Жужуево); или Абракадабра - менеджер - grantor = 2 (Заносит все регионы) ну и так далее... Конечно это не единственное и не всегда правильное решение - но Вам оно может быть полезным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 18:19:12
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
да, авторизация проходит на стр1. в приложении есть подключени к бд, к Таблице1, в которой находится вся информация о товаре, менеджере, авторизации (да, это всё в одной таблице, тк если разбить эти данные на несколько, связи будут между ними 1-к-1). Доступ у него полный (редактирование, обновление, удаление) , но ТОЛЬКО в своём районе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.11.2008, 19:12:05
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
авторв приложении есть подключени к бд, к Таблице1, в которой находится вся информация о товаре, менеджере, авторизации (да, это всё в одной таблице, тк если разбить эти данные на несколько, связи будут между ними 1-к-1 ). Смотрите - у вас опять зажигание заливается в бензобак. Что с того что связи будут 1-к-1? Вам надо сначала обеспечить вход а потом красить стены. пусть даже они будут покрашены в один цвет. Или я не разумно выражаю свои мысли, Коллега? Вы понимаете или нет о чём я? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.11.2008, 09:04:49
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
в моей таблице Т1_Менеджеры хранятся и данные об авторизации. те мне нужно сделать ещё 2 таблицы: одна для авторизации, вторая - промежуточная, так ??? Т_Авториз 1-к-М Т_Промеж 1-к-М Т_Менеджеры???? объясните, ПОЧЕМУ данные об авторизации не могут храниться в Т_Менеджеры?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.11.2008, 10:58:40
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
seeerg_23в моей таблице Т1_Менеджеры хранятся и данные об авторизации. те мне нужно сделать ещё 2 таблицы: одна для авторизации, вторая - промежуточная, так ??? Т_Авториз 1-к-М Т_Промеж 1-к-М Т_Менеджеры???? объясните, ПОЧЕМУ данные об авторизации не могут храниться в Т_Менеджеры?? 1. Данные об авторизации могут храниться в таблице "Менеджеры". Они, также, могут храниться и в отдельной таблице - применяют оба этих подхода. Кстати, связь между этими двумя таблицам (Менеджеры и Авторизация) не 1:1, а 1:1-0. Т.е. менеджер может существовать, а записи в таблице авторизации может не быть. Например, это имеет смысл если менеджер уволился, а историю по его операциям хранить надо. 2. Когда 100% имеет смысл разделять таблицы Менеджер и Авторизация - это если у вас менеджеры хранятся в общей таблице "Люди" (ФИО поставщиков, прочих сотрудников, ФИО клиентов-физ лиц). Тогда для большого списка людей (несколько тысяч) информация об авторизации будет лишней и ее имеет смысл вынести в отдельную. 3. В этом запросе: where (((login=@login) and (parol=@parol) and (rayon='Кукуевский')) or ((login=@login) and (parol=@parol) and (rayon='Жужуевский'))) можно использовать IN Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.11.2008, 17:12:17
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
Можно вообще ВСЁ хранить в одной таблице. Но это не особенно практикуется. Коллега я не знаю ни Вашего бизнеса ни Вашей системы Не знаю даже БД на которой у Вас решение сделано. Если это не СУБД - в общепринятом понимании - тогда конечно. Смотрите моё первое предложение. А почему не практикуется и почему не логично - потому что Ваша модель предполагает постоянную поддержку авторизации. параметры @login и @parol должны (по вашей модели) постоянно или храниться где то рядом - у клиента (что само по себе нарушение условий безопасности) или постоянно вноситься в каждый модуль обращения. Я извините НЕ ВЕРЮ что у Вас в системе ничего КРОМЕ этих двух таблиц. Уж простите моё стариковское предположение. Значит - логичным и практикующим методом будет - взять ключ, открыть дверь (внести @login и @parol) попасть КУДА НАДО (Кукуево или Жужуево) закрыть за собой дверь и работать себе там не вызывая претензий у администратора. Моё сугубо мнение - если Вам так неинтересно - смотрите Предложение 1 или совет Ув Коллеги Baly. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.11.2008, 18:17:54
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
Mr MarmeladМоё сугубо мнение - если Вам так неинтересно - смотрите Предложение 1 или совет Ув Коллеги Baly.Да вы так не горячитесь, спокойне... спокойне... Как вы отмечали ранее (в другом посте) - Правд их может быть несколько. То что описываете вы - это один из вариантов хранения структуры безопасности. Он довольно гибок, хотя и не всеобъемлющь. То о чем говорил я - о том что, логин, пароль и DISPLAY_NAME можно хранить в одной таблице - так не только я так считаю. В большинстве OS именно так и хранится информация о пользователях. Unix /etc/passwd, MS Acitve Directory - там структура везде плоская и нужды ее разделять - особо нет. Что касается "как именно стыкуется таблица товара с менеджерами" - тут, боюсь, автору придется много попотеть чтобы сделать ее, всетаки, по человечески. Но к структуре авторизации - это не относится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.11.2008, 10:34:43
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
СУБД SqlServer2005. Есть у меня помимо 2х таблиц ещё 1 ХП. ЗАписей будет в Т1_Менеджер много: каждый день производится заказ товара, возврат и тд. за год может накопится несколько тысяч записей, может больше. Менеджеров не много, несколько десятков. Связь 1:0 не может быть, тк если менеджер уволился, вместо него другой будет. Все данные "перейдут", присвоятся новому менеджеру. Так стоит мне отдельно заводить таблицу для авторизации??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.11.2008, 15:04:59
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
BelyДанные об авторизации могут храниться в таблице "Менеджеры" Категорически не согласен. Контроль доступа всегда имеет смысл делать обособленно от данных. Функциональный администратор может обладать ограниченными правами, а именно, только на администрирование прав доступа, и не должен иметь доступ к самим данным. Это общая концепция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.11.2008, 15:52:09
|
|||
|---|---|---|---|
|
|||
не понятно с количеством таблиц |
|||
|
#18+
seeerg_23, автор 1. Смотреть все регионы 2. Заносить все регионы 3. Удалять все регионы 4. Смотреть продажи Кукуево 5. Вносить продажи Кукуево 6. Удалять продажи Кукуево 7. Смотреть продажи Жужуево 8. Вносить продажи Жужуево 9. Удалять продажи Жужуево Смотреть, Заносить, Удалять - это функции программы все регионы, Кукуево, Жужуево - это объекты или группы объектов права раздаются ролям (т.е. группам пользователей) на функции (группы функций) и на объекты (группы объектов). В итоге д.б. одна таблица доступа типа юзер-объект/функция-тип доступа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.11.2008, 16:22:59
|
|||
|---|---|---|---|
не понятно с количеством таблиц |
|||
|
#18+
Сергей ВаскецовBelyДанные об авторизации могут храниться в таблице "Менеджеры" Категорически не согласен. Контроль доступа всегда имеет смысл делать обособленно от данных. Функциональный администратор может обладать ограниченными правами, а именно, только на администрирование прав доступа, и не должен иметь доступ к самим данным. Это общая концепция.А вы переименуйте таблицу "Менеджеры" в "Пользователи" и будет вам счастье. Просто я называю таблицы так, как это делал автор. А что касается реквизитов человека, то заводить отдельную таблицу где будет только ФИО одним полем (к примеру) - считаю нецелесообразным. Как именно дела обстоят у автора - надо спрашивать у него. Я написал "применяют оба этих подхода". Или вы с этим не согласны, что два подхода применяют? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1543559]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
177ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 466ms |
| 0 / 0 |
