I'm trying to implement a personalized news aggregator. I have to save user's preferred news sources in db. Should I store all the news sources liked by a user as JSON string and then decode it after retrieving?
feeds | user
or have individual column for each news source(no of news sources would be around 200)?
feed_name1 | feed_name2 | ..... | user
Sounds like a many-to-many situation. A solution that used a person table, a newsfeed table, and a person_newsfeed table might be appropriate. There are lots of articles on line about this and any good database theory book (or Something like Oracle: The Complete Reference) should cover this in detail.
This article is a pretty good (but very short) summary:
http://www.databaseprimer.com/pages/relationship_xtox/
Oracle8 The Complete Reference covers this around page 35 with the worker, skill, workerskills example during their discussion of third normal form.
Related
I am working on some web apps which should all use the same user table. The different applications all need different table designs, so I created one table for each app, with the UserID being a foreign key referring to the user table.
Now I want to add tags to all apps. The tags should be in one table for every app in order to easily query all tags from one user(for searching purposes, the search should be able to find everything tagged with that tag, no matter the app). Personally, I don't think splitting them up into multiple tables would be a good idea, but I am not that into database design so I might be wrong. My current attempt looks something like this:
[tags]
EntryID | UserID | Tag
The thing is that the EntryIDs of course would have to be unique across all app tables with this solution. For the notes app I need something like this:
[notes]
EntryID | UserID | title | content | etc.
For my calendar I have the following table:
[calendar]
EntryID | UserID | name | start | end | etc.
Now I don't know how to manage those EntryIDs. Should I create another table like this
[entries]
EntryID | UserID | type
with type being something like "note" or "calendar", and EntryID being the primary key? And should the type be something like an integer, or a string, or is there a possibility to kind of refer to another table in the type column? And should I then make the EntryIDs in the app tables into foreign keys referring to the entries table?
I put the userID in every table because I think this is going to speed up querying, for example when I need every tag one user has set across all apps. I know normalization usually prohibits this, but I again think that it would very much increase query speed and reduce load for both the MySQL server and my back-end.
I would appreciate every tip for structuring this, and thanks in advance!
You can use inheritance, similar to this:
I'm not sure what the role of the user is supposed to be here, exactly. In the model above, user "owns" an entry and (presumably) tags it. If you want multiple users to (be able to) tag the same entry, USER would need to be connected to the junctions table TAG_ENTITY.
For more on how to physically implement inheritance, see here.
You may also be interested in this and this.
I have a site nearing structural completion. Essentially, it's made up of Users and Photos. However, Photos have a LOT of HABTM relationships, most of which are different kinds of tags, and others being categories, collections, etc...
My client would like to be able to have a conditional CMS based off the content being viewed for different promotional purposes or whatnot. For example, if a user is browsing the Category "Leprechauns", he may want to show html content about St. Patrick's Day or something. He may even want to easily include the browing user's name, if available. In which case, it'd be nice to have some sort of templating system. The part that makes this tricky is that these are small blocks of HTML for something like a 300x300 space in the sidebar and is NOT the primary content.
I've looked into refinery, but it seems to be too much of a complete solution. I've also thought about building in from scratch, but I don't know where to begin with treating dynamically generated pages (such as a new Category) as a recognizable object in Rails. I'd like to keep it more global than a slew of HABTM relationships, but it's looking like that might be where I'm heading. Ideally, he'd be able to make some HTML and check off "I'd like this to show on x and y Category page and b and z Collection page and for the tag Foo and for the tag bar as well as on my homepage"
Any suggestions? I'm open to finding a gem or getting a solid start on a homebrew.
UPDATE
I'm thinking of setting up some models Like the following:
cms_contents
============
id:integer
contents:text
timestamps
cms_associations
================
id:integer
cms_content_id:integer
model_id:integer
record_id:integer #optional
secondary_model_id:integer #optional
secondary_record_id:integer #optional
models
======
id:integer
name:string
Where:
cms_content would contain the HTML.
cms_associations would be an ActiveRecord model using has_many, :through
models would contain a the models the CMS content could be associated with
if record_id is not given, it associates with the model index
if record_id is given, it associated with the record of the provided model with that
id
if secondary information is given, a combination is created for other many to many
relationships
eg:
User has_many :photos
Browsing Photos for User(10)
model_id => #User model Id
record_id => 10
secondary_model_id => #Photo model id
So you could customize the content for browsing photos for specific users such as featured users or companies that may pay for advertising.
Any thoughts on this structure?
It's actually not that complicated. This is what you should do:
Introduce new object in the DB, name it htmlchunks
For every object that you'd want to associate with htmlchunks, create a join table and define habtm relationship
Modify your sidebar (for objects that have association with htmlchunks) in a way that they recognize whether there's htmlchunk associated with this particular object. For example, let's say you have a htmlchunk called "April Fools' Day" that contains simple html paragraph. In the sidebar, you'd just ask something like #category.htmlchunk? and output according to the result. You'd ideally place all this in a partial
As for creation of the htmlchunks you'd just offer simple wisiwig editor and ability to select any number of tags, categories, whatever. You'd create habtm entries between them and htmlchunks during the creation process
Let me know if you have further questions in the comments.
It's almost as if the almighty Ryan Bates is looking out for me, but the latest Railscast is on CopyCopter, which does exactly what I'm looking for, and runs as a separate app, so I don't have to worry about bogging down my main app. I suggest anyone who finds this to watch the screencast, as it seems pretty impressive.
http://railscasts.com/episodes/336-copycopter?autoplay=true
I am working on the data model for a relational database where I have to store User Information as well as User's profile such as Education Level, personal interests, hobbies, and etc. Similar to what most of the social networking sites have or any other systems that allow you to build a profile.
I cannot decide if it would be better to store all this information in one Users table, or break it into 2 tables.
If I would break it into two tables I would have Users table that would just store UserID, Name, e-mail, DOB, gender.
UserProfiles would store the rest of the stuff pertaining to a profile, sharing the same UserID with Users table
If there are multiple profiles of a single user means one to many relation then i would recommend you to create 2 tables one is user and other is user-profile.
If one user have only one profile then your should create only one table with both attributes on User as well as profile.
Go for the more modular design, this will allow for more flexibility and control. The only time I would recommend keeping the data in a single table is if you plan to query the same data frequently.
There is a great article here which goes into depth as to why joins are expensive. You should ultimately base your decision off the information provided in the link, however as I mentioned before if you plan to query the two tables together frequently then keep the data in a single table.
I think,in order to decide which data model to chose, just look at some of the similar requirement Datamodels, which are presented in this Datamodel Library.
Specific to your User-profiles Datamodel Requirement, this link may be useful.
Hope those links will be useful. OR I got this Data model image depicting facebook type data model:
We are providing document upload on different things like tasks, feeds, comments etc..
And there are lots different permission on documents for which user can share it or download it. Document is private or public.
We already have legacy code and database but it's not maintainable and scalable.
I want to get idea how should I have to design a database which covers all this scenarios. And it will be maintainable and scalable for other users.
Any example or solution ?
I'm not sure what exactly you mean by "upload on tasks, feeds, comments, etc." It would be useful if you could provide more detail or even the legacy database structure. Here's a general idea, though...
--users--
uid
name
email
(etc)
--comments--
cid
uid
docid
date
text
--documents--
docid
uid
upload_date
(etc)
--permissions--
pid
docid
uid
The "comments" table would be for comments on the document (if that's what you were looking for?).
The "permissions" table is just a list of document ids and user ids who are allowed to access the document. Or, you could even define permissions via groups of users (which would require another table, but you get the idea).
I'm in middle of creating a social networking site something like facebook, and got struck up with database schema design for it.. from previous questions i posted here, i confirmed that i cant create new database or tables for a new user who registers onto my site. I need to insert new row [thats my only option(correct me if i'm wrong!)]. but, this works out for registration for the first time. what if the user posts something new on his profile.. where should i insert this update.. coz, i cant insert them into rows as dey correspond to each user.. and too many columns cannot be created.. what is the solution for this.?
schema =>
TableName : User_content
userId Name College City Status_Updates Messages
1 a sfd fds fsds sdds
2 f dfg dfd fdf dfd
what if user 1 updates something.. what i need to do nw. Think its a status update, how to go about it.?
Before you start thinking about this social network site you dream if
Developing you need to understand database modelling fundamentals. This link will help you with some simple concepts. http://www.databaseanswers.org/tutorial4_data_modelling/index.htm
Add tables based on what you want to allow your users to do and the related data you need to store as a result. Some example tables:
'user_account': User account information (e-mail address, password) - referenced by user ID
'user_profile': Basic user profile information - referenced by user ID
'user_status': User status message - referenced by user ID
I have the sense that this is your first major database application, and if so, you need to learn more about database design in general before you take on creating an application like this. There are many things to consider when designing a database schema and designing it well from the start is key. The core of your application will rely on how well your data is organized and accessible, so ensure you spend enough time developing a good design.
Good luck!