About the 3rd point:
The `Relative` entity in this case is representing the ManyToMany association
between 2 `User` entities. This associations needs additional data, so it
becomes a OneToMany/ManyToOne association (hence the entity).
I do agree that the name `Relative` might not be the best choice. I agree that
it's the User that's a relative of another User. So maybe it could be called
`Relation`, because the association represents the _relation_ between 2 Users.
I think the current `Relation` entity should be named `RelationType`, as it's
metadata about the `Relation` (currently named `Relative`). If I understood
correctly it's going to contain values like "brother/brother" and "father/son".
So the complete picture would look like this:
User <- OneToMany -> Relation <- ManyToOne -> User
Relation <- ManyToOne -> RelationType
A final suggestion:
Give `Relation` the properties `$id`, `$user`, `$relatedToUser` and
`$relationType`.
You have a `invitedby_id` in the table, but I'm not sure this is needed. I
think you want to store the user that initiated the relation, but that's always
the user in `$user` (never `$relatedToUser`), I'll get to that in a moment.
Have `RelationType` contain values like "father" and "son", not "father/son".
Now, say you have User(1) and User(2), and $user1 wants $user2 to be his son.
You can create a `Relation` entity like so:
$id = 123
$user = User(1)
$relatedToUser = User(2)
$relationType = RelationType("son")
Now you app knowns User(2) is the son of User(1) (from User(1)'s perspective),
but it doesn't know that User(1) is the father of User(2) (from User(2)'s
perspective). If you do want your app to know the latter, create a second
relation:
$id = 456
$user = User(2)
$relatedToUser = User(1)
$relationType = RelationType("father")
If you always want to have these 2 `Relation` entities for a single father/son
-like relation, have something like a RelationManager service create (and
remove) those entities.
The reason I suggest using 2 `Relation` entities is because using this
throughout your app will be much easier. When you need to know all the
relatives of User(1), you can simple query all `Relation::$relatedToUser` users
where `Relation::$user` is User(1).
When using only one `Relation` entity, you would have to query for all
`Relation::$relatedToUser` users where `Relation::$user` is User(1) OR all
`Relation::$user` users where `Relation::$relatedToUser` is User(1).
I hope this helps!
--
Jasper N. Brouwer
(@jaspernbrouwer)
On 1 Apr 2014, at 10:06, Herman Peeren <[email protected]> wrote:
> On Tuesday, 1 April 2014 07:12:49 UTC+2, Swapna V wrote:
> (...) that model could be improved, definitely would like to get suggestions
> (...).
>
> First thing I would do: to name all entities in singular, not plural. You
> don't have a "Users" entity, but a User. That its data is based on a
> users-table (named in plural) is OK, but the entity itself is a User, not a
> Users. It seems trivial, but it will help you in thinking in objects
> (entities) instead of tables.
>
> Second: what is your Relation-object? Do you need it? What is it that you try
> to model? Easier is not to start with the tables, but first have a look at
> what your "domain" is that you want to model. See next point too.
>
> Third: I doubt if a Relative is something else than a User. Probably
> relatives are other users. In that case it is a User entity with a ManyToMany
> association to itself: a User can have many other users as relatives and a
> User can be the relative of many other users. I always start with sentences
> like that.
--
You received this message because you are subscribed to the Google Groups
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/d/optout.
