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.
Related
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.
I have one Category List user will select a category from the list if user didn't find a category in the list, then he will select "other" option and it will display a text box there user will enter a new category name. This newly added category will go for approval to Site Admin till then it should be mentioned as "Uncategorised".
So my question is how to achieve this using a mysql table should I create a new table as uncategorized category or should I add one extra column to category table as "isApproved". As the solution should be for both add and edit of new category.
As you described
Admin must approve newly added category.
To acheive that you definitely will have a field status or something like that to check if this category is approved or not. You can simply use that field. If it is not active, it is "Uncategorized.
A more flexible way than adding one isApproved (or rather a more generic name like status) column to your table is to create a whole new temporary table. There are number of reasons why this is the better approach:
You can save diagnostical information like who created this category, when did he create it, and so on.
You separate your logic: An unapproved entry is, simply put, a temporary one. Approving it is nothing more than moving it over to your categories table and thus making it permanent.
Your categories table doesn't get clustered with unnecessary entries.
I didn't know how to give title to this but I have the following database:
accidentDetain(id, location, weather_conditions desc (and few more columns));
weatherConditions(id, title)
acc_weat_cond(id, wc_id, ad_id)
wc_id = weatherConditions ID, ad_id = accidentDetain ID
Now the situation is the user can store multiple weather conditions such as (rain, wet, snow Ice Fog etc)
Let's say user chooses 3 out of those 6 options and those will be stored in acc_weat_cond table, with accident Detail id and weather conditions id.
After saving, the user decided to change and to unchecked one of the option and then presses the save button. The issue is, there are 3 records already stored into acc_weat_cond table how would I would change and make them to two records.
Will I have to delete the first records from the database and then store again newly checked options? Or is there any easier way doing the above mentioned situation.
One last option is that I violate the role of database normalization and stored directly in the accidentDetails table and separate the values with a comma.
Feel free to ask if any more information is required...
I would have an <input type='hidden'name='checkedflds' value='1,2,3' />-field which contained the values that were checked before the user updated. Then after postback, you can compare the new list against this and will easily see what additions he made and which elements he removed...
I would call all of the options and compare to what is checked, and delete what you need. If you store it on the form, then there is a potential for out of date data.
A user can submit his data, after login. There is two tables in mysql: items, categories. Categories has a field: user_id, but in item table, there isn't, every item should belongs to a category.
When a user submitting a category, its fine, i get the user id from session, and inserting it.
When he submits an item, i set the category_id for it.
The problem is, the user can simply rewrite the category_id (javascript, on the frontend, click on a category : set the category_id), and submit the item into a category which is not related to him.
Two solutions what i'm thinking (but i haven't made like this):
When the user inserts an item, i check the category relation, and if it's not the user's one, its exit.
Add the user_id field into the items table too (not looking as a good option).
What is the good way or what's the proper/common solution in this case?
Add the user_id field into the items table too
If you already have the user_id in the categories table, and you're certain that each item has a category, then this is unnecessary duplication, as you suspect.
Check the category relation, and if it's not the user's one, its exit.
That's the way to do it - when you read the category id before inserting an item, make sure that category belongs to the user. Simple. I would probably just show_404(), but it's up to you if you want to show a meaningful error message.
Why not create a user_id column in category table. When user tries to submit entry check the user_id, if it is not that user redirect him wherever you want
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...