I have a table for storing the postman coverage area. It has two fields
postmanid
covering_pincode
What i am going to implement is, when a user enters a pincode in the textbox, the list of the postman covering that pincodes are displayed.
My doubt is, how can i enter the values in the table
1. Multiple pincodes stored in single row like
postmanid->1, covering_pincode-> 626123, 626124, 626432, 654564
OR
2.Storing each pincode by each seperate fields like
postmanid->1, covering_pincode->626123,
postmanid->1, covering_pincode->626124,
postmanid->1, covering_pincode->626432,
postmanid->1, covering_pincode->654564
Please help which one is best for searching the table by pincode
The rules of normalisation say: use the second one!
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
I'd store each one as a separate row in your table, this would make it easier to add/edit/delete new values without having to append to or extract individual pin codes.
Use a compound key on the database table and you won't need a primary key and shouldn't have duplication.
What you really want is a second table
covering_pincodeid->1,postmanid->1,convering_pincode->626123
covering_pincodeid->2,postmanid->1,convering_pincode->626124
covering_pincodeid->3,postmanid->1,convering_pincode->626125
Related
i am creating plugin in wordpress for contact us form and in that i am creating fields(textbox,textarea etc...) dynamically based on my requirement. so there is no fixed number of fields. i am storing dynamically created fields in my db table.
in some project i may require to create 3 fields and some project i may require to create 5 fields.. my dynamic form is working fine...
now my problem is DB. how do i create table to store contact us data? bcz sometimes there might be 3 fields and sometime there might be more than or less than 3 fields..
so my question is how do i make my table schema for this scenario...
suggestion will be highly appreciated...
Thanks in advnce
Change table structure is strongly not suggested, it's bad in performance, and may lost data if you drop a column.
So, the original subject 'make db table field dynamic' is possible but not a good plan, we still have alternative plan:
Store dynamic field in one table column
Find a way to combine your dynamic field to a string, either use a separator, or use json_encode works, if the column is long enough (TEXT --> MEDIUMTEXT), you can have unlimit dynamic field.
Create enough column at beginning
Apearently this not as good as upper plan, but it's easier to understand, and search in these column is easier too.
BTW, Have you considered convert these dynamic column to rows ?
You need to store the information taken from the form in one table field using an array. That way it should not matter how many question there are.
Should be quite simple take a look at php arrays.
You can have a single longtext datatype column in your database table and you just need to serialize your form values and store in the single column.
I agree with the others. Dynamically creating database tables is bad. The database schema should hardly ever change once a project is complete.
One solution is:
If you had a contact with multiple addresses, you create a parent/child relationship as follows. Perhaps you can do something similiar with your situation.
Contact
long contactID primary key
name
addressID
Address
long addressID primary key
long contactID foreign key
streetAddress
CityID
CountryID
i don't think so it's a good idea to do like this... but i am suggesting you this because in your case it might be useful
you can do it by ALTER...
so what you can do is "When you are creating new field dynamically at that time only you can create new column in your table like this...
ALTER TABLE table_name ADD $name(Column name) //$name may be your attribute name <input name="">
and same way when you are deleting your field at that time you can drop your table column
ALTER TABLE table_name DROP $name(Column name) //$name may be your attribute name
here i assumed that you have already created table table_name (without any fields)
hope it may help you
I am working on a web application that manages the clients of the company. Details such as phone, address, email and name are saved for each client and there are corresponding fields in the database table where I save these details.
The user of the application has to be able to change the different details. For instance, he might decide that we need an extra field to save the fax number of the client or he may decide that the address field is no longer needed and delete it.
Using NoSql is not a option. I have to use PHP and mySql.
I have been considering using a JSON string to save database table fields but I have not come up with a solution yet.
Is altering the structure of my db table the only solution to my problem? I would like to prevent dynamically altering the structure of the db table, if possible.
Would it be a could idea to implement dynamic views? However, I guess that this would not address the necessity to insert new fields.
Thank you in advance.
Wouldn't it make more sense to have another table, let's call it 'information' which has the user_id as a foreign key?
So you have:
CREATE TABLE user (
user_id ...
/* necessary information */
);
CREATE TABLE information (
user_id ...
information_type /* maybe enum, maybe just string, maybe int, depending how you want to do that */
information_blob
);
You then retrieve the information with JOIN, and do not have to alter the table every time somebody wants to add another bit of info.
What you need a key-value pair system for MySQL. The idea of NoSQL databases is that you can create your own schema based on key/values, using essentially anything for the value.
Create a table special_fields with a field_name column, or something named more specifically to field names. Use this table to define the available field names, and another table to store the client_id and special_field_id and then a value.
So client #1 would have an address (special_field record #1) value of "123 x street"
The only other way I can think of is to actually change the schema of a table to add/remove columns. Don't do that.
Trying to store the terms of a search. I've created a table "Searches" which stores each of the search terms in it's own field (bedrooms, baths, etc). So each row will contain one search.
On the advanced search form, users can select multiple search terms for a single field using an option select. I thought it would be wise to store each of these terms in a unique row of a related table for easy statistics reporting. I thought this way I could quickly report how many times a term is searched for. I also need to have the ability to save and regenerate the search query.
However if none of the terms searched are in the main table, I still need to generate a unique id to link it to the related table. So I would need to insert a blank row to generate the foreign key which I'm reluctant to do.
Is there a better way? I could store the multiple search terms questions in the primary table comma separated but it seems like it would be more difficult to pull them back out and count for statistics etc.
Why do you need to insert a blank row? You don't need to persist any of the records until the time comes to persist all of the records, right?
So as I understand it, your table layout is something like:
Table1
--------
ID
etc.
Table2
--------
ID
Table1ID
etc.
If that's the case, then the order of operations for inserting the data would look like this:
Begin Transaction
Insert into Table1
Get the last inserted ID
Insert into Table2
Commit Transaction
Assuming I understand your UX correctly, this would all happen when the user submits the form.
if i understand you,
it seems like you should have two tables:
search_term
-----------------
term_id
term
and
search
-----------------
search_id
term_id
then you can query search for all the terms and issue the SELECT statement.
Im wondering if someone could help me out with a little issue im having.
I have some code which enables a user to click a button and it will create a additional file input box ... The amount of times they can click this is unlimited, so realisticly they can add unlimited images to their profile.
The problem im having is im not sure how to go about saving that information to the database, usually i would add a row for a file input and store the name, but as there can be unlimited amounts of filenames, im not sure how i would go about saving it.
Could anyone out there give me some suggestions on how they would do it?
Thanks
I would store additional pieces of information in a separate table. It only needs 2 fields, data and user_id, Then for each additional input, you would store the data and the user's unique user_id. To retrieve the data, just filter using the user_id.
Usually it's doing using 2 tables and foreign keys. One table with users(user) (id, name, ...). Second table with photos of users(user_photo) (id, user_id, photo_path, ...). Foreign key will be created between user.id and user_photo.user_id with cascade delete/update.
I'm sorry if this a stupid question, but I am new to this. I want to store all the information from all my customers' different contact forms in a database so they can retrieve the information later. Each contact form has a different number of fields. Ideally I'd store all of this info in one MYSQL table, but as I said each customer's contact form has a different number of fields.
I was thinking of creating a database with the following fields
ID, customerID, dateTime, data
The data would be the html of the contact form. However I am sure that's not best practice. Also it wouldn't allow me to offer a download option to the customer of all their contact forms as a csv or similar.
I don't want to have a different table for each customer either, and I am sure having a table with 'field1', 'field2', 'field3' etc isn't that good either.
Any ideas?
If you don't need it to be relational, that would be fine. You wouldn't be able to query it very easily.
You could store the answers in another table using keys to link back to the form and field.
Or use a KeyValue store type DB like MongDB, and you could store all your data without worrying about the schema.
Make another table called user_data. In it, have:
id, user_id, data
Then, if they fill out a form with 10 fields, you can enter 10 entries into this table. When you pull data for the user, just also pull any data from the user_data table that has user_id = their id.
If you need more than that, you could also add a "field_name" field or something:
id, user_data, field_name, data
You can use the MySQL database to have a schema for your desired information that relates many tables to one another.
Here is another discussion about database design:
Database Design Best Practices
If you must have only one table, the other choice I would mention is to have the ID created automatically, and then make the fields be not required. This way when a customer fills out one form before the other it won't mess you up. You can then store the ID as a Session Variable and reuse it for different INSERT statements to your database.
You can make a download function for the customer that will output in the desired format that queries your table and then generates the file.