Есть ли проблемы с производительностью при хранении контента в базе данных, а не на обычной странице ASPX или PHP?

Question

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

Мой коллега согласился с этим до некоторой степени.Он считает, что существуют проблемы с производительностью, связанные с извлечением контента из базы данных, особенно если каждый символ контента поступает из базы данных.Когда он создает веб-сайт, любой контент, который не будет часто изменяться (если вообще будет), будет жестко запрограммирован на странице, а любой контент, который будет регулярно изменяться или добавляться, будет поступать из базы данных.

Я не вижу преимущества в том, чтобы делать это так, просто с точки зрения того, что каждый раз, когда мы вносим изменения в страницу ASPX, нам нужно перекомпилировать сайт, чтобы загрузить его.Поэтому, если на одной странице есть ошибка "The" (то есть "Teh"), мы должны изменить ее на этой странице, затем перекомпилировать сайт (весь сайт) и затем загрузить его.

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

Что нас обоих поразило, так это то, что если веб-сайт извлекает все из базы данных (не HTML-код как таковой, а скорее контент для верхних и нижних колонтитулов, ссылок и т. Д.), Это замедлит работу сайта?И кроме этого, если есть проблемы с производительностью, что будет лучше?Веб-сайт, на 100% управляемый базой данных, с проблемами производительности, или веб-сайт с жестко закодированным контентом, который будет означать 10/20 минут, потраченных на компиляцию и загрузку веб-сайта только ради изменения одного слова или буквы?

Мне интересно узнать, слышал ли кто-нибудь еще об этом или у них есть свои мысли на этот счет?

Приветствия

Answer 1

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

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

b) разница в производительности в любом случае будет крошечной, особенно по сравнению со временем передачи страницы с сервера клиенту

Подход на 100% к базе данных открывает потенциал для большей гибкости и возможностей в вашем приложении.

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

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

Answer 2

Жесткий код строк в коде (если вы не планируете поддерживать несколько языков). Это не стоит

• дополнительный код, необходимый для поддержки строк
• добавленная сложность
• и, возможно, снижение производительности

Не могли бы вы извлечь строку "Отмена" из кнопки? Если так, вы бы использовали одну и ту же строку на нескольких кнопках отмены? Или по одному на каждого? Если вы решили переименовать одну кнопку в «Отменить регистрацию», как определить, какую «Отмена» обновить в базе данных? Вы были бы вынуждены настроить рабочий процесс вокруг того, как справиться с этим, и, по моему мнению, это просто не стоит.