Занимаюсь деланием БД Историй болезни для одного лечебного заведения на MS SQL 2000
Как и у всех моих коллег — история болезни хранит диагнозы, назначения и прочую дрянь..
Но вот возникла необходимость "прикреплять" к истории болезни различные файлы, и тут до меня доперла

такая мысль: хранить кучу файлов на MS SQL — это просто какой то бред, ведь для этого есть файловые сервера..
Тогда историю болезни проще понимать как папку №.. на общедоступном диске, куда и можно положить кучу всего..
Я на распутьи — чего делать?? Может кто уже сталкивался с проблемой такой , подскажите плиз

Здравствуйте, barn_czn, Вы писали:

_>Занимаюсь деланием БД Историй болезни для одного лечебного заведения на MS SQL 2000
_>Как и у всех моих коллег — история болезни хранит диагнозы, назначения и прочую дрянь..
_>Но вот возникла необходимость "прикреплять" к истории болезни различные файлы, и тут до меня доперла

_>такая мысль: хранить кучу файлов на MS SQL — это просто какой то бред, ведь для этого есть файловые сервера..
_>Тогда историю болезни проще понимать как папку №.. на общедоступном диске, куда и можно положить кучу всего..
_>Я на распутьи — чего делать?? Может кто уже сталкивался с проблемой такой , подскажите плиз
Тем не менее, люди умудряются складывать файлы в базу. Что же касается общедоступного диска, то тут есть варианты, вы можете набросать файлы в кучу, а в БД хранить полный или относительный путь (в зависимости от того, нужно ли вам хранить копию или что бы это работало в разных сетях), можете сделать контейнер, в который складываются ваши файлы (это положительно для мелких файлов, но которых большое количество, потому что экономия на кластерах на диске), а можете на своем любимом языке написать простенький сервис, который выдает выдает и складывает ваши файлики, то есть в этом варивнте вам шара не нужна, и как хранятся файлы клиентам не важно.

Здравствуйте, Chupa_Kabra, Вы писали:

C_K>Здравствуйте, barn_czn, Вы писали:

_>>Занимаюсь деланием БД Историй болезни для одного лечебного заведения на MS SQL 2000
_>>Как и у всех моих коллег — история болезни хранит диагнозы, назначения и прочую дрянь..
_>>Но вот возникла необходимость "прикреплять" к истории болезни различные файлы, и тут до меня доперла

_>>такая мысль: хранить кучу файлов на MS SQL — это просто какой то бред, ведь для этого есть файловые сервера..
_>>Тогда историю болезни проще понимать как папку №.. на общедоступном диске, куда и можно положить кучу всего..
_>>Я на распутьи — чего делать?? Может кто уже сталкивался с проблемой такой , подскажите плиз
C_K>Тем не менее, люди умудряются складывать файлы в базу. Что же касается общедоступного диска, то тут есть варианты, вы можете набросать файлы в кучу, а в БД хранить полный или относительный путь (в зависимости от того, нужно ли вам хранить копию или что бы это работало в разных сетях), можете сделать контейнер, в который складываются ваши файлы (это положительно для мелких файлов, но которых большое количество, потому что экономия на кластерах на диске), а можете на своем любимом языке написать простенький сервис, который выдает выдает и складывает ваши файлики, то есть в этом варивнте вам шара не нужна, и как хранятся файлы клиентам не важно.

Про относительные ссылки на общую папку понятно.. Про контейнеры не врубился. Сервис — вот это пожалуй лучшее решение.. Но еще лучше б если б была хранимая процедура, незнаю возможна ли такая, не писал хп еще

Chupa_Kabra wrote:

> Тем не менее, люди умудряются складывать файлы в базу.
Ничего в этом плохого нет. Если тебя смущает что они в одной базе,
сделай еще одну специально для файлов в отдельном таблспэйсе. С
файлсервером гемороя еще больше. У Майкрософта есть продукт SharePoint
Portal. Он в базе хранит вообще все файлы web-портала(asp, html, ...) и
перед тем как ты ломишься не него он их сперва считывает с базы, а потом
тебе выплевывает.

Здравствуйте, Аноним, Вы писали:

А>Про относительные ссылки на общую папку понятно.. Про контейнеры не врубился. Сервис — вот это пожалуй лучшее решение.. Но еще лучше б если б была хранимая процедура, незнаю возможна ли такая, не писал хп еще

Забудьте про контейнеры.
Хранимую процедуру вы конечно можете написать, можете складывать файлы в табличку. или попытаться написать расширеную хранимую, которая вам файлы будет в папочку складывать и изымать, но если вы не писали обычных хранилок, то про расширенную забудьте, тем более, что я не уверен, можно ли ее сделать эффективной (горлышко там узкое).
А вообще каждая задача всегда имеет множество решений и выбор зависит в том числе и от накладываемых вами ограничений ... Если вы хотите, что бы вам посоветовали уже конкретное решение, то потрудитесь полностью описать задачу. Либо рассматривайте предлагаемые варианты.

При хранении файлов в базе есть плюс.
Сделал бэкап и все что нужно уже в нем есть.

