управление доступом к файлам на сервере посредством бд -клиента

← →
Девушка © (2007-12-14 14:56) [0]

Добрый день!
Стоит следующия задача:
организовать хранение и поддержку процессов работы с документами (конструкторская документация, бухгалтерская и т.д.)

В локальной сети есть файл-сервер, где сейчас эти документы лежат просто в папках с определенным уровнем доступа, регулируемым средствами ОС.
На сервере также крутится InterBase 7.0. Под его управленем работает система, в которой хранятся данные о составе изделий, складские данные, данные о движении продукции и продажах.

Если например, конструктора хотят приложить к данным об изделии некий документ, то они выкладывают его на файл-сервер и сохраняют ссылку на него в БД.

Это вариант плох тем, что не гарантирована целостность этих ссылок, т.к. доступ к файлу возможен просто по сети через расшареную папку.

Планируется:
хранить документацию на файл-сервере не в расшареных, а в закрытых папках. Добавлять и открывать файлы можно только через клиент БД.

вот только не знаю с чего начать :) :((((

← →
Andrey © (2007-12-14 15:05) [1]

В принципе можно начать с того что паролить доступ на файлсервер. Тогда и без IB обойтись можно.
Если всётаки хочется чтобы IB был файл-сервером, начать можно с http://ibase.ru/develop.htm раздел "User Defined Functions".

← →
Anatoly Podgoretsky © (2007-12-14 15:08) [2]

> Девушка (14.12.2007 14:56:00) [0]

Научиться на сервере превращать файл в поле набора данных, информации об этом не встречал.

← →
Sergey13 © (2007-12-14 15:11) [3]

> [0] Девушка © (14.12.07 14:56)

А не задумывались над тем, что бы хранить сами файлы в БД?

← →
Anatoly Podgoretsky © (2007-12-14 15:22) [4]

> Andrey (14.12.2007 15:05:01) [1]

Никак не обойдешься, поскольку разрешена запись, то разрешено удаление и переименование.
Целостность никак не гарантирована, да что там ссылочная целостность, даже содержимое не гарантировано.

← →
Anatoly Podgoretsky © (2007-12-14 15:24) [5]

> Sergey13 (14.12.2007 15:11:03) [3]

В этом случае нет проблем с целостностью. Но некоторые не верят, что это оптимально, мол файловая система работает надежнее, быстрее.

← →
Девушка © (2007-12-14 15:35) [6]

> А не задумывались над тем, что бы хранить сами файлы в БД?

задумыввалась, но предварительные прикидки как-то не в пользу этого.

текущий размер Бд примерно 700-800 Мб, а объем файлов, которые туда будут занесены 2,6 и более Гб

боюсь что будет сильно тормозить все :(

← →
Sergey13 © (2007-12-14 15:38) [7]

> [5] Anatoly Podgoretsky © (14.12.07 15:24)

Быстрота в этом случае, ИМХО, вообще по барабану. А надежность - БД то ведь тоже на файловой системе лежит. 8-)

← →
Sergey13 © (2007-12-14 15:39) [8]

> [6] Девушка © (14.12.07 15:35)
> боюсь что будет сильно тормозить все :(

За счет чего?

← →
Andrey © (2007-12-14 15:39) [9]

>Anatoly Podgoretsky [4]
Эх... ну может и никак.

Мне единственной что не нравится - это то что из SQL-сервера делают файловый шлюз.

← →
Девушка © (2007-12-14 15:41) [10]

суть даже не в том, чтобы реализовать все именно так, а в том, чтобы:

организовать "правильное и контролируемое" движение и модификацию документов.

← →
Девушка © (2007-12-14 15:43) [11]

возможно тут вопрос сформулирован правильнее:
http://forum.ibase.ru/phpBB2/viewtopic.php?p=26188#26188

← →
Anatoly Podgoretsky © (2007-12-14 15:49) [12]

> Девушка (14.12.2007 15:35:06) [6]

Ты неправильно считаешь, у тебя две файловые группы 800 мб (данные) + 2.6 (файлы) - вот это твой размер базы, а физическая организация не играет роли.
При хранение в базе, возможно даже и меньше объем будет, кроме того надежность и возможность передачи как блоб поля, есть еще куча преимуществ и недостатки тоже.
Сильно зависит и от физической организации базы, от объема пересылаемых данных, от повторного запроса одних и тех же данных, у БД свое кеширование.

← →
Anatoly Podgoretsky © (2007-12-14 15:52) [13]

> Anatoly Podgoretsky (14.12.2007 15:49:12) [12]

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

← →
Andrey © (2007-12-14 16:01) [14]

>Девушка © (14.12.07 15:43) [11]
Ну да, kdv всё сказал:

1. в базе такую информацию надо хранить, если она должна обрабатываться транзакционно
2. если объем такой информации больше чем база, причем составляет гигабайты, то на мой взгляд лучше использовать файловую систему.

Только если в обычной базе (без блобов) долгоиграющая write-транзакция не причинит много проблем, то в блобятнике, при относительно активной паралельной работе, базейка может и в разы вырости.
Девушка, как у вас с длинными пишущими транзакциями? Есть? Много? Не желаете избавиться?

← →
Sergey13 © (2007-12-14 16:03) [15]

> [10] Девушка © (14.12.07 15:41)
> суть даже не в том, чтобы реализовать все именно так, а
> в том, чтобы:
>
> организовать "правильное и контролируемое" движение и модификацию
> документов.

Именно это и позволит тебе использование СУБД. Хоть версии/подверсии храни с детальным логом кто/что/когда.

← →
Девушка © (2007-12-14 16:12) [16]

Andrey © (14.12.07 16:01) [14]

> Только если в обычной базе (без блобов) долгоиграющая write-
> транзакция не причинит много проблем, то в блобятнике, при
> относительно активной паралельной работе, базейка может
> и в разы вырости

эх,ма! :(((

можно попробовать это обойти так:
1. пользователи, которые имеют доступ к файлам только на чтение - получают его в режими только чтения. Поидее они могу тсохранить себе копию, но это видимо никак не обойти.
2. пользователи которые имеют право на изменене файла - получают его копию - без всяких торчащих транзакций. Они могут менять его на сове усмотрение, а потом просто "заменить" старый файл на новую версию в Бд.
3. пользователи которыемогут удалять файлы - берут и удалюят их :)

← →
Девушка © (2007-12-14 16:14) [17]

имеет ли для BLOB создавать отдельную таблицу и "привязывать" её к нужным таблицам?

← →
Anatoly Podgoretsky © (2007-12-14 16:18) [18]

> Девушка (14.12.2007 16:12:16) [16]

Ты реши как ты будешь передавать файл в этом случае, реализуй SELECT blob FROM tbl
А права это самое простое.

← →
Anatoly Podgoretsky © (2007-12-14 16:19) [19]

> Девушка (14.12.2007 16:14:17) [17]

Не имеет смысла, блобы и так отдельно хранятся и передаются отдельным потоком данных.

Можно сделать решение и без хранения файлов в базе.
ДКОМ сервер и клиент. Доступ к хранилищу файлов - тока у ДКОМ сервера (никаких сетевых папок).

>Девушка © (14.12.07 16:12) [16]
1. read-транзакция

2. при чтении файла наклиент короткая write-тразакция:
select user, trans, current_transaction from table where id = 1 for update;
if (trans is null) then
update table set user = current_user, trans = current_transaction where id = 1
commit;
else
commit;
showmessage(Звыняй, файло зохвачено господином user-ом. Иди к нему, пусть освобождает);

при записи файла на сервер короткая write-транзакция
select user, trans from table where id = 1 for update;
if (user = я сам) and (trans = та транзакция которой я вытаскивал файло) then
update table set blob = :blob, trans = null where id = 1;
commit;
else
commit;
showmesage(Катастрофа!!! Армагедец! Файло захвачен еще юзером user! По идее такого не должно было произойти, но раз уж произошло, иди к Девушке, пусть решает кто из вас правее, а кому морду разцарапать);

3. короткая write-тразакция:
select user, trans from table where id = 1 for update;
if (trans is null) then
delete from table where id = 1;
commit;
else
commit;
showmessage(Звыняй, файло зохвачено господином user-ом. Иди к нему, пусть освобождает);

Единственное, при таком подходе файлы могут быть захвачены и никогда не отданы безответсвенными юзерами.
Знач периодически нужно проводить проверку типа
select id, user, lock_date from table where lock_date <= неделю назад
и юзерам из этого списка бить морду, если не предоставят сносного объяснения на вопрос: "А какова!!???"

P.S. Ессна псевдокод )

как вариант:
написать udf - принимающую путь к файлу и имя и парольпользователя.
Данная UDF вызывает процедуру в базе, проверяющую права пользователя.
Если с правами все хорошо - она подгружает файл в специальную таблицу и отдает пользователю как обычный BLOB.
По окончании работы - очищает строку таблицы.

Ну например, как вариант, UDF может сама возвращать blob... или даже возвращать true/false (можно/нельзя читать файло), а возвращать blob в var-параметр...

Но вообще не совсем понятно как udf будет "вызывать процедуру в базе". Открывать свой коннект? Аццтой.

Уж лучше пусть вызывается некое:
select b.result, b.blobloblo from give_my_blob_plz("файло зовут как-то так") b

процедура give_my_blob_plz примерно такая:
Смотрим может ли current_user читать это файло.
если не может, сразу result = "пнх"; suspend; и выход из процедуры
если может:
из откуданибудь берем указатель на каталог в котором лежат файлы (ведь по сути пользователю не нужно знать где на сервере лежат файлы, он знает имя файла, и что ему этот файло может предоставить сервер, остальное лирика)

читаем блоб с помощью нашей волшебной udf в параметр blobloblo; suspend; the end;

и кстати, зачем пароль то передавать? пользователь подключился к базе? наверняка да. значит наверно он прошел аутентификацию. так зачем опять пароль то?... да и логин незачем... или (телипалка подсказывает) что все ходят к базе под sysdba и сверху накручена своя аутентификация. да? тогда всеравно пароль не надо, надо только пользователя... хотя в какой-то последней птичке появились переменные сеанса, но у нас же иб6.х, незнаю как всё там.

и кстати, желательно уточнить что же скрывается за этой загадочной буквочкой "х" из сабжа "иб6.х".

> и кстати, желательно уточнить что же скрывается за этой
> загадочной буквочкой "х" из сабжа "иб6.х".

в вопросе явно написано: InterBAse 7.0

> процедура give_my_blob_plz примерно такая:
> Смотрим может ли current_user читать это файло.
> если не может, сразу result = "пнх"; suspend; и выход из
> процедуры

все конечно здорово.. но у пользователя я так понимаю должны быть права на вызов udf. Если сама udf не проверяет - правильный ли человек её вызывает, то вполне можно получить доступ к любому файлу в такой системе - просто вызывая udf в самописном клиенте.

> Но вообще не совсем понятно как udf будет "вызывать процедуру
> в базе". Открывать свой коннект? Аццтой.

почему отстой? коннект будет кратковременным.

>в вопросе явно написано: InterBAse 7.0
Дя? Пропустил знач.

>у пользователя я так понимаю должны быть права на вызов udf
У пользователя должны быть права на вызов процедуры, а у процедуры на вызов удф. Процедура сама контролирует из какого каталога брать файлы. Пользователю вообще не обязательно знать где и как файлы хранятся, на диске, в блобах, да хоть их дядя вася налету в онлайне рисует... Такой себе презентейшен-лэер получается. Пользователь знает, что есть процедура выдающая файлы или фигу, а как она работает - это не его собачье дело. Одна из основопологающих концепций шаблонов проэктирования походу ) "Инкапсулировать не только данные, но и алгоритмы".
Но если совсем боимся злобных буратин, жестко путь прошиваем в удф, а параметром принимаем только имя файла. Это конечно немного нарушает стройность, но добавляет надежности )

>почему отстой? коннект будет кратковременным.
Эх... толком не могу объяснить, но это в среде программеров огнептицы считается моветоном (попробуйте на sql.ru это спросить, только сразу предупреждаю, не обижайтесь, я очень белый и пушистый по сравнению с ними )).
Скажу лишь, что наверняка этот вариант будет гораздо более гемороен в отладке... и работать будет медленнее, чем с блобами или файлами на диске. Ведь из дополнительных движений нужно как минимум установить и разорвать конект, а это тоже время.

> У пользователя должны быть права на вызов процедуры, а у
> процедуры на вызов удф. Процедура сама контролирует из какого
> каталога брать файлы.

Простите, но не умею в Interbase 7.0 выдавать права процедуре :(((

Научите!! Всегда об этом мечтала!!
А еще лучше чтоб процедурам выдавались права на таблицы, а пользователям только на процедуры

э... хм...
Ну вот тут чтоли почитай: http://ibase.ru/v6/doc/langref.zip
grant и revoke

тока чета я там не нашел как грантить удф-ки... думаю наверно так же как и хранимые процедуры, но потестить сейчас неначаем.

управление доступом к файлам на сервере посредством бд -клиента Найти похожие ветки