Please help me to understand the basic use of Datamapper's include_join_fields function. I tried it lots of but not getting any results.
I have application like $object->include_join_fields()
I have User table and Country table.
Please help me to set $hasone=array('country_id'); relation
I haven't any idea about this all, even not getting the exact point after reading documentation of include_join_fields
Any help will appricate
Thanks
include_join_fields are for many to many relationships, where you have a countries_users pivot table, and users could belong to many country.
For example, you could take one user, and the countries, where he belongs to. But you also store, how is a user related to that country. You have to store this extra field in your pivot table: countries_users.
So your pivot table, countries_users will look like something like this, with an example extra field is_he_working_there:
id
country_id
user_id
is_he_working_there
When you make a query for the user's countries, Datamapper won't add that field default. And here comes the include_join_field(), so if you call that, Datamapper will add this field to the end result.
But with hasone, it won't take any effect, because you get the user, and the other table fields also. No pivot table here, so don't need include_join_fields()
Related
i wanted to get your expert opinion about this dilema chosing bewteen JSON or Pivot Table
Let just say we have 2 tables here
people
jobs
A person may have multiple jobs, alas, a jobs might have multiple person subscirbed to it.
What is the best approach to it?
Method 1: JSON
I would have jobs column in people table, that contain json array of that person's jobs id, example : [1,2,4]
Method 2: Pivot
I would create pivot table job_person with job_id and person_id column, well, you know Laravel Eloquent style many to many pivot table
I have done some searching, and i found articels favouring each method, some say JSON better because it musch simpler, others would say Pivot is better due to that is how relationship database should work, etc etc.
But i want to know, which one should i use in what scenario? Like if it is just simple case like above scenario, JSON would be better?
What if there are other variables included like additional pivot columns
(Maybe each pivot also contain status column that can be set to active or past_job)
Or what if in the future we want to be able to get all peoples whom have a specific jobs, in which case Pivot would be preferable i think.
What if instead of jobs, the other table would be books and a person can have an extensive of books making we might have tens, or even hundreed pivot records just for one person? And there will be another hundreed persons?
What if instead of books, the other table were stocks in which case, a person might subscribed / unsubscribed multiple stock multiple times?
And maybe to the basic principle, what is each one's advantages/disadvantages?
Thank you very much
I would rather not choose JSON, as there's no benefit from choosing it, you will sacrifice many of the database features and make querying the data difficult and slow.
What if there are other variables included like additional pivot
columns (Maybe each pivot also contain status column that can be set
to active or past_job)
Job and Person are not dependent on each others, so you need to create an associative table between them something like "PersonJob" and add necessary information to it, this is easy to traverse in Laravel.
Or what if in the future we want to be able to get all peoples whom
have a specific jobs, in which case Pivot would be preferable i think.
You could easily query this using the associative table.
And maybe to the basic principle, what is each one's
advantages/disadvantages?
it just that relational databases are made for this kind of stuff and JSON offer no value just hardship.
I know, there already is similar questions, but I can't find a good answer at my problem.
I'm developing a social network, I have all my users in a table, but each users must be able to save multiple post from the website.
My Question is:
How can I store all the saved post for each user without creating a new table for each users. I know this is bad to do this, so I'm looking for an alternative
If I understand you correctly, you just need a middle table (for example names user_post) that have 2 columns : user_id and post_id
this is a simple implementation of a many-to-many relationship
You only need a table to store all posts call it posts table with structure like this:
|post_id|user_id|title|content|etc..|
So you can do something to save posts and identify them by user_id.
It's called one-to-many relationship, you can search more about database relationships.
I'm having conception difficulties to implement something in a database. I have two solutions for a problem, and I was wondering which one is the best.
Problem :
Let's picture a table speciality with 2 fields : speciality_id and speciality_name.
So for example :
1 - Mage
2 - Warrior
3 - Priest
Now, I have a table user with fields such as user_id, name, firstname etc ...
In this table, there is a field called speciality. The speciality stores an integer, corresponding to the speciality_id of the table speciality.
That would be acceptable for users that have only one speciality. I want to improve the model to be able to have multiple specialities for a user.
Here are my two solutions :
Create a table 'solution1' which link the user_id with the speciality_id and remove the speciality field in the user table. So for a user which has 2 specialities, 2 rows will be created in the table 'solution1'.
Change the type of the field speciality in the user table to be able to write down the specialities, separated with commas.
For example 2;3
The problem I got with the second solution is for making foreign keys between my table user and my table specialities, to link them. I may have a bit more difficulties with the PHP in the future too, while wanting to get the specilities for a user (will need to use a parser I guess).
Which solution do you find is the best ?
Thanks.
Absolutely go with your first solution.
Create a third "Many-to-Many" table that allows you to relate a user to multiple specialties. This is the only way to go in your case.
When designing tables, you always want to have each column contain one and only one data element. Think about what querying your second solution would look like. What would you do when you wanted to see all users who had a given specialty?
You might try something like this:
select * from user where specialty like '%2%'
Well, what happens when you have specialties that go to 12? Now "2" matches multiple entities. You could devolve further and try to be tricky, but...you really should just make your data design as normal as possible to avoid all the mess, headache, and errors. Go with Solution 1.
i think the best way is to follow solution1 cause solution2 will end up will lot of complexity later on
I'm modeling a DB for an application where one of the functions is to get a user from the DB and display in a diagram the selected user and all the referrals of that selected user, and the referrals (if any) for the selected user's referrals, going that way up to 3 referral levels.
I have two theories on how to model a scheme to accomplish this, but I don't know which one is the "best" (in terms of optimization, normalization, etc).
We have one scheme where the referrals are stored in a different table, with only a BOOLEAN to show if the user is, in fact, referred from another user.
On the other hand, I can substitute the BOOLEAN with a nullable INT (if referred, just store an INT, if null meaning is not referred by anyone).
If there is a better way to accomplish this, suggestions are also welcomed. Thank you.
I'd suggest a third model. You're talking a model where you can optionally have a referral, so perhaps a table that joins twice to the users table, the first column the refered persons ID, and in the second column, the referring users ID.
Then you know if there is a referral by joining to this table in your queries
I would use the second design and perhaps add a closure table for easily finding the referrals across multiple levels (see: http://wiki.pentaho.com/display/EAI/Closure+Generator)
This may seem strange, but I am wondering if it is possible to have a MySQL table have a column that can contain a list of values. For instance, say I have a table that represents a friends list like facebook, how can I simulate this in a table? I'm thinking that you could add the usernames into an attribute column but not sure that is the best idea or even how to do that. Any suggestions on how to achieve this or an alternative?
Under certain circumstances you could use the SET type, which is similar in functionality to the ENUM type. It allows you to store one or more predefined values in a field. However, for the facebook friends case it would not be practical as each time a new user is created the column definition would require updating.
Wolfram's suggestion of a mapping table is definitely the better solution as it also enables the use of foreign key constraint which will ensure referential integrity when one user is deleted (assuming you use cascading). Also, if you ever need to use the relationship in a JOIN then the mapping table is the only solution.
So what you're looking for, in keeping with the facebook example, is to have a table with two columns. The first, identifies the user, and the second a list of that user's friends?
As far as I know, you can't treat a column like an array. You could have a string containing all the individual names separated by dashes, but that would be un-robust.
My suggestion would be to have a friends table which has two columns, both of which are varchars or strings. Each column contains the name or id of 1 person only, which denotes a friendship between those two people.
Then, if you wanted a list of foobar's friends, you would just query:
SELECT *
FROM friends
WHERE user_a == 'foobar' || user_b == 'foobar'
Now, this would actually give you both columns, one of which is foobar and one of which is his/her friend. So you might have to get a little creative as to separating it into just foobar's friends, but I'm sure you can figure out a way that works for your code.
While this isn't usually a great idea, MySQL does have this:
FIND_IN_SET('b','a,b,c,d')
SELECT ... FROM friends WHERE FIND_IN_SET('foo',friends_list) > 0;
So you could do what you asked very easily. It's just not typically suggested.