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

Question

Я работаю над веб-приложением ASP.net, которое использует SQL в качестве базы данных.Одна проблема, с которой я сталкиваюсь, заключается в том, что иногда моему администратору базы данных требуется время для создания или изменения таблиц в базе данных, которые я ни при каких обстоятельствах не могу изменять самостоятельно.

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

Предположим, пользователь загружает новую запись для таблицы с именем Student_Records.Пользователь загружает запись с fname Бобом и lname Смитом.Записи присваивается первичный ключ 123 Пользователь также загружает два файла: attendance_record.pdf и homework_record.pdf.Предположим, у меня есть сетевой ресурс: \\ foo \ bar, в котором сохраняются файлы.

Один из способов справиться с этой ситуацией - иметь таблицу Student_Records_Files, которая связывает ключ 123 с Bob Smith.Однако, поскольку у меня возникают проблемы с созданием таблиц, я пошел и сделал что-то другое: когда я сохраняю файлы на сервере, я называю их 123_attendance_record.pdf и 123_homework_record.pdf.Таким образом, я могу легко определить, с какой записью таблицы связан каждый файл, не создавая новую таблицу SQL.По сути, я использую саму файловую систему в качестве таблицы соединений (очевидно, файловая система является типом базы данных).

В моем коде для получения файлов я сканирую каталог \\ foo \и ищите файлы, которые начинаются с каждого номера первичного ключа от Student_Records.

Кажется, это работает очень хорошо, но это хорошая практика?

Answer 1

Здесь действительно два вопроса.Во-первых, учитывая, что по административным причинам вы не можете вносить изменения в схему базы данных, приемлемо ли придумать какой-то обходной путь.На это я должен был бы сказать да.Что еще можно сделать?Теоретически, если администратору базы данных потребуется две недели, чтобы внести изменения в схему, эти две недели должны быть добавлены к любому заданному сроку.На практике этого почти никогда не бывает.Я часто работал в местах, где какие-то документы или что-то еще требовалось за две недели до того, как я смог начать работу, а затем мне дали две недели и один день, чтобы сделать проект.Иногда вам просто нужно соединить его с резинками и полосами.

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

С положительной стороны: (a) Встраивая информацию в имя файла, вы облегчаете как компьютеру, так и человеку идентификацию ассоциаций файлов.(Человек может быть прочитан, если соглашение об именах достаточно простое). (Б) Исключая отдельное хранилище ссылки, вы исключаете возможность плохой ссылки.Конечно, файл с соответствующим именем может не существовать, но запись в базе данных с соответствующими ключами может не существовать, или ссылка на файл в такой записи может быть нулевой или недействительной.Таким образом, кажется, что она решает одну проблему без создания каких-либо новых проблем.

Потенциальные минусы: (a) У вас могут быть символы в ключе, которые недопустимы в именах файлов.Вы можете просто удалить такие символы, или это может привести к дублированию.Единственная безопасная вещь - это как-то избежать их, что является болью.(б) Вы можете превысить допустимую длину имени файла.Не так много проблем, как это было в старые добрые 8,3 дня.(c) Вы не можете делиться файлами.Если запись базы данных указывает на файл, то две записи базы данных могут указывать на один и тот же файл.Если вам необходимо сделать две копии файла, это не только расходует место на диске, но также означает, что если файл обновляется, вы должны обязательно обновить все копии.Если в вашем приложении не имеет смысла обмениваться файлами, то это не проблема.

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

Я действительно не могу думать ни о каких минусах.Как я уже сказал, я делал это время от времени и не сталкивался с какими-либо конкретными проблемами.Мне интересно видеть ответы других.

Answer 2

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

Во-вторых, создание такого важного имени файла кажется мне опасным; нет защиты от человека или приложения, изменяющего имя файла, не осознавая его важность.

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

Answer 3

Нет ничего плохого в использовании файловой системы для хранения файлов.Это то, для чего он используется.

Однако следует помнить несколько вещей.

