Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Dec 2004
    Posts
    3,008
    Rep Power
    376

    Database vs files?


    Ok so I have to create user forms on a regular basis. I have made the steps to automate this task. I have a form () where i get all the info regarding the user form I need.

    From here on I could have gone two ways:

    1, save details into database and then do a query to extract/make the user form

    2. save details into database and then do a query to extract/make the user form AND save it in a file.

    I went the option 2 route because i figured that asking PHP to re-create the form each time will be less efficient than including a file, especially if 1000s of people visit the page.

    Should have posed this question before but recently I have been thinking that MAYBE I should have done option 1. It would have been a bit complicated at first i.e. saving into database not just what fields will be used, but form styling + css too. (currently I create a template for these too!).

    so what do you reckon?
  2. #2
  3. Confused badger
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Mar 2009
    Location
    West Yorkshire
    Posts
    1,118
    Rep Power
    487
    Eh?!???!?!

    Ok, so you have a "create user form" ok, that, when validated and made safe, saves just the data from it into a database (fields like Firstname, surname and so on).

    When your user logs in and clicks on "Edit my details" or whatever, that will need to call a pre-written page, e.g. "edit_user.php". This PHP file will query the database, get whatever info you request from the query and then using PHP will write that data into the appropriate elements on the form.

    Saving the data to a file as well as a database is IMO bonkers.
    You'd have to check the file AND the database every time to see if one is different to the other and then re-create the saved (or cached) version.

    If you want to cache something, look into a proper cache solution such as Memcache or APC - or both - as that is their sole purpose in life.
    "For if leisure and security were enjoyed by all alike, the great mass of human beings who are normally stupefied by poverty would become literate and would learn to think for themselves; and when once they had done this, they would sooner or later realise that the privileged minority had no function and they would sweep it away"
    - George Orwell, 1984
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Dec 2004
    Posts
    3,008
    Rep Power
    376
    no sorry.. if i didnt make it clear. I create different USER FORMS (Landing pages) for different clients.

    Most of the time they all want the same thing (Title, First Name, Last Name and email). SOmetimes they might want slightly different things.

    So I keep the "skeleton" the same but allow the "automation" of the form. so my landing page looks like this: domain.com/index.php?client=someone..

    Now I can query the database each time, get the fields and "Re-create" the form OR create the form once, and then use the template (after all including a file is faster than querying/re-creating a file)
  6. #4
  7. Confused badger
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Mar 2009
    Location
    West Yorkshire
    Posts
    1,118
    Rep Power
    487
    Right, please bear with me as it's difficult to put into words without my usual mad scrawlings on bits of paper ....
    I think you want something like:

    landing.php?client=1
    landing.php?client=2
    landing.php?client=3
    ...
    landing.php?client=n

    Clients have different requirements for their forms ... for example:-

    Client | Name | Address | Telephone | Fax | Email
    1 | YES | YES | NO | NO | YES
    2 | YES | YES | YES | NO | YES
    3 | YES | NO | YES | NO | YES
    ....

    So landing.php would be something like this (presume you've captured the appropriate client's requirements into the $fields array):-
    PHP Code:
    <?php
     
    if ($fields['name'] == "YES") { require_once "form_name.tpl.php"; }
     if (
    $fields['address'] == "YES") { require_once "form_address.tpl.php"; }
     if (
    $fields['telephone'] == "YES") { require_once "form_telephone.tpl.php"; }
     if (
    $fields['fax'] == "YES") { require_once "form_fax.tpl.php"; }
     if (
    $fields['email'] == "YES") { require_once "form_email.tpl.php"; }
    ?>
    You see, if you decide to have a different fully formed form for each client and then their requirements change, it's much harder to administer, let alone write the code for ... your landing.php would change to something like this

    PHP Code:
    <?php
     $client_template 
    $fields['client'] . ".tpl.php";   // Would make something like 1.tpl.php
     // Then you'd need to see if the template file does not exist
     
    if (!file_exists($client_template)) {
      
    // Create the template file
      // ....
     
    }

    require_once(
    $client_template);

    ?>
    Okay ... so that WOULD WORK - BUT the problem is, what if the client changes their requirements?
    The script would need to load the $client_template and compare it to their requirements somehow and THAT will be your problem.
    Sure, in 99.999% times it won't change but that 0.001 time will cause you the headache.

    Does that help?
    "For if leisure and security were enjoyed by all alike, the great mass of human beings who are normally stupefied by poverty would become literate and would learn to think for themselves; and when once they had done this, they would sooner or later realise that the privileged minority had no function and they would sweep it away"
    - George Orwell, 1984
  8. #5
  9. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    bench mark it

    loading from RAM is always quicker than loading from the file system, so it depends how you're storing each form....

    for example if you store a form on the file system are you storing the raw html or a php file of config options for the form (which mirrors what would otherwise be in your database)?

    The raw html version might then be quicker than the database option, but the php files should be slower than the database if the database cache/buffer options are used to optimise storing the data in RAM.

    Then there's server side caching like memcached and APC. If you used APC's opcode cache then the PHP files will be quicker, if you stored a database result in memcached then who knows what!!!!

    There's a lot of optimisations that can be done or that may be in place which makes this question non-trivial.

    Like I said, bench mark it - use apache's ab tool from another server and DOS attack your forms, see which performs better.

    Then there's maintainability.

    I have one form manager script which manages all my forms - I define a form in terms of a nested PHP array and pass this into my form manager and everything else just gets sorted. It's dynamic, easily maintainable and creates less coding errors when measured against number of forms created
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Dec 2004
    Posts
    3,008
    Rep Power
    376
    Thanks guys. looks like I will need to re-think this approach (again!)
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Dec 2004
    Posts
    3,008
    Rep Power
    376
    Originally Posted by badger_fruit
    Right, ....

    ?>
    [/php]
    generally they dont want "full" details. most of them just have:

    first name, last name, email, title.

    Now what i am doing currently is if they want the basic details

    1. creating a raw html template (if another template doesnt exist already)
    2. assigning this to current client
    3. echoing out this in the relevant section (no if statements like you did).

    if they want additional fields, i just create a new template which in future can be used by other clients form if the fields element match up.

    I also choose a form style i.e. how the form elements are laid out, it could be they want

    label -> field OR

    label
    field

    these are predefined styles which i apply to the form.
  14. #8
  15. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    This is where OO can come to the rescue - by extending a base class you can add/remove elements. Your base class may have the first name, last name, email, title.

    you can extend this to add fields "telephone", "position", "company" etc and remove fields, eg "title".

    You'd then pass this off to a form rendering script and probably link the submission to a validation scripts.

    Here's an example of my new user form class

    PHP Code:

    namespace libs\forms;

    class 
    NewUser extends manager {

        public function 
    __construct($account) {
            
    parent::__construct(__CLASS__);
            
    $this->account $account;
        }

        public function 
    getFormDefinition() {
        
            
    $this->form_name 'New User';
            
            
    $form[] = array(
                    
    "label"=>"First Name",
                    
    "name"=>"firstname",
                    
    "required"=>1,
                    
    "input_type"=>"text",
                    
    "data_type"=>"text"
            
    );
            
    $form[] = array(
                    
    "label"=>"Last Name",
                    
    "name"=>"lastname",
                    
    "required"=>1,
                    
    "input_type"=>"text",
                    
    "data_type"=>"text"
            
    );
            
    $form[] = array(
                    
    "label"=>"Username",
                    
    "name"=>"username",
                    
    "required"=>1,
                    
    "input_type"=>"text",
                    
    "data_type"=>"text"
            
    );
            
    $form[] = array(
                    
    "label"=>"Email",
                    
    "name"=>"email",
                    
    "required"=>1,
                    
    "validate"=>"email",
                    
    "input_type"=>"text",
                    
    "data_type"=>"text"
            
    );
            
    $form[] = array(
                    
    "label"=>"Password",
                    
    "name"=>"password",
                    
    'type'=>'password',
                    
    "required"=>1,
                    
    "validate"=>"match:confirm-password",
                    
    "input_type"=>"password",
                    
    "data_type"=>"password"
            
    );
            
    $form[] = array(
                    
    "label"=>"Confirm Password",
                    
    "name"=>"confirm-password",
                    
    "required"=>1,
                        
    "validate"=>"match:password",
                    
    "input_type"=>"password",
                    
    "data_type"=>"password"
            
    );
            
    $form[] = array(
                    
    "label"=>"Account ID",
                    
    "name"=>"account_id",
                    
    "input_type"=>"hidden",
                    
    "data_type"=>"text",
                    
    "value"=>$this->account
            
    );
            
            
    $form = array(
                
    "regions"=>array(
                
    "fieldsets"=>array(
                    
    "_default"=>$form
                
    )
                )
            );

            return 
    $form;

        }

    The manager class contains default methods to filter the data based on direction and datatype (eg html entities for re displaying an erroneous form or password hashing for database input). I then have validation methods so the manager class will automatically call validate::email($_POST['email'])

    In PHP, you can use variable names for function calls or call_user_func_array, so while looping over the form definition and having the submitted data in $_POST, I have this

    PHP Code:
    //
    public function CheckIn() {
            
    $errors 0;

            for(
    $i=0;$i<count($this->form);$i++) {
                
    $valid true;
                if(
    $this->form[$i]['validate']) {
                    
    $a call_user_func_array(array(__NAMESPACE__.'\FormHandler_Validation',$this->form[$i]['validate']),array($this->form[$i]['html_name']));
                    if(
    $this->form[$i]['required'] && !$a) {
                        
    $valid false;
                    }
                    if(
    trim($_POST[$this->form[$i]['html_name']]) != '' && !$a) {
                        
    $valid false;
                    }
                }
                
                if(
    $this->form[$i]['required']) {
                    
    $value trim($_POST[$this->form[$i]['html_name']]) == '' false $_POST[$this->form[$i]['html_name']];
                } else {
                    
    $value trim($_POST[$this->form[$i]['html_name']]);
                }

                if(
    $value === false || $valid === false) {
                    
    $errors++;
                }

                
    $_SESSION[$this->form_name][$this->form[$i]['html_name']]['value'] = $value;
            }

            return 
    $errors == true false;    
        } 
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  16. #9
  17. Confused badger
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Mar 2009
    Location
    West Yorkshire
    Posts
    1,118
    Rep Power
    487
    I think you may have just overdosed the OP lol ....
    "For if leisure and security were enjoyed by all alike, the great mass of human beings who are normally stupefied by poverty would become literate and would learn to think for themselves; and when once they had done this, they would sooner or later realise that the privileged minority had no function and they would sweep it away"
    - George Orwell, 1984
  18. #10
  19. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    You guys might be thinking a bit too conventionally.

    If the form is being dynamically built based on who the client is then how the data is taken into PHP can similarly be dynamic. There's no reason to explicitly handle every possible field.

    In the simplest form:
    - Have your database that lists what fields to present
    - Use that database to custom-build the form
    - Use that database to custom-handle the form input
    - Do something with it
    - Victory

    Then it just depends how far you want to take it.

    Validation?

    If you have form fields that require standard validation logic, include an identifier of that logic in the database on a per-field basis. So when your script takes the data in, it can run the appropriate validation on the individual inputs.

    If a certain custom field really requires a new kind of validation, then you might have to hardcode something new.

    What are you doing with the data?

    If you're just emailing it off immediately or dumping it somewhere as JSON, there's not too much to worry about. If you're storing it in a database then you might want a database schema that's flexible enough to likewise store the data in a more "vertical" way that can tie back to the unique design of each form template. Been there, done that, but it is taking things to another level of complication.

    But to the actual question...
    I think we've wondered a bit; you didn't actually ask about handling the form input, etc. So to what you actually did ask, I'd say just built it dynamically each time.

    Naturally there's added overhead to that but it shouldn't be so much that you'd really notice. Especially if you're only dealing with a handful of form fields. Compare one of your forms to your standard forums tool and you'll see how the latter is having to render a lot more based on looked-up data, and that's done all the time, business as usual.

    And it would save you the additional (albeit minor) concern of having proper write permissions to folders, the number of files becoming unwieldy, etc.
  20. #11
  21. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    I did start out with a database driven form specification.....however, I found attempting to manage things like options, option groups, disabled inputs, fieldsets, nested fieldsets and certain validation methods became tricky and would require an (GU) interface of its own just to manage it, so I stated to spec them out in their own classes - quicker for me to develop.

    If I can a client who wanted a GUI to manage their own forms with this much granularity then that would be when I did the work, and I'd charge for it!

    See rackforms for what a full on form specifying GUI can end up looking like
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  22. #12
  23. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,316
    Rep Power
    7170
    I went the option 2 route because i figured that asking PHP to re-create the form each time will be less efficient than including a file, especially if 1000s of people visit the page.
    So what you've essentially built is a cached version of the page. That's an extremely common practice for improving performance. There is absolutely nothing wrong with that approach unless you customize the generated file by modifying it directly. ie: you should be able to regenerate the file at any time for any reason and not break anything.

    Unless your form generation code is really extensive though, having 1000's of people visit the page wouldn't matter either way unless they're all visiting it at the same time. At that traffic level, more important concerns should be development time and quality.

    the php files should be slower than the database if the database cache/buffer options are used to optimise storing the data in RAM.
    There's enough overhead involved in running a SQL query that loading a file off the disk is almost always faster than loading the same amount of data out of a database. This is generally true though only if all of the data you would get from a particular query all comes from one file. ie: if you have to load 100 separate files to get the same data that a single query would produce, then the database is going to be hugely faster; but if all the data is in one file, then the file will load quicker.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Dec 2004
    Posts
    3,008
    Rep Power
    376
    Originally Posted by Northie
    I did start out with a database driven form specification.....however, I found attempting to manage things like options, option groups, disabled inputs, fieldsets, nested fieldsets and certain validation methods became tricky and would require an (GU) interface of its own just to manage it, so I stated to spec them out in their own classes - quicker for me to develop.

    If I can a client who wanted a GUI to manage their own forms with this much granularity then that would be when I did the work, and I'd charge for it!

    See rackforms for what a full on form specifying GUI can end up looking like
    I think re-reading your original post and this post, it seems ( ok i know I am re-iterating but i am not the expert here ) you have a class called form, then for each new form, you create a new form sub class. everything else stays the same i.e. rendering the form etc..

    how do you then "call" this sub class? i.e. if my file is called index.php, how would I know which subclass to call? i could do it index.php?call='subclass'? or i could have it index.php?client=A and then in index.php i have a logic that says if client=A call sub class?

    Also each form is connected to a "table" in the backend mysql, it also needs a pixel tracking image to be outputted once user submit the form. form needs styling too.. all this will go into the sub class or should i create another class for styling because multiple forms could have same styling?
    Last edited by paulh1983; June 21st, 2013 at 03:40 AM.
  26. #14
  27. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    I think re-reading your original post and this post, it seems ( ok i know I am re-iterating but i am not the expert here ) you have a class called form, then for each new form, you create a new form sub class. everything else stays the same i.e. rendering the form etc..
    yes

    how do you then "call" this sub class? i.e. if my file is called index.php, how would I know which subclass to call? i could do it index.php?call='subclass'? or i could have it index.php?client=A and then in index.php i have a logic that says if client=A call sub class?
    The logic is pretty much how you want it, looking at your position, I'd have something like this

    PHP Code:
    //logic to determine client
    $client '......';

    //logic to determine class from client
    $form_class '....';

    $form = new $form_class;

    $form->Execute();

    if(
    $form->isValid()) {
         
    $data $form->getData();
         
         
    //logic to determin database object based on form or client
         
    $dbobject '....';

         
    $dbobject->create($data);
    } else {
         
    $html $form->render();
         echo 
    $html//?

    I use the twitter bootstrap css and js library to render the forms. As it's CSS based then it can be extended by custom css files. All of the above code could also sit inside a custom html file. Your app, your choice.

    Also, how are you using your tracking pixel?, What are you trying to track? Can't you just know that they've submitted by the fact that they have submitted the form? (silly question, I know but you maybe making life more complicated for yourself)
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  28. #15
  29. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Dec 2004
    Posts
    3,008
    Rep Power
    376
    thanks again northie, One question, the answer is obvious but say if i had created a base form class (title, name, email), then i create a sub-class (telephone, address).. this means that for each "new" form (where fields are not in the base) i would have to manually create a new sub-class? Or could I create a form that creates this class automatically? because the whole idea of this form generation is so that I do not have to waste my time creating forms and instead one of other non-IT colleague can use this "thing" i am creating.

    Re: your question. The tracking pixel is there so that we know the user has submitted the form. This data goes to an external system we have. basically for each "lead" we collect we send it off to our client. tracking pixel i think helps us do rough counting i.e. 21 leads came in today so if the client argues saying it was less we know it isn't. something to that effect.
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo