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