Develop Reference

Entity Framework joining tables from two different entities

I’m working on a project with over 15 databases, I need always to join tables from different entities so I end up using .ToList.
I had an advice from a friend to do a database link-server and then to create views in the same database for all the references tables.
But I'm not happy with both of them.
Is there any alternative solution other than .ToList & database views and what is the best practice in this case?

Plenty of ways around this, each with their own disadvantages.
Linked databases with views
Check the usage on the Microsoft docs
The ability to access data from outside of SQL Server.
The ability to issue distributed queries, updates, commands, and transactions on heterogeneous data sources across the enterprise.
The ability to address diverse data sources similarly.
Point three is your case exactly. You also have the ability to link multiple databases like mysql if need be.
A lot of disadvantages though (check here). I will add one of my own and say that
Implement with code and automapper
If all the tables are similar, then you can use a tool like automapper to make easy lists from your data
Get your data with entity framework
Map to DTO objects with the common properties using automapper
Merge your lists with Range add.
Duplicate data
We live in a world were nosql solutions are used alongside RDBMS solutions. it might be that you create a common db (RDBMS or nosql or whatevers suits you), and duplicate your data there.
It's extra work but it's the fastest in usage.
I could think of more, but this is the gist of it.

Multiple databases with slightly changing models. How do I allow `EF` to work with different database structures at run-time?

I am working with EF6, MSSQL, Oracle, .NET4.5 on a system that is used globally across company (many departments) to query different databases that belong to our department, that have mostly same EF model, some databases are Oracle and some are Microsoft SQL, some are development or uat, some are logs.
I am using different EF models for Oracle and for MSSQL databases.
One requirement is to switch between databases at run time, and this is easy,
public AggregatorEntities(string connectionString)
: base(connectionString)
{
}
however it does have side effects - many databases (dev, uat, dr, logs,...) are out of sync from what Live is (model is generated from Live), which results in errors when querying those databases.
Management knows about situation and they are ok for devs that work on some specific database to do changes to global querying system that would allow testers and uat to query the data. However they want changes they have to do to take minimum time to do this - as it is additional cost to each project that involves database changes. I will basically need to build a 'can handle all' resilient system, that when one changes database in EF will do something to accommodate to specific database.
There are different failure scenarios:
1. Name of column on table is the same but Type is different in entity
2. No column on table but there is one on entity in EF
3. Additional columns on table that are not on EF
4. Additional tables in database that are not in EF model
5. No table in database but there is entity in EF model.
I have done some thinking and this question is broad and might get closed for same reason. However I am not sure if it is worth splitting the question into each scenario, as it depends on the answer. The way I understand if single answer can answer all points then no need to split, however if each situation has different 'cure' then question should be split for that part only, but without answer no way to know.... (catch 22).
Only option I see ATM is to generate it's own model for each mirroring database, but then I end up with 50+ models.
How do I allow EF to work with different database structures at run-time?

This now officially cannot be done in a proper manner.
However end result of being able to switch between different databases with similar structures still can be achieved (for those without morals). Part with removing columns can used.
Solution is to have all inclusive EF model that is generated from database that has all the tables and all the columns (that are in any database think like logical OR of everything). Then model with all entities that have all properties from all db environments can be removed specific to environment that is queried at runtime in mechanism described here. This does not cover cases where type of column changes.
Hope this saves you some time as it took 2 weeks from mine...

Database schema for multiple companies

I am working on a inventory app using c# and entity framework code first approach.
One of the design requirements is that user should be able to create multiple companies and each company should have a full set of inventory master tables.
For example each company should have its own stock journal and list of items. There would also be a way to combine these companies in future to form like a 'group' company, essentially merging the data.
Using one of the file based RDBMS like sqlite, its very simple, I would just need to create a separate sqlite database for each company and then a master database to tie it all together. However how should I go about doing it in a single database file! not multiple file databases.
I do not want to have a 'company' column on every table!
The idea that I had given my limited knowledge of DB's is to separate using different schemas. One schema for each company with the same set of tables in each schema, with a separate schema holing the common tables and tables to tie up the other schemas together. Is that a good approach? Because I am having a hard time finding a way to 'dynamically' create schemas using ef and code first.
Edit #1
To get an idea of the number of companies, one enterprise has about 4-5 companies, and each financial year the old companies are closed off and a fresh set of companies created. It is essentially good to maintain data for multiple years in the same file but it is not required as long as I can provide a separate module to load data for several years, from several of the db files to facilitate year on year analysis.
As far as size of individual companies data, it can hit the GB mark per company.
Schema changes quite frequently at least on the table level as it will be completely customizable by the user.
I guess one aspect that drives my question is the implementation of this design. If it is a app with discrete desktop interface and implementation and I have my on RDBMS server like SQL Server the number of databases do not matter that much. However for a web-based UI hosted on third party and using their database server, the number of databases available will be limited. The only solution to that would be to use serverless database like SQLite.
But as far as general advice goes, SQLite is not advised for large enterprise class databases.

