I want to develop an web-service where a user can add tickets. Every ticket has got an input text field title and a textarea description. If the user klick the save button, the data will be saved in a mysql database.
The admin has got an admin panel. He can add or remove input fields in this admin panel to change the add ticket view form the user.
For example: The admin adds a select field category. You can select category A, B or C. If you select category A, there will be a new input text field called animal. If you select category B, nothing happens. If you select category C, there will be 2 new fields: A text field and a number field. The number field is required. And so on, and so on. After a week, the admin could remove some fields, or add a category or... To conclude, the admin can add and remove select, text, number, password,... fields to the add ticket section with relationships, length and requirements.
I dont know how to structure the database and to save the data. I think about something like a mysql table tickets with title, desc, and data and put an XML / JSON String to the data field and another table ticketFields with name (category, animal,...), type (text, number,...), required (yes/no), length (int), data (to store data for select fields). The problem is, that the relationships are missing in this model. So how can I save this data efficient?
The relational model might look like this:
Ticket:
id PK
Answer:
ticketId FK PK
fieldId FK PK
value
Field:
id PK,
name,
parentFieldId NULL FK,
parentFieldValue NULL,
type,
required,
min NULL,
max NULL,
range NULL
(...other "constraint" fields, checked regarding choosen type)
At first, fields with parentFieldId of NULL are displayed. Fields having parentFieldId set are shown only if the answer for parent field is given. Fields having parentFieldId and parentFieldValue set are displayed if the answer for parent field is given and it equals parentFieldValue.
Given answer is checked regarding to field's type (e.g. if type is "number" then the answer must be a number between min and max).
You can create another table with id, category and field for the admin to use and relate them both using a common id field, preferably primary key. Now, this table can be queried for the reference of new categories inserted against a particular id in your main table. Use javascript/jquery to dynamically create html code for the new fields and show them on your page.
Suppose your the user selects Option 'A', then the new table can be queried to see if there are any fields set by the admin against the option 'A'. If yes, retrive those fields and show them to the user.
Related
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 designing a site where comments can be added in reply to an initial post and each comment can have attached images (and likely will given the type of content). I'm wondering how I will grab the proper comment ID to insert it into a MySQL DB column in the image table.
So far the db has a table for the initial post with serial as the primary key, the db also has an image table with id as the primary and columns for various attributes of the image as well as a column for the serial of the post images belong to (serial comes from the serial of the item the post is about), I plan to also add a column to that table for the comment ID which will be filled with the ID of the comment they belong to if they don't just belong to the initial post. I'd like to add comments in their own table with ID, info, date and title.
What I'm unsure of is when inserting a comment with attached image, how do I grab the comment ID to insert into the image table comment ID column? Or is there a better way to approach the issue?
Thanks in advance for any advice.
This may not be possible but I'm trying to figure out a solution to link a field from one table to a separate table without having to map an id to a table name in my code.
I've attached a simple image of what I'm trying to achieve.
I have a PRODUCTTYPES table which has a productType field where I would like to enter an id that represents a TABLE (The schema's are different for every table I'm trying to link to). I have another field called productID that would then link to ID of that table. That part is easy to do but the issue is based on the productType in PRODUCTTYPES I need to know which table to query to link the productID to the tables ID.
Is this something that can only be done via code by putting the name of the table in the productType field? For example, instead of productID=2 it would be productID=Shoes
So I created this application, that displays widgets. Each widget is a *.php file that displays different type of data from the mysql database. Also I created a file options.php, that each user can access and they can change the position where each widget is displayed, the height, the color, and the width. (lets say the widget is a div with info pulled out for the database)
The issue I am having is how to store the data to be specific to the user. At this point after the button save is pushed it UPDATES all the rows while each row contains a specific widget options.
For example:
Options table has these fields: [id] [name] [height] [position] [color]. For now all users see the same placement because it is not user specific. I was thinking about storing all the widget names in 1 row with a separator, then all positions with a separator ...but I'm not sure how to do it.
I recommend you to store every field in a different column, is more clear and elegant, use separator in a column to store different values seems a bit nasty.
You can create a table widget configuration where you have different columns for the required parameters :)
If every widget has a different amount of settings ( therefore different amount of columns ) you could make one field blob and pass serialized array there. Other option is to find common fields for every widget and serialize only what is left in separate column.
To make widget settings
specific to the user
just link corrent widget settings row to the user id. Better in same if every user will have personal row with settings.
All of the following is of course if I understood your question correctly.
You want one table for position options:
Divtable:
id - INT (You want this to be Auto Incrementing Primary Key)
Name - VARCHAR
userid - INT
Top - INT
Left - INT
Width - INT
Height - INT
the ID is the primary key, and really should be the first thing
in damn near every MySQL Table...
The name is the name of the Div.
UserId is a foreign key in your table that points to the ID number on the "Users" table.
Then you know which user owns that DIV, you can select all of HIS divs to redraw later easily, etc, etc...
you can get the user id number from the Users table by username (or whatever)...
select ID from `Users` where username='johndoe121'
Lets say it returns 21. Find all of /his/ DIV options now like so:
select * from `options` where userid = '21'
Currently I have a form that submits an image with textfields such as
title, description and another field that autoincrements for imageID, another
area for the actual file , called vfile, and *** another part that has
3 checkboxes and a text field.
Everything works fine, and this is what it does. Submits the data to a database so that it can pull the information to a page on the website.
The only part I am trying to update is:
The 3 checkboxes and the textfield.
Lets say the first checkbox reads: Apples
The second : Oranges
The Third: Grapes
And in the other category is a blank textfield that if you add something, it would add it to a category called "Other".
So the database design has 4 fields: 1 - apples, 2 - oranges, 3 - grapes, 4 - other.
When I click a checkbox, it would add checked to the database under the correct one, either apples, oranges, or grapes.
If I add a field to the textbox such as: Bannanas, then it would add "Bannanas" to the database field vother and show that in the database.
This is all fine, but what if the next picture has all 4 items, plus another one? Such as if the next picture had Apples, Oranges, Grapes, Bannanas, and Plums?
How could I have the "Bannanas" other category, change into a checkbox category that could be chosen for the next pics when I go to the add images page next time.
So that when I go to the second picture to submit, it would give me the option of not just 3 checkboxes, but 4 checkboxes now, that I could check the first 4, "Apples, Oranges, Grapes, Bannanas" and then put Plums in the other category.
Basically upon submit it takes what is in the other feild and addes a new category to the database, which is then displayed in the array of checkbox choices and it is removed from the Other Category now, for it is a checkbox. (thus it would not want the value left in the old field, for it would keep creating the same category over and rewriting the old data possibly.
Anyway, any suggestions?
Thanks in advance.
(It sounds like this is more of a database design question and not a php question, but I may be misunderstanding what it is you are looking for advice on)
It sounds like you are saying that these attributes (Apples, Orange, etc) are stored as columns in your main table; but the situation you are describing sounds more like Tagging. Typically you would maintain a list of things that get tagged (your images), and a separate list of all possible tags (Which would be a table containing the rows : Apple, Orange, Grape). Your UI has the option to select from pre-existing tags (rows in the tag table) or add a new tag using the "Other" box. New tags would be added as a new row to the tag table. Since tags and tagged items have a many-to-many relationship you would create a third table (called a join table) that stores keys of tagged items and keys of tags; that way you can select either side of the relationship easily : get all the tags for a given item; get all the items with a given tag.
Does that help?
(EDIT : for comments)
So, Activities sounds like the list of Tags. If I want to show a form with checkboxes for all the Activities I can query the activities table for them. Each of those checkboxes can have a name attribute or something that captures the ID of the row that its bound to.
Also I would select from the join table the ids of the tags that my currently viewed image has selected. As I am populating the checkbox list I can check this result set to see if the id of the checkbox I'm putting on the page is in the list of tags for the image.
To store this back to the db on submit, the easiest thing is probably to (in a transaction) delete all the entries for the image from the join table and replace them with new entries based on the state of the check boxes in the form.
Drop the apples, oranges and grapes columns.
Create a second table with two fields: imageID and itemtype.
Don't make any of the two a key. Now you can list as many different types of items for each image as you need. It will be comparatively expensive to get the list of item types in use from the database but unless you have millions of items this shouldn't be a problem. (Mikeb is suggesting to keep the list of item types in use in a separate table to speed this up.)
The alternative is to dynamically add a column to the first table for each item type you encounter. This will create a very sparse table. I wouldn't do this.
You need to change your database schema to support an infinite number of attributes.
You should move your list of attributes from a set of fields in the record to a list of related records in a new table. This new table requires 2 columns. The first is the primary key from the existing table so you can establish the relationship between the tables. The second is the attribute field ('Bananas' or 'Apples' or 'Plums', etc.) You can have as many records in the attributes table as you like for each record in your main table. You could also have no attribute records if none are checked.
This kind of relationship between two tables is called a one-to-many relationship.