 |
|
Модераторы: LSD |
 
|
|
Органайзер, Хранение данных различных пользователей 
| BoomeR |
|
|||
 Шустрый  Профиль Группа: Участник Сообщений: 79 Регистрация: 24.12.2006 Где: Санкт-Петербург Репутация: нет Всего: нет |
Добрый день!
В данный момент занят разработкой приложения выполняющего функции, схожие с MS Outlook, исключая почтовик. Нахожусь на стадии проектирования структуры БД. Как я себе это вижу, структура получается простенькая и нечего тут городить огород и подключать различные методы проектирования (кроме "умо-зрительного"  ).Сущности определяю так : встречи/события(строго привязанные ко времени), контакты, заметки, задачи. Атрибуты пока в процессе, но думаю с ними более-менее и так ясно. Вопросы возникают дальше : к БД будут удалённо обращаться некоторое (<100) количество пользователей, у каждого должна быть своя учётная запись и, соответственно, данные. 1) Никогда не доводилось заниматься безопасностью БД - как лучше хранить пары логин/пароль? Завести под них таблицу и набросать функцию аутентификации? Или есть лучшие решения? 2) Как лучше разграничить данные пользователей? Я вижу два решения (второе, на мой взгляд, откровенно плохое) : добавить в каждую таблицу по атрибуту "логин" и таким образом делать выборки по данным или плодить по 4 таблицы на каждого юзера. Думаю вопросы несложные  Особо не пинайте, просто совсем пока новичок в разработке БД. |
|||
|
||||
Загрузка ...
| LSD |
|
||||||
 Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15719 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Зависит от того, где ты хочешь проверять права доступа. Если у тебя 3-х звенное приложение, то безопасность можно возложить на сервер приложений. Если 2=х звенка, то тогда надо все реализовывать на уровне БД.
Не логин, а ID пользователя. И можно не в каждую а только в независимые сущности. Например есть сущность заметка и есть сущность атачмент-к-заментке, которая всегда относится к какой либо заметке и не существует сама по себе. В сущность заметка надо добавить ID пользователя, а вот в атачмент-к-заментке нет. Т.к. атачмент-к-заментке всегда будет относится к тому же пользователю что и родительская заметка.
Очнь зря. Возьми какую нибудь утилиту для визуального проектирования БД, работать станет намного легче. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
||||||
|
|||||||
| BoomeR |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 79 Регистрация: 24.12.2006 Где: Санкт-Петербург Репутация: нет Всего: нет |
LSD, спасибо. Многое прояснилось
 Ушёл читать мат. часть  |
|||
|
||||
| BoomeR |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 79 Регистрация: 24.12.2006 Где: Санкт-Петербург Репутация: нет Всего: нет |
Привет!
Поковырял я за последнее время некоторую теорию проектирования БД. Кое-что применил. Вспомнил UML - набросал use case diagram и физическую модель, которую получил в результате алгоритма синтеза. Структура получилась странноватая :  Все таблицы, кроме UID_Note_Task_Event, я так себе и представлял, но вот эта табличка меня смущает... Без неё не выполняется свойство соединения без потерь, получается убить её нельзя. Но кто её будет заполнять? Она сама по себе содержит очень невнятный набор информации... Её поля : ID юзера, даты создания неких заметок, встреч, задач и ID некого контакта - вся это информация связанна лишь косвенно через ID юзера... А держать путсую таблицу - не серьёзно Подскажите куда копать? Или я ошибаюсь в основах? |
|||
|
||||
| LSD |
|
|||
|
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15719 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Я честно говоря вообще не понимаю, что за данные содержит UID_Note_Task_Event.
-------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
| BoomeR |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 79 Регистрация: 24.12.2006 Где: Санкт-Петербург Репутация: нет Всего: нет |
LSD, вот-вот. Сегодня ездил говорить с научником по этому вопросу : решено было просто удалить эту таблицу, т.к. она не содержит никакой вменяемой информации, ну а свойством соединения без потерь в этом случае можно пренебречь. Не самое лучшее решение, но для данной структуры другого подхода не видно... Спасибо, за участие
ПС. Аутентификацию пользователя было решено делать на серверной стороне, логин передаётся в открытом виде, а пароль в хэшированном, в таблице с данными пользователя хранятся хэши паролей. |
|||
|
||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0470 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |