Настройка хранилища конфигурации [файл и база данных]

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

CitrusDB имеет таблицу в базе данных, называемую "праздник". Эта таблица состоит только из одного столбца даты, называемого "holiday_date", который содержит даты, которые являются праздниками. Идея состоит в том, чтобы позволить пользователю добавлять праздничные дни в таблицу. Citrus и программисты, с которыми я работаю на своем рабочем месте, предпочитают помещать всю эту информацию в таблицы, потому что она "стандартная".

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

ОТВЕТЫ

Ответ 1

Иногда вы хотите создать немного гибкости для продукта. Что делать, если ваш продукт выпущен в другой стране с разными праздниками? Просто подкрепите стол, и все будет хорошо работать. Если он жестко закодирован в приложении или, что еще хуже, жестко закодирован во многих местах через приложение, вы можете оказаться в мире боли, пытаясь заставить его работать в новой локали.

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

Иногда эффективность/скорость - не единственная мотивация для дизайна. Полезность, гибкость и т.д. Являются очень важными факторами.

Ответ 2

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

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

Ответ 3

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

Также учитывается доступность данных с точки зрения других аспектов проекта. Где большая часть данных в веб-приложении? В базе данных. Таким образом, мы стараемся хранить ВСЕ данные в базе данных или насколько это возможно. Таким образом, в будущем, если вы решите, что теперь вам нужно снова присоединиться к датам праздника, список событий (например), все данные находятся в одном месте. Эта сегментация разрозненных слоев создает уровни в вашем приложении. Когда каждый уровень может быть посвящен исключительной обработке ролей в пределах своего домена (база данных обрабатывает данные, презентацию HTML-документов и т.д.), Это снова легче изменить или масштабировать ваше приложение.

Наконец, при разработке приложения нужно учитывать "удар по принципу шины". Поэтому вы, разработчик 'A', помещаете праздники в файл PHP. Вы знаете, что они есть, и когда вы работаете над кодом, это не создает проблемы. Тогда... вы попадете в автобус. Вы вне комиссии. Разработчик "B" приходит, и теперь ваш босс хочет, чтобы даты отпуска изменились - мы больше не получаем президентского дня. Um. Johnny Next Guy не имеет представления о вашем PHP файле, поэтому он должен копать. В этом примере это звучит немного тривиально, может быть, немного глупо, но опять же, мы всегда разрабатываем с учетом масштабируемости. Даже если вы ЗНАЕТЕ, он не будет расширяться. Эти стандарты облегчают другим разработчикам возможность забрать, где вы остановились, если вы когда-нибудь уходите.

Ответ 4

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

  • Разбор файлов медленный. Струнные считыватели, сравнивающие символы, ищущие последовательности символов, требуют времени. Базы данных SQL имеют файлы, но они считываются и затем кэшируются, причем более эффективно.

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

  • Опции: SQL имеет множество встроенных функций, чтобы делать много мощных вещей, от сдачи вещей, чтобы только возвращать результаты x в y.

  • Безопасность

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

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

Ответ 5

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

Ответ 6

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

По многим допустимым причинам администраторы баз данных, например, имеют таблицы значений для перечисляемых значений. Это помогает с целостностью данных и для работы с ETL, в качестве двух примеров того, почему вы этого хотите.

По крайней мере, на Java для этих коротких фиксированных списков я обычно использую Enums. В PHP вы можете использовать то, что кажется хорошим способом делать перечисления в PHP.

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

Ответ 7

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

Если вы знаете, что имеете дело с очень небольшим количеством значений, и вы знаете, что это требование никогда не изменится, поместите данные в файлы и прочитайте их. Если вы не уверены на 100%, не стреляйте в ногу. Работайте с базой данных, и вы, вероятно, будете в будущем доказательством.

Ответ 8

Это большой вопрос. Короткий ответ был бы, никогда не хранить "данные" в файле.

Сначала вам приходится иметь дело с проблемами с правами на чтение и запись файлов, что представляет угрозу безопасности.

Во-вторых, вы всегда должны планировать расширение приложения. Когда массив "праздник" становится очень большим или его нужно расширить, чтобы включить типы праздников, вы захотите, чтобы он был в БД.

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