Привет всем!

Сабж:
База данных сотрудников, пример аля "БОРЕЙ", там есть фотография сотрудника. Она сохранена как путь на файл на диске, самая наверное разумная реализация.

Проблема:
Когда несколько юзеров работают с базой по сети, естественно фотки видит только тот у кого локально на машине расположена база, потому как в поле _фото_ запись типа:

d:\мои документы\база клиенты\фотки\сидоров.jpg

Возможное решение:
Я так пологаю, что нужно как то впихивать туда сетевые имена на файлы, аля:

\\Comp_1\second (d)\мои документы\база клиенты\фотки\сидоров.jpg

но шестое чувство подсказывает, что это СОВСЕМ не правильно, потому как, а что будет если изменится имя компа или сетевого диска или базу перенесут на другой комп, да мало ли что?!

Плиз, кто знает поделитесь методологией решения подобной задачи!

Спасибо всем!

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

M>Сабж:
M>База данных сотрудников, пример аля "БОРЕЙ", там есть фотография сотрудника. Она сохранена как путь на файл на диске, самая наверное разумная реализация.

M>Проблема:
M>Когда несколько юзеров работают с базой по сети, естественно фотки видит только тот у кого локально на машине расположена база, потому как в поле _фото_ запись типа:
M>

M>d:\мои документы\база клиенты\фотки\сидоров.jpg
M>

M>Возможное решение:
M>Я так пологаю, что нужно как то впихивать туда сетевые имена на файлы, аля:
M>

M>\\Comp_1\second (d)\мои документы\база клиенты\фотки\сидоров.jpg
M>

M>но шестое чувство подсказывает, что это СОВСЕМ не правильно, потому как, а что будет если изменится имя компа или сетевого диска или базу перенесут на другой комп, да мало ли что?!

M>Плиз, кто знает поделитесь методологией решения подобной задачи!

я, как раз, сторонник хранения файлов в файловой системе. но это — вопрос архитектурного подхода.
...ну или философии, если угодно.

в конкретно указаном случае, можно хранить где-то в конфигах проекта:
d:\мои документы\база клиенты\фотки\
или
\\Comp_1\second (d)\мои документы\база клиенты\фотки\

и уже от указанного "рута" писать путь (или просто имя файла) до указаной фотки.

в качестве бонуса, пропишите альтернативный рут. и положите файлы сразу на двух сетевых серверах.
при ненахождении в одном месте — можно попробовать спросить в "альт".

p.s. а вот хранить файлы в базе мне не нравиться, сорри.
обьяснить могу, но к вопросу отношение не имеет.

во

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

B>p.s. а вот хранить файлы в базе мне не нравиться, сорри.
B>обьяснить могу, но к вопросу отношение не имеет.

Интересно услышать объяснение.

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

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

B>>p.s. а вот хранить файлы в базе мне не нравиться, сорри.
B>>обьяснить могу, но к вопросу отношение не имеет.

А>Интересно услышать объяснение.

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

во

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

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

M>То есть я так понимаю, прописываем жестко в конфиге базы например два путя,сетевой и локальный и
M>по одному из них находим то что нужно. Соответственно если меняется имя машины или сетевого диска то нужно
M>покрайней мере сетевой адрес в конфиге подправить. Так я понял, да?

да. только я имел ввиду config-файл.
но не вижу проблемы, почему бы конфиги не хранить в базе.

во

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

M>Плиз, кто знает поделитесь методологией решения подобной задачи!

Пусть все картинки лежат в некоторой папке (назовем ее корневой папкой изображений) и подпапках на одном компьютере.
В базе храни относительные пути (назовем колонку с путями RelativeImagePath).
В конфиге приложения заведи переменную ImagesRootFolder.
Тогда.
В базе будет что-то вроде

Image1.jpg
Image2.jpg
MoreImages/Image3.jpg
MoreImages/Image4.jpg

Картинки могут лежать даже не на той машине, на которой база твоя лежит (пусть это будет комп с именем ImagesServer).
Расшариваешь на этом компе корневую папку изображений под некоторым именем (пусть это будет Images).
В настройках клиентов прописываешь в конфиге

ImagesRootFolder = "\\ImagesServer\Images"

При работе с картинками в клиенте должен быть примерно такой код:

string relativeImagePath;
// Получить из базы relativeImagePath из колонки RelativeImagePath
string imagePath = Path.Combine(Settings.ImagesRootFolder, relativeImagePath);
//теперь в переменной imagePath абсолютный путь к картинке. Делай с ним чего хочешь.

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

M>Привет всем!

M>Сабж:
M>База данных сотрудников, пример аля "БОРЕЙ", там есть фотография сотрудника. Она сохранена как путь на файл на диске, самая наверное разумная реализация.

А почему бы не хранить фотки в blob , тогда не будет таких проблем. Да и менять их будем в транзакциях

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

А>А почему бы не хранить фотки в blob , тогда не будет таких проблем. Да и менять их будем в транзакциях
Тогда база очень быстро умрет. У Аксесса принципиальные проблемы при работе с файлами БД большого размера (то ли два, то ли четыре гига для него вообще предел возможностей).
Я вообще считаю, что в базе хранить нужно всё, но для аксесса это не всегда возможно.

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

MF>

