I have a doubt about efficiency of a query I need to use to retrieve data from my DB for xamarin mobile app.
I'm using Azure SQL as db and entity framework as ORM. The situation is similar to this:
I have a table with some columns (including ID column)
App sends a list of IDs to my APIs (List IDs)
I'd like to retrieve data of row according to IDs
Now I'm using something like that:
_context.MyTable.Where(x => IDs.Contains(x.ID)).ToList();
It works very good but is it the best way?. Will it work with a lot of data
Related
I have a .Net Core 2.1 Web API which talks to two MySQL databases. Therefore I have two DbContexts, each with a connection string pointing to the relevant database.
In one of my controller actions, I need to return data which requires a join between two tables, one from each database. Is it possible to do this?
As an example, a simple controller action to retrieve data might look something like this:
[HttpGet]
public IEnumerable<Employee> GetEmployees()
{
return _context.Employees
.Include(e => e.Departments);
}
That example uses one controller only, because in that example both the employee and department tables are in the same database, and therefore both their DbSets would be in the same DbContext.
But what if the employee table was in one database and department table was in another? Then the DbSets for employee and department would be defined in different DbContexts. How could I handle the join in that case? (So that in the example above, the "Include" works properly?
I would imagine that I would have to inject both DbContexts into this controller. But I'm not sure where to go from there...
In my case, both datbases are MySQL databases, and both are on the same server, so that is the only scenario I'm interested in.
After more research, it looks like I could maybe use raw SQL to achieve this. However, what I ended up doing is creating a view on the server which does all the necessary joins, and then I simply call this view...
I am new on parse server ( parse.com ). I have two classes "students_records" and "students_fee". I am storing fee records in class "students_fee" with objectId of "students_records" in column "student_id". Now I want to collect records from both classes by one query similar to join query we do in mysql with base on column 'fee_year' in class "students_fee". for example get all students who have 'fee_year'=2016 and 'student_id'=objectId of "students_records", this is link https://parseplatform.github.io/docs/js/guide/ of guide I am currently getting help, but i can't find such thing. Can anyone tell me how to do that?
Thanks.
Since parse use MongoDB (NoSQL) behind the scenes there is no real "join". What you can do is to create a array relationship from students to records and then use include in your query in order to include all the records under a student.
You can read more about it here.
I recommend you to use Parse SDK's here in order to keep it simple.
the Parse SDK is available for all the popular programming languages (e.g. iOS, Android, PHP, JavaScript and more)
I would like to provide an OData interface for my application. The examples that I have seen use EF to map the LINQ queries to SQL queries.
IMHO it this approach pretty much exposes the physical database model to the world (I know EF/NH give some flexibility, but it is limited).
What I would like the be able to do, is the following:
Define my Data Contract via some DTOs.
Have a OData Service that will let users query over my Data Contract Dtos.
Have some translation layer to translate the queries over the DTOs to queries over, let's say, EF model or NH.
Execute the translated query.
Map the results back to my Data Contracts.
Am I out of my mind or is there a solution to this problem?
I have 2 models, the "contract" model and the "persisted" model. The persisted model is what Entity Framework is mapped to. The Get method that returns an IQueryable returns a IQueryable which is just something along the lines of:
return dbContext.PersistedCustomers.Select(x => new Customer(Name = x.OtherName, ...));
At least when using DbContext as opposed to ObjectContext, Where criteria based on the contract model get translated automatically into Where criteria of the PersistedModel to be executed against the database. Hopefully the differences between the two aren't that complex that you need some weird data massaging. I'm sure there's limits to the reversal it does.
One way of doing it would be to create a ViewModel that will represent your Model and then use AutoMapper to map between them. You can use like this:
var address = _Context.Addresses.Where(p => p.AddressID == addressID).Single();
AddressVM result = Mapper.Map<AddressVM>(address);
I want to update many records in a 10 million record database. Examples here suggest that updates can be done like this:
Customer c = (from x in dataBase.Customers
where x.Name == "Test"
selext x).First();
c.Name = "New Name";
dataBase.SaveChanges();
but this looks like two trips to the database. One to get the record and the other to save the record. If I updated a thousand records in one call, I think this would have to pull 1,000 records from the database to my WCF server, make the change, then push the 1,000 records back over the LAN to the database server.
In the old days, "Update Customers set Name = 'Test' where Year < 1960 " would be one instruction over the LAN and the work is done at the database server.
Is there something like this in Linq to Entities?
*BTW: This is a simple example of what I'm trying to achieve, I actually have hundreds of commands to issue and I don't want 2*hundreds of trips to the database, nor do I see the need to bring all the data from the database to WCF just to change it and send it back!*
As you suspected. If you have 1000 records, you would indeed see 1001 database requests for this operation. ORM's are great for pushing objects into memory, working with them and then updating them. They are not good for bulk operations. In this case your best bet would be to either use ADO.Net and pass your update statement via code, or to put your bulk update command in a stored proc and map that proc to a function in EF.
I am currently working on a project where we are rewriting software that was originally written in Visual DataFlex and we are changing it to use SQL and rewriting it into a C# client program and a C#/ASP.Net website. The current database for this is really horrible and has just had columns added to table or pipe(|) characters stuck between the cell values when they needed to add new fields. So we have things like a person table with over 200 columns because stuff like 6 lots of (addressline1, addressline2, town, city, country, postcode) columns for storing different addresses (home/postal/accountPostal/ect...).
What we would like to do is restructure the database, but we also need to keep using the current structure so that the original software can still work as well. What I would like to know is would it be possible using Linq to write a DataContext Object Model Class that could sort of interpret the data base structures so that we could continue to use the current database structure, but to the code it could look like we where using the new structure, and then once different modules of the software are rewritten we could change the object model to use the correct data structure???
First of all, since you mention the DataContext I think you're looking at Linq to SQL? I would advice to use the Entity Framework. The Entity Framework has more advanced modeling capabilities that you can use in a scenario as yours. It has the ability to construct for example a type from multiple tables, use inheritance or complex types.
The Entity Framework creates a model for you that consists of three parts.
SSDL which stores how your database looks.
CSDL which stores your model (your objects and the relationships between them)
MSL which tells the Entity Framework how to map from your objects to the database structure.
Using this you can have a legacy database and map this to a Domain Model that's more suited to your needs.
The Entity Framework has the ability to create a starting model from your database (where all tables, columns and associations are mapped) en then you can begin restructuring this model.
These classes are generated as partial so you could extend them by for exampling splitting the database piped fields into separate properties.
Have you also thought about using Views? If possible you could at views to your database that give you a nicer dataschema to work with and then base your model on the views in combination with stored procedures.
Hope this gives you any ideas.