I have a multi-client level PHP application that I wrote. This application has many database object just like any other PHP app. But since it is a multi-client level app, I have different client requirements every time we on board a new client. There are couple common object (aka accounts) that host most of the client information. But blmost, every time I want to add new client to the database, this new client is going to require a new column in the accounts databases added because they will have some unique data. There are standard required data (ie. account_name, status......), but some data are unique and labeled different based on the client business type.
Currently, what I have to do to accommodate the requirements is
Alter the accounts table and add this new column manually.
edit the PHP script where I display the account information and display the content of the field like so
if(!empty($row['new_filed']))
echo 'Single Client Required Field: ' . $row['new_filed'];
if the field is editable, then I have to add rules to the edit/add form to do a data validation check before save.
I am trying to build a front end tool that will does that automatically for me. This way I can have an admin "not a programer" go the the front end tool and add a new field and that field will be displayed in the selected section of the selected page.
From the front end tool I want to be able to say add a custom field called "brand_c" and make it of a type varchar(100). Then on the page that is called "account_info.php" in the section called "Other" display this field with the label "Brand" only if the client = 'XYZ' so if the data belong to client 'ABC' do not display the data since this column is custom only for 'XYZ'.
I understand this is a wide question but what I am looking for is any help of how such a thing can be build (were to start from?). This is something that most of the big CRM do "ie. Microsoft CRM Dynamic, Salesforce.com ...) have it. How can I architect something like this?
Thank you
The first step you will need to do is design the tables properly, so basically you need to know how to design table to support dynamic fields and the field will be able to validate/handle such such data.
What I did with my application(dynamic application where the UI fields can be configured in the application's admin) is saving the configuration in the database, each time there is a transaction, the page will fetch the configuration for the selected biller and it will generate the required fields. and when the form is submitted, the application will again fetch the configuration and make validation based on the setting in client_field
Account table *Contain information such as account
account_id //primary key of this table
account_name
account_status
Client table
client_id //primary key of this table
account_id //foreign key:account table
client_name
client_status
you can add different column for the client depending on your requirement, but make sure not to add the required UI fields in this table, instead create the table like below
client_field table //will contain table that can be defined/configured
field_id //primary key of this table
client_id //foreign key:client table
field_name //the field name that will appear in the user interface
field_title //appear when on mouseover on the field
field_datatype //this can be text,integer,date,boolean,etc
field_type //field input type: this can be a textbox,datepicker,dropdown list,etc
field_required //flag to indicate whether the field is required
field_display //flag to indicate whether the field will appear/hidden in the user interface
field_defaultvalue //default value to set when the page renders
field_minvalue //minimum value the field will accept: only acceptable when dataytpe is integer/double
field_maxvalue //same as field_minvalue description instead it will check the maximum integer/double value
field_maxlength //max length for the field
field_order //order of the field in the interface
field status //activate or deactivate the field
You can add additional column but you need to make sure it will be fluid and not redundant.
let us say, you have field_type dropdown list, you need to create another table, lets call it
field_dropdown
id //primary key for this table
field_id //foreign key from client_field
dropdown_value //the value that will be used in the dropdown list when selected
dropdown_description //the description that will appear in the dropdown list
dropdown_order //order of the item
dropdown_status //flag whether this record is active/inactive
You might be wondering how to save the data if this is the case, the data must be saved in another table, lets call it
client_information
id //primary key for this table:
client_id //foreign key from the client table
field_id //foreign key from client_table.
value //the value from the user interface
this way, when you save a new client, each field in the client_field will add a new row in the client_information table along with the value inserted by the user
the challenges in designing this kind of application are:
it is quite hard to develop (lots of condition and mapping, and require alot of time)
you will need to properly configure the fields in order for it to properly work
proper system design,architecture, and flow otherwise it will ruin the dynamicity of the system
you will need proper documentation so that you will understand which is which.
the process will be linear for all the clients except if you can alter your own flow by saving them into the database
the PROS for this design is:
once it is finished, you do not require anymore developer to add additional code except for software enhancement such as feature that is not supported when it was released.
the application will be dynamic and adding any field will be easy and maintainable via the admin module
I am not saying this is the MUST DO, but this is my suggestion on how to develop application that requires dynamic data fields, and so far from my experience in developing one, it did work well just as long it is well design and developed.
Instead of adding additional fields as a new column into your accounts table, you could create a new table, say extra_data, with for example the columns account_id, data_label, and data_content. This way you could save as many extra pieces of data per account into that table, and fetch it in account_info.php.
Related
I've posted a few questions on here and have gotten very great help and support. I'm still fairly new to programming and I'm putting together what I thought would be a simple website for the company I work at. I apologize in advance for my lengthy post/question, I just want to be thorough and clear in what I'm asking. My question is more of needing some help getting pointed in the right direction of how to get started and some best practices to be aware of. What I'm working on right now is to create a system where a user can submit a questionnaire/online form to inquire about a specific product (in this case it's a hard money loan product). The way I am planning on setting it up is to have a database with multiple tables (users, user_info, loan_app, property) and connect these together by referencing each other. I've read about table joins and I understand them conceptually but I have no idea how to implement in practice. I've had a hard time finding actual examples.
Specifically, this is what I am doing and how I am thinking it should work (correct me if I'm wrong or if there's a better way to do it):
1- the user (aka the borrower) signs in to the website. The user log in system references the user table where things like first name, last name, user name, password and user ID are stored. I have included an "active" column in this table so that when a user logs in the condition for them to get into the website is that the username and password match AND the user is activated. This way we can control on the back end certain user accounts access. I have this part working.
2- when the user registers, they only fill out the information that creates a new record in the "user" table. I have created a second table called "user_info" that will contain other data like home address, phone number email etc. But I need to be able to associate the correct record with right user. This is my first issue to wrap my head around. My thinking behind doing this instead of simply putting all this information in the user table is that for one, I might keep adding to that table and make it very big, and two for security reasons, I would like to keep the information separate. I don't know if this thought process has any merit to it though. Again, that's why I'm posting this here.
3- The user, once logged in, clicks on a button on their home screen/dashboard that will take them to the loan "pre-approval application" form, which is the questionnaire. On this form their basic information will be echoed/posted from the "user_info" table to pre-populate certain fields like first name, last name, email, phone number, address etc. So going back to #2 making sure I can associate the user with the correct record in the "user_info" table is critical. THEN, there are additional fields that the user has to fill out in order to submit the application/questionnaire. These form fields will create a new record in the "loan_app" table. This table will have a loanid column that is the primary key for that table, and an auto generated/randomized 6 or 7 digit loan number (loannum). The loanid will be a hidden value but the loan number will be like a reference number that is associated with the loan for the life of it and used for later accounting and recording purposes internally, whether or not it actually becomes a loan. The loanid, I'm assuming here, is the Foreign key in the "user" table and the userid is the Foreign key in the "loan_app" and "user_info" tables correct? If so, how do I incorporate being able to simultaneously associate all these records when the loan application/questionnaire is submitted? My thought would be write individual php scripts that does each of these things separately then have a "master" php that includes all of those individual ones that is placed as the form action associated with the submit button on the form.
Thanks for taking the time to read through this. I'd really appreciate any advice or reference material that I can read up on to learn more about this stuff. My job has a pretty crazy schedule and I travel a lot so I don't have the time to take actual classes to learn this stuff formally. I'm pretty much doing this as I go.
Also, I'm using MAMP with mysql, not sure if that helps any or not...
The user table's primary key userid can be the primary key of the user_info table as well, since each user will have only one user_info record, right? A foreign key constraint is good to ensure only valid userids get recorded in user_info.
The loan_app table can contain a denormalized relationship from loanid to userid so that each loan application is associated with a user. Again, use an FK constraint for integrity.
Don't include loanid in the user table - that would mean each user has a relationship to a single loan application. You already have the one-to-many relationship you need in the loan_app table.
Lets say I have a database table containing a list of statuses.
In my apps form, I have a <select> containing options for all of those statuses which a user can select.
Now, lets say there is another table called people which contains a column for status which represents a status that was previously selected from the list of statuses.
And lets say that I have removed a status from my statuses table, but there are still database rows for people with that removed status.
Now in my form, I can no longer pre-select the <select> option for that status because it no longer exists in my statuses table.
So how would I handle this so that it still pre-selects the removed status in the select? Is my only option to have an <input type="text"> and then some type of autocompletion like twitter typeahead? And if so, how would I validate this? Would I check if the status they enter is what is already there and also in the database table statuses?
Any insight would be awesome.
SOLUTION
Since you are using PHP, you could dynamically append the appropriate status value to the end of your list based on the person.
SUGGESTIONS
First, you should be using a foreign key to link the status table to your person table, and not just storing the status string in the person table. Creating this relationship would have kept the referential integrity of your tables and prevented you from deleting current statuses in the first place.
Never delete statuses from your table. If you need to remove a status from the list of active statuses, you should add a bit field to your status table called "IsActive" (or something similar). Then you could query SELECT * FROM status where IsActive=1 for new records while still having all the old values when needed.
I'm working on an app that lets a user create projects custom to the users needs, the project is basically a form that can be submitted by another user.
I want to allow the user to dynamically create new fields (with Javascript) to the project (a basic form) and choose custom values for each field.
And when the project (the form) is ready it can be submitted and the user specified values goes to a database. Then another user can submit the form and the values the original user has chosen are as options for that form.
The values (that are dynamically created by the user) are most likely going to be basic data, like name, phone, email etc. But there is also options for specific data like food, address, etc. I want the user to be able to ask for any data he/she sees necessary.
So how should I structure my database? I cannot be sure what or how many fields the user is going to choose for his project, i was thinking of doing this app in a traditional relational database, most likely Postgres or Mysql.
So should a create columns for all the data I can think of (or allow user to create) or could this be done in some other way?
You may want to take a look at the EAV model. It has some pros as you will have some flexibility to create whatever structure you want, but it has also some limitations on retrieving and querying afterwards.
Your database should contain the following columns in the table for the form specs:
name (name of the field, used as "name" attrubute of the form's input field)
label (Description to print in the form)
format (if you want to distinguish selects/inputs/checkboxes)
validation (if you want a set of validation rules)
value_type (int/string/date/etc.. - type of value to accept from user. helpful for validation)
I ran into a similar situation with an assessment application. Each assessment asked a number of questions, but periodically, the question set would change. Rather than creating a separate table with key/value pairs for the questions and answers, I took advantage of serializing in PHP.
Determine what data must be a part of every form (Id, submitter, submission datetime, name of project, phone) Make those data elements columns in your table.
Create an additional column for the serialized data. This is where you store the additional attributes.
(Only 1 table needed)
When it comes to displaying the form, use the serialized data to build the additional form elements that are needed.
With this model, it is difficult to search the additional data that gets stored in the serialized data, but it simplifies the development; with thousands of records, and over 100 'questions' per assessment, we haven't run into an issue yet.
One possible option:
table: inputs
Description: Stores different types of inputs (select, select multiple, input, checkbox, radio)
Fields: inputtypeid (primary), input_type, status
table: fields
Description: Stores individual fields that the project owner has created.
Fields: fieldid (primary), inputtypeid (ref inputs), label
table: values
Description: Stores values (default and user submitted) for fields.
Fields: valueid (primary), fieldid (ref fields), value, default (bool yes/no)
table: project_forms
Description: Stores a list of fields that apply to the project.
Fields: pfid (primary), projid (ref project), fieldid (ref inputs)
One side note here. Make sure you take care not to let users store personally identifiable information into something like this. Or if you do, make sure you take the necessary precautions to safeguard that data, which is a bit different in this setup than in most cases.
I am currently working on a system that would allow users to add additional custom fields for the contacts that they add.
I wondered what is the best and most efficient approach to add such ability?
Right now what I was thinking was to have 1 table per users (with foreign keys to a "main" contacts table) and then adding a column for each custom fields that the user adds (since I don't expect to have more then 100-200 users per database shards [sharding is easy since every users never see each-other's content in this system]), although I am not 100% sure that this would be the right solution for such problems.
Maybe you could try to have one separated table to store a reference to the user, plus the field name and value, this way you will be able to have lots of custom fields.
If you go with Boyce-Codd, you separate the information and store them into a table.
Means one table for all users with a foreign key.
One table per user would lead to hundreds or more tables with possible repeated information.
You need to have one table named USERS that stores the id of a user and fixed info you might want. Then, you could have a CONTACT table, that stores the type of contact user might create, and one matching table USER_CONTACT that matches the user unique id with the id of the contact that was created.
With this, you could have advanced data mining on all the information stored, like nowing how many contacts each user created, who created more, etc...
I have a simple database with multiple tables. I can't figure out how to make cakePHP display the values associated with a foreign key in an index view. Or create a view where the fields of my choice (the ones that make sense to users like location name - not location_id can be updated or viewed on a single page).
I have created an example at http://lovecats.cakeapp.com that illustrate the question. If you look at the page and click the "list cats", you will notice that it shows the location_id field from the locations table. You will also notice that when you click "add cats", you must choose a location_id from the locations table. This is the automagic way that cakePHP builds the app. I want this to be the field location_name.
The database is setup so that the table cats has a foreign key called location_id that has a relationship to a table called locations.
This is my problem: I want these pages to display the location_name instead of the location_id. If you want to login to the application, you can go to http://cakeapp.com/sqldesigners/sql/lovecats and the password 'password' to look at the db relationships, etc.
How do I have a page that shows the fields that I want? And is it possible to create a page that updates fields from all of the tables at once?
This is the slice of cake that I have been trying to figure out and this would REALLY get me over a hump. You can download the app and sql from the above url.
Hah, you figured it out correctly! Cake uses the $displayField variable do decide what to..well, display.
If I remember correctly, by default, cake looks for 'title' and 'name' fields, and if those two are not available, it will simply show your primary key field. Luckily, you can override it the way you figured out yourself ;)
I guess you need to echo $cat['Location']['location_name'] in your view.