Здравствуйте, barn_czn, Вы писали:

_>Занимаюсь деланием БД Историй болезни для одного лечебного заведения на MS SQL 2000
_>Как и у всех моих коллег — история болезни хранит диагнозы, назначения и прочую дрянь..
_>Но вот возникла необходимость "прикреплять" к истории болезни различные файлы, и тут до меня доперла

_>такая мысль: хранить кучу файлов на MS SQL — это просто какой то бред, ведь для этого есть файловые сервера..
_>Тогда историю болезни проще понимать как папку №.. на общедоступном диске, куда и можно положить кучу всего..
_>Я на распутьи — чего делать?? Может кто уже сталкивался с проблемой такой , подскажите плиз

Уточним вопрос — повысятся ли требования к производительности сервера если перенести бинарники с файлового сервера в БЛОБ ?

Здравствуйте, _kdv_, Вы писали:

__>Chupa_Kabra wrote:

>> Тем не менее, люди умудряются складывать файлы в базу.
__>Ничего в этом плохого нет. Если тебя смущает что они в одной базе,
__>сделай еще одну специально для файлов в отдельном таблспэйсе.
Присоединяюсь. Можно обойтись и тем, что добавить отдельную группу файлов данных в БД — размещенную на отдельном диске, а при создании таблицы (где будут BLOB'ы) указать на эту группу

CREATE TABLE FILE_CATALOG
(FILE_ID VARCHAR(5) PRIMARY KEY,
FILE_PATH VARCHAR(100))
GO
CREATE TABLE FILES
(FILE_ID VARCHAR(5) FOREIGN KEY REFERENCES FILE_CATALOG(FILE_ID),
FILE_DATA IMAGE)
ON FILES_STORAGE /*предварительно созданная отдельная группа файлов*/

IBoB wrote:
>
> Уточним вопрос — повысятся ли требования к производительности сервера
> если перенести бинарники с файлового сервера в БЛОБ ?
Смотря что ты будешь делать? Если ты поставишь каког-нить агента и он
тебе будет туда-сюда гонять файлы, или это юзеры которые в день закинут
пару десятков файлов и столько же откроют для просмотра.

Здравствуйте, _kdv_, Вы писали:

__>IBoB wrote:
>>
>> Уточним вопрос — повысятся ли требования к производительности сервера
>> если перенести бинарники с файлового сервера в БЛОБ ?
__>Смотря что ты будешь делать? Если ты поставишь каког-нить агента и он
__>тебе будет туда-сюда гонять файлы, или это юзеры которые в день закинут
__>пару десятков файлов и столько же откроют для просмотра.
Если бы второй вариант, то я бы вопрос не задавал.
Есть сервер, который интенсивно работает с базой на запись. При вставке данных в базу соответствующие им бинарные данные сливаются на файл сервер. Плюс есть еще клиенты которые эти данные таскают себе, но эта наррузка на порядок-другой ниже чем от сервера.
Вопрос в том, что если начать сваливать их в блоб будет ли выйгрышь в скорости и на моного ли поднимутся требования к ресурсам со стороны SQLserver'a.

IBoB wrote:

> Вопрос в том, что если начать сваливать их в блоб будет ли выйгрышь в
> скорости и на моного ли поднимутся требования к ресурсам со стороны
> SQLserver'a.
Если по скорости считывания файла с БД? то можешь написать тестик. объем
файлов какой? Конечно если у тебя тысячи файлов гоняются туда-сюда по 10
и больше Мб, то не стоит делать из сервера БД- файлсервер.

Здравствуйте, _kdv_, Вы писали:

__>IBoB wrote:

>> Вопрос в том, что если начать сваливать их в блоб будет ли выйгрышь в
>> скорости и на моного ли поднимутся требования к ресурсам со стороны
>> SQLserver'a.
__>Если по скорости считывания файла с БД? то можешь написать тестик. объем
__>файлов какой? Конечно если у тебя тысячи файлов гоняются туда-сюда по 10
__>и больше Мб, то не стоит делать из сервера БД- файлсервер.
Дык именно по этом у и спросил, что не хочется тест писать. Файлов действительно тысячи. Размер очень разный, в среднем 100к.
А стоит\не стоит на глазок не оценить

IBoB wrote:
>
У меня был проект в котором я реализовывал сохранение файлов в бд, и
меня вполне все устраивало. Но правда такой частой периодики обмена
файлами у них не было.
Я бы попробовал. Зато потом будет у тебя совет для нуждающихся, стоит
этого делать или не стоит.

Здравствуйте, _kdv_, Вы писали:

__>IBoB wrote:
>>
__>У меня был проект в котором я реализовывал сохранение файлов в бд, и
__>меня вполне все устраивало. Но правда такой частой периодики обмена
__>файлами у них не было.
__>Я бы попробовал. Зато потом будет у тебя совет для нуждающихся, стоит
__>этого делать или не стоит.

Тоже делал подобное, предварительно пропуская файлы через библиотеку компрессии. Учитывая что у меня в основном документы офисные, сжатие в 5-6 раз существенно экономит место.