Can anyone give me a bit of a steer in the right direction.
I'm currently trying to write a web interface using asp.net mvc3 which provides a singular view of two systems with backend databases in MSSQL and DB2.
Being new to the entity framework I've attempted to connect to each of the databases in isolation and can pull data back succesfully.
The next logical step is to attempt to join the databases together to gain some leverage over the data. This is where I've hit a bit of a stumbling block.
Looking at Entity Framework it doesn't appear to facilitate cross database joins when the databases are sat on different physical servers. Have I missed something obvious here? I can't seem to find any reference to this?
As a fall back option I thought about using linked servers and wrapping the sql in a view which would theoretically allow me to run the types of queries I need. Has anyone done this?
I thought about using linked servers
and wrapping the sql in a view which
would theoretically allow me to run
the types of queries I need. Has
anyone done this?
I have done this approach many times. I have only needed one or two tables from the other database, so creating the views is easy.
Related
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.
Actually I am new to the software development, I have an idea to create an web application in which I am going to use front end C#.Net and Back end:SQL Server. What happen if my client ask me to use other database management software other than SQL Server? Is there any solutions to run same application without changing the SQL code like dynamic database creation based on the client requirement?
Help me..
Each Database like SQL Server , Oracle is having it's own coding syntax and are totally different . It's not possible to use the code of one DBMS for another.
In most cases SQL statements will work across various Database as it's standard for relational databases . But moreover when work with different databases you need to work in it's own standard.
Also there are different kind of databases available such as RDBMS ,NoSQL etc.. so each different in it's own way.
There might be some tools available to help you to convert one code to another.
You need to isolate database access from the rest of the program so that database specific code is in one place only.
For this convenience you need to learn MVC to perform these tasks. It can happen to certain level but still altogether certains functionalities need specific methods to be called but it increases efficiency...
This is quite a long one, but I'd very much appreciate your thoughts and suggestions.
We are busy rebuilding a legacy system which was written in PHP and MySQL and replacing its components with ASP.MVC in C# and SQL Server. The legacy architecture leaves much to be desired and there is a serious issue with spaghetti code, no referential integrity in the DB, unused code and database fields and just generally bad coding.
As much as I'd love to, we can't just rip out all of the old code and replace it. The company needs to stay functional during the development process, so we will need to build new functionality while using the old databases to ensure that their data is accurate at all times. The level of data accuracy isn't real-time, but if we had 2 systems, they would have to be in sync 100% of the time. The old system uses 6 different MySQL databases, all on the same server, running Linux. We will be running Windows 2008 R2 on the new server for the new system and we are planning to use the latest version of SQL Server.
The problem I'm having to solve is: I need to somehow map all of these databases into a consolidated model that we can use through C# to develop the new system on. Once we have moved all the functionality over to C#, we need to port the data into a DB that matches our code model. This DB will be running on SQL Server. I'm not too worried about the migration just yet; my current issue is finding an ORM tool that will allow me to map these 6 MySQL databases into a single, well planned out and designed model that we can use for the new development.
The new model might have additional fields that we would have to store in a new MySQL database until we port the data across at some stage, so the ORM should support easily building entities that span multiple tables and databases.
Is what I'm trying to do possible? Is it viable in terms of effort? Is there an ORM that can do all of this? and what other way is there to maintain operational capacity of the company whilst developing on the system actively?
I have looked at these ORM options:
SubSonic (great, but I think too lightweight for what we are trying)
Entity Framework (looks like I might be able to use this if I use very dirty models with tons of stored procedures for inserts, updates and deletes)
NHibernate (the client does not want us to use this due to bad experiences in the past)
LLBLGen (seems like it can do what we need it to, but long term support could be a concern with the client)
Anything else I should look at? Is there a different approach I could try?
ORMs aren't designed to solve the problem you have. That said, a quality ORM will get you some percentage of the way toward a solution.
NHibernate is the easy choice. LLBLGen would be my second choice. I wouldn't even bother with EF or SubSonic as they are very feature poor compared to the other two and you need decent feature support in your scenario.
You'll likely have to invest a lot of time in writing custom code around your migration requirements. Your use case is not a standard, well traveled path.
For Entity Framework: if you're prepared to maintain one complete set of stored procedures with a static interface (i.e. same signature) you could implement them all in Transact-SQL on the SQL Server box, with linked servers (to the MySQL farm).
When the time comes, you could migrate the data into SQL Server and update your stored procedures.
Basically, design a nice model with nice stored procedures, and as a temporary solution implement any ugliness inside the stored procedures. Once MySQL is out of the way, you can replace the stored procedures with better ones.
SQL Server has a tendency to retrieve the entire remote table when you're running queries against a linked server, so if performance is a concern it might eventuate that all your stored procedures are wrappers around OPENROWSET (see Example A for running a query on a remote server).
I was thinking about utilizing RavenDB for some of my look-up scenarios I am doing in a high throughput application. This would replace all of the look-up calls I need to make to the DB to get things like site location, etc. Looking at a couple of options really (also .Net caching). I know that you can replicate Indexes from RavenDB to SQL Server, but wondering if anyone has done the reverse where they sync RavenDB with Sql Server?
Any suggestions / comments would be appreciated.
--S
I've done a similar scenario where data needed to be transferred in batch from a SQL Server system nightly into our RavenDB instance.
I couldn't find an off the shelf tool to do what I wanted as typically you should optimise the model you give RavenDB differently to SQL Server.
I wrote a custom console app that put the data into my RavenDB instance.
For example my console app:
Compacted several relationships into one document
Dealt with the different datatypes
TLDR: I wrote my own console app as I couldn't find a generic product that could do it.
So far the only avaible solution is write your own sync process.
I was looking for ways to improve the search scenearios using RavenDB , the RavenDB will be filled using my sql server relational database.
I think it should be a better way, however the only i can think rith now is to use a ETL process that keeps updating your NoSQL version of your structured data.
I am working on a personal project as a way of learning more about C# and .NET, specifically creating an application that utilises a database (MS SQL Server 2008 in my case). Whilst I appreciate there isn't always a definitive "right" way of doing things, given the choice between using an old technology/idea or a new one, I would rather use the new one. For example, one of my aims for this project is to learn, or at least familiarise myself with, WPF rather than using WinForms as I have done in the past.
On that basis, I've been muddling around without a great deal of direction with regards to saving data to my database and retrieving it. So far I've managed to get both those working using TableAdapters but I feel like they are the "old" way of working (my basis for this is that they are listed under Visual Studio 2005 on MSDN). Firstly, am I correct in this assumption? If so, what are the newer methods of saving and retrieving data from a database? I would be grateful of any pros and cons each method offers.
I've Googled and searched MSDN extensively but I don't feel like I am using the correct search terms as I have only succeeded in confusing myself.
I have .NET 3.5, Visual Studio 2008 and Microsoft SQL Server 2008 at my disposal.
Any guidance would be much appreciated.
I would agree that TableAdapters, DataSets, DataTables, etc. are the "old" way of doing things.
The "new" way would be Linq-to-SQL, Entity Framework or NHibernate.
Personally, I like to use a combination of Linq-to-SQL along with plain old DBConnections, DataReaders and DTO's where needed.
If you would like a newer way of doing Database access in .NET, I would recommend looking into LINQ to SQL or the Entity Framework.
There are many many many different ways to retrieve data from SQL Server 2008 using .Net.
Table Adapters are not a bad way; they are core to the .Net Framework, easy to get started with and reasonably powerful, although they do not perform quite as well as other options and often require more memory.
Basically Table adapters are good if your data is structured the way you want to view it. If you want to view data in a different way to it is stored you can do this with a table adapter but you loose the ability to write back changes to the database, this is OK if you are just generating a report.
If you want to view and change the data and the data is not in the structure you want to view it you need entity framework so you can query the data to get it into a different format and still have the ability to write any changes back. This is what the call the data from the server the MV to the display the VM