I have a project where I need to design a code first entity system with an existing database. These existing tables in the database are not just any tables, they were being created by Microsoft's ERP tool "Dynamics Navision". The Navision tool holds different company information and creates different tables per company. Let's assume there are 3 types of tables;
TableX
TableY
TableZ
And also there are 3 different companies;
CompanyA
CompanyB
CompanyC
The tool created 9 different tables from above combinations. It simply duplicates all of the tables and adds a prefix with the company name to the table names. At the end, our database looks like this;
CompanyA$TableX
CompanyA$TableY
CompanyA$TableZ
CompanyB$TableX
CompanyB$TableY
CompanyB$TableZ
CompanyC$TableX
CompanyC$TableY
CompanyC$TableZ
What Did I do so far?
So as you can see, there is an opportunity to simplify this architecture at the Entity Framework side. To achieve this, I created 3 entity classes for TableA, TableB, TableC and at the run time, I let the user to choose a company and according to the chosen company, I reflected my entity class with a custom TableAttribute where the table name prefixed with the company name. I am not going to give details on how I achieved it right now(but you can find implementation details on this article: LINK) but so far so good and I have applied all of the previous steps successfully and I managed to be dynamic on table names with the chosen company. However, there is another problem.
What is my question?
The problem is, even though I managed to create a system where I can change the entity class' table name attribute at the runtime and access to the target companies tables, there were no guarantee that duplicated tables with different company name prefixes are sharing %100 same inner field architecture. For example, CompanyA$TableX can have 5 fields while CompanyB$TableX has 6 fields where the first 5 fields are the same with CompanyA$TableX's fields but the last 1 field is extra. Let's also visualize it;
CompanyA$TableX's table fields;
ID
Name
Surname
Adress
PhoneNumber
CompanyB$TableX's table fields;
ID
Name
Surname
Adress
PhoneNumber
EMail
As you see, the Email field is the extra however the table names are the same(TableX), only the company differs and in my system, they share the same entity class and the company name determined at the run time as I mentioned before.
So, I want to know about how can I achieve to be dynamic on this. How I can have only one entity class but be dynamic in the fields of this class according to the chosen company. I want to know if it is possible technically and if it is, how to implement it. Thanks in advance.
What you are saying about Nav is not true. It is not possible to create the same table in Nav that will have different structure per company. Even the modern extension architecture will not give you that kind of result.
Related
I have tables with the same structure but with a letter prefix of every table.
For example:
A_Company, B_Company, C_Company
There is combo box from which the user can select A, B or C, and then the code saves data into the appropriate table.
How can I do this using EF database-first?
I solved this problem adding a column for code prefix and triggers on my base table company for insert update and delete.
As the other commenters have said, it would be much better to refactor the database to a single table. If you can't do that then the only other thing that I can think of is to have a class which will select the table for you.
I would create a new class which has the same properties as your company tables, and also has the descriminator property. This would then be used as the data source for your ui.
in this class you would have to code manually to draw the data from the correct actual table (and save to it) based on the value of the discriminator. This is fine if you have only a few tables, but as your number of identical tables grows large, this will become more of a headache.
It might be possible to have the base tables all inherit from a virtual base class which would help a bit - you could then create a dictionary which the base class could use to switch the final data source on the fly.
As a final thought have you considered:
1. Creating the master table as suggested by the other commentators as a single table and then having views for each company.
Creating the master table as suggested and then having code to create the individual tables from that one at some point prior to their use?
I am getting data from an external API and want to save it in SQL Server with the Entity Framework. The data I am getting is order information. The data is roughly laid out like this:
Order:
Order ID
Customer
Shipping Address
Items
Customer:
Customer ID
Customer Details
The problem is that any customer can place more than one order. My entity framework is based around the Order information. So if a customer places more than one order, I get a primary key violation because the customer is already in the database even though the order is not.
For reference: I usually add orders like so: orderContext.Orders.Add(order);
Since every order contains the customer data, I can not add an order without "adding" a customer. Even if I were to check for an existing customer, I would still have to add the record to the Orders table, which would still trigger the problem. Is there any way to tell EF to add or update each "child" class?
The example here is more simplistic than the actual data. There are several other dependencies like this, such that even if I were to switch to using the Customer class as the basis for the EF, it would still have this problem.
Change your tables like this:
add CustomerID to your Order table, this is because everyone Order has just one Customer and every Customer has many or zero Order
Order(OrderID,CustomerID,ShippingAddress)
Customer(CustomerID,...)
I am working on a CMS using ASP.NET / C#. It works fine and life is good. However, it was decided to add extra functionality to support a wider variety of websites.
Basically, the current CMS is still alpha but will be able to host data for multiple websites running for the same group of companies all having somewhat the same requirements.
I have constructed the database as per the diagram attached below:
"Image removed for security reasons"
Now, in addition to this diagram, I was asked to add support for products under different 'attributes' than Sectors. Meaning that a product now can have a type and many other attributes. So let's say you're using one of our sites and we make tissue paper. Products should somehow support filtering by 'type' say 'tissue' and by 'application' say 'how you use it' and other unknown 'attributes' that may pop up in the future.
For example a product may fall under the 'Agricultural Packaging' sector and is of type 'Bag' and is applied by some way of applying it.
The end result is to be able to sort products by how they are used and or their type and or the sector they fall under. Or even all together.
What is the best approach for this sort of problem to include into the data model and the CMS?
Thanks!
It looks like you're taking the right approach. If a product can be assigned more than one of the new 'attributes', then you'll want to create a new Attributes table where you can define a finite set of attributes. Then link that table to Products via a cross-reference table, just like you're doing with Products & Sectors. If a Product can only be assigned a singe attribute, then add the Attributes table, but instead of using a cross-reference table, add an AttributeID column to the Products table to join the two.
I feel like I may be telling you something that you already know, however. So if there is any additional information, or more specifics you want, maybe you can post an update.
The pattern you are looking for is called EAV
You will end up with an attribute table and an attribute value table that has the product id, attribute id, and attribute value in in it.
I have database to be designed about people info
there will be some common details about people like name,age,address,contact etc...
but there are categories of people like government servants,business man,salaried , politicians etc...
so there will be some dynamic fields about the categories...
common details table can be made easily but the problem is with dynamic fields of categories like
government servants will have income, dept, since,etc...
I have created three tables :
Peoples Table: name, age, DOB, etc...
Category:rows for Government servants, salaried etc...
Attributes:
------------------------
ID|Category|Field|Value
-----------------------
1 |GS |dept |electricity
the above database design (what i am using now) is kind of
NopCommerce database deign with
Nop_Customer and Nop_CustomerAttribute table
so is this a good one or anything better than this could be done: (for this situation)
Two imp points to be considered:
1-users will add data for this so controls will have to be created accordingly
2- this database will be searched by others.
EDIT:
The fields for each Category will be fixed.
but the categories will be added over time not by users but by developers, so need it be less hectic and maintainable for developers
Make tables for each type of person. In those tables, only store what is applicable. If Phil Jones is a politician, then he would have an entry in the Person table that describes him as far as a person is concerned. He would also have a row in the Politicians table that would describe him as far as a politician is concerned. Make each of the child tables have a foreign key relationship with the person table's ID column.
You could opt to use an ORM tool such as NHibernate:
NHibernate is a mature, open source object-relational mapper for the
.NET framework. It's actively developed , fully featured and used in
thousands of successful projects.
You could then use OOP principals such as inheritance to have one super class covering the basics and then extend the class depending on what other extra features you need. This tutorial gives you an idea on how to do it.
You can use XML field so You can store unstructured data or use one of inheritance mappings
see here http://www.agiledata.org/essays/mappingObjects.html
I am trying to come up with a database design that would work with Entity Framework 4 Code First. Actually, I have no experience yet of EF4 Code First but as I understand it, if I write the code, it will create the database and tables.
The issue is this. There are various types of auctions, they all have some common fields and some specific ones. In the code I envisage having a base abstract class called Auction and subclasses like LowestUniqueBidAuction and EnglishForwardAuction etc.
Nothing surprising there. The problem is that I imagine the database structure to mimic this. I imagine an Auction table and a LowestUniqueBidAuction table and a EnglishForwardAuction table. In the Auction table I imagine a foreign key into one of these two tables for each row depending on the type of auction that that row is. I also imagine another column in the Auction table with the name of the derived auction table (such as EnglishForwardAuction).
The problem is that whenever I've ever created a foreign key I've had to specify the name of the foreign table into which the key points (which makes sense). In this case, however, there is one of many tables that the key could point. So there are many issues here. Firstly, I could simply not use a foreign key and just use an ordinary field, but then the database will not be able to maintain data consistency for me. The second issue is how will EF Code First handle this? In other words, how will it know that if I ask for all EnglishForwardAuction rows from the Auction table that it should look at the column with the table name and then join on the EnglishForwardAuction table to get the extra fields?
Has anyone ever faced similar issues?
Thanks,
Sachin
This problem is solvable in Entity Framework in a number of ways - read up on how EF handles inheritance and what strategies are available.
There are basically three strategies how to handle this:
(1) Table per Hierarchy
You have only one single table, that represents all possible sub classes. Of course, this means, several rows (that only exist in a given subclass) must be nullable, since they don't show up / don't exist in super classes or other subclasses.
(2) Table per Type
Each subclass gets its own table, and by default, the sub-types table shares the PK with the base classes' table - e.g. PK = 1 in Auction will also be PK = 1 in EnglishForwardAuction. So your subclass tables reference the base table - not the other way around.
(3) Table per Concrete Type
Each concrete subclass (your separate auction types) gets its own table, but that table contains everything - all the columns, from that specific type, but also its base type.
Read more here:
Inheritance in the Entity Framework
Inheritance and Associations with Entity Framework Part 1
Entity Framework Modeling: Table Per Hierarchy Inheritance
Entity Framework Modeling: Table Per Type Inheritance
Searching for Entity Framework Inheritance and/or one of these strategies will reveal a lot more hits, too - that topic is very well covered and discussed on the interwebs! :-)