Does anyone know if SurveyCTO or Qualtrics have the ability to restrict data access based on physical location? For a specific project, we're thinking about storing the data on Qualtrics (or SurveyCTO if it works better) with a restriction that the data can only be accessed in the specific country the data is being collected. Does anyone have experience with this?
Tried googling but found no clear answer.
Related
I am writing an app where there is not a lot of interaction with other users. Set and retrieve your own data only.
In Firebase Firestore how could I model this so that everything fits under a users UID?
Something that would look like this?
users/{uid}/user/
users/{uid}/settings/
users/{uid}/weather/
If I want to achieve something like this, then I need to create another UID:
users/{uid}/user/{uid}/{userInfo}
This feels a bit off to me.
Is this wrong? Would it be better if I moved every subcollection into its own collection?
Is this faster / more efficient?
Any help is appreciated!
The most common approaches for me:
Store the profile information, settings and weather in the user document (your {uid}) itself. This most common for the profile information, but it's always worth considering for other types too: do they really need to be in their own documents?
Have a default name for a single subcollection for each user, and then have each information type as a document with a known name in there. So /users/$uid/documents/profile, /users/$uid/documents/settings, and /users/$uid/documents/weather. So now each information type is in a separate document, meaning you can for example secure access to them individually.
If the information for a certain type is repeated, I'd put that in documents in a known/named subcollection. So if there are many weathers, you'd get /users/$uid/weather/$weatherdocs. So with this you can now have an endless set of the specific type of information.
Neither of these is pertinently better/worse, as it all depends on the use-cases of your app.
There will be performance differences between these approaches, as they require a different number of network requests. If this is a concern for your app, I'd recommend testing all approaches above to measure their relative performance against your requirements.
Here is what I want to do:
Users are getting logged in and then save data (such as thier e-mail, their work, their adress and so on). I saved this data at „/userProfile/exampleUID“. This works as I wnat it to.
Then every user should create his or her own story. Within this stories, mostly strings should be stored. A friend of mine told me, that it would be better to normalize my data, so I thought of saving the stories to „/storyData“. He also told me, that every Story has to have a unique identifier as well, which i create with .push(). Under this identifiers I want to store the users unique id (auth().currentUser.uid) to assign the story to the user who has created it. The strings for the stories should also be stored under the unique ID created by .push(). („/storyData/exampleStoryID/exampleUID“)
The problem is now that i can’t find a method to access this strings or the "/exampleUID". In this case I would need to skip the „/exampleStoryID“-child when creating a query, because without saving I would not know its name. Am I right or did I oversee the method for this?
There would be solutions to this:
I have to save the „.key“ of the „/exampleStoryID“ to the „/userProfile/exampleUID“. With this key I would not need to skip one child while querying, because I can enter this key to Access the data in /“storyData“.
I have to denormalize my data. For me, this would mean that I have to create a new child: „/userProfile/exampleUser/storyData“. Here I could save all the strings.
It may be possible that there will be more data like „/storyAnalysis“ and „/storyComments“. Having that in mind: Which solution should I prefer?
Or do you have other suggestions?
Thanks in advance.
MfG
I've been struggling for a couple of days trying to figure out the best way to design a database of a large data set on Firebase, I even wrote a question on database administration site.
I came up with a design, I don't know that's what's called denormalized data or not. I want to minimize querying time of data and also not making inserting/updating data so hard.
Here's my design:
Is that the right database design for this kind of data ?
(Please check my question at database administration site for more details about the nature of the data).
But also here's a short description of the data nature:
So I have an affiliator_category which maybe banks, clubs or organisations. And each category contains a number of affiliators and each affiliator contains number of stores divided into store_category, each store has a number of offers.
And for the user side (the one who do the shopping). A users has a number of memberships in several affiliators, and a number of spendings he/she does.
I'm writing a simple Wordpress plugin for work and am wondering if using the Transients API is practical in this case, or if I should seek out another way.
The plugin's purpose is simple. I'm making a call to USZip Web Service (http://www.webservicex.net/uszip.asmx?op=GetInfoByZIP) to retrieve data. Our sales team is using a Lead Intake sheet that the plugin will run on.
I wanted to reduce the number of API calls, so I thought of setting a transient for each zip code as the key and store the incoming data (city and zip). If the corresponding data for a given zip code already exists, then no need to make an API call.
Here are my concerns:
1. After a quick search, I realized that the transient data is stored in the wp_options table and storing the data would balloon that table in no time. Would this cause a significance performance issue if the db becomes huge?
2. Is this horrible practice to create this many transient keys? It could easily becomes thousands in a few months time.
If using Transient is not the best way, could you please help point me in the right direction? Thanks!
P.S. I opted for the Transients API vs the Options API. I know zip codes don't change often, but they sometimes so. I set expiration time of 3 months.
A less-inflated solution would be:
Store a single option called uszip with a serialized array inside the option
Grab the entire array each time and simply check if the zip code exists
If it doesn't exist, grab the data and save the whole transient again
You should make sure you don't hit the upper bounds of a serialized array in this table (9,000 elements) considering 43,000 zip codes exist in the US. However, you will most likely have a very localized subset of zip codes.
Suppose you are writing a survey application and would like to somehow guarantee results to be secure from user stand point. Put simply, i know what IP you came from but i want to make sure you sleep well at night knowing i know nothing of your responses. I can't store IP in raw form.
I do need to guarantee 1 thing though, that is that you answer questions once. So once your PC comes in with some data, i need to recognize that your PC already has responsed to the survey.
Any suggestions on how to best handle it?
Thanks
-mac
Create a one-way hash of the IP address (and any other unique identifying attributes), and store the hash with the response. That way no one can lookup the IP address for a response, but you can compare the hash to previously submitted responses to keep ensure people only submit the form once.
There's not much you can do to convince someone your respecting their privacy. Just don't abuse the trust, and people will work it out.
(For an idea on how to create a hash in java see How can I generate an MD5 hash?)
You can't guarantee either of these. All you can do is raise the bar so it's harder to get around it. If someone really wants to get around your tracking they can if they know enough about your system. Good thing is most people either don't want to bother or don't know how.
You can generate a cryptographic hash and store that in a cookie on the persons browser if you want to prevent proxy problem. Lots of websites do this to keep session creation to track authentication. This is something like using an HMAC to generate something that identifies the browser with a unique key that can't be faked. If they clear their browser though you won't be able to track them.
One way hash of IP address is a way to keep your IP from being tracked, but the same IP always hashes to the same value so you can tell if someone is doing that. However if they go to an internet cafe viola they can resubmit. You'd use SHA1, MD5, etc for that.
You can do the same thing with email address and hash it. To get people to want to participate send the results to their email address instead of displaying in the browser. People just have to trust you won't do nasty things with their email.
Other ideas might be if you know who you want to send the survey too. Generate a random number that identifies the individual response. Then email those links to people. They will then submit under that number, and you don't track email -> random number then you can't correlate the answers with the email address. Once a random number is used once you don't let them submit it again. Track Responses once. Display results many times.
You can combine some of these together to try and work around the deficiencies of the other.