So I am working on a booking system where I am posting small avaiable jobs for the kids in the community. I am not looking for a direct booking system in the sense that the user can just press the "booking button" and directly have the job. The approach i want to take is that you can SUBMIT INTEREST and then the poster of the job can accept one of the applicants.
So i have a few tables going on but the essential for the questions are these two.
|users|
|id | name | age |......
|jobs|
|id | date | salary |
What i am looking for explained in it's most simplest form is that i want multiple user id´s to be stored in a column so that i can later display/controll the users connected to the job in matter.
Would very much appreciate a sultion or just as much a tip on how i would go about solving the problem.
(I am using mySQL database if that adds any value to the question)
Best regards.
That is an n:m relation. A user can be interested in multiple jobs and a job can be interesting to multiple users. You should have a third table user_jobs for this where you store one record per user interested in a job.
Something like
user_jobs
userid
jobid
date
status
Related
I'm looking for some help with a problem. I've a table with the following columns/fields -
COLUMNS = userName | userEmail | userInterests | .... and other fields
VALUE = userA | userA#email.com | 1,2,10
VALUE = userB | userB#email.com | 15,27,9,7,2
userName(varchar) = the primary key
userEmail(varchar) = user's email
userInterests(varchar) = comma separated numbers for interests. I've mapped these number to their actual value (interests) in PHP script. e.g. 1 - Painting, 2 - Dancing and so on...
Now I'm trying to find the users having the similar interests. The number of interests a user can have can vary. My goal is to find the best match for any user.
Suppose if User A has 3 interests and User B has 5 interests, from which 1 interest is common in both user, so I wanna get the matched user's name. Suppose if there's another user with 2 common interests, then in that case, return that profile. In General, I wanna find the best match (where all interests meet with other user), if not, then second best match (at least have 2 or 1 common interest).
I have already been to this solution but I'm unable to get the desired output. There's only one table, so I can't use the joins as well.
SQL - Finding Users with Similar Interests
Please help me with this, I've been meddling with this from past 2 days and couldn't find the right solution. I tried my best to explain the problem, If I failed to do so, Please let me know and I can elaborate. Thanks
I think the best approach would be to first normalize your database so you don't have an array like structure. This would make this type of query more efficient and much easier to do.
If that's not an option, you can have a look at this answer of how to do this normalization via query to a temporary table and work from there. Once you have a separate table for interests, you can proceed with the solution you already pointed in your question, making a count of the occurences.
I am creating a database for a community to store details of all their members along with those members' relations with each other.
For Instance: There is a family of 4. Mother, Father, Son and Daughter. The Son gets married to a girl from another family in the same community (Their data is also in the same database). The newly married couple has a new member soon. Also they need to add their grand parents to the database at a later stage (Parents of both the Mother and Father in this case).
What would be the best way to create a schema for such a database.
I have a schema called member_details that'll store all community members' data in a single table something like this.
member_details: ID | Name | Birthdate | Gender | Father | Mother | Spouse | Child
All members would have relations mapped to Father,Mother,Spouse,Child referenced in the same table.
Is this schema workable from a technical pov?
I just need to know if my solution is correct or is there a better way to do this. I know there are a lot of websites storing this kind of data and if someone could point me to the right direction.
I'd advice you to use two tables. One for members of community and one for relations beetween them. Something like this:
Members:
ID | Name | Birth | Gender
Relations:
First Member ID | Second Member ID | Relation
Where you use IDs from first table as foreign keys in second. That way you'll be able to add more relations types when you need it. By the way, I'd add a third table to store relation types, so it can work as a dictionary. Same thing for genders.
As usual, "it depends".
The first question is "how will you use this data?". What sort of questions do you expect the database to answer? If you want to show a person's profile with their relationships, that's pretty easy. If you want to find out how many children a person has, or who is the grandfather of a person, or the age of someone's youngest child, that could be a little harder.
The second question is "how sure are you these are the only relationships you want to store?" Perhaps you also want to store "neighbour", "team member", "engaged_to" - or maybe you need to store that information later on. Maybe you need to take account of people getting divorced, or remarrying.
The schema you suggest works fine for most scenarios, but adding a new type of relationship means you have to add a new column. There are no hard and fast rules, but in general it's better to add rows than columns when faced with events in the problem domain. Asking "who is this person's grandfather" requires a couple of self joins, and that's okay.
#ba3a suggests splitting the information about people from the information about relationships. This is much "cleaner" - and less likely to require new columns as you store more types of relationship. Showing a person's profile requires a query with lots of outer joins. Finding a grand parent requires self joins on the "relations" table.
I'd like to do some Php graphs with MySQL datas, but first I have to think about the best design for my database, I prefer ask you some advice because I'm a newbie and I think there is a better way that the one I'm thinking.
I have a main table called "companies", with an autoincrement id column and a region column, more companies and more column could be added later.
On the Php graphs, I'd like to choose the graphs by companies regions and maybe others filters later, this is why my table "companies" is the the central table.
I'd like to fetch new datas (stocks, commands, roi, etc..) for every companies one time per day and use those datas on graph. The old datas won't be overwritten but keep for the graphs history, more data I'll have more the graph will show the behavior of the company.
So, every day there will be one more row per companie (more than 200 companies in total), and this point is my issue.
I was thinking to create one table per companie and add a new row everyday on each on those tables, but I feel it's dirty and there is a better and cleaner way to do that, is anybody can show me the best way ?
Thanks for reading, I hope you'll can help me.
From what I understand, you have at least those entities in your domain:
Companies
Company indicators (stock, ROI, commands, ...)
Indicator types (stock, ROI, commands, ...)
Regions
So you should probably have something similar to the schema below:
,---------.
,-------. |Indicator|
|Company| |---------|
|-------| |date |
|name |*---|value |
|-------| |---------|
`-------' `---------'
o o
| |
,------. ,-------------.
|Region| |IndicatorType|
|------| |-------------|
|name | |-------------|
|------| `-------------'
`------'
So I have this application that I'm drawing up and I start to think about my users. Well, My initial thought was to create a table for each group type. I've been thinking this over though and I'm not sure that this is the best way.
Example:
// Users
Users [id, name, email, age, etc]
// User Groups
Player [id, years playing, etc]
Ref [id, certified, etc]
Manufacturer Rep [id, years employed, etc]
So everyone would be making an account, but each user would have a different group. They can also be in multiple different groups. Each group has it's own list of different columns. So what is the best way to do this? Lets say I have 5 groups. Do I need 8 tables + a relational table connecting each one to the user table?
I just want to be sure that this is the best way to organize it before I build it.
Edit:
A player would have columns regarding the gear that they use to play, the teams they've played with, events they've gone to.
A ref would have info regarding the certifications they have and the events they've reffed.
Manufacturer reps would have info regarding their position within the company they rep.
A parent would have information regarding how long they've been involved with the sport, perhaps relations with the users they are parent of.
Just as an example.
Edit 2:
**Player Table
id
user id
started date
stopped date
rank
**Ref Table
id
user id
started date
stopped date
is certified
certified by
verified
**Photographer / Videographer / News Reporter Table
id
user id
started date
stopped date
worked under name
website / channel link
about
verified
**Tournament / Big Game Rep Table
id
user id
started date
stopped date
position
tourney id
verified
**Store / Field / Manufacturer Rep Table
id
user id
started date
stopped date
position
store / field / man. id
verified
This is what I planned out so far. I'm still new to this so I could be doing it completely wrong. And it's only five groups. It was more until I condensed it some.
Although I find it weird having so many entities which are different from each other, but I will ignore this and get to the question.
It depends on the group criteria you need, in the case you described where each group has its own columns and information I guess your design is a good one, especially if you need the information in a readable form in the database. If you need all groups in a single table you will have to save the group relevant information in a kind of object, either a blob, XML string or any other form, but then you will lose the ability to filter on these criteria using the database.
In a relational Database I would do it using the design you described.
The design of your tables greatly depends on the requirements of your software.
E.g. your description of users led me in a wrong direction, I was at first thinking about a "normal" user of a software. Basically name, login-information and stuff like that. This I would never split over different tables as it really makes tasks like login, session handling, ... really complicated.
Another point which surprised me, was that you want to store the equipment in columns of those user's tables. Usually the relationship between a person and his equipment is not 1 to 1 and in most cases the amount of different equipment varies. Thus you usually have a relationship between users and their equipment (1:n). Thus you would design an equipment table and there refer to the owner's user id.
But after you have an idea of which data you have in your application and which relationships exist between your data, the design of the tables and so on is rather straitforward.
The good news is, that your data model and database design will develop over time. Try to start with a basic model, covering the majority of your use cases. Then slowly add more use cases / aspects.
As long as you are in the stage of planning and early implementation phasis, it is rather easy to change your database design.
I have a problem on accouting, I need to control the cash flow.
Actually my schemma is somehing like this:
**invoice_payable** control all my payable invoices
**invoices_receivale** control all my receivale invoices
Also I have other to entities to receive only the payment. They Are :
**invpay_paid** and **invrec_paid**
It receive only the payment coming from the first two tables.
Now I need to generate the daily balance, it is no problem, cause it is done already, but on the fly. I need to save the daily balance in a new table that I have called balance_history .
Now I will try to give more details about my tables.
My invpay_paid looks like this
id | invoiceid | amount_recvs | recv_data | cashier | company
the balance_history looks like this
id | balance | balance_date | cashier | company
The invrec_paid is a little different. but folow the same logic.
The problem is, I need to down the bill by company and cashier, I really need to do like this 'cause is more then one company and cashier that have registered payment everyday.
I'm really confused about this. How to control all the payment in the same place but for different companies and cashier (banks).
Here follow my data model: http://deepcell.org/app/AccountingDataModel.png sample.
Thanks for everyone, I have edited this topic, I hope to be clearer now.
I'm just answering my own question to give this topic as closed.
The question was solved using the follow data model.
Here follow my data: Model Sample.
Also I have an script workng to me every night (cronjob) generating my daily balance.