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.
Related
I'm using MS SQL Server 2008R2, but I believe this is database agnostic.
I'm redesigning some of my sql structure, and I'm looking for the best way to set up 1 to many relationships.
I have 3 tables, Companies, Suppliers and Utilities, any of these can have a 1 to many relationship with another table called VanInfo.
A van info record can either belong to a company, supplier or utility.
I originally had a company_id in the VanInfo table that pointed to the company table, but then when I added suppliers, they needed vaninfo records as well, so I added another column in VanInfo for supplier_id, and set a constraint that either supplier_id or company_id was set and the other was null.
Now I've added Utilities, and now they need access to the VanInfo table, and I'm realizing that this is not the optimum structure.
What would be the proper way of setting up these relationships? Or should I just continue adding foreign keys to the VanInfo table? or set up some sort of cross reference table.
The application isn't technically live yet, but I want to make sure that this is set up using the best possible practices.
UPDATE:
Thank you for all the quick responses.
I've read all the suggestions, checked out all the links. My main criteria is something that would be easy to modify and maintain as clients requirements always tend to change without a lot of notice. After studying, research and planning, I'm thinking it is best to go with a cross reference table of sorts named Organizations, and 1 to 1 relationships between Companies/Utilities/Suppliers and the Organizations table, allowing a clean relationship to the Vaninfo table. This is going to be easy to maintain and still properly model my business objects.
With your example I would always go for 'some sort of cross reference table' - adding columns to the VanInfo table smells.
Ultimately you'll have more joins in your SP's but I think the overhead is worth it.
When you design a database you should not think about where the primary/foreign key goes because those are concepts that doesn’t belong to the design stage. I know it sound weird but you should not think about tables as well ! (you could implement your E/R model using XML/Files/Whatever
Sticking to E/R relationship design you should just indentify your entity (in your case Company/supplier/utilities/vanInfo) and then think about what kind of relationship there is between them(if there are any). For example you said the company can have one or more VanInfo but the Van Info can belong only to one Company. We are talking about a one – to- many relationship as you have already guessed. At this point when you “convert” you design model (a one-to many relationship) to a Database table you will know where to put the keys/ foreign keys. In the case of a one-to-Many relationship the foreign key should go to the “Many” side. In this case the van info will have a foreign keys to company (so the vaninfo table will contain the company id) . You have to follow this way for all the others tables
Have a look at the link below:
https://homepages.westminster.org.uk/it_new/BTEC%20Development/Advanced/Advanced%20Data%20Handling/ERdiagrams/build.htm
Consider making Com, Sup and Util PKs a GUID, this should be enough to solve the problem. However this sutiation may be a good indicator of poor database design, but to propose a different solution one should know more broad database context, i.e. that you are trying to achive. To me this seems like a VanInfo should be just a separate entity for each of the tables (yes, exact duplicate like Com_VanInfo, Sup_VanInfo etc), unless VanInfo isn't shared between this entities (then relationships should be inverted, i.e. Com, Sup and Util should contain FK for VanInfo).
Your database basically need normalization and I think you're database should be on its fifth normal form where you have two tables linked by one table. Please see this article, this will help you:
http://en.wikipedia.org/wiki/Fifth_normal_form
You may also want to see this, database normalization:
http://en.wikipedia.org/wiki/Database_normalization
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'm writing my first rails app & want to get into some good habits from the start. The table in question is to be to hold employee data, one of the fields being the manager's ID. To reflect the hierarchical structure, I'm thinking of using acts_as_tree, so the parent_id would be the manager's id field (right?). If we are to use (import) data from our existing HR application - PeopleSoft - the employee ID is a string. Employee ID seems to make the most sense as a PK (coming from the PeopleSoft developer perspective, I realize I may be biased and/or not seeing all of the possibilities -- I welcome suggestions on this as well)
I know that one of the philosophies behind rails is "convention over configuration", so I'd like to use the defaults - the PK being the autoincrementing integer. Would it make sense in this case to create a "lookup table" or something in order to maintain the use/association of the ID coming from PS? There will be reports/exports going back into the PS world....
Thanks
You're correct in that the convention in Rails is to use the default auto-incrementing id. If you have a one-to-one relationship between people and employee IDs, then employee ID should just be a field (column) on your person model. Make it a key (but not a primary key) if you're going to be doing a lot of lookups using it.
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...
How do you handle real name conflicts? Is there an established best practice or UI design pattern for disambiguating records like this? If authors can have many articles but more than one author can possibly have the same name how would you enable users to select the author they actually want when creating articles?
I can't dictate the author names be unique. The authors may have some other information that could individuate them (their articles or other optional fields).
To make this clearer - users are not authors. Users are people entering information about authors and articles. The only guaranteed information present for an author is the author's name. Other details are optional.
So if a user is creating a new record for an article they will have to either select or create an author for the many-to-many relationship between authors & articles.
With unambiguous rails examples such as the blog post category dropdown, like ryan bates uses in his railscasts, it is easy to create or update. If it exists link the blog post to it, if it doesn't then create and link the blog post to it.
My case is much messier. If it exists isn't that meaningful but I don't want to create a separate author entry for every article the author does.
Presumably you have a key that means you know which user authored which records, so it comes down to how you can best disambiguate them for your users.
Perhaps you need to ask your authors for a brief summary of themselves in their profile that you can use to disambiguate them on their terms. Alternatively depending on the type of article you might choose to describe them in terms of geography ("John Biggs, Florida", "John Biggs, California" ) or perhaps by the subject areas they choose to write about: "John Biggs, Java Expert", "John Biggs, Indonesia Specialist" and so on.
You could even just have "John Biggs (1)", "John Biggs (2)" and so on. I seem to recall this works alright for IMDB, who are a good example of a site that has had to sort this problem.
The important thing in usability where these types of thing are concerned is consistency- you need to always identify your authors in the same way so you don't have "John Biggs, Florida" and "John Biggs (2)" and you need to make sure that the identity you give to an author doesn't change once it is set up, so "John Biggs (2)" never becomes "John Biggs (5)" and your users can identify them whenever they see the disambiguated name as the same person who had that name previously.
One thing that worked for me on a past project is to have a text box in which users can type in the author's name. As they type, I update a div with possible matches - similar to Stack Overflow when you type a tag in the ignored or interesting box.
Users can click on a name in the div which opens the record in a new window - new window has a button, "select this author," which takes you back to the original page with that author in the textfield as Author Name (id).
If they submit the form with an ambiguous name, we have an extra step where we display matches, and they choose which one they mean.
I imagine you'd want something a little more streamlined if this is a data-entry type application, but on that project adding an author was an infrequent operation.
Several things to think about:
Can you filter by subject matter first?
For instance if John Jones (1) writes articles about genetics and John Jones (2) writes articles about computer networking, bu having the user select the general subejct matter first, you may be able to filter out many of the less applicable possible duplicate names.
(I would however have a button to see the unfiltered list becasue sometimes people write arrticles in a new subject matter). If you don't want to limit the choices perhaps a sort by subject matter or location could make it easier to find the right one.
When you show the list of possible duplicate names, show general information about the author including address and university affiliation and possibly the name of one article. Have a button to click on to show existing articles for any one of them. That way if you know the John Jones you want is located in FL, you only need to check out the three in Fl for articles not all 37 John Jones who wrote genetics articles.
Be aware that users are often lazy, they would rather just insert a new name than choose from a long list of existing names. So make it harder to insert a new name than to pick one. They have to go through the pick process first before they can enter a new name. We have an application which doesn't even show the button to add a new person until after you have done a search. Since names can have variations consider if you want to use fuzzy logic for your search. You might want to display J. Jones, Johnny Jones and Jon Jones as well as John Jones in your pick results.
Now a lot of this depends on how much knowledge your users have about the author ahead of time. If they know nothing beyond the name, they have no basis to judge between the 37 John Jones you have in the database. In this case it might be better just to accept the duplicates and return results based on a filtering by keywords or whatever you are storing about the article. Is it really necessary to make sure that the articles are ascribed to the correct John Jones, if you really know nothing about the author other than his name? Are you more concerned with the subject matter and name of the article or with having a list of all articles written by John Jones from UVA who is a professor of Political Science?
You don't! Names are a bad method of identification as you're finding out. You have a number of methods around this:
Add some form of unique identifier with normal users this would be a username to check for uniqueness. In your case, the method described above name(1) might have to do, if you really have no other information other than the name.
An alternative would be to use multiple attributes to make a composite key (e.g. name + dob)