I am planning to create a web application that using php-mysql, I created database to provide to store the form results. I create each column for each input fields in the database, It's working fine except that people tell that I'm doing it wrong because the database design that I created is "too static, bulky".
I created these columns: date, name, address, phone, bla bla, service1, service_price1, service2, service_price2, service3, service_price3, service4, service_price4, service5, service_price5, part1, part_price1, part2, part_price2, part3, part_price3.
I think my database columns is too bulky and static especially in the service and part. I'm looking for a better way to design my database and making it viewable in query results. Any advice for me? Thanks in advance
Here is my form sample:
Here is my database structure:
You should split this into multiple tables, one for customers, one for products (services), one for orderItems, and one for orders.
The orderItem table can hold reference to the customer and the list of products in this order, for example:
orderItemId_a : orderId_1 : customerId_a : productId_01
orderItemId_b : orderId_1 : customerId_a : productId_03
etc.
Related
I'm currently working on a project where people can give theire feedback about the website, just like www.usabilla.com. But i'm stuck at designing my database.
I would like to make it possible for users to create matrix radio buttons with a label above them. Something like the second image on this page; https://www.webpoll.org/program/help/Help_QuestionType_GRB.php
Does anyone of you guys have an idea how I should design my tables, including the relationship, to make this happen?
Thanks in advance.
You can create a standard Product table with id, title, description, etc...
and another table called product_ratings with a product_id relationship, user_id (User relation) and 4 more columns as Quality, Efficiency, Price, etc... every of this columns will be an integer or NULL.
Hy everyone.
I'm actually building a job board with CakePHP and a little help for designing the database will be appreciated!
I have a table jobs with differents foreigns keys:
id, recruiter_id, title, sector_id, division_id, experience_id etc.
The associated table (sectors, divisions and experiences) have the same configuration id, name and job_count and sometimes on or two other fields (like company_count for sectors).
So I would like to know if there is better way to design these tables. I thought for putting the three of them in one table named lists with the keys: id, value and list_name. With this configuration I have just one request to do to get all the list and not 3.
My question is what is the "good way" solution ? May be there's another one ?
Seems kind of repetitive to have them in separate tables, when really they're all the same thing - properties of a job, and would have VERY similar table structures.
I would think you could create a single table for "job_properties" or something.
Each property could have a unique slug (if you wanted) or just use it's id.
// job_properties table example
id
slug // (optional or could be called "key" if you prefer)
type // (optional - "sector", "division", "min_exp")
name // (for use on the names of things like "marketing" or "technology")
value // (int - for use on things like minimum experience)
Then each Job would hasMany JobProperty. It would also allow any job to have more than one sector if that is ever needed.
This would allow you to pull based on if a job has a particular property or set of properties and seems overall cleaner and more consolidated while not making it too obfuscated.
I think a found a solution by using a system of taxonomy. I created a table terms which contain the list of all terms that can be associated (sector, division, type of contrat, etc.).
Table terms id, name, type
And I created a second table term_relationships which contain all the association including the name of the model that is associated.
Tabe term_relationships id, ref, ref_id, term_id
"ref" refers to the associated model (example: Job or Applicant in my case), the "ref_id" refers to the associated data (which job or which applicant) and term_id refers to which terms is associated. I think is the most evolutive and cleaner solution.
Thanks all for your help (especially Grafikart from where I get the idea) and hope that this topic can help someone else !
I'm trying to get used to relational active record but things look too complicated for now.
If it's not difficult please point me in right direction.
I have 4 tables.
Users
userID[pk],userName
Cars
car_id[pk],userID[fk to Users],car_nickname,make_id[fk to Makes],model_id[fk to Models]
Makes
make_id[pk],make_name
Models
model_id[pk],model_name,make_id[fk to Makes]
Now input data is userName,make_name,model_name and task is to get car_nickname from Cars table.
Is this possible using relations or should I do it step by step checking makes,models,users for IDs and then puting all IDs into Cars to get car_nickname ?
You can yous only one Model with reliations to all tables. And create one _form.php in the Views, where there will only fields you need.
Some halpfull information. if you save some data into some table and you need saved data id, you caN use $newid = $model->getPrimaryKey(); and assign to new variable , wich will save into other tables.
I think this is short way to solve problem
I've done quit a bit of programming with php/mysql on small scale personal projects. However I'm working on my first commercial app that is going to allow customers or businesses to log in and perform CRUD operations. I feel like a total noob asking this question but I have never had to do this before and cannot find any relevant information on the net.
Basically, I've created this app and have a role based system set up on my data base. The problem that I'm running into is how to separate and fetch data for the relevant businesses or groups.
I can't, for example, set my queries up like this: get all records from example table where user id = user id, because that will only return data for that user and not all of the other users that are related to that business. I need a way to get all records that where created by users of a particular business.
I'm thinking that maybe the business should have an id and I should form my queries like this: get all records from example where business id = business id. But I'm not even sure if that's a good approach.
Is there a best practice or a convention for this sort data storing/fetching and grouping?
Note:Security is a huge issue here because I'm storing legal data.
Also, I'm using the latest version of laravel 4 if that's any relevance.
I would like to hear peoples thoughts on this that have encountered this sort problem before and how they designed there database and queries to only get and store data related to that particular business.
Edit: I like to read and learn but cannot find any useful information on this topic - maybe I'm not using the correct search terms. So If you know of any good links pertaining to this topic, please post them too.
If I understand correctly, a business is defined within your system as a "group of users", and your whole system references data belonging to users as opposed to data belonging to a business. You are looking to reference data that belongs to all users who belong to a particular business. In this case, the best and most extensible way to do this would be to create two more tables to contain businesses and business-user relations.
For example, consider you have the following tables:
business => Defines a business entity
id (primary)
name
Entry: id=4, name=CompanyCorp
user => Defines each user in the system
id (primary)
name
Entry: id=1, name=Geoff
Entry: id=2, name=Jane
business_user => Links a user to a particular business
user_id (primary)
business_id (primary)
Entry: user_id=1, business_id=4
Entry: user_id=2, business_id=4
Basically, the business_user table defines relationships. For example, Geoff is related to CompanyCorp, so a row exists in the table that matches their id's together. This is called a relational database model, and is an important concept to understand in the world of database development. You can even allow a user to belong to multiple different companies.
To find all the names of users and their company's name, where their company's id = 4...
SELECT `user`.`name` as `username`, `business`.`name` as `businessname` FROM `business_user` LEFT JOIN `user` ON (`user`.`id` = `business_user`.`user_id`) LEFT JOIN `business` ON (`business`.`id` = `business_user`.`business_id`) WHERE `business_user`.`business_id` = 4;
Results would be:
username businessname
-> Geoff CompanyCorp
-> Jane CompanyCorp
I hope this helps!
===============================================================
Addendum regarding "cases" per your response in the comments.
You could create a new table for cases and then reference both business and user ids on separate columns in there, as the case would belong to both a user and a business, if that's all the functionality that you need.
Suppose though, exploring the idea of relational databases further, that you wanted multiple users to be assigned to a case, but you wanted one user to be elected as the "group leader", you could approach the problem as follows:
Create a table "case" to store the cases
Create a table "user_case" to store case-user relationships, just like in the business_user table.
Define the user_case table as follows:
user_case => Defines a user -> case relationship
user_id (primary)
case_id (primary)
role
Entry: user_id=1, case_id=1, role="leader"
Entry: user_id=2, case_id=1, role="subordinate"
You could even go further and define a table with definitions on what roles users can assume. Then, you might even change the user_case table to use a role_id instead which joins data from yet another role table.
It may sound like an ever-deepening schema of very small tables, but note that we've added an extra column to the user_case relational table. The bigger your application grows, the more your tables will grow laterally with more columns. Trust me, you do eventually stop adding new tables just for the sake of defining relations.
To give a brief example of how flexible this can be, with a role table, you could figure out all the roles that a given user (where user_id = 6) has by using a relatively short query like:
SELECT `role`.`name` FROM `role` RIGHT JOIN `user_case` ON (`user_case`.`role_id` = `role`.`id`) WHERE `user_case`.`user_id` = 6;
If you need more examples, please feel free to keep commenting.
I have some small issue with relationships with tables as below:
I have created a login and registration script which has the following
table name: members:
fields: member_id, firstname, lastname, login, password
Now i have made another table with this
table name: phone
fields: member_id, phoneid, name, number, prefix, time,total
I want to make a form whereby a admin can select the name of the client from a drop down list, and then add a record such as the number called, number prefix, total time and the amount for that period.
I dont know how to do this, please help me by creating a script or help me how to go about this.
So all the time a admin makes a form on Client A it gets added to a new row on the phone table, then i will just add a call script on the client side where they can see all the records that they have done.
Thanks please assist.
Regards
Your db design seems fundamentally flawed - the is no association between the members and the phone_numbers tables. Add a FK (member_id) to phone_numbers table.
Regards creating the front-end, there are quite a lot of libraries that have data stores (we use ExtJS), and upon flushing the store you can do the persistence with php.
Hope this helps!