Orders grid is containing a sub-grid for order details. Normally I am doing this by implementing RowDataBound event. but I think it is bad idea to fetch order details from database for every row of orders grid. Is there a better way?
Thanks
As far as "bad idea", I assume you mean from a performance standpoint. In my opinion the scenario you describe isn't necessarily a bad idea, depending on the performance expectations of your application. The method you suggest is the easiest to implement that I can think of, and could be the best way if your page isn't going to be hit very often.
Having said that, I can think of two other ways to approach this.
1) Join your order details at the DB level, and render the table manually using a repeater, adding outer rows only when the main order record changes. This method would require only one trip to the database for each page render but requires more coding for presentation.
2) Pre-fetch all of your order details on page load into a DataTable or collection and load your details from there on your outer gridview RowDataBound. This method would also reduce trips to the database down to two (one for the orders, one for order details) but wouldn't require as much presentation coding.
Related
I'm going to display a product detail from a database. But I can't decide whether to use an $.ajax post to a WebMethod that returns a JSON string, or a traditional Page.Load with sqldatareader in codebehind.
I know how to do both, coding is not the issue. I'm wondering what would be faster and more secure?
It depends on what kind of data you are showing on the page. (more of howmuch data)
Lets say if you are showing a fixed amount of data like, summary, product detail then its better to fetch data from server side and bind in label in Page Load event.
But if you are about to display the list of item (which may vary depending on the user input) for example product list, order list, employee list. in that case it is good to fetch the rows using ajax. reason is to display the fixed number of rows on the page (lets say 10) and there should be a pagination to jump to the next/pre page. now when user click next or previous it should not post back the page and should get the rows using ajax.
Each method has its advantages and disadvantages.
AJAX advantages and disadvantages
Advantages:
Forces you to separate the concerns in the code a bit more, you will have the data gathering and the data display in different places
The code will be more testable due to this additional modularity
Disadvantages:
Slower due to the additional HTTP request
Harder to deal with the back button and with bookmarking
Search engine optimization will be harder due to data not being right in the html
The project I am currently working requires retrieving/searching from large amount of data, the flow as below:-
Enter a keyword and search from about 500,000 members
Retrieve only top 6 members.
Allow sorting based on the member country or gender.
Requirements: Using EF5.0
The data is currently displayed using a UserControl and DataBinded using Repeater, will be updated through an UpdatePanel with next, previous button, etc.It is preferably but not limited to using EF5.0, and I am opened to other options (e.g. SqlDataReader) and cast it back to the members object manually.
My current solution calling the Entities with skip by using the page number, i.e.
members = context.Members.Where( conditions here ).Skip(page number * size).Take(size);
My question will be: Is my strategy the industrial / common ways of doing it? Anyone with similar experience can share with me in terms of performance / optimization, is there any other better way to do so?
I got really good performance using a stored procedure, instead of a LINQ query. This saves performance because of the query metadata generation/sql translation. If you are returning a large result set, disabling change tracking is a good option too.
I am using database paging which uses ROWCOUNT check it here https://web.archive.org/web/20211020131201/https://www.4guysfromrolla.com/webtech/042606-1.shtml and it gives really good performance with 200000 records including sorting and paging.
Here's my scenario:
1) User runs search to retrieve values for display in ListView via LinqDataSource.
2) They click on one of the items which takes them to another page where the details can be examined, further drill-down can happen, etc.
3) User wants to go back to the original ListView results to select another item for inspection.
I can see it's possible to pass the querystring params around, allowing the querying to be duplicated each time the user comes back to the ListView, but it seems like there ought to be a way to cache the results.
Since I'm using the LinqDataSource, though, I believe the actual results are fetched each time the query is run. I'm currently feeding a "select new {blah, blah}" type of IEnumerable to the e.Results, which can't be turned into a List since it's populated with anonymous types.
In short:
1) Does it make sense to try to place potentially large query results in the users session?
2) If it does, is a List the reasonable data structure?
3) Do I need to resort to something like creating a class with the correct properties to hold the anonymous data, enumerate the query return, populate the List?
4) Is there a better option than the LinqDataSource for this type goal?
5) Or, does it just make more sense to run the query each time they hit the ListView?
I apologize if this wasn't clear. I would really appreciate it if someone can set me straight before I nuke a bunch of my free time headed down the wrong path :)
First, I would suggest that you look into the caching mechanism that comes with ASP.NET, unless the data is private for a certain user.
Second, I would suggest that you design your application in a way so that you create natural points where you could try to get data from a cache before querying the database (and insert data into the cache, with expiration rules), but don't start putting stuff into the cache until you have verified that it will actually make a difference.
Measure how much time that is actually spent on retrieving data and use caching in the cases where it makes a difference.
I'm not sure if resurrecting threads from the dead is cool on SO, but here is what I found to answer this question:
http://weblogs.asp.net/pwelter34/archive/2007/08.aspx
I'm using ASP.net and an SQL database. I have a blog like system where a number of comments are made against a post and I want to display the number of those comments next to the post. To get that number I could either hold it in the post record and add/subtrack when a comment is added or deleted or I could use the SQL to calculate the number of comments using a query each time a user hits the page. The latter seems to be a bad idea as its going to hit my SQL database harder however holding the number against the record feels like it could be error prone. What do you think is best coding practice in this case?
Always start with a normalized database (your second option). Only denormalize if you have an absolute necessity for performance reasons. Designing it in the denormalized way (which is error-prone as you guessed) is premature optimization. With proper indexes it should be fine calculating the number on the fly.
I think the SQL statement should be fine. The other is duplication of data you already have. A count query should be quick.
Don't optimize prematurely. Use the simple solution and pagefault in optimizations only when they're needed.
I would query the database each time you want the information. I would revisit it later if you find that performance is lacking (optimize later). For the traffic most blog type applications will get, that should be sufficient.
Perhaps get the count back as part of the main thread query so as to limit the number of hits on the actual DB from the webserver. But I would always query the actual count and not try and keep it in a field, data will eventually get out of sync as that is reality.
To increase performance, you could keep a flag in the main table to indicate if the item has any comments but only use this as a 'hint' as to whether or not to perform an additional query to count and retrieve comments at a later time.
Imagine a photo gallery that returns 50 photos to rotate through. Each photo could have its own comments.
The initial page load would return a list of photos plus a flag indicating if a photo has comments.
When a photo is displayed, if the comments flag is set to True, your app would make an ajax request to count and fetch the comments for that photo.
If only 3 out of the 50 photos have comments, you just saved yourself 47 additional requests!
This does denormalize the data, but on a limited level.
Creating hints can really help improve performance for very busy sites.
Depending on how your data model looks...Don't add the total post count to the main thread record, it is error prone, you should calculate the comment count when needed based on the thread ID, IMHO
Caching the pages and updating that cache as comments are added/removed would be a good option a long with the SQL count query if you are that worried about the number of queries happening against the db..
I usually use an indexed view for this kind of thing. This allows you to denormalize the data for quick retrieval, but there is no way for it to get out of sync. Folks will also not be confused and think the view is the master of the data. I have mostly used the standard sku of SS2K5, so I have to specify the (noexpand) hint to get it to actually use the index on the view (enterprise will do it automatically). So for standard sku, I always create a wrapper view that everyone hits so I know the hint is always in place.
Coding this on the web page, so hopefully no syntax errors ;)
create view postCount__
as
select
threadId
,postCount=count_big(*)
from thread
group by threadId
go
create unique clustered index postCount__xpk_threadid on postCount__(threadId)
go
create view postCount
as
select
threadId
,postCount=cast(postCount as int)
from postCount__ with (noexpand)
go
So I use a nomenclature on the actual indexed view to let everyone know not to query it directly. Instead they look for the associated wrapper view that enforces the noexpand hint. Using an indexed view forces you to do count_big, so I often cast down to int in the wrapper view to be able to keep our asp.net code lazily using 32 bit ints. It would be better to omit the cast, but it hasn't been of any significant impact for me.
EDIT - I can tell you that forum software always denormalizes the post count to the thread table. It kills the DB to continually count the post count on every page view if you have an active forum. I love that mssql has indexed views so you can define the denormalization declaratively rather than maintain it yourself.
This is a purely theoretical question (at least until I start trying to implement it) but here goes.
I wrote a web form a long time ago which has a configurable section for getting information. Basically for some customers there are no fields, for other customers there are up to 20 fields. I got it working by dynamically creating the fields at just the right time in the page lifecycle and going through a lot of headaches.
2 years later, I need to make some pretty big updates to this web form and there are some nifty new technologies. I've worked with ASP.NET Dynamic Data just a bit and, well, I half-crazed plan just occurred to me:
The Ticket object has a one-to-many relationship to ExtendedField, we'll call that relationship Fields for brevity.
Using that, the idea would be to create a FieldTemplate that dynamically generated the list of fields and displayed it.
The big questions here would probably be:
1) Can a single field template resolve to multiple web controls without breaking things?
2) Can dynamic data handle updating/inserting multiple rows in such a fashion?
3) There was a third question I had a few minutes ago, but coworkers interrupted me and I forgot. So now the third question is: what is the third question?
So basically, does this sound like it could work or am I missing a better/more obvious solution?
Did you try creating a FieldTemplate that had a "ListView" of all the Fields? (the ListView would use Dynamic Data to determine which FieldTemplate to display for each field.)
I don't see why this would not be possible. Although, "out of the box", you may have to hit "edit" on each row of the new FieldTemplate's ListView to edit the values. It would be like replacing the "Order Details" link in the Orders List, with an inline List of the "Order Details".
1.) Not very nicely. Can you imagine showing a DateTime, Integers, Phone numbers, Urls, etc with just ONE user control, like text.ascx? Why not have multiple field templates and use UIHint to specify usage per column?
2.) Yes.
3.) Define basically?
regarding one to many relationships, you might have a look at the ListDetails.aspx Page Template in Dynamic Data. Hope this helps.