I am creating an affiliate tracking system and am looking for the best database structure to use on mySQL for low load on the server.
There will be 1000 affiliates. Each affiliate will have stats per day.
I am thinking of this scenario. One main table for the affiliates:
Affiliates
id affiliate_id username password and so on (other affiliates details)
1 0000001 johndeer password
... and creating a new table for each affiliate which will have store his statistics like this:
Table name : affiliate-userid
Date Clicks sales sale_price total_earned bonus
12/12/12 45 2 20 40 0
12/13/12 12 3 20 60 0
So in this case each affiliate will have his own statistics table.
Is this correct or do I need to do something else?
Create two table
Affiliates(af_id(pk),*) and
Stats(stat_id(pk),af_id(fk),*)
Then, Refer Affiliates table in stats table. you can add any number of stats for any number of affiliates. No need to go for a table for each affiliate. It's a bad Idea.I think you understood.
Related
I'm using MySQL with InnoDB tables.
I have a USERS table like this:
ID MONEY APPLES
1 10 5
2 500 0
USER 1 selling 1 apple to USER 2. (1 apple costs 50 money.)
How to do it safely in MySQL?
You will want to wrap the two UPDATE statements required in one TRANSACTION
see http://dev.mysql.com/doc/refman/5.6/en/innodb-transaction-model.html
I was trying a set up for my tables, which seemed simpler to me, but I am not managing to find the proper way.
This is to calculate after sales costs for vehicles where each vehicle will receive one of each of a sub-group of services from a price list to make up the total after sales cost.
Please see the scenario below:
Table AfterSalesPriceList would be like:
as_id as_description as_value
1 service kit1 1000
2 service kit2 1500
3 service kit3 2000
.......
10 repair kit1 5000
11 repair kit2 8000
12 repair kit3 9000
.....
21 pneu 1 1500
22 pneu 2 2500
23 pneu 3 4000
.....
31 battery 1 500
32 battery 2 800
33 battery 3 1000
Now, in another table? I would place which of these services each vehicle will receive.Each vehicle has to have one and ONLY 1 of each item from service, repair, pneu, battery,etc, like in a Table VehicleAS:
vehicle_id 1 service kit1, repair kit 2, pneu 3, battery 1
vehicle_id 2 service kit2, repair kit 2, pneu 1, battery 2
etc.....
Of course, this does not work in mysql, at least far as I know.
Is there a way to do this in mySql without the need to break apart Table After Sales in multiple tables, one for each subset (one for service, another for repair, another for battery, etc).
It will certainly work with exploding the AfterSalesPriceList Table, but I am trying to make it what seems to me more logical, ie, have all After Sales prices in a single table.
Thanks
It's a one to many relationship. Both tables will have primary keys. The child/many table will have a FOREIGN KEY column whose value will point back to the primary key in the parent/one table.
You'll find all the children that belong to the parent by doing a JOIN on parent primary key and child foreign key.
Table AfterSalesPriceList seems to be OK.
Your another Table VehicleAS however can have
vehicle_id, as_id FOREIGN KEY (as_id) REFERENCES AfterSalesPriceList(as_id)
it can have multiple rows for a vehicle_id for each service it has used.
I would like to create a relational database in which there are two tables Users and products. Each item of each table can be related to many items of the second table.
My current implementation is as follows:
Two main tables-
->Users
User ID
UserInfo
->Products
Product ID
ProductInfo
Two different lookuptables
->UserToProduct
UserID
ProductID
->ProductToUSer
ProductID
UserID
Each time a relation from a user to a product is added, i just add an extra row to the first lookup table, and vice versa.
Is this the right way to do it? Are there any standard models for such scenarios that I can refer to?
You don't need two lookup tables, all you need is users_products. As far as resources, there are zillions, just google "database many to many".
UPDATE
Consider this data:
products
------------
id info
------------
1 car
2 flute
3 football
users
------------
id info
------------
10 bob
20 tim
30 manning
Now, as a simple example, let's say manning owns a football and and a car. Let's say tim owns a flute and a football. Now here's your lookup table:
users_products
----------------------
user_id product_id
----------------------
20 2
20 3
30 3
30 1
That's it. Now you can do queries like "give me all the users that have cars", or "give me all the cars that a user has", etc.
Cheers
You really don't need or want two different lookup tables. You should just have one (either of your tables, UserToProduct or ProductToUser, would be fine). The primary key of the lookup table should be a composite key consisting of both ProductID and UserID.
I am maintaining record of expenses an expenses table looks like this
Expenses(id,name)
Expenses_data(id,amount,expense_id)
Expenses are based on years, lets say 10 years and i am saving it as months, so it would 120 months
If i would have 10 expenses then expenses_data would have 120*10 = 1200 Rows
I want to save it from 1200 rows to 120 rows and data would be like this as i enter in excel
id month marketing electricity bank charges
1 month-1 100 200 300
2 month-2 95.5 5000 100
Please suggest if it is possible and how ?
I think you probably what to stick to the database structure you already have, but use a query to display the data in the format you wish.
If you think about the number of data-points you're storing, there's not much difference between your sought schema and what you already have -- it's still 1200 data-points of expenses. Having to upgrade your schema each time you add an expense column would be pretty invasive.
Sticking with a query for your excel export would allow the database to understand the concept of expense categories, and updating your export query to include the new category would be much easier than modifying the schema. The necessary JOINs could even be calculated programmatically by iterating an initial query of "What Expense Categories are known?"
QUESTION: Is it okay to have "shortcut" identifiers in a table so that I don't have to do a long string of joins to get the information I need?
To understand what I'm talking about, I'm going to have to lay ouf an example here that looks pretty complicated but I've simplified the problem quite a bit here, and it should be easily understood (I hope).
The basic setup: A "company" can be an "affiliate", a "client" or both. Each "company" can have multiple "contacts", some of which can be "users" with log in privileges.
`Company` table
----------------------------------------------
ID Company_Name Address
-- ----------------------- -----------------
1 Acme, Inc. 101 Sierra Vista
2 Spacely Space Sprockets East Mars Colony
3 Cogswell Cogs West Mars Colony
4 Stark Industries Los Angeles, CA
We have four companies in our database.
`Affiliates` table
---------------------
ID Company_ID Price Sales
-- ---------- ----- -----
1 1 50 456
2 4 50 222
3 1 75 14
Each company can have multiple affiliate id's so that they can represent the products at different pricing levels to different markets.
Two of our companies are affiliates (Acme, Inc. and Stark Industries), and Acme has two affiliate ID's
`Clients` table
--------------------------------------
ID Company_ID Referring_affiliate_id
-- ---------- ----------------------
1 2 1
2 3 1
3 4 3
Each company can only be a client once.
Three of our companies are clients (Spacely Space Sprockets, Cogswell Cogs, and Stark Industries, who is also an affiliate)
In all three cases, they were referred to us by Acme, Inc., using one of their two affiliate ID's
`Contacts` table
-----------------------------------------
ID Name Email
-- -------------- ---------------------
1 Wylie Coyote wcoyote#acme.com
2 Cosmo Spacely boss#spacely.com
3 H. G. Cogswell ceo#cogs.com
4 Tony Stark tony#stark.com
5 Homer Simpson simpson#burnscorp.com
Each company has at least one contact, but in this table, there is no indication of which company each contact works for, and there's also an extra contact (#5). We'll get to that in a moment.
Each of these contacts may or may not have a login account on the system.
`Contacts_type` table
--------------------------------------
contact_id company_id contact_type
---------- ---------- --------------
1 1 Administrative
2 2 Administrative
3 3 Administrative
4 4 Administrative
5 1 Technical
4 2 Technical
Associates a contact with one or more companies.
Each contact is associated with a company, and in addition, contact 5 (Homer Simpson) is a technical contact for Acme, Inc, and contact 4 (Tony Stark) is a both an administrative contact for company 4 (Stark Industries) and a technical contact for company 3 (Cogswell Cogs)
`Users` table
-------------------------------------------------------------------------------------
ID contact_id company_id client_id affiliate_id user_id password access_level
-- ---------- ---------- --------- ------------ -------- -------- ------------
1 1 1 1 1 wylie A03BA951 2
2 2 2 2 NULL cosmo BF16DA77 3
3 3 3 3 NULL cogswell 39F56ACD 3
4 4 4 4 2 ironman DFA9301A 2
The users table is essentially a list of contacts that are allowed to login to the system.
Zero or one user per contact; one contact per user.
Contact 1 (Wylie Coyote) works for company 1 (Acme) and is a customer (1) and also an affiliate (1)
Contact 2 (Cosmo Spacely) works for company 2 (Spacely Space Sprockets) and is a customer (2) but not an affiliate
etc...
NOW finally onto the problem, if there is one...
Do I have a circular reference via the client_id and affiliate_id columns in the Users table? Is this a bad thing? I'm having a hard time wrapping my head around this.
When someone logs in, it checks their credentials against the users table and uses users.contact_id, users.client_id, and users.affiliate_id to do a quick look up rather than having to join together a string of tables to find out the same information. But this causes duplication of data.
Without client_id in the users table, I would have to find the following information out like this:
affiliate_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `affiliates`.`company_id`
client_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `clients`.`company_id`
company_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `company`.`company_id`
user's name: join `users`.`contact_id` to `contacts_types`.`contact_id` to `contacts`.`contact_id` > `name`
In each case, I wouldn't necessarily know if the user even has an entry in the affiliate table or the clients table, because they likely have an entry in only one of those tables and not both.
Is it better to do these kinds of joins and thread through multiple tables to get the information I want, or is it better to have a "shortcut" field to get me the information I want?
I have a feeling that over all, this is overly complicated in some way, but I don't see how.
I'm using MySQL.
it's better to do the joins. you should only be denormalizing your data when you have timed evidence of a slow response.
having said that, there are various ways to reduce the amount of typing:
use "as" to give shorter names to your fields
create views. these are "virtual tables" that already have your standard joins built-in, so that you don't have to repeat that stuff every time.
use "with" in sql. this lets you define something like a view within a single query.
it's possible mysql doesn't support all the above - you'll need to check the docs [update: ok, recent mysql seems to support views, but not "with". so you can add views to do the work of affiliate_id, client_id etc and treat them just like tables in your queries, but keeping the underlying data nicely organised.]