Позволяет пользователю сохранять данные в файл

Question

Существует ли более эффективный способ реализации сохраненного пользователем файла в моем приложении?

(я использую C#/.Net с Sql Server)

МОЯ ЦЕЛЬ:

Я хочу, чтобы позволить пользователям сохранять свои созданные точки данных (наряду с некоторыми другими структурированными данными) к «файл проекта» с произвольным расширением.

Предлагаемый метод:

• магазин каждый DataPoint в базе данных вместе с колонной FILEID
• Когда пользователь сохраняет файл, захватить все точки данных: «SELECT * ... WHERE FILEID = @ CurrentFileID».
• Экспортировать все эти точки данных в файл XML.
• Удалить все эти точки данных из базы данных.
• Сохраните файл XML как (или как часть) файла проекта.
• Каждый раз, когда пользователь загружает свой файл проекта, импортируйте данные из XML обратно в базу данных.
• Отобразить данные из базы данных, имеющей FileId = Идентификатор текущего файла.

АЛЬТЕРНАТИВА: Использование Sqlite и создать отдельный файл базы данных SQLite для каждого из проектов пользователя?

Answer 1

«Лучший» ответ зависит от нескольких факторов. Вы можете помочь себе прийти к лучшему внедрению для вас, задав некоторые вопросы, касающиеся использования данных.

Первый вопрос, который я задал бы: есть ли какая-либо причина, о которой вы можете думать сейчас или в будущем, для хранения точек данных в виде дискретных полей в базе данных.

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

Если, например, вы должны иметь возможность вытащить их в отчет или экспортировать только часть из них за один раз на основе некоторых критериев, то вам почти наверняка необходимо сохранить их как дискретные значения в базе данных.

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

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

Вы можете уточнить ответ на также просят дополнительные вопросы:

• Какова величина данных (сотни, тысячи, миллионы, миллиарды)?

• Какова частота вставок и обновлений (х в секунду, минуту, день, год)?

• Какое требуемое время отклика (миллисекунды, секунды, не имеет значения)?

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

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

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