We are planning to develop a charting application based on Silverlight(using infragistics xamdatagrid). The application will be very much like Google Finance like charting tool with an ability to view historical data. We have a master table that has stock indicies and a bunch of other parameters for the last 20-25 years.
Is it wise to use RIA services to retrieve the data and render the data charts on a silverlight application? Also please note that the master table in the database may be subject to many changes(addition or removal of columns) and we would not like to always update the service/webapp to reflect the changes and therefore needed the design to be generic.
Hope not too much late, anyway I hope this answer could help others. I recommend for this scenario create a Data Warehouse to make the queries to create the charts against it and not against the real active and frequently changing source database.
Related
I looking simplest way to implement master detail winforms app (using mainly data grid view)
It should interact with database, handling database exceptions (eg unique index violation) and work in multi user environment (concurrent updates etc)
I know how to do that with data set and relation between tables, not sure what is best approach if this has to work with database
Few years ago I did similar app base on business objects and stored procedures but I believe this can be done easier this days.
Appreciate if someone can share general ideas or share some links to webpages discribing that in detail
A DataSet combined with a BindingSource could be, what you are looking for.
For a simple master/detail view it provides everything you need.
Connection management.
Certain degree of error handling.
Binding every kind of control to your data
In simple cases, like yours, almost everything can be done in Visual Studio GUI
Data-navigation controls
BindingSource
BindingNavigator
I have some SQL Server Store Procs that generates statistical data for charting in a C# web application.
Right now the user in the web app has to wait about 5 minutes to see these charts with updated data and this is a pain in the neck for the user and for me.
Some of the Store procs takes more than 5 minutes to generate the data but the web user don't need to see the info on the fly. Maybe update the chart every 2-3 hours.
So, I dont know what is the best practice to solve this.
I was thinking on creating a windows service that every 2-3 hours will call the SP's and then store the data in different tables.
Any clue on how to deal with this?
Appreciate the help
As I said in the comments, indexed views (kind of like materialized views) can increase performance of certain common queries without having to make temporary tables and things like that.
The benefits of indexed views are performance and that it doesn't require much extra coding and effort. When you create an indexed view as opposed to a temp table, the query navigator will (should) know when to take advantage of this view, without the end user needing to specify a temp or aggregate table.
Examples of the benefits of indexed views and how to implement them can be found here http://msdn.microsoft.com/en-us/library/dd171921(v=sql.100).aspx
here are some links to indexed views. Like the comments said, views allow you to quickly get information rather then always doing a select every time using a stored proc. Read the second link for a very good explanation about views.
MSDN
http://msdn.microsoft.com/en-ca/library/ms187864%28v=sql.105%29.aspx
Very well explained here
http://www.codeproject.com/Articles/199058/SQL-Server-Indexed-Views-Speed-Up-Your-Select-Quer
Ok, this is very "generic" question. We currently have a SQL Server database for which we need to develop an application in ASP.NET with will contain all the business logic in C# Web Services.
The thing is that, architecturally speaking, I'm not sure how to design the web service and the data management. There are many things to consider :
We need have very rapid access to data. Right now, we have over a million "sales" and "purchases" record from which we need to often calculate and load the current stock for a given day according to a serie of parameter. I'm not sure how we should preload the data and keep the data in the Web Service. Doing a stock calculation within a SQL query will be very lengthy. They currently have a stock calculation application that preloads all sales and purchases for the day and afterwards calculate the stock on the code-side.
We want to develop powerful reporting tools. We want to implement a "pivot table" but not sure how to implement it and have good performances.
For the reasons above, I'm not sure how to design the data model.
How would you manage the display of the current stock, considering that "stock" is actually purchases - sales and that you have to consider all rows to calculate it ? Would you cache "stock" data in the database to optimize performances, even though its redundant data ?
Anybody can give me any guidelines on how to start, or from their personnal experiences (what have you done in the past ?)
I'm not sure if it's possible to make a bounty even though the question is new (I'd put 300 rep on it, since I really need something). If you know how, let me know.
Thanks
The first suggestion is to not use legacy ASMX web services. Use WCF, which Microsoft says should be used for all new web service development.
Second, are you sure you can't optimize the database, or else place it on faster hardware, or nearer to the web server?
I don't know that you're going to get that much data in memory at once. If you could, then you could use a DataSet and use LINQ to DataSets for queries against it.
I hope I hope I'm misunderstanding what you wrote, but if by
contain all the business logic in C# Web Services
you mean something like this then you're already headed in the anti-pattern direction. Accessing your data from an ASP.NET application over web-services would just cause you to incur the serialization/deserialization penalty for pretty much no gain.
A better approach would be to organize services you want to make available into a common layer that your applications are built on and access them directly from your ASP.NET application and maybe also expose them as Web Services to allow external sources to consume this data.
You could also look into exposing data that is expensive to compute using a data warehouse that is updated at regular intervals (once or a couple of times/day). This would help with getting better read performance out of data (as long as you're willing to accept data being a bit stale).
Is that the kind of information you're looking for?
I am designing a dashboard application (An asp.net web app) where I get the latest updated data in a grid format. The grid should contain all the real time info. The dataaccess is from most of the tables and may have a 1-many relations and aggregates. So for each record, I loop thru 100's of tables to get the aggregates of all tables. What are the best practices for designing a dashboard application which is database read intensive. I am expecting more than 1000's to be able to access the app at a time. Any Design patterns I should follow? or any best practices etc.?
If your data doesn't need to be absolutely real-time, you could cache your results so queries don't have to be run so often.
Performing lookups across hundreds of tables sounds like it will perform really badly when a lot of traffic starts hitting it. You should cache stuff as much as possible. Even if you only cache the data for 20-30 seconds, it will be better than always retrieving data in real time.
How you go about doing this depends on your architecture. If using ASP.NET, you could look into Microsoft's ASP.NET Caching Overview for some better ideas.
I'm writing a website that will sell items from one of my classes. It will be linked to a SQL Server db where I will pull pricing, item name, quantity and description. If I wanted to display the items from the database in a thinkgeek fashion, what would be the best control to use so I can custimize the display to actually look ok?
You'll get the best flexibility with an asp:Repeater. This means you'll have to program more, but it will give you more flexibility.
Not sure if you have any technology requirements, but the ASP.Net has a new type of ASP.NET project called the Dynamic Data project. Using that project you can point to your SQL Server and generate pages to display and edit the data. Pretty easy to get up and running quickly using that.
I'm a fan of the ASP.NET GridView & DataGrid, throw in some template fields for your images and links and what not.
#rslite and #Bryant both have good suggestions. My initial go of the problem would probably involve creating a "Thinkgeek-esque" user control, and plopping that into a repeater for display. However, the DDP would be a good call as well. Really depends on deeper level requirements than you mention.