I'm building a small forum app where a user has a profile and on that profile, the user who owns the profile as well as other users, can make posts ( pretty much the same concept as with fb ).
My concern is whether it is better to have multi-word classes or whether it is better to have a separate class for each word.
For example, if i have a profile on which i can create posts.
Would it be better to have a model Profile and a model Posts
Or it is better to have a ProfilePost model
My approaches so far are the following
The tables for the first approach
users
- id
profile
- id
- user_id
posts
- id
- body
- profile_id
comments
- id
- body
- poster_id
- post_id
Where poster is the user who creates the post
The user has a profile
The profile has posts
Posts have comments
As a result, if i want to add a new post, then i'd have to make multiple joins, for example
$user->profile()->posts()->addBy($anotherUser, $post)
$user->profile()->post($post)->addCommentBy($comment, $anotherUser)
The tables for the second approach are
users
- id
profile_posts
- id
- body
- profile_user_id
- poster_id
comments
- id
- poster_id
- profile_post_id
And the approach to create a post and a comment will be like
$user->postToProfile($profileUser, $post);
$user->profilePost($post)->addComment($comment);
The first approach requires multiple joins but the naming seems more elegant to me.
While the second approach consists of multiwords such as profilePost which seems like these words can be extracted into their own classes.
Related
I'm looking for a way to best analyse the user data in our app.
for example
how many users have read 0 articles on our site
how many users have read 1 article on our site etc
we have a users table with id, username columns and we also have an activities table that creates an entry when an article is viewed. For example it would create a database row with
id
activity
user_id
1
read
1
all of the data we need is there, I just don't know how to interrogate to give that detail.
I personally would use an int code for activity and not a string. So "read" would = 1, "edit"=2...etc If you have no care about what user read with no association, that becomes easy by just setting a flag on the article that was read by article id. So your article table would have:
id article_id activity user_id
1 5 1 8675309
From there just do an eloquent query on article_id where activity = 1...
$articlecount = Article::where('article_id', $request->id)->where('activity', 1)->count();
$articlecount will give you all of the reads for that article.
If you need it based on user you could do a one to many relationship from your users models to articles models. Then query the user with(articles). That will bring back all the articles where that user has activity. You could also specify in your eloquent to only bring back activity of reads/edits..etc too. In the same respect you could do the reverse and query the article and see all the users that have read that same article.
I am doing a simple blog project for which I've come up with the following object class structure.
user class (email address, password)
blog_entry class ( title, body, dateposted, state[draft, published] )
comment class ( comment, date posted )
category class ( category name )
object relationships
a user can post zero or more blog entries, a blog entry belong to one and only one user
a user can publish one or more comments, a comment belong to one and only one user
a comment belong to a one and only one blog entry, a blog entry can have zero or more comments
a blog entry belong to one and only one category, category can exist without a blog entry
I need to know how to map these object structure(including relationships) into a relational data model for mysql. Since this is my first MVC project I don't have a clear understanding how to get this done properly.
Pl. advise.
PS: I've come up with following data model. Appreciate your ideas on this:
users
- id
- email_address
- password
categories
- id
- category_name
blog_posts
- id
- post_title
- post_contents
- post_dateposted
- post_state
- users_id
- categories_id
comments
- id
- comment
- comment_dateposted
- blog_posts_id
- users_id
Thanks.
I'm new to server side web development and recently I've been reading a lot about implementing RESTful API's. One aspect of REST API's that I'm still stuck on is how to go about structuring the URI hierarchy that identifies resources that the client can interact with. Specifically I'm stuck on deciding how detailed to make the hierarchy and what to do in the case of resources being composed of other resource types.
Here's an example that hopefully will show what I mean. Imagine we have a web service that lets users buy products from other users. So in this simple case, there are two top level resources users and products. Here's how I began to structure the URI hierarchy,
For users:
/users
/{id}
/location
/about
/name
/seller_rating
/bought
/sold
For products:
/products
/{id}
/name
/category
/description
/keywords
/buyer
/seller
In both of these cases objects in each hierarchy reference a subset of the objects in the other hierarchy. For example /users/{id}/bought is a list of the products that some user has bought, which is a subset of /products. Also, /products/{id}/seller references the user that sold a specific product.
Since these URI's reference other objects, or subsets of other objects, should the API support things like this: /users/{id}/bought/id/description and /products/{id}/buyer/location? Because if those types of URI's are supported, what's to stop something like this /users/{id}/bought/{id}/buyer/bought/{id}/seller/name, or something equally convoluted? Also, in this case, how would you handle routing since the router in the server would have to interpret URI's of arbitrary length?
The goal is to build convenient resource identifiers, don't try to cross-reference everything. You don't have to repeat your database relations in URL representation :)
Links like /product/{id}/buyer should never exist, because there already is identifier for that resource: /user/{id}
Although it's ok to have /product/{id}/buyers-list because list of buyers is a property of product that does not exist in other contexts.
You should think of it in a CRUD fashion, where each entity supports Create, Read, Update, and Delete (typically using GET, POST, PUT, and DELETE HTTP verbs respectively).
This means that your endpoints will typically only go one level deep. For instance
Users
GET /users - Return a list of all users (you may not want to make this publically available)
GET /users/:id - Return the user with that id
POST /users - Create a new user. Return a 201 Status Code and the newly created id (if you want)
PUT /users/:id - Update the user with that id
DELETE /users/:id - Delete the user with that id
Going into more detail, such as /users/:id/about is likely not necessary. While it may work, it may be getting slightly overspecific.
Perhaps in your case you could add in:
GET /users/:id/bought - Array of products that the user bought
GET /users/:id/sold - Array of products that the user sold
where you could return a list of id's (which can be fetched through the products API), or you could populate the Products before sending them back if you wish. If you do choose to populate them, you probably should not then populate users referenced by each product. This will lead to circular includes and is wrong.
And for Products, in your sitation I would use:
GET /products- Return a list of all products
GET /products/:id - Return the products with that id
POST /products- Create a new product. Return a 201 Status Code and the newly created id (if you want)
PUT /products/:id - Update the product with that id
DELETE /products/:id - Delete the product with that id
GET /products/:id/buyers - Array of who bought the product
GET /products/:id/sellers - Array of everyone selling the product
I have looked through most of the mongodb schema design articles on mongo's website and most of the questions here on SO. There is still one use case which I haven't figured out. When looking at these tutorials, they usually reference the article comments problem and the products/categories problem. I want to figure out how to model the one to many relationship (author to posts) when querying a list of posts. Here are the example schemas:
Users: {
_id: ObjectID
Name: String
Email: String
}
Posts: {
_id: ObjectID
user_id: ObjectID
body: String
comments: [
body: String
]
}
Now, lets say you want to run a query for the latest 10 posts. A pretty simple query, but now you have posts with the possibility of each one having a unique ObjectID pointing to the user. Now, how should you accomplish getting the name and email of each user for a post.
Should you create an array of the user ObjectID's from the posts query and then run the query db.users.find({ _id: {$in: PostsUserIDArray}}); After that would you use your application logic to match the right user information to the correct post?
Should you keep a copy of the data in posts. I.E. keep the user ID, name, and email in the posts table. Then just have a hook when a user updates this information to update all the information in posts.
An option which myself or my friend have not thought of.
I appreciate all help as I try to wrap my head around mongo data modeling.
For a few videos I have seen from MongoDB creators, they advocate the second solution. If your user have more data than just a name and email and if you display only name and email when displaying apost, then it's not really bad to store it in the post. Thus you don't have to perform others queries when querying for posts. And since a user doesn't normally change his name every day, it's more effective to run an update to all posts once he changes his name than perform other queries to retrieve informations when displaying posts.
Edit : link to a video http://lacantine.ubicast.eu/videos/3-mongodb-deployment-strategies/
I'm currently logging all actions of users and want to display their actions for the people following them to see - kind of like Facebook does it for friends.
I'm logging all these actions in a table with the following structure:
id - PK
userid - id of the user whose action gets logged
actiondate - when the action happened
actiontypeid - id of the type of action (actiontypes stored in a different table - i.e. following other users, writing on people's profiles, creating new content, commenting on existing content, etc.)
objectid - id of the object they just created (i.e. comment id)
onobjectid - id of the object they did the action to (i.e. id of the content that they commented on)
Now the problem is there are several types of actions that get logged (actiontypeid).
What would be the best way of retrieving the data to display to the user?
The easiest way out would be gabbing the people the user follows dataset and then just go from there and grab all other info from the other tables (i.e. the names of the users the people you're following just started following, names of the user profiles they wrote on, etc.). This however would create a a huge amount of small queries and trips to the database in a while loop. Not a good idea.
I could use joins to retrieve everything in one massive data set, but how would I know where to grab the data from in just one query? - there's different types of actions that require me to look into several different tables to retrieve data, based on the actiontypeid...
i.e. To get User X is now following User Y I'd have to get my data (User Y's username) from the followers table, whereas User X commented on content Y would need me to look in the content table to get the content's title and URL.
Any tips are welcome, thanks!
Consider creating several views for different actiontypeids. Union them to have one full history.