I have a CSV file of the form (unimportant columns hidden)
player,game1,game2,game3,game4,game5,game6,game7,game8
Example data:
Alice,0,-10,-30,-60,-30,-50,-10,30
Bob,10,20,30,40,50,60,70,80
Charlie,20,0,20,0,20,0,20,0
Derek,1,2,3,4,5,6,7,8
Emily,-40,-30,-20,-10,10,20,30,40
Francine,1,4,9,16,25,36,49,64
Gina,0,0,0,0,0,0,0,0
Hank,-50,50,-50,50,-50,50,-50,50
Irene,-20,-20,-20,50,50,-20,-20,-20
I am looking for a way to make a Data Studio view where I can see a chart of all the results of a certain player. How would I make a custom field that combines the data from game1 to game8 so I can make a chart of it?
| Name | Scores |
|----------|---------------------------------|
| Alice | [0,-10,-30,-60,-30,-50,-10,30] |
| Bob | [10,20,30,40,50,60,70,80] |
| Charlie | [20,0,20,0,20,0,20,0] |
| Derek | [1,2,3,4,5,6,7,8] |
| Emily | [-40,-30,-20,-10,10,20,30,40] |
| Francine | [1,4,9,16,25,36,49,64] |
| Gina | [0,0,0,0,0,0,0,0] |
| Hank | [-50,50,-50,50,-50,50,-50,50] |
| Irene | [-20,-20,-20,50,50,-20,-20,-20] |
The goal of the resulting chart would be something like this, where game1 is the first point and so on.
If this is not possible, how would I best represent the data so what I am looking for can work in Data Studio? I currently have it implemented in a Google Sheet, but the issue is there's no way to make views, so when someone selects a row it changes for everyone viewing it.
If you have two file games as data sources, I guess that you want to combine them by the name, right?
You can do it with the blending data option. Resource > manage blends I think is the option.
Then you can create a blend data source merging it by the name.
You can add also both score fields, with different labels.
This is some documentation about it: https://support.google.com/datastudio/answer/9061420?hl=en
I am working on an app that helps the user search for their desired medication in nearby pharmacies then shows a list of the pharmacies that have the drug in stock with prices.
I come from a SQL background and have been having a hard time deciding how to structure Firestore databases for better queries, I think normally you would go through the list of pharmacies and their databases but is there a way to have a single database for all the drugs with maybe a field that has the primary keys of the pharmacies that have it in stock in Firestore?
There are two ways in which you can solve this. The first one would be to create a sub-collection under each pharmacy to hold all available drugs:
Firestore-root
|
--- pharmacies (collection)
|
--- $pharmacyId (document)
|
--- drugs (sub-collection)
|
--- $drugId
|
--- name: "Aspirin"
|
--- inStock: true
To get all pharmacies that have, for example, Aspirin in stock, a collection group query is needed. In Android, the query should look like this:
db.collectionGroup("drugs").whereEqualTo("name", "Aspirin").whereEqualTo("inStock", "true");
The second option that you have is to create a single top-level collection of drugs:
Firestore-root
|
--- drugs (collection)
|
--- $drugId (document)
|
--- name: "Aspirin"
|
--- inStock: true
|
--- pharmacyId: $pharmacyId
And create a simple query that looks like this:
db.collection("drugs").whereEqualTo("name", "Aspirin").whereEqualTo("inStock", "true");
So you can choose to work or one or the other according to the use-case of your app.
In my features when i execute my behat test i send it like this :
And the following user:
| id | array |
| ID1 | [{"key1":"value1","key2":"value2"}] |
But in my database i receive this information
| id | array (DC2Type:json_array) |
| ID1 | ["[{\"key1\":\"value1\"","\"key2\":\"value2\"}]"] |
So i can't use this informations on my array.
Have you got any idea which expression i have to use for have the same informations like tests entries?
I precise i work with symfony 3.4.15, API Platform and PhpMyAdmin
Thank you!
Feature files are flexible, but we should avoid adding to much details.
I would hide all unnecessary info from the scenario that doesn't bring any value.
You could hide this information in the feature file and create a method that sets some user details based on some key/parameter identifier.
/**
* #Then /^I have an (.*) user$/
*/
public function iHaveAUser($user) {
// generates/gets some data in any format you need
$dataINeed = generateUser($user);
}
I am trying to implement a Firestore Cloud DB but I am new to NoSQL databases.
I want to know whats the best way of arranging these sets into collections/documents:
I have restaurants which have different foods and reservations. What would be the best approach to structure these sets of data into Firestore DB?
Is this a right approach:
Restaurant1 (Collection)
----> Foods (document)
----> Reservations (document)
I think storing Foods and Reservations as top level collections will ultimately yield you more flexibility later on.
It's easy enough to take a restaurantID and stick it in the each document in those collections, so I don't personally think you should nest them in the Restaurants collection. It's a personal preference from working with a lot of nested collections.
I think the optimal structure is:
Restaurants (collection)
--- Name: Chipotle
--- ID: restaurant1
--- Foods: [{ Name: foodItem1 }, { Name: foodItem2 }]
Foods (collection)
--- Name: foodItem1
--- Ingredients: abc
--- Nutrition Facts: xyz
Reservations (collection)
--- User: user1
--- Restaurant: { id: restaurant1, name: Chipotle }
--- Time: 3pm
Users (collection)
--- ID: user1
What you'll notice is there is some redundant info. This is good so if you request all reservations, you'll get the restaurant's name and ID, etc. stuff you would likely want. You will find you'll want to store data multiple times and this to me feels like a good structure for it.
With this structure you can very easily just call:
All reservations by user X or All foods meeting nutrition limits of Y
Instead of a collectionGroup query which would call for all restaurants' sub collection list of reservations. You won't always want to query your reservations by restaurant, maybe you want to pull by user or time, etc.
According to your comment:
the restaurant´s management should be able to see his reservation together with other reservations from other clients, in a list. And each client should be able to see his history of reservations as well.
I'll try to provide you a schema that can help you get that data very easily.
Firestore-rrot
|
--- users (collection)
| |
| --- uid (document)
| | |
| | --- type: "manager"
| |
| --- uid (document)
| |
| --- type: "client"
|
--- reservations (collection)
|
--- reservationIdOne (document)
| |
| --- reservedBy: "uid"
| |
| --- date: September 21, 2019 at 1:15:02 PM UTC+3
|
--- reservationIdTwo (document)
|
--- reservedBy: "uid"
|
--- date: September 21, 2019 at 1:18:42 PM UTC+3
Using this schema, you can simply query the database to get all users or specific users (manager or clients). You can also get all reservations by adding a reference on reservations collection. If you want to get the reservation only of a single type (manager or client), you should use a query that might look like this:
db.collection("reservations").whereEqual("type", "manager");
As you can see, I have also added a date property so you can easily sort them descending (last reservation first).
It really depends on the use-case you are trying to solve, as you should be optimizing for specific queries on those models.
I recommend watching these videos to get a better idea:
Series of What is a NoSQL Database? How is Cloud Firestore structured?
Model Relational Data in Firestore NoSQL
Firestore Data Modeling - Five Cool Techniques
I want to manage roles and permissions. Most of designs on web look like this
tables:
Users
Roles
UserRoles
Permissions
RolePermissions
Here, what is permissions? I am thinking for such a design instead:
Users
Roles
UserRoles
Permissions
In this design, Roles is supposed to be:
id | name
while permissions is supposed to be:
id | role_id | section | action
permissions defines which role in which section has what action control. something like this:
id | role_id | section | action
1 | 2 | posts | edit
2 | 2 | posts | add
3 | 2 | posts | delete
4 | 3 | users | approve
5 | 3 | users | edit
6 | 4 | articles | delete
7 | 2 | users | givepermission
It uses two strings instead of an extra table and numbers. Also checking it on PHP seems easier.
Does this design have problem? And is it recommended by you according to your experiences?
As to whether your design is recommended, then it depends on the problem you are trying to solve. However, your design makes sense for a RESTful application, and should be resilient.
For your permissions table, you may want to consider using a bitmask instead of strings.