I know this might have been asked quite a few times, however I can not find any suitable solution for my problem.
I am implementing database where I have users and articles.
Now the article can be either liked or loved by any of the user.
And here comes the problem, I have to return json that contains list of all articles extended by two fields, liked and loved, because queries are gonna be connected to users.
So liked and loved might be true or false.
I thought about creating two different tables Liked & Loved where I would keep article_id - user_id and if that record exists that means user liked/loved particular article. However I am not quite sure if thats the correct way, nor I have any idea how would I build such query.
If it is important I am using postgresql together with ormlite.
Thanks for any ideas.
If I have understand your question you are basically describing an M-N relationship. A user likes/loves N articles and an article is liked/loved by M users. Such relationships are implemented via a third table that stores the association of users and articles.
You could create a table UserPreferences that links user_id and article_id and has extra columns to indicate if he liked/loved the article.
I can't tell you more about the schema since I don't know if you have other degrees about the preferences (hated, indifferent, confused etc)
Related
I'm working on a classified ads site with 12 categories. E.g. category vehicles has items cars, bikes, Commercial Vehicles and spare parts. The following is a flow diagram for posting an ad:
I need to show the specification in the Form Filled section of the above image to the users in dropdown lists in the form when they are posting an advertisement. The car specification will be its color,engine,fuel type.
The ERD is below :
How should this issue be tackled, what are the best practices and is the current design going along the right lines?
On the whole this looks ok. Here are some observations:
likes.iker_id should point at users.id? Just trying to understand your model to start.
I would probably change the pics table to be one pic per row and then add an ordinal for ordering.
One question here is how you intend to look at your graph model. As it is, you might have a graph that could be traversed easily to a depth, a couple deep. I assume you are doing this to recommend ads. If so, I think this is sufficient. If not it would be good to further discuss which rdbms you are targetting.
Hope this helps:
In a simplified case, you will need some extra tables.
So, you are trying to be able to have different specifications for different items in your categories? Or, in other words, it is like having different attributes for different types of products in an e-commerce website.
If that the problem you are tackling, then you should look into the Entity–Attribute–Value (EAV) model that is how the problem is solved. By the way, one of the most popular open source e-commerce engines uses it as well.
i agree look at EAV models...
for some other tables, you have many normalization issues - for example:
you should have a separate address table (not part of the ad)
you should have a picture table (and link those to the ads with another table)
you should have a person table - and link that to the ad as 'owner'
the idea of 'favorite' should also be in this person->ad relationship table as a role or type column
Database Design
Is this a bad design for a relational database. I don't see anyone doing examples that look like this.
But considering that an interview is comprised of all the different tables I have linked to the interview table it seems valid.
Except of OH Number (Oral History Number.) An oral history from one narrator may be comprised of different interviews conducted at different dates. Each individual interview is assigned a unique ID that make op a series that is assigned 1 OH Number.
I'm also thinking of putting "Interviewer, Indexer, and Transcriptionist in the same table.
I created the following mock-up for you given the details you have provided. I believe this will be a good starting place. You have an interview object and a person object. You have a joining table of InterviewPerson. This allows you to have one to many person objects per interview.
I want the database to be robust enough that if a researcher called in
and wanted all the interviews conducted by John Doe, on Race
Relations, I could pull a query for it.
To do the aforementioned as you have stated, you would join both the Interview table and the Person table on the InterviewPerson table, and then you would limit your query of that joining based on the Person.firstName, Person.lastName, Interview.topic (or title).
Please note, this is a rough draft but should be a good general idea and start.
Database Design Redux
This is what I came up with based on your suggestions.
I'm in the process of structuring a databasemodel for my new project. For all the entities in my model (which is a cms, and the entities as such f.ex: page, content, menu, template and a bunch of others) they all have in common the same attributes on dates and names.
More specifically each entity contains the following for the dates: IsCreated, IsValidFrom, IsPublished, IsDeleted, IsEdited and IsExpired, and for names: CreatedByNameId, ValidFromByNameId, PublishedByNameId and so on...
I'm going to use EF5 for mapping to objects.
The question is as simple: What is the best way to structure this: Having all the fields in every table (which I am not obliged to...) or to have two separate tables which the other can relate to...?
Thanks in advance /Finn.
First of all - give this a read - http://www.agiledata.org/essays/mappingObjects.html
You really need to think about your queries/access paths. There are many tradeoffs between different implementations.
In reply to your example though,
Given the following setup:
COMMON
ValidFromByNameId
SPECIFIC1
FieldA
SPECIFIC2
FieldB
Querying by the COMMON attributes is easy but you'll have to work some magic when pulling up the subclasses (unless EF5 does it for you)
If the primary questions you're asking are about specific1 and specific2 then perhaps this isn't the right model. having the COMMON table doesn't really buy you much necessary as it will introduce a join to load any Specific1 object. In this case, i'd probably just have duplicate columns.
This answer is intentionally partial as a full answer is better handled by the numerous articles and blogs already out there. Search for "mapping object hierarchies to databases"
I'm currently building a forum component for a larger application and I'm considering different approaches to certain parts of the database schema. In particular, I am considering representing topics and posts in a single table. While I view topics and posts as practically the same, I feel a bit apprehensive as this may make things less flexible in the future.
When topics of a particular forum are queried, the title and first post will be shown as well as some of the user information (basically the name and avatar). In this application, there are various attributes that are used by both topics and posts except for views and replies; and perhaps title, and forum_id(forum_id because that would mean potentially hundreds of records need to be affected if a topic is changed to another forum as opposed to changing the forum_id attribute in the topic relation).
The tables look something like what I have below here:
TOPIC POST
topic_id poster_id
forum_id topic_id
poster_id content
title upvote
views dnvote
replies closed
post_id deleted
last_edited
last_editor
parent_id
content
post_id
Doing it this way, using table inheritance, generating the posts in the topic would require a 4-table join via TOPIC, POST, USER, and TOPIC_TYPE.
On the other hand, if I decide to take the single table approach, should I simply leave the views, replies, title, and forum_id attributes as null if the topic_type is a regular post? (topic_type references an appropriate icon for the type of topic displayed, and will be used for statistics and etc.)
If you are definitely committed to using relational technology (I would consider NoSQL db for this like Mongo, etc. as well) I would separate into two tables as you proposed.
Your case here is a fundamental of relational master-detail design or whole-parts and I think that two tables are appropriate.
I think in this scenario simple normalization is preferred. It will also be useful to generate different types of reports as well. Although single table may be used but as you have designed the table in this case if you use two tables that would be more manageable to avoid entry of same value multiple times.
It might be worthwhile to distinguish between a "topic" and a "topic starter" as such. A "topic starter" is a comment that is not a reply. Every topic has exactly one topic starter, which could be referenced by a foreign key in the topic table.
Other than that, I agree with both your analysis and your design.
I'm working on a proprietary feedback application. I have a table named topics that I will to use to store suggestions, questions, and problems.
topics [ id, user_id, title, content, type[suggestion, question, problem] ]
I can easily store this data in one table using a type column to distinguish between the three different topic types.
However, there's another wrinkle: Each topic has its own responses too, and responses are very similar to the topics themselves. I'm tempted to store them in the same table as well. So now I have type (suggestion, question, problem) and subtype (topic, response).
Am I asking too much of my topics table? Should I split my data into separate tables? I'm using Postgres and Rails for this particular project.
Best way to visualise is to compare it to StackoverFlow. SO stores questions and answers in the same posts table. Now suppose instead of only questions SO decided to allow suggestions and problems. Would they still use the same table?
How often you'll want to query both topics and responses in one action? Maybe when searching, but sometimes you also want to search only topics or only responses. And how often you will need to query only one of them? Most of the time.
Go for two separate tables, you can use views with UNION clause if you want to use them together. Also at the application level you can build inheritance model on top of relational database. Say Post object with Topic and Response subclasses. Some libraries like hibernate will transparently translate query for *all posts that...` into two separate queries and union results together.
Another approach (also being one of the ways to deal with inheritance in relational store) would be to have... three tables! Posts, Topics and Response, the last two having foreign key to Posts. This way common columns are in one table and type-specific columns are separately.
Keeping topics and responses in one table is better for forums. (A lot depends on the functionality you plan to have. Is it a forum or a news/articles/reviews site?)
Most forum frameworks use this design. Including SO as you mentioned. One distinction to make clear - note that what you are defining as "topic" is generally "post". So "responses" are also posts. What other frameworks call "topic" is the thread info.
Here's an image of phpBB's schema (warning, 1MB). Notice the phpbb_posts table with post_text and topic_id (where topic_ is the title, forum id, view count, etc. but not the post_text).
StackOverflow: The PostTypeId in the Posts table - "1 is a question, 2 is an answer. Answers will have a ParentId field populated to link back to the question post."
See this related question and google for others: How would you structure a forum's DB schema?
You could query a post + responses using something like:
select t.id, t.user_id, t.title, t.content, t.type, t.parent_id,
r.id, r.user_id, r.title, r.content, r.type, r.parent_id
from topics t
left join topics r on r.parent_id = t.id
where t.parent_id = 0 and t.id = <specific id>
The part you should separate is: If you want to show thread summaries like the stackoverflow Questions/Active/Newest pages; or forum index with latest topics, response, poster, etc. then maintaining a thread_info table would help for database performance, especially if you expect high vistor volume and/or many threads and posts.
Now suppose instead of only questions SO decided to allow suggestions and problems. Would they still use the same table?
For Suggestions that depends. Look at comments for example. Different table. The nature(model) + functionality of comments is different enough to be stored separately.
Taking another example: on news / reviews sites or like in wordpress, articles and their responses would be stored separately because of the same reasons. Articles would have relations to site authors, related articles, formatting, categories, etc. Responses would be threaded, possibly unformatted, etc.
Use multiple tables here, you said it yourself: there's another wrinkle: Each topic has its own respons*es* too
Multiple of anything usually requires another table.
I'd see it like this:
[TOPICS] [ topicID, user_id, title, content, type[suggestion, question, problem] ]
[SUGGESTION] [ suggID <fields here> *topicID ]
Note topicID as a foreign key in [SUGGESTION]