You've provided viable solutions, and even some design requirements, but it's difficult to advise "what's best" without knowing the base requirements like:
How many companies now - and can be reasonably expected in the future
How many tables per instance
How many records per 'large' table, per company
How likely are things to change frequently, dataschema-wise
With that in mind, off to some general opinion on your solutions. First off, considering the design requirements, it would make sense to consider using seperate databases per company. This would seperate your data and allow for example roles and security quite easily to be defined on a database level. Considering you explicitely mention you could "make it simple" using this approach, you could just create a database (file) per company. With your data access layer through Entity Framework you could also easily change connection strings between databases, and even merge data from A=>B using this. I see no particular reason, besides a possible risk in maintaining and updating different instances, why this shouldn't be a solution to consider.
On the other hand, using the one-big-database-for-all approach, isn't bad by definition either. The domain of maintenance becomes more compact and easily approachable. One way to seperate data is to use different database schemas, as you suggest yourself. However, database schemas are primarily intended to seperate the accessability on a role based level. For example, a backoffice employee e.g. user role should only communicate to the "financial" schema, whilst the dbo can talk to pretty much anything. You could extend this approach on a company base, seeing a company as a "user", but think of the amount of tables you would get if you have to create more and more companies. This would make your database huge. Therefor, in my opinion, not the best approach.
Finally, I'm intrigued by your statement "I do not want to have a 'company' column on every table". In my opinion, you should consider this as well. Having a discriminator property, like the companyId column on several tables are pretty easy to abstract using Entity Framework (or any ORM for that matter). This is what the concept of foreign keys is all about. Also, it would give you the advantage of indexing this column for performance. Your only consideration in this approach would be to make sure you provide this 'company discriminator' on all relevant tables.
The latter would be quite simple to enforce using EF Code First if you use a contract for each seperate data class to inherit from:
interface IMyTableName {
int companyId;
}
Just my quick thoughts, though.

I agree with Moriarty for the most part. Our company chose the one database per company approach, and we're paying for it every time we want to do a schema change. Since our deployments are automated, they should all be the same, but there are small differences each time. Moreover, these databases are really independent, so it's hard to keep our backups in sync as well.
It has been painful working with all these databases. The only plus side is that we can spread them out over multiple servers to increase performance. So I'm going to cast my vote for the one big database design.

Entity Framework: how to use multple tables for the same entity?

My situation is as follows. I'm using entity framework (4.0) in which I have defined a relatively simple model like, let's say, two entities:
user
transaction
A user can have multiple transactions in this scenario. When generating the database this would result (obviously) in 2 database tables names 'user' and 'transaction'.
The problem is that I want to use the code as a webservice where different companies should have their own environment (read: own users and transactions). A simple solution would be to add a column to both tables like, lets say 'company_id' to identify one user/transactions for companya from the user/transaction from companyb.
What I would like to have is a duplication of the tables like so:
compa_user
compa_transaction
compb_user
compb_transaction
This way..all data would be nicely separated and if company a generates a lot of transactions, company b would not notice that the system is getting slow or whatsoever.
My question: is there a way to accomplish this based on entity framework. So, can I have multiple tables representing one entity in my model and switch from table to table depending on which company is connecting to the service.
Any help appreciated!

If you really want to keep the tables seperate, then a seperate database for each client would be the easiest - only need to change the connection string in EF.
The other benefit of this model (seperate databases) is that the database will scale quite easily as each database could theoretically be on a different database server should the DB ever become the bottleneck.

How can I wrap tables into a more generic class for use with multiple data contexts?

I have two different DataContexts (SQL Databases) that have the same data, just with slightly different naming:
DB1: Serialnumber Productnumber
DB2: SerialNumber ProductNumber Result
So I want to be able to wrap these tables in a class that will let me get back the serial number and product number regardless of the DataContext that it is coming from. I've looked into DataTableMappings, but I really have no idea where to begin. I'd also like this to work via LINQ and direct SQL queries. Again, I'd like it to be as generic as possible so I can use the same LINQ queries for the two different contexts. What is it that I am looking for?

As a start, you'd probably want to consider coding against interfaces with your business logic - that way you can pass in DB1 or DB2 objects as long as their classes implement the interfaces specified.