Я вижу, что программисты вкладывают много информации в базы данных, которые иначе можно было бы помещать в файл, содержащий массивы. Вместо массивов они будут использовать множество таблиц SQL, которые, я считаю, медленнее.
CitrusDB имеет таблицу в базе данных под названием «праздник». Эта таблица состоит только из одного столбца даты, называемого «holiday_date», который содержит даты, которые являются праздниками. Идея состоит в том, чтобы позволить пользователю добавлять праздничные дни в таблицу. Citrus и программисты, с которыми я работаю на своем рабочем месте, предпочитают размещать всю эту информацию в таблицах, потому что она «стандартная».
Я не понимаю, почему это было бы правдой, если вы не позволяете пользователю через пользовательский интерфейс добавлять праздники. У меня такое чувство, что я чего-то не хватает.
Иногда вы хотите создать немного гибкости для продукта. Что делать, если ваш продукт выпущен в другой стране с разными праздниками? Просто подкрепите стол, и все будет хорошо работать. Если это жестко закодировано в приложении или, что еще хуже, жестко закодировано во многих разных местах через приложение, вы можете оказаться в мире боли, пытаясь заставить его работать в новой локали.
Используя таблицы, существует также один способ доступа к этой информации, что, вероятно, делает программу более последовательной и более простой в обслуживании.
Иногда эффективность / скорость – не единственная мотивация для дизайна. Поддержание работоспособности, гибкость и т. Д. Являются очень важными факторами.
Основным преимуществом, которое я нашел для хранения «конфигурации» в базе данных, а не в файле свойств или в файле с массивами, является то, что база данных обычно хранится централизованно, тогда как сервер часто может быть разделен на ферму нескольких , или даже сотни серверов.
Я реализовал в корпоративной среде такое решение и способность изменять конфигурацию в одной точке доступа, зная, что он будет немедленно распространен на все серверы, без заботы о процессе развертывания, на самом деле очень мощный, и тот, к которому мы привыкли полагаться довольно сильно.
Теоретически базы данных разрабатываются и настраиваются для обеспечения более быстрого доступа к данным, чем чтение диска из файла. На практике для малых и средних приложений эта разница незначительна. Однако лучшие практики обычно ориентированы в более широких масштабах. Путем внедрения передового опыта в вашем маленьком приложении вы создаете тот, который способен масштабироваться.
Существует также рассмотрение доступности данных с точки зрения других аспектов проекта. Где большая часть данных в веб-приложении? В базе данных. Таким образом, мы стараемся хранить ВСЕ данные в базе данных или насколько это возможно. Таким образом, в будущем, если вы решите, что теперь вам нужно снова присоединиться к датам праздника, список событий (например), все данные находятся в одном месте. Эта сегментация разрозненных слоев создает уровни в вашем приложении. Когда каждый уровень может быть посвящен эксклюзивному управлению ролями внутри своего домена (база данных обрабатывает данные, презентацию HTML-документов и т. Д.), Это снова легче изменить или масштабировать ваше приложение.
Наконец, при разработке приложения нужно учитывать «удар по принципу шины». Поэтому вы, разработчик 'A', помещаете праздники в файл PHP. Вы знаете, что они есть, и когда вы работаете над кодом, это не создает проблемы. Тогда … вы попадете в автобус. Вы вне комиссии. Разработчик «B» приходит, и теперь ваш босс хочет, чтобы даты отпуска изменились – мы больше не получаем президентский День. Um. Johnny Next Guy не имеет представления о вашем PHP-файле, поэтому он должен копать. В этом примере это звучит немного тривиально, может быть, немного глупо, но опять же, мы всегда разрабатываем с учетом масштабируемости. Даже если вы ЗНАЕТЕ, он не будет расширяться. Эти стандарты облегчают другим разработчикам возможность забрать, где вы остановились, если вы когда-нибудь уходите.
Ответ лежит во многих сферах. Я использовал для кодирования своего собственного программного обеспечения для чтения и записи в свой собственный формат базы данных с плоскими файлами. Для небольших систем с несколькими полями это может показаться целесообразным. Как только вы изучите SQL, вы, вероятно, будете использовать его даже для самых маленьких вещей.
Анализ файлов происходит медленно. Струнные считыватели, сравнивающие символы, ищущие последовательности символов, требуют времени. Базы данных SQL имеют файлы, но они считываются и затем кэшируются, причем более эффективно.
Для обновления и сохранения массивов вам необходимо прочитать все, перестроить все, написать все, сохранить все, а затем закрыть файл.
Опции: SQL имеет множество встроенных функций, чтобы делать много мощных вещей, от сдачи вещей, чтобы только возвращать результаты x-y.
Безопасность
Синхронизация – скажем, что вы одновременно просматриваете одну страницу одновременно. PHP будет читать из вашего файла, обрабатывать и писать в одно и то же время. Они будут перезаписывать друг друга, в результате чего dataloss.
Количество функций, предоставляемых SQL, простота доступа, отсутствие необходимых вам кодов и многое другое способствуют тому, что жестко закодированные массивы не так хороши.
Фактические даты некоторых праздников меняются каждый год. Гибкость для обновления праздников с помощью запроса или с помощью скрипта делает его в базе данных самым простым способом. Можно легко реализовать скрипт, который каждый год обновляет праздники для своей страны или региона, когда он хранится в базе данных.
Ответ зависит от того, с какими списками вы имеете дело. Кажется, что здесь ваш список состоит из небольшого фиксированного набора значений.
По многим допустимым причинам администраторы баз данных, например, имеют таблицы значений для перечисляемых значений. Это помогает с целостностью данных и для работы с ETL, в качестве двух примеров того, почему вы этого хотите.
По крайней мере, на Java для этих коротких фиксированных списков я обычно использую Enums. В PHP вы можете использовать то, что кажется хорошим способом делать перечисления в PHP .
Преимущество этого – это поиск в памяти, но вы все равно можете получить целостность данных, о которой заботятся администраторы баз данных.
Если вам нужно найти одну часть информации из 10, чтение файла или запрос базы данных может не дать серьезного преимущества в любом случае. Чтение одного фрагмента данных сотен или тысяч и т. Д. Имеет серьезное преимущество при чтении из базы данных. Вместо того, чтобы загружать файл определенного размера и читать все содержимое, занимая время и память, запрос из базы данных выполняется быстро и возвращает именно то, что вы запрашиваете. Это похоже на запись данных в базу данных и текстовые файлы – вставка в базу данных включает только то, что вы добавляете. Написание файла означает чтение всего содержимого и повторное завершение их записи.
Если вы знаете, что имеете дело с очень небольшим количеством значений, и вы знаете, что это требование никогда не изменится, поместите данные в файлы и прочитайте их. Если вы не уверены на 100%, не стреляйте в ногу. Работайте с базой данных, и вы, вероятно, будете в будущем доказательством.
Это большой вопрос. Короткий ответ был бы, никогда не хранить «данные» в файле.
Сначала вам приходится иметь дело с проблемами с правами на чтение и запись файлов, что создает угрозу безопасности.
Во-вторых, вы всегда должны планировать расширение приложения. Когда массив «праздник» становится очень большим или его нужно расширить, чтобы включить типы праздников, вы захотите, чтобы он был в БД.
Я вижу, что другие ответы перекатываются, поэтому я оставлю это.