Каков предпочтительный метод хранения данных локально для веб-приложения, который часто не меняется?

Question

У меня есть пользовательское веб-приложение ASP.NET 4, которое в настоящее время работает в Windows Azure. Существует большой набор данных (несколько тысяч записей, каждая со значением «ключ» и описанием из 1-3 предложений), которые меняются очень редко (дважды за последние 25 лет), которые мне необходимо отображать как часть приложение (в выпадающих элементах управления, сетках и т. д.).

Я думаю, что не имеет смысла хранить данные в базе данных, поскольку их вряд ли когда-либо придется менять, и при каждой перезагрузке страницы будет отправляться несколько предложений. Я оцениваю как XML-файл, доступ к которому осуществляется через LINQ-to-XML, так и файл ресурсов. Существует потенциальная потребность в локализации строк (что, я думаю, будет направлено на файлы ресурсов), но из-за задействованной бизнес-логики мне иногда придется запрашивать данные также на основе различных атрибутов (определенных «ключей» значение или другие атрибуты, я думаю, будет проще с LINQ).

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

Answer 1

Вы можете использовать таблицу Windows Azure. Это быстро и надежно и частично поддерживает LINQ. Здесь - операторы запросов, доступные для LINQ в Azure. Также, если вам нужна локализация, вы можете использовать ту же таблицу и ту же культуру, что и PartitionKey. Также у вас не будет проблем при увеличении или уменьшении, потому что хранилище будет общим для всех узлов.

Параметром таблицы Windows Azure может быть выделенный контейнер с файлом XML, доступ к которому осуществляется через LINQ-to-XML. Но я бы предпочел первый вариант.

Answer 2

Почему бы не сохранить XML-файл в ресурсе? Это позволит вам получить преимущества как простой упаковки, быстрого доступа, LINQ, так и локализации.

Однако я бы не стал исключать SQL Azure, если у вас там уже есть база данных. Доступ к нему быстрый, и вы не будете платить никаких дополнительных сборов (при условии, что у вас уже развернута база данных), независимо от того, как часто вы к ней подключаетесь. ATS немного медленнее (хотя и более масштабируемо), но каждый раз, когда вы обращаетесь в ATS, вы платите за него почти копейку.

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

Answer 3

Я бы не стал исключать базу данных только потому, что данные не меняются - при условии, что Azure это позволяет, облегченная база данных, такая как SQL CE или SQLite, вероятно, будет работать нормально.

Тем не менее, другиеФакторы, которые вы упомянули (сопоставление ключа с короткой строкой, возможность локализации, отображаемая как часть пользовательского интерфейса), делают файл ресурсов лучшим вариантом.

Кажется, что выполнение запросов на основе строк ресурсоводнако, это немного странно - я считаю, что это возможно (см. этот вопрос ), но выполнение любого вида запроса, например, «дать мне все строки ресурсов, содержащие« foo »», сломало бы момент, когда вы что-либо локализовали.*