I'm pretty new to php and mysql and I'm trying to put together a database that will contain customer details, assign these customers to groups, then assign promotions with unique codes to the customers on a group basis.
I've put together a simple schema http://i.imgur.com/5s2Kq.jpg would anyone be kind enough to give me some feedback, it seems pretty simple but maybe I'm missing some things those with more experience may pick up on.
Am I right in thinking those tables containing relationships with others are junction tables and are created this way:
CREATE TABLE customerPromotions (
customer_id int(11) REFERENCES customers (customer_id),
promotion_id int(11) REFERENCES promotions (promotion_id),
customerPromotions_code_code varchar(12) NOT NULL,
PRIMARY KEY (customer_id, group_id)
)
Any advice would be great, thanks.
CREATE TABLE customerPromotions (
customer_id int(11) REFERENCES customers (customer_id),
promotion_id int(11) REFERENCES promotions (promotion_id),
customerPromotions_code_code varchar(12) NOT NULL,
PRIMARY KEY (customer_id, promotion_id)
)
Related
First of all, I'm from Spain so I'm sorry if I made some mistakes writing. So, I have two problems. It will be better if I give context before. I am not even junior, still learning code, and I thought that it will be a good proyect to create a web page where you can add ingredients, foods with that ingredients, etc. So I decided to start learning PHP and SQL. Now I'm trying to create a database, starting with some ingredients and two kinds of rices. My 1st problem is that I don't know if I need to create a data base for that. The second and main one is that I don't have any idea about how to get this working as I want.
See, First of all I created the table for ingredients´
CREATE TABLE ingredientes(
id int(255) auto_increment not null,
ingrediente varchar(255) not null,
CONSTRAINT pk_ingredientes PRIMARY KEY(id) )ENGINE=InnoDb;
Sorry 'cause it's on spanish :/, but nothing to hard to understand.
So I add some ingredients.
Here the pic showing them
After that I created two tables, and add ingredients to them.
CREATE TABLE arroz_con_pollo(
id int(255) auto_increment not null,
ingrediente int(255) not null,
CONSTRAINT pk_arroz_con_pollo PRIMARY KEY(id),
CONSTRAINT fk_pollo_ingredientes FOREIGN KEY(ingrediente) REFERENCES ingredientes(id) )ENGINE=InnoDb;
CREATE TABLE arroz_cubana(
id int(255) auto_increment not null,
ingrediente int(255) not null,
CONSTRAINT pk_arroz_cubana PRIMARY KEY(id),
CONSTRAINT fk_cubana_ingredientes FOREIGN KEY(ingrediente) REFERENCES ingredientes(id))ENGINE=InnoDb;
Here the picture showing the ID's.
Here
So now I spend a lot of time researching and find out that I can show the names by using this command
SELECT a.id,i.ingrediente
FROM ingredientes i, arroz_cubana a
WHERE i.id = a.id;
And have something like this
At this point, everything is, more or less, working. My issue came when I want to create a data base that keep all the names (arroz con pollo, arroz cubana...) in an only table named as 'rices' to be able to choose a name, and automatically have the ingredients there, without any complication for the user. But, I literally have no idea. I've been coding for hours without any victory on that. And I haven't see anything similar on the web so, if someone tell me how to fix that issue or how to make that idea of a web to keep ingredients and foods, I'll be very greatful.
Your data structure is messed up. SQL is not designed to have a separate table for each ingredient. Instead, you want two other tables.
The first is for dishes:
CREATE TABLE dishes (
dish_id int auto_increment not null,
name varchar(255)
);
You would then insert appropriate rows into this:
INSERT INTO dishes (name)
VALUES ('arroz_on_pollo');
Then you have another table for the ingredients:
CREATE TABLE dishes_ingredients (
dish_ingredient_id int auto_increment primary key,
dish_id int not null
ingredient_id int not null,
CONSTRAINT fk_dish_ingredientes_dish FOREIGN KEY(dish_id) REFERENCES dishes(dish_id)
CONSTRAINT fk_dish_ingredientes_dish FOREIGN KEY(ingredient_id) REFERENCES ingredientes(ingredient_id)
);
Voila! New dishes are just rows in a table, so you can get the names using a SELECT.
Notes on structure:
int(255) really makes no sense. Just use int. The number in parentheses is a width for the value when printing it and 255 is a ridiculous width.
I am a fan of naming primary keys with the table name. That way, the primary key and foreign key typically have the same name.
You should not have a table per dish. Create one table "dish", that includes a column "name". Each row represents a dish. Then create a supporting table where you list the (multiple) ingredients for each dish. Look around for a tutorial on databases, this topic is too large to explain in a stackoverflow question (or several).
And so you do not need to be able to list the table names, the way you were considering. (Which is not something SQL supports directly; different databases provide non-standard ways to do it, but as explained you do not actually need such a feature.)
I have a problem while designing my database and I don't know how to solve it:
i have following table (relevant columns):
CREATE TABLE IF NOT EXISTS `prmgmt_tasks` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(300) NOT NULL,
`project_id` int(11) NOT NULL,
);
What I want: every task has a unique id (autoincrement). The name of the task is not unique, but it should be unique for each project. For example "Design userinterface" can occur in project with id 1 and 2, but not twice in project with id 1. Something like 'unique for: group by project_id'.
Of course, I could check that in every query, but I am looking for a way to model this in the database, so it will allways be consistent, no matter what queries are executed.
Thanks for help!
Create a unique composite index on the combined fields.
CREATE UNIQUE INDEX tasks_name_project
ON prmgmt_tasks (name, project_id);
I am working on a project where I want to allow the end user to basically add an unlimited amount of resources when creating a hardware device listing.
In this scenario, they can store both the quantity and types of hard-drives. The hard-drive types are already stored in a MySQL Database table with all of the potential options, so they have the options to set quantity, choose the drive type (from dropdown box), and add more entries as needed.
As I don't want to create a DB with "drive1amount", "drive1typeid", "drive2amount", "drive2typeid", and so on, what would be the best way to do this?
I've seen similar questions answered with a many-to-many link table, but can't think of how I could pull this off with that.
Something like this?
CREATE TABLE `hardware` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(256) NOT NULL,
`quantity` int(11) NOT NULL,
`hardware_type_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `type_id` (`hardware_type_id`),
CONSTRAINT `hardware_ibfk_1` FOREIGN KEY (`hardware_type_id`) REFERENCES `hardware_type` (`id`)
) ENGINE=InnoDB
hardware_type_id is a foreign key to your existing table
This way the table doesnt care what kind of hardware it is
Your answer relies a bit on your long term goals with this project. If you want to posses a data repository which has profiles all different types of hardware devices with their specifications i suggest you maintain a hardware table of each different types of hardware. For example you will have a harddisk table which consist of all different models and types of hardisks out there. Then you can assign a record from this specific table to the host configuration table. You can build the dataset as you go from the input from user.
If this is not clear to you let me know i will create a diagram and upload for you.
I'm quite new to mysql. I want to make a database in mysql for a school. This database should store teachers' information and give some of these teachers the possibilities to create groups.
So I created a database that contains a table group and a table professeur. Group has many-to-many relationship with teachers and vice-versa which derives another table Group_professeur. Here is a simple structure of the tables:
Professeur:
CREATE TABLE IF NOT EXISTS `professeur` (
`id_professeur` int(11) NOT NULL AUTO_INCREMENT,
`nom_professeur` varchar(50) NOT NULL,
`prenom_professeur` varchar(50) DEFAULT NULL,
PRIMARY KEY (`id_professeur`),
UNIQUE KEY `LOGIN` (`login`),
UNIQUE KEY `MDP` (`passwd`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=103 ;
Group
CREATE TABLE IF NOT EXISTS `groupe` (
`id_groupe` int(11) NOT NULL AUTO_INCREMENT,
`nom_groupe` varchar(255) NOT NULL,
`id_prof_responsable` int(11) NOT NULL,
PRIMARY KEY (`id_groupe`),
UNIQUE KEY `nom_groupe` (`nom_groupe`),
KEY `id_prof_responsable` (`id_prof_responsable`),
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
ALTER TABLE `groupe`
ADD CONSTRAINT `fk_professeur_to_groupe` FOREIGN KEY (`id_prof_responsable`) REFERENCES `professeur` (`id_professeur`) ON UPDATE CASCADE
Groupe_has_teachers:
CREATE TABLE IF NOT EXISTS `groupe_professeur` (
`id_groupe` int(11) NOT NULL,
`id_professeur` int(11) NOT NULL,
KEY `id_groupe` (`id_groupe`),
KEY `id_professeur` (`id_professeur`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
ALTER TABLE `groupe_professeur`
ADD CONSTRAINT `groupe_professeur_ibfk_2` FOREIGN KEY (`id_professeur`) REFERENCES `professeur` (`id_professeur`) ON UPDATE CASCADE,
ADD CONSTRAINT `groupe_professeur_ibfk_1` FOREIGN KEY (`id_groupe`) REFERENCES `groupe` (`id_groupe`) ON UPDATE CASCADE;
Teachers can modify only the group(s) they created(i.e they can insert and delete members from their groups). Also, not all teachers have the right to create and modify groups.
After creating the tables, I was wondering who will give them the appropriate rights to do all these stuffs. I thought about creating an administrator. The admin can give the rights to certain teachers to create and modify their own groups and can also revoke these privileges.
I created a table which will store an administrator but who will give the admin the necessary rights to do these. Which brings me back to square one. And this table might have some relationships with other tables in the database thereby deriving some unnecessary tables.
Anyway I thought about changing the professors table to something general like staffs and adding the admin to the table. And then adding these staffs to the database. That means creating a new staff corresponds to adding the staff's information to the table staffs and then adding this staff as a user to the database. From there I can use SQL functions like GRANT and REVOKE to each user.
I'm not sure if this method is very efficient because these means if the school has 1000 professors then it has 1000 users in it's database.
Is there any efficient way to tackle this problem? Thanks.
Controlling application user access using the built-in MySQL notion of a user is unorthodox. For a basic application, I would recommend having another column in the group table for an owner_user_id that would refer to the professor table. Then in the application code, check for that id when the group is being altered.
Good luck!
You'll want to take a look at Role-based Access Control
Another explanation by Tony Marston
I'm working on a real estate site and need to make notification mailer: when new property is inserted on a site, people who subscribed for notification in that particular country and/or area and/or city and/or particular property operation (rental, selling) will receive a notification on email. One person could subscribe for different areas, cities, etc, not only one. One person will receive only one notification a week let say if there are new properties for him, though. And I'm thinking on how better to create a mysql table for subscribers in order to easy retrieve them. Table like:
create table subscribers(
user_email varchar(255),
area_id int(4));
is a bad idea, because if there will be let say 100,000 (looking to the future) subscribers and each will subscribe for 10 areas there will be 1,000,000 rows in a table. So, I'm looking for efficient solution to do such task.
If you have additional recommendations, I will like to hear them.
Thanks in advance!
You should use a cross-reference (many-to-many) table. This will make data more normalized:
CREATE TABLE `areas` (
`id` int(10) unsigned NOT NULL auto_increment,
`name` varchar(255) NOT NULL
PRIMARY KEY (`id`)
)
CREATE TABLE `subscribers` (
`id` int(10) unsigned NOT NULL auto_increment,
`email` varchar(255) NOT NULL
PRIMARY KEY (`id`)
)
-- cross ref table
CREATE TABLE `areas_subscribers` (
`area_id` int(10) unsigned NOT NULL,
`subscriber_id` int(10) unsigned NOT NULL,
UNIQUE KEY (`area_id`,`subscriber_id`)
)
And a million rows is not a problem. Especially with a cross ref table.
there will be 1,000,000 rows in a table
So what? mySQL can handle it.
As far as I can see, the way you are doing it is perfectly fine. It's nicely normalized, I can't think of a better method.
Your table looks correct, assuming that user_email is the primary key identifying your users. If so, add to your subscribers table a PRIMARY KEY (user_email, area_id) to indicate that both fields together make up your primary key.
Your concern about duplicating e-mails has little to do with the schema design and more to do with the query you intend to run. That, of course, will depend largely on how your other data are stored, but might look something like:
SELECT DISTINCT user_email WHERE area_id IN (...)
(For a list of area_id values that have seen listings in the past week.)
That's a simple query that could be optimized and improved given the rest of your schema, but it illustrates how easy it is to avoid generating multiple e-mails despite the same person being listed multiple times.
You can make an extra table of the email addresses.
So you only store an ID in the subscriber table and not the same email address over and over again (whereas there might be some optimizations in the database anyway).