How can I create a networking system where
User A registers person 1 and person 2 in a week and he gets a matching bonus and then when person 1 registers another two people User A gets matching bonus from those two people.
How can I structure the database???
I'm finding it difficult to structure the database. Please can anyone help me?
This is a diagram showing what I'm actually talking about
Diagram 1
Diagram 2
Normally I would assign any bonuses the moment a person get registered. The algorithm assigning the bonuses has to deal with the complexities, not the structure of the database.
Using an algorithm for this is also more flexible, because you can change, and test, the algorithm without changing the structure of the database.
A basic setup for the database could be:
Table USERS:
UserID
Name
RegisteredByUserID
1
person A
0
2
person 1
1
3
person 2
1
4
person X
3
5
person Y
3
Table BONUSES:
BonusID
RewardedToUserID
ForRegisteringUserID
Amount
1
1
2
2,500
2
1
3
2,500
3
3
4
2,500
4
3
5
2,500
This is a very crude example. Basically when a new person is registered an algorithm sorts out which bonuses have to be given to which users and these bonuses are stored in a table.
The 'BONUSES' table can then be used to compute the total bonuses given to each user, and the total of bonuses given out for registering an user.
Related
As part of an online text based game, I will be simulating game events for a cricket game (or you can consider baseball). There will be an event generated for each delivery bowled (or pitch). Events will be of the type 4 runs, 2 runs, wickets, etc. For each event, there will be multiple players involved, bowler, fielder and batsman.
The design that I have in mind is such:
**Table 1 - MatchEvent**
EventID
EventType
BowlerID
BatsmenID
FielderID
**Table 2 - Commentary**
CommentaryID
GameID
Innings
DeliveryNum
EventID
The concern that I have is that, there will be at least 600 rows per match simulated.
Is there a better way to design the table, considering that I need to replay the results to the users per delivery.
I'm working on some sort of social network these days, and I'm wondering how I can store the user connections in a database.
The structure I've been thinking of looks like this, and it suits me pretty good. I guess it's against the third rule of DB-normalization, but I don't see a better way to store the connections since there will be a big amount of users (hopefully ;) ) and it doesn't make sense to create a new column for every new connection.
table-name: tbl_users
user_id username connected_users
---------------- ---------------- --------------------
1 Freak 2,4
2 Banana 1,3,5
3 MacKing 1,2,4,5
4 Nightmare
5 Dreamer 2,3
... ... ...
What I'm looking for is:
- a way to add and/or delete single values from the 'connected_users' column (for example when a user is on another user's profile and clicks the button 'connect-with' or 'delete-connection')
and to find connections, for example when a user writes a post (button 'new-post'), to find all the authors current connections and save them to my other table: 'tbl_blogposts' (seems strange, but I want those current connections to be stored within the post and never be changed again, no matter whom the author is connected to, later):
table-name: tbl_blogposts
post_id author connected_users
---------------- ---------------- --------------------
1 1 2,4
2 3 1,2,4,5
3 3 1,2,4,5
4 5 2,3
5 2 1,3,5
... ... ...
or
- a better way to store all these connections
Not sure exactly how I should be setting this up as far as databases go.
In words what I need to do is query one funding source from either my credit cards table or my bank account table. There can only be one funding source between the two tables. So I am thinking do I need a lookup table?
Here is what I am thinking for tables:
table 1
id user_id credit_card_num
1 22 2222222222222222
2 55 3333333333333333
table 2
id user_id bank_account_num
1 22 2323232323232323
2 55 2323232234323423
table 3
id user_id funding_source_id type
1 22 1 1 (or CreditCard table)
2 55 2 2 (or BankAccount table)
So again a user can only have one funding source, which could either live in the credit card table or bank account table. Is this needed?
And for the Laravel crew. If this is correct is there an Eloquent relationship that would work for this? From what I am seeing in the Documentation I don't think so.
Please give me your advise.
Citti
I'm coding a Classified Ads web application. The application has several types of Ads:
General ads(electronics, toys, pets, books...)
Real estate (houses, apartments, terrains...)
Vehicles (motocycles, cars, vans, trucks...)
Each type has several common fields (id, title, description) and also some that are exclusive to its kind:
General Ads (no exclusive fields)
Real estate (area, type-of-property...)
Vehicles (type-of-vehicle, cubic-capacity, kilometers...)
What is the most recommended approach to this situation?
A table that contains all fields and leave empty the fields that
don't apply to the current recordset.
A main table with the fields common to all Ads, and an additional table for each type of Ad that has exclusive fields.
One table for each type of Ad.
Other
I would build a solution depending on various criteria :
If you believe the table will be large in the future (a lot of ads to be published), you may want to minimize the number of JOINs for better performance => option 1. "one table with empty fields when not relevant to ad type"
Previous comment applies especially if your data storage cost is low.
If you have to query the data against certain field values (e.g. house size, car kilometers), you might avoid the solution described by phpalix (ad_type | property | value) or Andy Gee since your SQL syntax will be a nightmare, and prefer to have all your data in the same table (again).
If there are A LOT of custom fields per ad type, you might prefer to separate each ad type in their own table, for easier maintenance and data storage optimization. Then you can either JOIN or UNION to query your ads lists.
I'll add to my answer if i think of something else.
You can normalise (a table for the abstract concept and a table the the specialised one) or denormalise (a table with all the fields)
As always, the choice must be done according to the cost of each solution, reprensented by the speed of the queries (normalised model means more joins (buffer/cpu) whereas denormalised more disk reads usually because the columns are sometimes retrieved when it is not necessary) or the storage required in both cases.
All solutions are acceptable and a matter of preference, performance, complexity and design needs. The terms for what you are discussing are Table-Per-Type, Table-Per-Class and Table-Per-Hierarchy. If you google on these you are guaranteed to get a ton of Entity Framework results, but the underlying design considerations are much the same.
For flexibility I would have all the field in a separate table then allow the assigning of each field to each ad type. This would also allow you to add and remove fields easily at a later date.
Each field may have different types of data so this information should also be in a separate table.
Something like this (not very clear sorry)
Table: fields
field_id, field_type, field_name
1 1 title
2 1 price
3 2 size
4 3 description
5 1 square meters
Table: field_types
field_type_id, type
1, textbox
2, select_box
3, text_area
Table: field_data
field_data_id, ad_id, field_id, field_type_id, field_data
1 1 1 1 Cool t-shirt
2 1 2 1 5.99
3 1 3 2 L,XL,XXL,XXXL
4 1 4 3 Some description
5 2 1 1 Nice house
6 2 2 1 250000
7 2 4 3 Some description
8 2 5 1 1024sq/m
Table: ad_types
ad_type_id, ad_type_name, fields
1 general 1,2,3,4
2 real_estate 1,2,4,5
Well, store the values in columns and not in rows, so create a table and have 3 columns:
ad_type, property, value
define your properties for each type of ad and query the ad type for its fields.
Hope that helps
So I want my users to be able to restrict who may contact them.
There are several factors they should be able to filter, including Age (e.g. Must be between 18 - 29), income (must earn between $25,000 - $60,000), what they're looking for (e.g. Friendship, Hang out, etc.), what drugs they do (Marijuana, Meth, Cocaine, etc), etc.
The problem is, I want them to be able to select and store multiple choices for some of the criteria (e.g. drugs), but I do not know how I should store that in the DB or how I should structure the table to best accomplish that.
For example, how would I store a user's row that for "drugs" chose "Marijuana", "Cocaine", and "Heroin" within this context? Would I simply store those as comma-separated values in the "Drugs" column? Or should I do it in a completely different way?
What would be the best way to do this (considering I will obviously have to retrieve and check this information every time a user wants to contact another user) and why?
No, don't store the values in CSV format in the database. Instead create a join table called user_drug and store one row for each user/drug combination:
user
id name income
1 Foo 10000
2 Bar 20000
3 Baz 30000
drug
id name
1 Marijuana
2 Cocaine
3 Heroin
user_drug
user_id drug_id
1 1
1 2
2 1
2 3
3 3
A DB column (at least theorethically) should NOT hold multiple values. Unfortunately, there are some programmers that store multiple values in a single column (values separated by comma for examples) - those programmers (in most cases) destroy the concept of DB and SQL.
I suggest you to read about Database Normalization to get a start in organizing your tables. And, do your best to achieve the Codd's Third Normal Form
You can try with this:
criterium
------------
user_id type value
1 AGE_MIN 18
1 AGE_MAX 29
1 INCOME_MIN 25000
1 INCOME_MAX 60000
1 DRUGS Marijuana
1 DRUGS Meth