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
Good Morning all. I'm trying to write some of my first scripts and I'm having a difficult time doing so. I'm trying to match data from one file to another, and add a label to that row in the original.
I'm using two different data sources, to accomplish this and there are tens of thousands different rows to match. I'm trying to take one column of zip codes in data source one, match it to the same zip codes in a data source two, and add a new column labeling the location in data source one. see example below.
Data Source One:
|A | | B |
|13329 | X |
|22193 | X |
|13211 | X |
Data source two:
|A | | B |
|13211 | Syracuse |
|22193 | D.C. Metro |
|13329 | Utica Rome |
New Data Source one:
| A | B | C |
|13329 | X | Utica-Rome |
|22193 | X | D.C. Metro |
|13211 | X | Syracuse |
New Data Source One is the desired end state. I am dealing with rows that will have no new labels and can be labeled as N/A or NA (whichever way is fine). I hope I have explained the problem and the desired result well enough. Please help.
More commonly than Matching and labeling this is called joining.
join <(sort DS1) <(sort DS2)
I wish to use Datastore, but I read that an entity size is limited to 1mb.
I have an entity "Users", which contains around 50k "User". I wonder if the entity size restriction is not too restrictive for my case. And if a day I will have more users, will I be blocked.
This is how I imagine my database, maybe I misunderstood how it's supposed to work:
+--------- Datastore -------------+
| |
| +---------- Users ------------+ |
| | | |
| | +---------- User ---------+ | |
| | | Name: Alpha | | |
| | +-------------------------+ | |
| | | |
| | +---------- User ---------+ | |
| | | Name: Beta | | |
| | +-------------------------+ | |
| +-----------------------------+ |
+---------------------------------+
Where "Users" is an entity which contains entities "User".
Thank you.
Your "KIND" is user, your "entities" are EACH user. So no matter how MANY users you have, as long as EACH user is under a meg, you're fine.
The only limit to the size of the full "kind" is what you're willing to pay in storage. Reading up on this doc, or watching this introduction video could give some high level advice to your situation.
To better understand keys and indexes (another VERY important concept of datastore), I would suggest this video that explains VERY well how composite indexes work and behave :)
I'm having a bit of trouble designing an ER diagram for a bike shop. The shop contains many bike parts (wheel, gear, brakes etc.) which have different attributes. I have therefore made each part as an entity in order to model the different attributes of theirs. They all contain a quantity attribute, name and price which is made by using inheritance. However, now when I have all these entities they should be mapped to the 'Bike' entity which is a collection of all the parts and the 'Stock' entity where all the parts are listed as well as their preferred amount and minimum amount.
My problem is that I'm not sure how to map the parts to the 'Bike' and 'Stock' entity. In the figure below I've made two different designs. Which one of them is correct, if any at all? Can I model it in a smarter way? (I have removed the attributes for simplification)
Solution 1
Solution 2
I think you are looking at a Bill of Materials type schema, where you could have a Part super-type and as many sub-types as you wish to hold specific details for particular types of Part. The Bill of Materials contains a quantity to hold the number of child Parts required to make the parent Part e.g 2 wheels, 1 frame. This goes all the way up to Bike, which is just another type of Part. The Part can then link into your entities for managing Stock and Inventory.
+-----------------+
| BOM |
+-----------------+
| parent_part_id |
| child_part_no |
| quantity |
+-----------------+
| |
| | +-------------+
| | | STOCK |
+-------------+ +-------------+
| PART |-----| ... |
+-------------+ +-------------+
| part_id |
| part_type |
+---------| ... |---------+
| +-------------+ |
| | |
| | |
| | |
+-------------+ +-------------+ +-------------+
| WHEEL | | GEAR | | BIKE |
+-------------+ +-------------+ +-------------+
| part_id | | part_id | | part_id |
| ... | | ... | | ... |
+-------------+ +-------------+ +-------------+
None of them. Sorry.
First of all, you may want to consider "Wheel", "Gear", "Brake" as a single entity "Part", instead of separate entities.
This makes the diagram more simple. And, rememeber, than there can be more parts, like "chain", "lights", and so on.
So instead of defining a sngle entity for each part, just define a single one: "Part", for all.
Second, Some parts can be parts of another part, and so on. This is called a "recursive" or "self referenced" entity. This may look odd, at first, but, also, makes the diagram more simple.
............................................................
...........+-------------+..................................
...........|.............|..................................
...........|.............|..................................
.........../\............|.........../\.....................
........../ \...........|........../ \....................
........./ \.....Many.|....Many./ \...................
......../ \.1.+-----+----+.../ \...1+----------+..
.......<IsPartOf>--| Part +--< Stores >---+ Stock |..
........\ /...+----------+...\ /....+----------+..
.........\ /.........|..........\ /...................
..........\ /..........|Many.......\ /....................
...........\/...........|............\/.....................
......................./ \.................................
....................../ \................................
...................../ \...............................
..................../ \..............................
...................< Composed >.............................
....................\ By /..............................
.....................\ /...............................
......................\ /................................
.......................\../.................................
........................|...................................
........................|1..................................
...................+----------+.............................
...................| Bike |.............................
...................+----------+.............................
............................................................
Cheers.
There is a database of spare parts for cars, and online search by the name of spare parts. The user can type in the search, for example "safety cushion" or "airbag" - and the search result should be the same.
Therefore, I need somehow to implement the aliases for names of spare parts, and the question is how to store them in the database? Until now I have only one option that comes in mind - to create an additional table
| id | name of part | alias_id |
-------------------------------------------------- ---------------
| 1 | airbag | 10 |
| 2 | safety cushion | 10 |
And add additional field "alias_id" to table containing all the spare parts, and search by this field...
Are there other better options?
If I have understood correctly, it's best to have 3 tables in a many to many situation (if multiple parts have multiple aliases:
Table - Parts
| id | name of part |
-----------------------
| 1 | airbag |
| 2 | safety cushion |
Table - Aliases
| id | name of alias |
-----------------------
| 10 | AliasName |
Table - PartToAliases
| id | PartId | AliasId |
-------------------------
| 1 | 1 | 10 |
| 2 | 2 | 10 |
Your solution looks fine for the exact problem you described.
BUT what if someone writes safetycushion? or safety cuschion? With these kinds of variations your alias lookup table will soon become huge and and manualy maintaining these will not be feasible.
At that point you'll need a completely different approach (think full text search engine).
So if you are still sure you only need a couple of aliases your approach seems to be fine.