Храните данные в файловой системе, а не в базе данных SQL или Oracle

Question

Поскольку я работаю над системой управления сотрудниками, у меня есть две таблицы (например) в базе данных, как указано ниже.

EmployeeMaster (структура таблицы БД)

EmployeeID (PK) | EmployeeName | Город

MonthMaster (структура таблицы БД)

Месяц | Год | EmployeeID (FK) | PrenentDays | BasicSalary

Теперь мой вопрос: я хочу хранить данные в файловой системе, а не в SQL или ORACLE.

Я хочу, чтобы мои данные в хранилище файловой системы использовались для операций вставки, редактирования и удаления с сохранением связи с объектами.

Я разработчик на C #. У кого-нибудь могут быть мысли или идеи по этому поводу. (Хранить данные в файловой системе с сохранением связей между ними)

Заранее спасибо.

Есть идеи по этому поводу?

Answer 1

Если вы хотите выполнить операции РЕДАКТИРОВАНИЕ / УДАЛЕНИЕ, не делайте этого. В конечном итоге вам придется только воссоздать базу данных с нуля, так что вы можете просто использовать ее. Если вы не хотите использовать SQLServer или Oracle, тогда используйте mysql, postgresql или любую другую базу данных в памяти (persist-to-disk). Если вам необходимо поддерживать файлы данных, читаемые человеком или простые / текстовые данные, все равно используйте базу данных в памяти и сохраняйте ее как .csv при сохранении на диск.

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

Вы также можете эффективно использовать файловую систему, если вы используете один файл на запись, и ваши операции ограничены MAP / INSERT / DELETE / REPLACE; и никогда не пытайтесь ОБНОВИТЬ. Но опять же, если мне нужно сделать обновления или корреляции, или любой из ряда других интересных запросов, я использую базу данных.

Наконец, вы можете использовать файловую систему, если ваши операции выполняются в режиме DUMP / RESTORE из структур данных памяти в один файл. В этом случае вы должны использовать любую стандартную библиотеку постоянства XML для вашей платформы и просто выполнить RESTORE при запуске приложения и DUMP при выходе или периодическом сохранении. Практически, как только вы перейдете к нескольким файлам, вы должны снова просмотреть базу данных и ORM.

В конечном счете, если вы не имеете дело с очень небольшим количеством данных; или вы имеете дело с большим объемом данных (не менее 100 миллионов записей), придерживайтесь базы данных.

Answer 2

Вы можете использовать SQLite , который по сути является "облегченной" СУБД, размещенной в виде DLL в вашем процессе.
Это будет хорошо для вас, если формат данных не должен быть удобочитаемым и если одновременный доступ к данным (несколькими процессами одновременно) не требуется.

Answer 3

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

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

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