Search code examples
phpsymfonydatabase-designconceptual

PHP Project : How to handle general configuration data?

I'm currently starting the conception of a new project that will use either Zend Framework 2 or Symfony 2.

I am currently wondering, as I'm quite a newbie in data modeling and application conception, how to handle general configuration data that wouldn't be linked to my entities. For example, I have constants, numbers, and maybe even texts and medias that should be configurable via an administration and that concerns the whole application, but that is not related to my Model data (for example, the maximum price of products, some general ranges, etc.. that I don't know at all how to store). So, should I :

  • Create a "parameter" table or something related, that would store all my global parameters of my application?
  • Use INI files or YML files (like in Symfony, if I finally use this one) to store my parameters? If so, how to handle them? What are the best practices?
  • Any better solution for that task?

The only possibility I found was with Symfony, using config.yml files or generally YML files to store my general configuration. But what are the best practices for this kind of storage? How to securely manage them?

I hope this question is not too general.

Thank you.

Solution

  • Personally, for most of my bigger projects I use both file and database solutions combined together (and i know a lot of people do that).

    • Configuration table in database to store all parameters that can be configured via CMS / Admin Panel.
    • One bigger INI / YAML file to keep base configuration of the application.
    • Many smaller INI / YAML files for modules / functionality / routes etc.

    These INI / YAML files are kept out of code versioning, changed rarely and also cached.

    For getting these values inside code i use only one ConfigManager class with priorities like database value -> partial file value (dependant on module etc.) -> main file value.

    P.S. YAML (native for Symfony) is really good, i wouldn't be changing it to INI if i had it already implemented.