Отправить файл на сервер

@master_fatum · Регистрация: 26.02.2015

Студворк — интернет-сервис помощи студентам

Добрый день! Подскажите пожалуйста с решением одного вопроса. Первый раз столкнулся, ломаю голову с реализацией. Есть физический сервер. На нем крутится MS SQL server. На нем БД, для работы с WPF-приложением.

Так вот задача. Есть юзеры, которые отправляют с данного приложения записи в БД. Теперь нужно, чтобы вместе с данными в БД на этот сервер отправлялись файлы. Например архивы. Реализация такая, что в БД столбцы UserId, Id-записи и несколько столбцов с текстовой информацией. Вообще не могу понять, как реализовать данную задачу.

Я так понимаю, отправил я файл на сервер. В БД есть запись, Id-юзера и Id записи. Ну пусть в БД добавляется путь к этому файлу с его именем. Правильный ход мыслей?

Короче, как должна располагаться структура ФС на сервере? Тупо отправлять файлы в одну папку? И искать его по пути/имени? А если у 2 файлов будут имена одинаковые?

Подскажите что-то друзья!

@Usaga · 30.08.2019, 12:16

Сообщение от master_fatum

Я так понимаю, отправил я файл на сервер. В БД есть запись, Id-юзера и Id записи. Ну пусть в БД добавляется путь к этому файлу с его именем. Правильный ход мыслей?

Нет, не правильный. В базе должны храниться метаданные файла. Имя, автор, дата создания, всё такое. А сам файл может храниться где угодно.

При хранении файлу можно давать сгенерированное имя на основе его ID в базе. Всё равно его оригинальное имя уже в базе сохранено, так ведь? Тогда бояться коллизий имён не надо будет.

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

Конечно же, на сервере должен крутиться сервер приложения с которым ваши WPF-клиенты и должны работать. И не факт, что этот сервер (и хранилище файлов) должен ютиться на той же машине, где СУБД крутится.

@master_fatum · 30.08.2019, 12:30 **[ТС]**

А нельзя сделать так? Будут папки с ID пользователями. И там будут файлы с именами "UserId_Id" где второе Id, это запись в БД. Это по идее будет уникальный ID файла. (Пусть например ему присваивает имя само приложение с учетом ID пользователя и ID записи. Т.к имена файлов абсолютно не важны) А потом просто юзер обращается к записи БД по своему Id и Id-записи и приложение ищет в папке данный файл с подобным именем? Или это танцы с бубном?

@Usaga · 30.08.2019, 13:12

master_fatum, танцы это.

У записи о файле в базе есть свой уникальный ID. Никаких юзеров приплетать не надо. И название файла в ФС можно как-то генерировать, а не брать строго ID из базы и точь-в-точь повторять.

@carrotik · 30.08.2019, 13:31

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

@Usaga · 30.08.2019, 13:33

carrotik, не согласен. Вся информация есть в базе, а логика вытаскивания файлов - в сервере приложения. Надо найти архивчик за апрель? Милости просим запрос в приложение и базу.

@carrotik · 30.08.2019, 13:49

Сообщение от Usaga

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

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

@Usaga · 30.08.2019, 13:52

carrotik, речь о том, что если у вас есть информационная система, то вся работа должна идти через неё. И хранилища данных должны формироваться исходя из удобства использования их этой системой. Если вам один фиг надо руками куда-то лезть (не в экстренных ситуациях), то грош цена такой системе. И нафиг она вообще нужна.

Если что-то не было заложено в ТЗ, то пользователи будут обламываться, пока не будет сформировано новое ТЗ расширяющее функционал. Но функционал поиска по данным всегда закладывается вместе с функционалом их редактирования. Иначе что толку с возможности вностить данные, если их потом нельзя искать?

