Hi guys I have to model the following situation. I came up with 2 possible alternatives, but I want to know if there's a better solution.
Here's the deal...
Simplified Schema
User Group
----------- ------------
UserId (PK) GroupId (PK)
Name Name
... ...
\ /
UserGroup
-------------
UserId (FK)
GroupId (FK)
This is simple. A table for Users, a table for Groups and then a table for relating users to group (many-to-many)
Then I have other entities (ie. Articles) that can be owned by both User and Groups (can be owned by one User, or can be owned by one Group, or can be owned by a User AND a group, etc).
So here's the deal. I could do:
A
Article ArticleOwnership
-------------- ----------------
ArticleId (PK) <----- ArticleId (FK)
Title UserId (FK-NULLABLE)
... GroupId (FK-NULLABLE)
The thing here is that when I want to check if a particular user owns a particular article, seems I have to check for both. This is easy using T-SQL, but I want to use Entity Framework (never used an ORM before, so be nice xD).
How would you model this situation???
Another approach might be:
B
Create a group for every user, containing inside just that user and manage the ownerships only by groups. How does this sound for you?
Thanks to all and sorry if my explanation is not very clear, my english is not perfect.
I've ended up doing option A...
Related
Lets say a relationship is described as:
A company has many employees
A company has many departments
A department has many employees
So, something like this;
Company -<< Departments >>- Employees
If department table has a basic structure of:
// Pseduocode
company_id // Foreign key
department_id // Primary key
[employees] // Array or collection of employees
If we go back to this phrase;
A Company has many employees
Does this mean that the employee table needs or requires a reference for the company_id too?
So, Employee would be:
employee_id
company_id // I'm not sure if this is requried or not
department_id
I'm intending to hopefully abstract this data into a contracts table in case of employees are freelancers/contracters, etc or have multiple employees.
But for now..
My question is:
Does my employee table require a reference to the company table, or is the company reference implied via the department table?
Many thanks
Question is: do you need a straight connection between Company and Employee? If you do, add it, if not then yes, the connection is implied through Department.
EDIT:
Technically, your Department table does not need a list of Employees. Each row of Employee table has a reference ID to Department, that's enough.
Check this out for more information.
The relationship is implied through the department, so you don't conceptually need it. Adding it, would be an example of denormalisation, and would allow inconsistencies to crop up. For example, you might have company_1 with department_1 and company_2. Now employee_1 might be linked to department_1 but company_2, because of some flaw/bug in the application code. There's no way to express this constraint as a SQL schema, so you'd have to go with more complicated stuff such as triggers, or application code checks etc.
However, sometimes you only need info about companies and employees, but not about departments. If it's really performance critical, doing the extra join with departments in order to find the company for an employee or the employees for a company might not cut it, so you'll just have to live with the denormalisation.
You probably do not need to link Company with Employee. The relation between Departement and Company already do the job. You may need it only if there are existing particular cases requiring this relationship.
I have a User class which stores user's details like Id, Name etc.
Now, every user can follow or unfollow other user.So, should i generate a new table Follow with columns Original_Id and Follow_Id where Original_Id is the user's own Id and Follow_Id is the foreign key to User's table pointing to Id primary key.
Two possibilities i am seeing here:
1>Follow table would have one to one relationship with User table through Original_Id column.
2> Follow table would have many to one relationship with User table through Follow_Id column.
So, if you have a user named Newton that has two followers, Tesla and Edison, your Users table will have something like this:
Id, Name
1, Newton
2,Tesla
3, Edison
and my Follow table will have following values:
Original_Id, Follow_Id
1, 2
1, 3
Is this approach correct. what i am thinking is possible, if any better approach please suggest me?
Will it be possible to filter User's related data from other tables through this Follow table.
I am showing here sample relationship of User's class with other class:
Now, i want to show user's only those post from user's whom he is following.
Any guidance most appreciated.
I have a relationships model that holds 2 user_ids, a follower_id and a followed_id
When a user "follows" another user a relationship record is added which includes these two id's. I would like the followed user to have some say as to what the following user can see, so I am thinking of adding adding field(s) to the record, such as "followed_user_allows_follower_to_see_email_address" (it would be a less verbose)
This seems like the correct place to add these attributes, are there any reasons I should store these some place else?
Is there any reason I should not just store a list of permissions, rather than an attribute for each permission? For example followed_user_allows_follower_to "see_email_address,see_some_other_detail,yet_another_detail" vs a separate field for each permission.
I have a book model and a notes model. Each book can have many notes.
# note.rb
id | book_id | content | page_number | author_id |
I want to run a lot of queries like
Get all the notes for page 43 of a certain book
Show all the noted pages of a certain book
These types of queries seem to favor making a separate noted_pages model so that a book can have many noted_pages and each noted_page can have many notes. This is fine but my noted_pages table would effectively just have an id column and a page_number column which doesn't sit right with me.
Is there a more standard way to implement this kind of setup or is my thinking ok?
A noted_page table would relate notes to pages, but do you need a page table?
If you need a page table, then yes, worry about the note<->page many-to-many relationship and create a link table. If you don't need to store book_pages as rows of a table, then don't.
Your design:
id | book_id | content | page_number | author_id |
Will give you the answers you want by querying like this:
Get all the notes for page 43 of a certain book
select *
from note
where book_id=123 and page_number=43;
Show all the noted pages of a certain book
select page_number, count(id)
from note where book_id=123
group by page_number;
If performance is an issue then put an index on the page number. You could also make (id, book_id, page_number) into a composite key, so your data will store (note 3, book 123, page 43).
If you want a many to many relationship, as in a book can have many notes, and notes can have many books, you must have a join table like you stated.
It would look like:
noted_page
--------------
id book_id note_id
This is just general practice, whenever you have a many-to-many relationship you MUST have a join table.
(Some frameworks/orm's don't require you to have a id column, but as far as I know, Rails/ActiveRecord does require it.)
No design is bad ... it just need to be justified.
I see different solutions :
A BOOK {title, author, edited_date ...} has many PAGE {content} has_many NOTES {note_content}
A BOOK {content, title, author, edited_date ...} has_many NOTES {note_content, page_number}
It depends on how you work with the book. Do you plan on saving the content of the book by pages or not ? If not, then can you find the page, and therefore the notes ?
Regarding your questions :
A model with one attribute is not the sign that it "smells". You can even have a 1-to-1 relationship, if it's justifier.
There's no "standard" way of implementing stuff. Like I said, it depends on how you work, on how you plan your users to use it (UI-wised), how you would store, etc....
You definatly won't need a many-to-many in your case ... rails provide enough tools t fetch from a model to its associations, w/ w/o conditions, etc...
Let me know if it helps.
Both of these can be simple ARel queries, no scope is required
The latter one is a simple check of the existence of the notes collection:
#book.notes.empty? #if there are no notes, it'll return true and vice versa
To get the book notes for a certain page:
#book.notes.where(["page_number = ?", page_number]) #where page_number is a variable, possibly a parameter
However, I do think you need to think through how you're going to model your data. Marcel has a good point.
Your design is fine. Don't over normalize. You'll probably just want to put an index on book_id, page_number on your notes table so you can do the lookup efficiently.
I was wondering if anyone knows of some good community distributed custom DDL templates for Entity Framework 4.0. The default DDL to SQL10 Works well enough, but we're looking to do some customization to the naming convention that it just isn't offering us.
I'm not really finding many samples out there of people doing this, so I was hoping someone might know of a resource I'm overlooking (perhaps I am searching for it wrong, or misunderstanding how the whole process works)
Specifically we're wanting to change up how it writes out fields from relationships. For instance, the default template puts in..
tablename_propertyendpoint_propertyname.
We're wanting to find tune this to our naming scheme a little more. And none of us can quite figure out where in the .tt files it is doing this exact behavior.
One of the more specific problems I am trying to solve is how it appends and changes property names in the database. For example..
Products
-------
Id (int)
Name (varchar(32))
Customers
-------
Id
Name
Carts
-------
Id
Customer (fk)
Baskets
-------
Cart (fk) (pk)
Product (fk) (pk)
Assuming this is my object structure... It would look much like listed above. but the database generator expresses it like this..
Products
-------
Id (int)
Name (varchar(32))
Customers
-------
Id
Name
Carts
-------
Id
Customer_Id (fk)
Baskets
-------
Cart_Id (fk) (pk)
Product_Id (fk) (pk)
Now, I realize this doesn't actually 'hurt' anything; but consistency is kind of important to me, and this is a good place to 'learn' how all of this code is generated. I basically wish to design it so that it does not change the names of my fields on me.
Absolutely - you can download the entity designer database generation power pack here:
http://visualstudiogallery.msdn.microsoft.com/en-us/df3541c3-d833-4b65-b942-989e7ec74c87
The problem with column names is that they are needed in two places: In the MSL and in the SSDL, and that is where they are generated. So, your easiest bet is to take the MSL and SSDL T4 templates and look at those.