Mamay Цитата: он бесплатный только для разработки !!! не для разработки его использовать нельзя !!!
Зачем столько восклицательных знаков ?
MSDE можно бесплатно использовать не только для разработки. Сомневающимся сюда
http://www.microsoft.com/sql/howtobuy/msdeuse.asp.
Цитата: И последнне - такие системы практически изжили себя. Тобишь - сейчас они неактуальны!
Онлайн предоставляет больше возможностей, чем офф-лайн, кто ж с этим спорит? У
RWSergey есть вполне конкретная задача, в которой обеспечить постоянный онлайн сложно (либо вообще невозможно). Может ему нужно организовать удаленный офис в деревне Гадюкино? Возможности для онлайна нет, так что, отказаться от проекта?
RWSergey Ситуация уточняется. Двигаемся дальше.
Для офф-лайна тебе в удаленном офисе нужна локальная БД. Что в ней будет - пока не принципиально. Но она точно нужна. Так что можеш начинать выбирать. MSDE (он таки бесплатен), Interbase, ... Вариантов много, так что подобрать подходящее решение, думаю, удастся.
Пункт 1. Дальше нужно определиться, кто, как и по какому расписанию будет выполнять синхронизацию с центром. Варианты:
1. система, автоматически по расписанию или наступлению заданного события (набрано ХХХ данных)
2. администратор, на основании утвержденных процедур и правил
3. пользователь с соответствующими правами, на основании утвержденных процедур и правил
Пункт 2. Кроме синхронизации необходимо решить, требуется ли пользователям поиск по ВСЕМ данным (центральная БД) или только по СВОИМ+СПРАВОЧНИКИ? Если нужен поиск по центральной БД, то как они будут соединяться с ней?
Пункт 3. Пока вырисовывается следующие два варианта (делай поправку на символьную графику
, вид от удаленного клиента:
Клиент --->
...Локальный сервер бизнес-логики --->
......{локальная БД,
......центральный сервер бизнес-логики ---> центральная БД}
Клиент --->
...{Локальный сервер бизнес-логики ---> локальная БД},
...{Центральный сервер бизнес-логики ---> центральная БД}
В первом варианте детали связи с центром скрыты от клиента; клиента делать будет проще, локальный сервер бизнес-логики сложнее. Во втором - наоборот. С точки зрения архитектуры - первый вариант существенно лучше. Выбор - по обстоятельствам, с учетом ресурсов, знаний, возможностей применяемых инструментов.
О системе безопасности С большой степенью вероятности тебе подойдет смешанная модель безопасности: ролевая (контроль функций) + упрощенная дискретная (контроль доступа к данным).
Ролевая составляющая ответственна за решения "может ли пользователь роли Х выполнить операцию Y", упрощенная дискретная "если пользователь из роли Х может выполнить операцию Y, то может ли он выполнить ее над данными Z".
Это пока общая схема.
Пункт 4. При реализации СБ нужно определиться с технологиями:
- использовать системные возможности (>= MS WIN 2K PRO + MS WIN 2K SRV DC, или что-то другое с похожими возможностями) + свои отдельные модули
- написать полностью свою прикладную систему безопасности с хранением данных в БД
В любом случае часть СБ тебе придется делать самому (как минимум контроль доступа к "строкам" таблиц).
Если есть желание использовать по максимуму системные возможности, то для ролевого контроля на серверах бизнес-логики (middleware) можно использовать >=WIN 2K + COM+ rolebase security или .NET rolebase security. Учетные записи при этом будут храниться в Active Directory (решение имеет свои радости и печали
)
О других платформах ничего сказать не могу, хотя и там, навервное, есть аналоги.
При полностью своей разработке все данные СБ будут храниться в локальной БД и, при необходимости, синхронизироваться с центром.
После того, как ты определишся с выбором по пунктах 1-4, можно будет двигаться дальше.
об офф-лайне интересуюсь, была бы возможность в он-лайне связываться так бы и делал.