Я разрабатываю CMS на С# и должен решить, где сохранить настройки конфигурации для сайта. Также рассмотрим определение базовых html-шаблонов, а затем обработку их на стороне сервера для создания страниц заблаговременно.
Итак, что обычно быстрее/меньше накладных расходов для сервера, читающего XML файл или запрашивающего эту же информацию из локальной базы данных?
Мне кажется маловероятным, что это будет узким местом в вашем коде. Как часто вы планируете читать настройки конфигурации? Конфигурация, как правило, довольно мала и читается нечасто. Есть более важные вещи, чтобы рассмотреть, где и как его хранить:
Bootstrapping: вы, вероятно, можете полагаться на свое приложение, имеющее доступ к локальной файловой системе, и можете жестко запрограммировать имя файла конфигурации... но если вся ваша конфигурация находится в базе данных, где вы настраиваете базе данных, чтобы поговорить с?
Простота настройки и развертывания: редактирование файла конфигурации на сервере вручную может быть быстрее, чем внесение изменений в базу данных... но если у вас несколько серверов, вы хотите настроить файл на каждом один из них?
Простота чтения/обработки кода конфигурации: как бы выглядела ваша конфигурация? Является ли она естественной иерархической? Если это так, XML, вероятно, будет хорошо подходить. Если это больше похоже на набор пар имя/значение, тогда простая таблица подходит. Разумеется, вы можете хранить XML в базе данных - вам не обязательно связывать решения для хранения и хранения. Редактирование XML-документа в базе данных может быть сложнее, чем редактирование XML файла или изменение отдельных значений... но вы всегда можете облегчить жизнь с помощью таких инструментов.
Просто для настроек сервера - действительно не имеет значения. Вы только прочтете их один раз. Даже если это займет пару секунд, все равно будет незаметно.
Сначала измерьте, затем оптимизируйте.
Как долго длится строка? Я могу написать запрос базы данных, который намного медленнее, чем чтение одних и тех же данных из файла XML, но я также могу написать XML файл, который гораздо медленнее запрашивать, чем чтение базы данных.
Я бы сказал, что если вы показываете "в основном" статический контент, и вы беспокоитесь о производительности, то, вероятно, лучше всего реализовать его так, как вы считаете, самым простым, а затем использовать механизм кеширования, чтобы сделать это перформанс - таким образом, первый доступ может быть "медленным", но последующие обращения будут намного, намного быстрее.
Как правило, если вы создаете HTML-контент, напишите заполненный HTML на диск и отправьте его в браузер, вместо того, чтобы заполнять его из файлов базы данных /XML при последующих запросах. Если у вас есть серверный процесс, удалите кешированные файлы всякий раз, когда он обновляет содержимое, тогда сервер может автоматически определить, когда файл не существует и повторно сгенерировать его снова.
Это зависит от стратегии, которую вы собираетесь использовать для доступа к данным.
Если вы идете по маршруту базы данных, собираетесь ли вы кэшировать свои результаты? Там может быть много разговоров в сети, если вы постоянно вытаскиваете детали из db.
В терминах простоты вы действительно можете быть агностиком для источника данных, используя Linq..
Быстрее? Когда материал находится в памяти, не должно быть разницы. Конфигурационная информация, как указывал другой плакат, обычно довольно статична. Почему бы не создать консольное приложение и не подсчитать различия, используя профилировщик.
если ваш самый важный момент - скорость, а затем используйте базу данных. xml очень медленный.
а, если ваши данные очень "сложны" или имеют много разных отношений и атрибутов, рассмотрите возможность использования xml
Я бы просто использовал базу данных по умолчанию здесь. Это быстрее и требует меньше кода.