I'm working on a project in ASP.NET MVC 5, with ADO.NET EF to generate data from the SQL server. I have several one-to-many relationships in the database. When I fetch data and project it to a local variable, e.g. var query = model.listFromDbChildTable.ToList(); where model.listFromDbChildTable is just entities loaded from the db. This is the lowest table in the relationship hierarchy.
So the thing is, and I am not sure why, every time I go to "locals" in VS, in debug mode, I can go deeper and deeper into my relations, for example, I am looking at a child table (department), and when I go to this child in locals, I see child has a relation with parent (above it), s I go to parent table, (I believe this is normal,) but when I'm at parent (table), again I can go to child table from there, and I am not going up one step back in the hierarchy, but so to say deeper, like a stair down all the time. So I go again to child, and child can go to parent again, every time with the same element. And I can redo this process many times?
So what is going on? Are my relations wrong or is this some normal procedure with locals in VS?
The following image shows two tables that participate in one-to-many relationship. The Course table is the dependent table because it contains the DepartmentID column that links it to the Department table.
Basically any link between two entities can be explored(Table in SQL ,class in EF)
In SQL you refer just a column in child table as key whereas in entity a property is create which has type of a class .
Like in below example, Course will have property name "Department" of type "Department" class as it depends on it (also a DepartmentId property).
you can read more in detail here on msdn..and Don't worry moving from SQL to Entity framework does give you small suprises :) .Hope it helps.
Parent Child Entity MSDN
I have a Dimensional table structure which resembles the following:
Ideally the hierarchial representation should be
CodeClassDesc --> CodeDesc
So A would be a Parent to A and B; B would be a Parent to A, B and C in my Analysis Server Cube. The problem is that because CodeClassDesc has multiple entries in the table it produces multiple duplicate Parents in my Cube with a single corresponding Child Element per Parent which is not what I'd consider a true Hierarchy. Or at least not what I am looking for the expected results.
I believe this is possible in SSAS without having to manipulate the data within the table via a VIEW but I don't know what I'm missing.
I've tried defining the CodeClassDesc and CodeDesc fields as a composite key but that doesn't work, yet I am almost certain there is a way to do this.
After attempting every conceivable permutation of methods to acquire resolution for this, I concluded that normalization of the required attribute was the only way to resolve the issue of having multiple entries of the Parent for every corresponding Child element.
So I created a VIEW of the table using a DISTINCT SELECT of only the CodeClass and CodeClassDesc fields in my DSV (DataSource View) in the Cube. Then I set the CodeClass field as a logical Primary Key and created a relationship between it and the CodeClass field of the main table.
I then used the CodeClassDesc field of the VIEW to create the top-level parent in my Dimension, which gave me only 1 distinct record for each value; and added the CodeDesc fields from the Table to create the Child Relationships. Works like a charm so I guess the answer would have to be that you cannot create a Parent Hierarchy consisting of a single Value per Parent if the source has multiple records.
In the dimension structure, you should change the property KeyColumn of the attribute "CodeClassDesc" to a composite key containing both "CodeClassDesc" and "CodeDesc" then change the NameColumn property to show itself
I am planning on using a recursive table in my data model so that I can support an undetermined number of children that can live under a parent. My example is a Table of Contents where I don't know how deep my subsections will be under a chapter.
The issue I am stumbling over is what techniques do folks use to populate there DB once they have defined a recursive table? By that I mean if I have a list of items that refer to a chapter -> Section -> Subsection...when I load the Chapter, Section, and Subsection into the model I need to identity the lowest level of the hierarchy and assign that value to the Item I am loading (Foreign Key - I would assume) so that I can always get all of the info about that item.
So for example:
Item: 2A-GHI: Chapter: 2 Section: A SubSection: GHI
If I have my data loaded like
ID|TOCID|TOC_VALUE|PARENT_ID
1|Chapter|2|-1
2|Section|A|1
3|SubSection|GHI|2
How do i tie the item to GHI so that I can set the FK to the Recursive Table for that Item?
Do you use all three values as a Key and set that as another column in the table so that on load you can identity the lowest level?
Like So:
ID|TOCID|TOC_VALUE|PARENT_ID|Key
1|Chapter|2|-1|2
2|Section|A|1|2_A
3|SubSection|GHI|2|2_A_GHI
I can load the recursive table and I am using a CTE to recurse the data, but I am not sure what the best method is to load the recursive data and tie that data into the model so that my item has a FK to the Table of Contents data.
You need a column for the row's parent ID.
ID|TOCID|TOC_VALUE|parent
1|Chapter|2|0
2|Section|A|1
3|SubSection|GHI|2
a parentID of 0 or null means it's a root (chapter) node
I'm not sure how to explain this. So here goes...
I'm trying to fit the method for lazy loading blobs as described here but I'm stuck with only one table.
I have a schema (fixed, in a legacy system) which looks something like this:
MyTable
ID int
Name char(50)
image byte
This is on Informix, and the byte column is a simple large object. Now normally I would query the table with "SELECT ID, Name, (image is not null) as imageexists..." and handle the blob load later.
I can construct my object model to have two different classes (and thus two different map definitions) to handle the relationship, but how can I "fool" nhibernate into using the same table to show this one-to-one relationship?
Short answer: you can't.
You either need to map it twice or (my preference) create a DTO that has the fields you want. In HQL you'd do something like:
select new MyTableDTO(t.ID, t.name) from MyTable t
Is there any way to use inheritance in database (Specifically in SQL Server 2005)?
Suppose I have few field like CreatedOn, CreatedBy which I want to add on all of my entities. I looking for an alternative way instead of adding these fields to every table.
There is no such thing as inheritance between tables in SQL Server 2005, and as noted by the others, you can get as far as getting help adding the necessary columns to the tables when you create them, but it won't be inheritance as you know it.
Think of it more like a template for your source code files.
As GateKiller mentions, you can create a table containing the shared data and reference it with a foreign key, but you'll either have to have audit hooks, triggers, or do the update manually.
Bottom line: Manual work.
PostgreSQL has this feature. Just add this to the end of your table definition:
INHERITS FROM (tablename[, othertable...])
The child table will have all the columns of its parent, and changes to the parent table will change the child. Also, everything in the child table will come up in queries to the parent table (by default). Unfortunately indices don't cross the parent/child border, which also means you can't make sure that certain columns are unique across both the parent and child.
As far as I know, it's not a feature used very often.
You could create a template in the template pane in Management Studio. And then use that template every time you want to create a new table.
Failing that, you could store the CreatedOn and CreatedBy fields in an Audit trail table referencing the original table and id.
Failing that, do it manually.
You could use a data modeling tool such as ER/Studio or ERWin. Both tools have domain columns where you can define a column template that you can apply to any table. When the domain changes so do the associated columns. ER/Studio also has trigger templates that you can build and apply to any table. This is how we update our LastUpdatedBy and LastUpdatedDate columns without having to build and maintain hundreds of trigger scripts.
If you do create an audit table you would have one row for every row in every table that uses the audit table. That could get messy. In my opinion, you're better off putting the audit columns in every table. You also may want to put a timestamp column in all of your tables. You never know when concurrency becomes a problem. Our DB audit columns that we put in every table are: CreatedDt, LastUpdatedBy, LastUpdatedDt and Timestamp.
Hope this helps.
We have a SProc that adds audit columns to a given table, and (optionally) creates a history table and associated triggers to track changes to a value. Unfortunately, company policy means I can't share, but it really isn't difficult to achieve.
If you are using GUIDs you could create a CreateHistory table with columns GUID, CreatedOn, CreatedBy. For populating the table you would still have to create a trigger for every table or handle it in the application logic.
You do NOT want to use inheritance to do this! When table B, C and D inherits from table A, that means that querying table A will give you records from B, C and D. Now consider...
DELETE FROM a;
Instead of inheritance, use LIKE instead...
CREATE TABLE blah (
blah_id serial PRIMARY KEY
, something text NOT NULL
, LIKE template_table INCLUDING DEFALUTS
);
Ramesh - I would implement this using supertype and subtype relationships in my E-R model. There are a few different physical options you have of implementing the relationships as well.
in O-R mapping, inheritance maps to a parent table where the parent and child tables use the same identifier
for example
create table Object (
Id int NOT NULL --primary key, auto-increment
Name varchar(32)
)
create table SubObject (
Id int NOT NULL --primary key and also foreign key to Object
Description varchar(32)
)
SubObject has a foreign-key relationship to Object. when you create a SubObject row, you must first create an Object row and use the Id in both rows