1. Я бы рассмотрел лучший способ хранения файлов - возможно, каталог для каждого пользователя.вместо простого добавления идентификатора пользователя к имени файла.
2. Убедитесь, что хранилище файлов устойчиво и резервное копирование выполняется с той же регулярностью, что и ваша база данных.Если ваша база данных настроена на резервное копирование каждые 10 минут, но хранилище файлов делает резервное копирование только каждый день (или, что еще хуже, неделю), то вам может быть больно.
3. Также подумайте, что быпроизойдет, если пользователь загрузит два документа с одинаковым именем.

Answer 4

Лучше всего хранить все в базе данных.

Сетевой файловый ввод / вывод в лучшем случае является пятнистым. Кроме того, он медленнее, чем ввод-вывод БД.

Если администратору базы данных сложно внести небольшие изменения в базу данных, вы
может иметь дело с:

• Вопрос политического контроля. Может быть, он просто знает вещи из БД и ему угрожают
  когда он видит, как другие приближаются к его газону. Какими бы ни были его причины, вам нужно
  ПОЛУЧИТЬ РАБОТУ СДЕЛАНО. Период. Документ все дополнительное время / общение / работа
  Вы должны сделать для каждого небольшого изменения и обсудить это с руководством.
  Если первый уровень управления не хочет видеть вещи по-своему,
  (не имеет значения, каковы их причины), обостри вопрос
  на следующий уровень управления. В прошлом я получал результаты таким образом.
  Это была скорее проблема политической территории, чем техническая проблема.
  В конечном итоге администратор базы данных сдался и дал мне полный доступ к системе TEST, НО
  он также оговорил, что мне нужно изучить его процесс тестирования,
  соглашение об именах, его стандарты и методы работы с БД, способ его тестирования и т. д.
  Я был игрой.
  Мне также нужно будет исправить любые проблемы с базой данных, возникающие из-за внесенных мной изменений.
  Это было честно, и я должен был носить шляпу DBA в дополнение к шляпе разработчика.
  У меня была свобода, в которой я нуждался, и у него было меньше забот.

• Проблема процесса. Возможно, администратору БД необходимо внести каждое небольшое изменение БД, которое вы отправляете
  через набор испытаний и анализа производительности. Может быть, он имеет очень
  нормализована схема БД и поскольку у него большая картина, ему нужно нормализовать или
  денормализуйте запрошенные вами изменения БД, чтобы они соответствовали существующей схеме.
  Попросите поработать с ним. Спросите у него полную схему проектирования БД.
  Получите хорошее представление о его философии проектирования БД. Реализуйте изменения в вашей БД с помощью
  его философия дизайна БД. Покажите, что вы понимаете, что он пытается
  чтобы поддерживать базу данных в хорошем состоянии (понять нормализацию, реляционные ограничения,
  проверьте ограничения) Дайте ему меньше беспокоиться. Ему нужно верить, что ты
  не испортит свою базу данных.
  Соберите все небольшие изменения в длинный скрипт и отправьте их администратору базы данных.
  Таким образом, вам не придется ждать каждого небольшого изменения, чтобы пройти все его
  процесс / тестирование. Кроме того, вы даете ему более широкую картину вашего
  планирование развития (что соответствует его философии проектирования БД) вместо
  просто игра за игрой.

Answer 5

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

Во-вторых, вместо того, чтобы пытаться обойти проблему, почему бы вам не попробоватьрешить проблему?Почему процесс внесения изменений в таблицы происходит так медленно?Вы хотя бы способны работать с базой данных разработки (в которой вы можете контролировать и испытывать эти изменения)?Даже если это ваш собственный ноутбук, вы можете продолжить разработку.Работайте с вашим менеджером, администратором базы данных и с кем бы то ни было другим, чтобы улучшить процесс.Поможет ли это ускорить процесс, если ваши сценарии прошли официальный процесс тестирования до того, как вы передали их администратору базы данных, чтобы ему не нужно было тестировать сценарии и т. Д. Самому?

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

Создание такого рода "данные "в имя файла имеют внутренние проблемы, как указали другие.У вас нет гарантий реляционной целостности, и «данные» могут быть изменены без ведома остальной части приложения / базы данных.

Answer 6

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

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