As with any other BI tool AWS Quicksight allows you to add calculated fields. So far, I haven't run into any limitations using them, but I can't help but wonder what is the better design approach? Adding a calculated field in my custom SQL query or using the calculated fields feature?
So there is a few ways to work with calculated fields in Quicksight:
You do them in your SQL query
You add them to your dataset
You add them to your analysis
I am not sure if this would be considered best practice, but my preference has evolved to:
Use calculated fields on an analysis, if I want to contain that field to the analysis only.
If the field will be used more than once, I add them to the dataset. This is my go-to method if I am not using a direct query and relying on the default UI.
For any complicated calculations that are not supported by Quicksight calculated fields or if I am already using a direct query, I'll do everything in SQL.
The downside of calculated fields is that looking up their computation can be a little annoying as it involves a few clicks. Also, I find it hard to differentiate between which fields are calculated and which aren't so I have a habit of prefixing calculated fields with _, e.g. _date or _day_of_week if it is a calculated field.
Related
Is there a way to dynamically append a driving distance of the CONSUMER in ES?
I am trying to create an app and sort PROVIDERS by driving distance.
One thing I could think of is get all the PROVIDERS within a range then put them in an array. Iterate to add driving distance then sort array. But this is not efficient.
Any suggestions?
thank you!
You can use runtime fields to achieve what you want, A runtime field is a field that is evaluated at query time. Runtime fields enable you to:
Add fields to existing documents without reindexing your data Start
working with your data without understanding how it’s structured
Override the value returned from an indexed field at query time
Define fields for a specific use without modifying the underlying
schema
For more information you can check Elasticsearch blog post here, and for runtime fields here.
I have simple data analytics to display in AWS QuickSight: some date fields and amounts. QS aggregates by default all date-fields and the lowest granularity is aggregate by minute. But my need is to display all data without any aggregation at all. I have searched but not found how it could be possible disable aggregation at all? Any ideas?
First contribution to Stack Overflow, feels good man.
I ran into the same problem and the solution is to convert the field selected for the y-axis to a dimension rather than a measure.
Converting fields from measure to dimension
Aggregations will automatically be applied to 'measure' fields and therefore they need to be converted to 'dimension'
i'm facing a big problem in my SolR DB.
My objects have a datetime field "Available_From" and a datetime field "Available_To".
We also have a "Ranking" field for the sorting.
I can search correctly with direct queries (eg. give me all the items that are available at the moment) but when i do a regular search i cannot find a way to show the items that result "available NOW" in the first places in the results, usually sorted by "Ranking" field.
How can i do this? Am I forced to write some java classes (the nearest thing i've found is there https://medium.com/#devchaitu18/sorting-based-on-a-custom-function-in-solr-c94ddae99a12) or is there a way to do with standard SolR queries?
Thanks in advance to everyone!
In your case you actually don't want sorting, since that indicates that you want one field to determine the returned sequence of documents.
Instead, use boosting - apply a very large boost to those that are available now, either through bq or boost, then apply a boost based on ranking. You'll have to tweak the weights given to each part based on how you want the search results to be presented.
Suppose you have millions items(say search results) and you have different parameters for sorting these items(like in eCommerce sites). We will be showing the items using pagination.
Let us say it can be sorted by date, popularity and relevance and results are paginated. How would you implement this functionality? Generally I would create different compare functions for parameters and get results accordingly.
If there any other efficient way to have this kind of functionality instead of sorting the search results every time? Also, do we generally run sql query every time using relevant order parameter or should we sort the search result of previous query to save us from re-searching time?
"If there any other efficient way to have this kind of functionality instead of sorting the search results every time?"
I would say you do not need sort every time but execute SQL query with appropriate OrderBy parameter, paginate it and show to the user
"Also, do we generally run sql query every time using relevant order parameter or should we sort the search result of previous query to save us from re-searching time?"
For sure you need to generate a new SQL query, as the first page data based on a new order parameter can contain completely different set of data from previouse one.
I have a search page with multiple search options(input text boxes) Based on the search criteria entered , I need to create a dynamic search query. (I need search results based on the fields for which user inputs some value)
or you can use <af:quickQuery> for a simple search. Here's the sample code taken from Oracle demo.
<af:quickQuery label="Search" id="search" searchDesc="search" binding="#{editor.component}" value="#{demoQuickQuery.queryDescriptor}" queryListener="#{demoQuickQuery.processQuery}">
</af:quickQuery>
If you are using ADF/BC, this is built-in. Just use the <af:query/> component.
af:query is the more robust of the two query components, but does require you create a viewcriteria object in the VO that will be the basis for the query. However it is very powerful: dynamically add new attributes to the query at runtime, change query rules (starts with, contains, etc)
af:quickquery allows you to choose one and only one attribute to query on at a time.
Please note: these components (and the executewithparms) are the only supported query methods in ADF Faces 11g