Это плохо для не использования DB, но использования в объектах памяти?
Для меня определили задачу для записи небольшого приложения, которое будет использоваться отдельным пользователем. Это приложение вытянет на ~500 имен/отделов сотрудника от нашего основного сотрудника DB. Затем пользователь войдет как 5 полей для каждого сотрудника. Те 5 полей обычно только изменятся один раз в год, но могли быть один раз в месяц худшим случаем. Я только, как предполагается, отслеживаю ценность 2 лет в любой момент времени.
Я посмотрел на SQLite и SQL CE, и я просто не взволнован ни одним из них. SQL CE не хочет позволять файлу данных находиться на сетевом ресурсе. (Только отдельный пользователь, но они хранят все свои документы на их частной доле, которая ежедневно сохраняется).
SQLite кажется, что отвечал бы всем требованиям лучше, но он не интегрируется также в Visual Studio без оберток или чего-либо.
Другая вещь рассмотреть состоит в том, что наши люди являются сведущими в SQL Server MS и мало еще также - что-то, что они понимают по сравнению с SQLlite, будет важная вещь моему боссу.
Таким образом, мой вопрос: Что, если я храню данные в Объектах в памяти и сериализирую их к диску при сохранении. Я сделал быстрый тест, и с 10k людьми (наше использование только будет 500-1000 макс.) и 10 годами каждый (или 10 месяцев, если они будут обновлять свои данные каждый месяц, очень вряд ли) только заставил мое демонстрационное приложение использовать 30 МБ памяти. Также заполнение тех данных было мгновенно даже с использованием GUID для случайного заполнения всех строк. Действительно ли это - плохая идея? Это - довольно простое приложение, и в этом случае это кажется хорошо мне.
9 ответов
Я вижу несколько проблем с идеей сохранения бизнес-данных с использованием сериализации объектов:
Это не обязательно препятствия для демонстрации идеи, это скорее то, о чем нужно подумать ...
- Данные могут ' не могут быть запрошены, сообщены или проверены. Это полностью непрозрачно улавливается приложением.
- Отладка сериализованных данных сложнее, чем возможность просматривать соответствующие данные в базе данных или даже в таком формате, как CSV.
- Нет атомарности - вы можете испортить всю вашу «базу данных» одним отключением питания или отказом приложения.
- Если модель данных изменяется, для обновления существующих постоянных сущностей требуется версия приложения, которая может читать как старый, так и новый формат. В базе данных вы можете просто добавить столбец (или подтаблицу).
- Не существует чистого способа реализовать одновременный доступ. Что произойдет, если несколько пользователей захотят просмотреть или отредактировать данные?
Я усвоил одну вещь: небольшие приложения имеют тенденцию расти и становиться «большими приложениями». Когда организации неверно предполагают потенциальную ценность приложения, они, как правило, несут расходы на такого рода неожиданный органический рост позже.
Вы также упомянули, что вам понравилось в SQLLite и не понравилось. Что тебе не понравилось? Какие проблемы вы ожидали?
Если вы просто ищете способ «срезать углы», чтобы сделать это быстрее - это может быть нормально в краткосрочной перспективе - но будьте осторожны - такого рода решения могут вернуться к укусам вы .
При сериализации данных вы теряете:
- Поиск в стиле SQL
- возможность вставлять / обновлять / удалять отдельные записи
- хорошо известны и понимается
- не зависит от языка
- доступность для других и нелокальных приложений
Вы получаете
- простое кодирование
- простое резервное копирование (убедитесь, что вы думали о резервном копировании!)
- меньше зависимостей
Судя по вашему описанию ваших целей и ограничений, я не вижу особых проблем с вашим подходом.
Другая мысль. Похоже, вы сохраняете простую табличную структуру данных, поэтому вы можете захотеть сохранить ее в удобочитаемой форме, такой как файл значений, разделенных запятыми, или даже XML. Таким образом, вы не зависите от языка, который используете в настоящее время.
Ваше собственное тестирование показывает, что он должен работать. Однако я настоятельно рекомендую абстрагироваться от уровня данных, чтобы в случае его замены вы могли сделать это быстро и легко. Если вы обнаружите, что вам нужен только намек на SQL с вашими объектами, вы можете посмотреть Linq to Objects
Храните данные в базе данных! Разделите его с помощью уровня данных. Вы можете использовать ORM, если хотите, или просто старый репозиторий, но никогда не используйте текстовый файл, файл xml, файл json для хранения такой информации.
Вы можете использовать SQL Server, если он у вас есть, используйте его, он есть не просто так.
Если вы можете сохранить эти 5 дополнительных полей данных в основной базе данных, то это казалось бы идеальным.
Если вы не можете, вы могли бы просто дать им файл Excel с каким-либо расширением или макросом для выборки данных из БД. Excel предоставляет вам множество хорошо известных функций для печати, сортировки, построения графиков и так далее. Вы не очень много рассказали нам о том, что приложение должно делать, кроме обновления этих 5 полей.
Если вы твердо настроены написать для этого приложение .net, а не использовать БД, по крайней мере поместите свои данные в формат XML, используя сериализацию XML.
Исходя из вашего обоснования, вы, безусловно, можете использовать файл, но мне кажется, что с бэкэндом базы данных он будет более расширяемым. Мы часто начинаем с проекта, который, как мы думаем, знаем все его требования и никогда не изменимся, но в действительности это не так. В вашем дизайне, если пользователь запрашивает дополнительное поле, вам придется снова настроить свой код, чтобы иметь дело с сериализованным полем фиксированной длины / двоичным полем. SQLite имеет хорошую поддержку, и они даже являются поставщиком LinQ для этого.
Я серьезно думаю, что самым простым решением для реализации вашего проекта в соответствии с вышеуказанным требованием является создание формы доступа. Определите поле, а затем используйте мастер для создания формы в доступе. Приложив совсем немного усилий, вы можете реализовать всю эту задачу с учетом расширяемости.
Если исходные данные находятся в SQL Server, который вы загружаете, никто из пользователей, разбирающихся в MS SQL Server , не попытается ВЫБРАТЬ изменения, вносимые вашим приложением? Если вы храните его где-нибудь еще, они его никогда не найдут.
Как хранение этих данных не в исходной базе данных поможет бизнесу? Или это будет мешать бизнесу? вам нужно решить это, а затем решить проблему оттуда. Не о том, как мне легче / лучше выполнить это задание.
На протяжении многих лет я видел много небольших приложений, которые должны были использоваться одним пользователем. (Долгое время все они по какой-то причине имели бэкэнды Access). Они неизменно становятся большими приложениями, используемыми несколькими пользователями.
Но на самом деле вопрос не в том, насколько он будет большим, а в том, как будут использоваться данные. Обычно люди хранят данные, потому что позже они хотят их увидеть, а это обычно означает отчеты, а это означает, что система реляционных баз данных была бы замечательной вещью!
Хранение данных в базе данных имеет некоторые другие преимущества, такие как чтение данных из другого приложения или из простого редактора базы данных. Если какое-либо другое приложение в будущем захочет повторно использовать данные, это будет проще сделать, чем десериализацию из объекта java. Также вам придется иметь дело с версией объектов, и запросы будут затруднены, если вы используете их с использованием объектов java.