MF>string relativeImagePath;
MF>// Получить из базы relativeImagePath из колонки RelativeImagePath
MF>string imagePath = Path.Combine(Settings.ImagesRootFolder, relativeImagePath);
MF>//теперь в переменной imagePath абсолютный путь к картинке. Делай с ним чего хочешь.
MF>

Только писать надо так?

std::string relativeImagePath;
std::string imagePath = Settings.ImagesRootFolder + relativeImagePath;

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

S>Только писать надо так?
S>

S>std::string relativeImagePath;
S>std::string imagePath = Settings.ImagesRootFolder + relativeImagePath;
S>

Это был кусок кода
Кода на шарпе.

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

MF>Это был кусок кода
Знаю.

MF>Кода на шарпе.
Знаю.

Здравствуйте, Sheridan, Вы писали:
S>Знаю.
Тогда зачем ты предлагаешь заменить Path.Combine (который еще и добавляет разделитель пути, если надо) на строковую конкатенацию?

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

S>>Знаю.
S>Тогда зачем ты предлагаешь заменить Path.Combine (который еще и добавляет разделитель пути, если надо) на строковую конкатенацию?
Если все верно написано, то добавлять разделитель пути не надо, а в этом случае конкатенация быстрее будет.
Почему я так думаю? А потому что гляди: одна строка совсем статична — проверку на символ пути можно провести в момент инициализации переменой (1 раз за время работы приложения, при чтении настроек), 2я строка берется из БД. Проверку на правильность 2й строки надо проводить перед вносом ее в БД. Тоесть например мы заранее делаем чтобы первая строка заканчивалась разделителем пути, а вторая начиналась с имени каталога после разделителя.

Settings.ImagesRootFolder: 
"c:\data\something\"

relativeImagePath:
"first\first.jpg"
"somebody.jpg"
"first\woo.jpg"
"second\foo.jpg"

В итоге при выборке из БД мы имеем уже подготовленные строки и проверки не нужны. А если данных большое количество? И на каждом Path.Combine помимо сращивания строк будут идти еще и разные проверки? Это господа тормоза получаются. Так писать не надо.

Здравствуйте, Sheridan, Вы писали:
S>В итоге при выборке из БД мы имеем уже подготовленные строки и проверки не нужны. А если данных большое количество? И на каждом Path.Combine помимо сращивания строк будут идти еще и разные проверки? Это господа тормоза получаются. Так писать не надо.
Гм. Во-первых, доставание картинок из базы как правило в массовом порядке не бывает.
Во-вторых, конкатенация, я тебя уверяю, работает бесконечно быстрее фетчинга из аксесса. Поэтому эффект ты и в микроскоп не заметишь.
Попытки выиграть пару сотен тактов за счет устойчивости приложения и облегчения поддержки — не рулят. Так писать не надо. Надо профилировать.

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

S>Гм. Во-первых, доставание картинок из базы как правило в массовом порядке не бывает.
S>Во-вторых, конкатенация, я тебя уверяю, работает бесконечно быстрее фетчинга из аксесса. Поэтому эффект ты и в микроскоп не заметишь.
Знаю что быстрее, но это не повод забивать на качество и скорость работы кода.
Делая себе поблажки в малом рискуеш споткнуться на чемто важном. Это я уже по своему опыту.

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

S>Так писать не надо.
Надо. Надо учить себя писать быстрый и качественный код. На каждом шагу проверки делать это никаких компов не хватит потом обработать.

S>Надо профилировать.
Да, профилировать тоже надо. Одно но. Профилировать надо языки типа С++. Шарп профилируй не профилируй бейсик он бейсиком и останется, можно не заморачиваться...

Здравствуйте, Sheridan, Вы писали:
S>Надо. Надо учить себя писать быстрый и качественный код. На каждом шагу проверки делать это никаких компов не хватит потом обработать.
Надо учить себя писать хорошо читаемый код. Даже если Path.Combine внутри себя делает банальную конкатенацию, его использование позволяет с первого взгляда понять, о чем идет речь. Не нужно бегать глазами вверх по коду, чтобы разобраться кто с кем склеивается и зачем.
S>>Надо профилировать.
S>Да, профилировать тоже надо. Одно но. Профилировать надо языки типа С++. Шарп профилируй не профилируй бейсик он бейсиком и останется, можно не заморачиваться...
О, еще один спец. Мне даже неохота начинать все сначала. Вкратце: твои интуитивные представления о производительности современного софта безнадежно отстали от жизни. Крайне рекомендую начать их развеивать.

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

S>>Да, профилировать тоже надо. Одно но. Профилировать надо языки типа С++. Шарп профилируй не профилируй бейсик он бейсиком и останется, можно не заморачиваться...
S>О, еще один спец. Мне даже неохота начинать все сначала. Вкратце: твои интуитивные представления о производительности современного софта безнадежно отстали от жизни. Крайне рекомендую начать их развеивать.

Как работает "современный софт" я знаю, думаю и Шеридан тоже. Твой ответ некрасивый. Я понимаю, что Шеридан снова перешел на "бейсики" и все такое Это тоже некрасиво, вернее неправильно. Тем не менее.

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

D> Как работает "современный софт" я знаю, думаю и Шеридан тоже.
По его ответу этого не видно.
D> Твой ответ некрасивый.
Меня утомляет писать одно и то же в седьмой раз. У меня нет желания объяснять Шеридану, что к чему. У меня есть желание предостеречь новичков от принятия его слов за чистую монету.

Используй поле "Поле объекта ОЛЕ" и храни там фотки....