Setup
I'm creating a react app to save and retrieve daily reports from MongoDb Atlas database. There can be only one report per day per user. The search criteria for daily reports is the date of course.
Logic and code
The app has a calendar widget from material-ui datepicker. It returns the selected date with the current UTC time. But if I search the database using that directly, then obviously I won't find anything because of the difference of hours:minutes:seconds:milliseconds. It's impossible that the Date() that you're searching for would have the exact millisecond match with the time the report was created. So my idea was to store the date for each report with a time of exactly 12am i.e. 00:00:00:000Z as well as search the database with a date of time 12am.
selectedDate.setUTCHours(0,0,0,0); //sets the time to 12am
selectedDate.toISOString();
Question
Is this the right approach for this case? Will I face problems down the line doing it this way? How should the date be stored if it's the search criteria and if it has to be the exact match? Also it must serve any user around the world to save and retrieve their reports.
Thanks,
Suraj
You can store the date as you like, just in your db query use between condition
SELECT * FROM reports WHERE date BETWEEN '2020-05-01 00:00:00' AND '2020-05-01 23:59:59'
Related
So I'm having trouble trying to configure a new cube that takes a snapshot of my company's open orders each day. Every night, a snapshot is taken and stored in the data warehouse with a date key for the date the snapshot was taken. This date would be the one that we want to be non-additive. However, we also have other dates in this data set, such as scheduled ship-date, order date, etc. that are fully-additive, just like the other non-date dimensions.
Does anyone have any advice on how I can create a cube for this data so that the order totals can be summed across the other dates, but the capture date is LastNonEmpty?
The first connected Date dimension in the Dimension Usage tab is the semi-additive Date dimension. The rest are additive. I describe the exact behavior here.
This answer applies to Multidimensional cubes (not Tabular) which is what I assume you have since you mentioned LastNonEmpty.
I created a simple report to track the funds raised for our primary school. Just a pie chart that picks data from a Google Sheets being maintained by the treasurer.
There is now a request to add a timestamp on the screen (the report is being shared by taking a screenshot and sharing in various social media platforms to report progress).
After some Googling I couldn't find a function that returns current time. Something like =now() in Sheets. However, it was recommended to try create the time in the source data.
So I created a field that stores the value of the current time in Google Sheets using this function:
=(now()-date(1970,1,1))*86400
I also set the Sheets to refresh every minute. The Sheets works perfectly.
On the Studio side I added a calculated field to display the time in my preferred format:
TODATE(Amount,'SECONDS','%H:%M:%S on %d %b %Y')
Again, this conversion works perfectly.
The problem is that the time refresh doesn't work on the report side. No matter how many times I refresh the data it still doesn't pick the updated time from the source. Yet the source sheet has the updated time.
As far as I can tell, the worksheet time update has to be triggered manually for the report to be updated.
That negates the whole purpose of the timestamp.
Sharing the report directly from Google Studio is not a practical option for now. Still, I have shared the report.
0) Summary
Use either:
#1 New Recommended Approach: Using Scorecards
#2 Original Suggestion: Using Tables
1) New Recommended Approach: Scorecards
It can be achieved using the CURRENT_DATETIME function (released on the 17 Sep 2020 Google Data Studio update to Dates and Times).
The below looks at three use cases using Scorecards which are aggregated by MAX or MIN (in the below scenario either aggregation would display the same Date Time); the fields will automatically update based on the chosen Data Freshness settings (for example, the Google Sheet used in this Report is set to refresh every 15 minutes) and can also be manually updated if required (by clicking on the refresh icon at the top of the report or using the shortcut keys Ctrl + Shift + E):
1.1) UTC
The default function would display a value based on UTC:
CURRENT_DATETIME()
1.2) Time Zone
A Time Zone could also be specified; for example, the below would display the the EST Time Zone:
CURRENT_DATETIME("EST")
1.3) Location
A location can also be specified, based on the TZ database name, for example, Colombo, Sri Lanka would be:
CURRENT_DATETIME("Asia/Colombo")
Added an Editable Google Data Studio Report and a GIF to elaborate:
2) Original Suggestion: Tables
The below looks at three use cases (outlined above) created using Tables.
Added an Editable Google Data Studio Report and a GIF to demonstrate:
There isn't a function to do that yet but hopefully will come soon (see:https://issuetracker.google.com/issues/78200216 which is assigned) however with a little careful design, you could achieve it using date rather than timestamp utilising a date filter.
If you don't have a date field in your data than you could simply set this to TODAY.
If you do have a date field then use the advanced date to set a start date of your field's earliest date and max date of TODAY.
You could then use some shapes / formatting to cover up what isn't needed.
Hardly ideal but maybe a stop gap?
There is a variable TODAY() that doesn't seem to be documented in their Function documentation but that works in calculated fields and may help you
I have created a report pulling data from four different datasets with all containing a parameter of startDate and EndDates. All datasets include the same table where this parameter is found. I want to create a subscription email for users to receive on a weekly basis (-7 days from run date).
You can setup an Email Subscription in SSRS in Report Delivery Options section. Please watch this video for more details.
If you don't have an E-mail Delivery Extension configured on your Reporting Services yet then please read the detailed guidelines here.
When creating a report, I create parameters for the dates and set the default values for the desired range on a regular basis.
If you want the previous weeks worth of data on a given day, you could use
=TODAY.AddDays(-7)
for the Start Date default value and
=TODAY.AddDays(-1)
for the End Date default value. On 6/4 this gives 5/28 for the Start date and 6/3 for the End Date.
With these default values, your report will always run for the previous week but can also be run for other dates when necessary.
Challenge :
I have a requirement in which I have to implement recurring events. I am storing day of the week , time and the date range for which the event will reoccur.
Possible solution:
Storing time and day of week as string and enumeration.
Storing current and setting the time and day for that day ?
Question :
What is the best practice on storing time and day of week ?
EDT: I am using SQL Server Database
Another alternative is to have computed columns representing the parts that you're after.
CREATE TABLE dbo.foo
(
bar DATETIME,
bar_day_of_week AS DATEPART(WEEKDAY, bar),
bar_time AS CONVERT(TIME, bar)
);
INSERT dbo.foo(bar) SELECT GETDATE();
SELECT bar, bar_day_of_week, bar_time FROM dbo.foo;
This best approach might dependson the database you are using. But, there are two general approaches, both quite reasonable.
The first is to store dates and times in the native format for the database. Most databases have functions to extract day of the week and time from a date time type. You would write your queries using these functions. Typically, you would store these as one field, but sometimes you might want to separate the date and time portions.
The second is to have a calendar table. A calendar table would have a date or dateid as a key, and then contain columns for what you want to know about it. Day of the week would be an obvious column.
A calendar table is the preferred solution in some situations. For instance, if you are going to internationalize your application, then being able to get day of the week from a table makes it easier to get the string English, Greek, Chinese, Russian, Swahili, or whatever your favorite language is. Or, if you want to keep track of specific holidays, then a calendar table can store this information as well. Or, if you have a business running on a strange financial calendar (such as 5-4-4), then a calendar table is a good choice.
In either case, you do not need to store redundant date information in the table. You should derive it, either from a built-in function or by looking up what you want in a reference table.
Create_date -> Assume it will record as 5/2/2009. For search purposes when searching create date can we search by individual month or year from this or do we need to even record a create_day, create_month, crate_year for this? Once of the search filters for user content will be like example -> "Show content from last 2 weeks, last month, last year, current month only"
create_day -> While we record numeric date, many times for we may need to display the text day (ie: Thursday) to show when the object was created. Like we see on social websites "created on Thursday, Jan 29, 2009 at 3:45pm". To get this output, do we need to record a create_day for all objects / activities or is it calculated on each page load at application level?
create_time -> What time are we storing in DB? User local time or a fixed time? This is a global website. If fixed then let's say I do GMT by default. Then next question is how to display the correct time to a user so it matches his local time? Must factor into calculation that in US time changes twice a year (day light savings). OR, maybe record time always in GMT but display it to users based on their detected time zone,but then that means calculating time from timezone on each page load?
And since I am here, a side Q-> Any difference between lookup and reference table? How to distinguish these two tables -> "Account_status" which has values Active, Confirmed, etc... AND another table "City" which has city names. First table is a system ID table used in back end only. The city table is ID table used by users to select city from. Are these both lookup or reference or same/different?
Create_date You'll usually want to use the DMBS underlying date storage type which stores all pieces of a date (and time if need be, like MySQL datetime). This opens up the ability to use date processing functions within the DBMS. For the filter example, you would calculate what the date was at 2 weeks ago. You may also get have a function to specify such a string in the DBMS. PHP's strotime() allows this.
Create_day The text output is either automatic (MySQL datetime for instance) or it's easy to render whichever piece you need. (PHP date() can do this). It's generally a Good Idea to store a time stamp (datetime) for every record.
Create_time If it's a global app you'll want to use UTC/GMT. Every user will have their offset applied to the times and as well as their form submissions (such as searching). PHP's DateTime objects allow specifying a timezone name as the offset. The user can choose from a list but in it's standard form that's a big list and isn't much towards usability if it doesn't even match their city (http://us.php.net/manual/en/timezones.php). The other option is getting the user's computer's timezone via Javascript.
Lookup Table Yes those are both lookup tables.