Here's what I want to do.
I have a big xml file (there are a lot of daily records... let's say for every 3 hours there are some production records (pieces, scrap and so on). Now... I parse this XML in jQuery and I want to put the data in a jqGrid then show it as a chart with highcharts. The problem is that I don't want to show every record... just the daily results or weekly or monthly so what I need is to sum up all those 3 hour reports by date or by week or by month. I know how to do it... but since there are a lot of records looping through the xml multiple times is not the best idea. So... is there any jquery function or something that will help me do this task more efficient? Or easier?
Thanks! If you didn't understand what I want please ask and I'll add more details.
You can try use client side grouping with groupSummary. See the demo from the answer as an example.
I am not sure that it's exactly what you need, but I hope that you can change the solution so that it's corresponds your requirements.
Related
I have an apparel list in Google Sheets with the following columns:
This is only a little part of it. It actually has over 9K items. So here's the thing, I have to manually search each of those legacy numbers on a HTML list provided by the client, which looks like this:
As you can see on the last column, there are some texts like "Completed", "Customer Review", etc. Those values have to be parsed on the google sheet "Status" column. After reviewing some orders and copying those values, the sheet looks like this:
Now, imagine doing this process individually with 9K+ orders, it's a pain in the ass. So I thought there could be a way to automatize this, maybe parsing the values from the HTML through some Javascript to a CSV or anything similar. I've been doing some research but haven't found anything. I'm not asking you to do the job for me. I'm looking for a hint to start this correctly, as it would make a lot easier and faster the work.
Note: this "automatization" isn't a task or job requested to me, I'm a designer (with some programming background) and I have to do the manual process with a deadline, so I thought I could try and speed up this.
Thanks in advance.
I would try using IMPORTHTML so you can add the data from the HTML list on a different tab in Google sheets and then perform an INDEX MATCH or an ArrayFormula to get the data that you need.
There are many ways to compare the data that you need using different formulas, if you can create a demo sheet we could help you finding a formula that could perform the query of the data that you need. As a friendly reminder always try to include a minimal example that reproduces the issue. That way we can provide better insights about what you want to achieve.
I am fairly new to javascript, and this is my first project involving sql. I'm making an ordering system, and i'm populating an order form based on an sql inventory database. I've figured out how to import the product descriptions, and how to change the number of inputs based on how many rows, but I don't know how to read the result of a SELECT count() with javascript, and use that to set the number of inputs. I'm also not sure if I'm doing this entire thing efficiently in the first place, so if anybody's willing to pm me for more details and help me streamline it, I would appreciate it greatly.
I have a lot of data which is date based in nature but with irregular reporting intervals. What I was hoping to do is to have my PHP backend send the data to the frontend JS/jQuery to display but in order to report effectively I need to be able to report by "week", "month", etc. I could try and do the SQL on the backend and structure different data series for each interval but that would be CPU intensive on the backend and I'd like the frontend to be a bit dynamic in being able to move between these intervals (aka, "show me monthly, no wait, show me weekly", etc.)
What I'm looking for -- I think -- is a JS/jQuery library that will help me take tabular data and group/aggregate it based on date based conditions. If need be I could try adding a column to the tabular structure which specifies the week number (and thereby simplifies the data math on frontend). In any case, I'm flexible at the moment and just hoping to hear of some good resources or approaches that have been tried before to solve this kind of problem.
Note: I am using jqGrid for tabular views on the frontend and Highcharts for graphical presentation. This is potentially not important but it might also open some creative alternatives.
I'm looking to create or find a screener tool similar to this that will read through the records in a database, allow you to select the criteria, create a histogram of said records and criteria, and allow the user to sort and filter through the data, just like the Google Stock Screener.
How would I go about creating something like this or is there somewhere that I could find a plug-in that would allow this? Thanks.
I think Flot would be a good javascript library to try for this. I've used it to display share market data in the past and it deals with time series data fairly well. It's not very hard to add interactive elements.
Are there any best practices for returning large lists of orders to users?
Let me try to outline the problem we are trying to solve. We have a list of customers that have 1-5,000+ orders associated to each. We pull these orders directly from the database and present them to the user is a paginated grid. The view we have is a very simple "select columns from orders" which worked fine when we were first starting but as we are growing, it's causing performance/contention problems. Seems like there are a million and one ways to skin this cat (return only a page worth of data, only return the last 6 months of data, etc.) but like I said before just wondering if there are any resources out there that provide a little more hand holding on how to solve this problem.
We use SQL Server as our transaction database and select the data out in XML format. We then use a mixture of XSLT and Javascript to create our grid. We aren't married to the presentation solution but are married to the database solution.
My experience.
Always set default values in the UI for the user that are reasonable. You don't want them clicking "Retrieve" and getting everything.
Set a limit to the number of records that can be returned.
Only return from the database the records you are going to display.
If forward/backward consistencency is important, store the entire results set from the query in a temp table and return just the page you need to display. When paging up/down retrieve the next set from the temp table.
Make sure your indexs are covering your queries.
Use different queries for different purposes. Think "Open Orders" vs "Closed Orders". These might perfrom much better as different queries instead of one generic query.
Set parameter defualts in the stored procedures. Protect your query from a UI that is not setting reasonable limits.
I wish we did all these things.
I'd recommend doing some profiling to find the actual bottlenecks. Perhaps you have access to Visual Studio Profiler? http://msdn.microsoft.com/en-us/magazine/cc337887.aspx There are plenty of good profilers out there.
Otherwise, my first stop would be pagination to bring back less records from the db, which is easier on the connection and the memory footprint. Take a look at this (I'm assuming you're on SQL Server >= 2005)
http://www.15seconds.com/issue/070628.htm
I"m not sure from the question exactly what UI problem you are trying to solve.
If it's that the customer can't work with a table that is just one big amorphous blob, then let him sort on the fields: order date, order number, your SKU number, his SKU number maybe, and I guess others,too. He might find it handy to do a multi-column stable sort, too.
If it's that the table headers scroll up and disappears when he scrolls down through his orders, that's more difficult. Read the SO discussion to see if the method there gives a solution you can use.
There is also a JQuery mechanism for keeping the header within the viewport.
HTH
EDIT: plus I'll second #Iain 's answer: do some profiling.
Another EDIT: #Scott Bruns 's answer reminded me that when we started designing the UI, the biggest issue by far was limiting the number of records the user had to look at. So, yes I agree with Scott that you should give the user some way to see only a limited number of records right from the start; that is, before he ever sees a table, he has told you a lot about what he wants to see.
Stupid question, but have you asked the users of your application for input on what records that they would like to see initially?