Consider Role-Employee-Address
An employee can have only one role but can have many addresses. So using split on is not efficient as we may get the duplicates of roles and employee. We can use query multiple, but i feel if there is a way we can capture the role and employee together in one result and address in another, then that would be better.
In that case, instead of returning role and employee separately, we can directly join both in a single query and split on some column while mapping.
I'm expecting something like this
string query = "StoredProcedure";
using (var multi = connection.QueryMultiple(query, null))
{
empRole = multi.Read<Employee,Role>().Single().SplitOn("Id");
add = multi.Read<Address>().ToList();
}
Is there any way we could do like this using both the techniques together?
Correct, you need a One-To-Many mapping which is not natively supported by Dapper, but can be easily implemented if the database you're using supports JSON. Here's an article I wrote (along with working samples) that shows how you can do it using SQL Server / Azure SQL:
https://medium.com/dapper-net/one-to-many-mapping-with-dapper-55ae6a65cfd4
Related
I am trying to use Django to create reports from a legacy MS SQL application. The application includes two identical schemas for storing tickets, one called Requests, the other ArchiveRequests.
I would like to create a single QuerySet that holds data from both tables. This can be done in T-SQL like this
SELECT TOP 100 *
FROM [AmCatHDSQL].[dbo].[ArchiveRequests]
UNION SELECT *
FROM [AmCatHDSQL].[dbo].[Requests]
However trying to union them using the | operator raises an AssertionError, Cannot combine queries on two different base models.
Is there a way to tell Django that these models are identical and can be unioned, or is there a better way to reference these (as a single model?)
I need to run a search query like this : SELECT from results WHERE owner=mike,john,tom ...etc which should provide a concatenation of the items owned by those usernames. There may be about 100-200 usernames in the query. Would be feasible to do this using the full text search API (I already use it for keyword queries) using the usernames as filters (e.g. filter(1)=mike&filter(2)=john etc ) or I should try some kind of datastore join operation ?
You could construct a query like this:
owner:mike OR owner:john OR owner:tom etc., but this will not be efficient for a large number of possible owner values.
Instead, consider whether you could group the owners according to some application semantics (e.g. some owners in 'usergroup1', some in 'usergroup2', etc.), and then instead query for documents with e.g. usergroup:usergroup1.
Alternately, if you could assign each owner a numeric value (that makes sense for your application), you can use numeric comparators, e.g. owner_number < 10.
I guess first query is MySQL query, right?
If field 'owner' have index in MySQL query then you could use following structure:
SELECT from results WHERE owner IN ('mike','john','tom')
I can't say too much about APP Engine, but certainly you need to use filters.
I have a LINQ-2-Entity query builder, nesting different kinds of Where clauses depending on a fairly complex search form. Works great so far.
Now I need to use a SQL Server fulltext search index in some of my queries. Is there any chance to add the search term directly to the LINQ query, and have the score available as a selectable property?
If not, I could write a stored procedure to load a list of all row IDs matching the full-text search criteria, and then use a LINQ-2-Entity query to load the detail data and evaluate other optional filter criteria in a loop per row. That would be of course a very bad idea performance-wise.
Another option would be to use a stored procedure to insert all row IDs matching the full-text search into a temporary table, and then let the LINQ query join the temporary table. Question is: how to join a temporary table in a LINQ query, as it cannot be part of the entity model?
I think I would probably suggest a hybrid approach.
Write a stored procedure which returns all the information you need.
Map an entity to the results. The entity can be created for this sole purpose. Alternately, use version 4 of the Entity Framework, which allows mapping complex types to start procedure results. The point is that instead of trying to coerce the procedure results in to existing entity types, were going to handle them as their own type.
Now you can build a LINQ to Entities query.
Sample query:
var q = from r in Context.SearchFor("searchText")
let fooInstance = (r.ResultType == "Foo")
? Context.Foos.Where(f => f.Id == r.Id)
: null
where ((fooInstance == null) || (fooInstance.SpecialCriterion == r.SpecialCriterion))
select {
// ...
This is off the top of my head, so the syntax might not be right. The important point is treating search results as an entity.
Alternately: Use a more flexible FTS system, which can do the "special", per-type filtering when building the index.
I've seen code like this for EF4:
var query = context.ExecuteStoreQuery<Person>(
"SELECT * FROM People WHERE FREETEXT(*,{0})",
searchText
).AsQueryable();
This may be simpler than creating a stored proc or UDP in some cases.
Currently I am designing a database schema where one table will contains details about all students of a university.
I am thinking the way how can I create the search engine query for administrators where they will search for students. (Some properties are Age, Location, Name, Surname etc etc) (approx 20 properties - 1 table)
My idea is to create the sql query dynamically from the code side. Is it the best way or is there any other better ways?
Shall I use a stored procedure?
Is there any other ways?
feel free to share
I am going to assume you have a front end that collects user input, executes a query and returns a result. I would say you HAVE to create the query dynamically from the code side. At the very least you will need to pass in variables that the user selected to query by. I would probably create a method that takes in the key/value search data and use that to execute the query. Because it will only be one table there would probably be no need for a view or stored procedure. I think a simple select statement including your search criteria will work fine.
I would suggest you to use LINQ to SQL and this will allow you to write such queries just in C# code without any SQL procedures. LINQ to SQL will care about security and prevent SQL injections
p.s.
Do not ever compose SQL from concatenated strings like SQL = "select * from table where " + "param1=" + param1 ... :)
Here’s an interesting question. Suppose we have related tables in the database, for example, Instrument and Currency. Instrument table has a currency_id field that is mapped to entry in Currency table. In Linq land what’s the better way:
a) Create Instrument and Currency entities in the DataContext and then create association or simply use join in Linq queries or
b) Create a view in the database that joins Instrument and Currency (thus resolving currency_id to currency code) and use that as an entity in Linq context?
Would you ever use them independently? If so, you will need to have entities for each one that will be used independently. I suspect that you will use the Currency independently (say for a dropdown that allows you to choose a currency when creating an instrument). That being the case, I think it would be easier to just keep them separate and have an association.
With the ORM now abstracting the data access logic that particular function of views is no longer needed. It would be best to leave it to the ORM since thats part of its function.
However views may still be useful to simplify stored procedures code and even for creating useful indices.
If you load in Instrument and later use the Currencies property to load in related Currencies, there will be two queries.
If you issue a linq query with a join, linq will convert that to sql with a join and you get all the data at once.
If you set up a DataLoadOptions, you get all the data in one query and you do not have to write the join.
http://msdn.microsoft.com/en-us/library/system.data.linq.dataloadoptions.aspx
http://msdn.microsoft.com/en-us/library/system.data.linq.dataloadoptions.loadwith.aspx
DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Instrument>(i => i.Currencies)
myDataContext.LoadOptions = dlo;
I find LINQ to be temperamental. I can run the same query 1 minute apart and get a different result. Note I am working of a local database so I know the data hasn't changed. Using a view with a dataset is far more reliable in my option, especially with joins.