В противном случае лучше завести сетевую папку на SMB сервере. Будет дешевле. И можно руками лазить.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@master_fatum 1 / 1 / 0 Регистрация: 26.02.2015 Сообщений: 125

	Отправить файл на сервер 30.08.2019, 11:11. Показов 739. Ответов 7 Метки нет (Все метки) Добрый день! Подскажите пожалуйста с решением одного вопроса. Первый раз столкнулся, ломаю голову с реализацией. Есть физический сервер. На нем крутится MS SQL server. На нем БД, для работы с WPF-приложением. Так вот задача. Есть юзеры, которые отправляют с данного приложения записи в БД. Теперь нужно, чтобы вместе с данными в БД на этот сервер отправлялись файлы. Например архивы. Реализация такая, что в БД столбцы UserId, Id-записи и несколько столбцов с текстовой информацией. Вообще не могу понять, как реализовать данную задачу. Я так понимаю, отправил я файл на сервер. В БД есть запись, Id-юзера и Id записи. Ну пусть в БД добавляется путь к этому файлу с его именем. Правильный ход мыслей? Короче, как должна располагаться структура ФС на сервере? Тупо отправлять файлы в одну папку? И искать его по пути/имени? А если у 2 файлов будут имена одинаковые? Подскажите что-то друзья! 0

@master_fatum 1 / 1 / 0 Регистрация: 26.02.2015 Сообщений: 125
	30.08.2019, 12:30 [ТС]
	А нельзя сделать так? Будут папки с ID пользователями. И там будут файлы с именами "UserId_Id" где второе Id, это запись в БД. Это по идее будет уникальный ID файла. (Пусть например ему присваивает имя само приложение с учетом ID пользователя и ID записи. Т.к имена файлов абсолютно не важны) А потом просто юзер обращается к записи БД по своему Id и Id-записи и приложение ищет в папке данный файл с подобным именем? Или это танцы с бубном? 0

@Usaga 14291 / 9376 / 1352 Регистрация: 21.01.2016 Сообщений: 35,331
	30.08.2019, 13:12
	master_fatum, танцы это. У записи о файле в базе есть свой уникальный ID. Никаких юзеров приплетать не надо. И название файла в ФС можно как-то генерировать, а не брать строго ID из базы и точь-в-точь повторять. 0

@carrotik 800 / 583 / 207 Регистрация: 21.02.2019 Сообщений: 2,095
	30.08.2019, 13:31
	..если подобное файлохранилище используется исключительно в рамках работы с приложением (или в системе цетрализованного документооборота) - то достаточно ID .. Но если возникают внешние задачи типа "А скинь мне по почте тот архивчик, который ты загрузил в апреле" - то тут уже имеет смысл позаботиться о файловой структуре с понятными для обычного пользователя (не софта) названиями папок с человеческими фамилиями/именами и, например, периодами (год, квартал) .. Но это скорее сисадминская задача ... 0

@Usaga 14291 / 9376 / 1352 Регистрация: 21.01.2016 Сообщений: 35,331
	30.08.2019, 13:33
	carrotik, не согласен. Вся информация есть в базе, а логика вытаскивания файлов - в сервере приложения. Надо найти архивчик за апрель? Милости просим запрос в приложение и базу. 0

@Usaga 14291 / 9376 / 1352 Регистрация: 21.01.2016 Сообщений: 35,331
	30.08.2019, 13:52
	carrotik, речь о том, что если у вас есть информационная система, то вся работа должна идти через неё. И хранилища данных должны формироваться исходя из удобства использования их этой системой. Если вам один фиг надо руками куда-то лезть (не в экстренных ситуациях), то грош цена такой системе. И нафиг она вообще нужна. Если что-то не было заложено в ТЗ, то пользователи будут обламываться, пока не будет сформировано новое ТЗ расширяющее функционал. Но функционал поиска по данным всегда закладывается вместе с функционалом их редактирования. Иначе что толку с возможности вностить данные, если их потом нельзя искать? В противном случае лучше завести сетевую папку на SMB сервере. Будет дешевле. И можно руками лазить. 0