Какой из них быстрее читает XML файл или запрашивает базу данных

Ответ 1

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

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

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

• Простота чтения/обработки кода конфигурации: как бы выглядела ваша конфигурация? Является ли она естественной иерархической? Если это так, XML, вероятно, будет хорошо подходить. Если это больше похоже на набор пар имя/значение, тогда простая таблица подходит. Разумеется, вы можете хранить XML в базе данных - вам не обязательно связывать решения для хранения и хранения. Редактирование XML-документа в базе данных может быть сложнее, чем редактирование XML файла или изменение отдельных значений... но вы всегда можете облегчить жизнь с помощью таких инструментов.

Ответ 2

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

Сначала измерьте, затем оптимизируйте.

Ответ 3

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

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

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

Ответ 4

Это зависит от стратегии, которую вы собираетесь использовать для доступа к данным.

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

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

Быстрее? Когда материал находится в памяти, не должно быть разницы. Конфигурационная информация, как указывал другой плакат, обычно довольно статична. Почему бы не создать консольное приложение и не подсчитать различия, используя профилировщик.

http://www.red-gate.com/products/ants_performance_profiler/index.htm?utm_source=google&utm_medium=cpc&utm_content=brand_aware&utm_campaign=antsperformanceprofiler&gclid=CLXmzbLXnKMCFQs-lAodSXTGsQ

Ответ 5

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

а, если ваши данные очень "сложны" или имеют много разных отношений и атрибутов, рассмотрите возможность использования xml

Ответ 6

Я бы просто использовал базу данных по умолчанию здесь. Это быстрее и требует меньше кода.