I want to retrieve all items within a specific column of a table.
In this scenario, I have 2 tables, The first table contains a primary key, and the second table contains a foreign key. a 1 to many relationship is set up for the tables respectively.
I want a function/way of retrieving all items within a column in table 2 that has a foreign key that matches the primary key in table 1.
One way of doing this is through a VLOOKUP, though surely through using DAX, or some other function set, I can exploit the relationship I have made in the DataModel to make this easier for me to do.
Why don't you just get the required data from the DB with a proper SELECT statement? Something like
SELECT column
FROM t1, t2
WHERE t1.key = t2.fkey
AND t1.key = 'whatever you search for';
Then you should get the data you want.
Related
Please see the code below for a Power BI table in DAX:
TABLE1 =
VAR ParticipantOneParticipantId =
SELECTEDVALUE(
ParticipantOneDetails[ParticipantId]
)
RETURN
FILTER(
ParticipantOneMeetings,
ParticipantOneMeetings[ParticipantId] = ParticipantOneParticipantId
)
I am fetching a value for ParticipantId from a sliced table called ParticipantOneDetails and setting ParticipantOneParticipantId to it.
In the next step I am trying to filter the table ParticipantOneMeetings based on its column ParticipantId comparing it against ParticipantOneParticipantId.
The problem is that the resulting table is coming out empty even though I know that ParticipantOneParticipantId must have a value and the ParticipantOneMeetings table also has values. I verified by comparing against a hard-coded string.
Can you please point out what I am doing wrong? Is comparing this way not legal?
The problem lies in the process you are trying. A calculated/custom tables and columns are static. They always refresh when the data set is refreshed. They do not interact dynamically with the slicer value. So it is impossible to get data from a slicer dynamically for a Custom Table generation.
Now, your requirement of creating a new table based on slicer value is not completely clear to me. As what you are trying, is a simple filtered output of your table "ParticipantOneMeetings" after applying the Slicer. If you have relation between your 2 tables using column "ParticipantId", change in Slicer will automatically filter out values in ParticipantOneMeetings table. Why you wants to hold this same filtered values in a new Custom table is really a mater here to know for finding appropriate solution for you.
Turns out I needed to add the following measure to the table output:
MeetingsAttendedByBothParticipants =
countrows(
INTERSECT(
VALUES(ParticipantOneMeetings[Name]),
VALUES(ParticipantTwoMeetings[Name])
)
)
The above provides an intersection on output of two sliced meeting tables. This results in a list of meetings that both persons attend.
I want to have a table in Cassandra that has a partition key say column 'A', and a column say 'B' which is of 'set' type and can have up to 10000 elements in the set.
But when i retrieve a row from this table then the whole set is retrieved at once and because of that the JVM heap increases rapidly. So should i stick to this schema or go with other schema where 'A' is partition key and i make dynamic columns for each element in the set in my other schema say 'B1', 'B2' ..... 'B10,000'where each of this column is a clustering key.
Which schema is suited best and will give the optimal performance please recommend.
NOTE: cqlsh 5.0.1v
Based off of what you've described, and the documentation I've read, I would not create a collection with 10k elements. Instead I would have two tables, one with everything but the collection, and then use the primary key values of the first table, as the partition key columns of the second table; adding the element name (or whatever you can use to identify an individual element) as a clustering column.
So for a given query, if you wanted everything for a particular primary key value (including all elements), you'd query the first table with the primary key, grab whatever you need, then hit the second table as well, looping/fetching through all elements.
If the query only provides a filter on the partition key (not the primary key - i.e. retrieving multiple rows) , the first query would have to retrieve all columns that make up the primary key for each row, and then query the second table looping for all elements - nested loop here - one loop for each primary key record retrieved from the first table, and a second loop to grab all elements for each pk record.
Probably the best way to go with this. That's how I would probably tackle this.
Does that make sense?
-Jim
I have 2 tables I am trying to create a relationship with in power bi. Both tables have the same values for example:
Table1 has location and Table2 has Location however the location is different. Every time I try to connect them say I need a unique value. Can someone please help me so I can connect them together?
Here is a passage from documentation regarding relationships in Power BI (Create and manage relationships in Power BI Desktop. In short, one of the tables you choose for the relationship should have unique values in the join column. So far in Power BI, you can define 1:*, 1:1 and *:1 relationship.
BlockquoteNote that you'll see an error that states One of the columns must have unique values if none of the tables selected for the relationship has unique values. At least one table in a relationship must have a distinct, unique list of key values, which is a common requirement for all relational database technologies.
If you encounter that error, there are a couple ways to fix the issue:
Use "Remove Duplicate Rows" to create a column with unique values. The drawback to this approach is that you will lose information when duplicate rows are removed, and often a key (row) is duplicated for good reason.
Add an intermediary table made of the list of distinct key values to the model, which will then be linked to both original columns in the relationship.
One of your table has to have unique values in Location (Primary Key) while the other can have duplicate values in Location (Foreign Key). Plus, the table with duplicates (the fact normally) must have values that are present in the other table (in the dimension).
In my opinion, to match your needs, you hshould add all the possible location in the table which would have unique values (the dimension).
I hope I made myself clear.
The CQL3 specification description of the UPDATE statement begins with the following paragraph:
The UPDATE statement writes one or more columns for a given row in a
table. The (where-clause) is used to select the row to update and must
include all columns composing the PRIMARY KEY (the IN relation is only
supported for the last column of the partition key). Other columns
values are specified through after the SET keyword.
The description in the specification of the DELETE statement begins with a similar paragraph:
The DELETE statement deletes columns and rows. If column names are provided
directly after the DELETE keyword, only those columns are deleted from the row
indicated by the (where-clause) (the id[value] syntax in (selection) is for
collection, please refer to the collection section for more details).
Otherwise whole rows are removed. The (where-clause) allows to specify the
key for the row(s) to delete (the IN relation is only supported for the last
column of the partition key).
The bolded portions of each of these descriptions state, in layman's terms, that these statements can be used to modify data in a solely row-based manner.
However, given the nature of the relationship (or lack thereof) between the rows and the static columns (which exist independent of any particular row) of a table, it seems as though there should be a way to modify such columns given only the keys of the partitions they're respectively contained in. According to the specification however, that does not seem to be possible, and I'm not sure if that is a product of the difficulty to allow such in the CQL3 syntax, or something else.
If a static column cannot be updated or deleted independent of any row in its table, then such operations become coupled with their non-static-column-based counterparts, making the set of columns targeted by such operations, difficult to determine. For example, given a populated table with the following definition:
CREATE TABLE IF NOT EXISTS example_table
(
partitionKeyColumn int
clusteringColumn int
nonPrimaryKeyColumn int
staticColumn varchar static
PRIMARY KEY (partitionKeyColumn, clusteringColumn)
)
... it is not immediately obvious if the following DELETE statements are equivalent:
//#1 (Explicitly specifies all of the columns in and "in" the target row)
DELETE partitionKeyColumn, clusteringColumn, nonPrimaryKeyColumn, staticColumn FROM example_table WHERE partitionKeyColumn = 1 AND clusteringColumn = 2
//#2 (Implicitly specifies all of the columns in (but not "in"?) the target row)
DELETE FROM example_table WHERE partitionKeyColumn = 1 AND clusteringColumn = 2
So, phrasing my observations in question form:
Are the above DELETE statements equivalent?
Does the primary key of at least one row in a CQL3 table have to be supplied in order to update or delete a static column in said table? If so, why?
I do not know about specification but in the real cassandra world, your two DELETE statements are not equivalent.
The first statement deletes the static_column whereas the second one does not. The reason of this is that static columns are shared by rows. You have to specify it explicitly to actually delete it.
Furthermore, I do not think its a good idea to DELETE static columns and non-static columns at the same time. By the way, this statement won't work :
DELETE staticColumn FROM example_table WHERE partitionKeyColumn = 1 AND clusteringColumn = 2
The error output is :
Bad Request: Invalid restriction on clustering column priceable_name since the DELETE statement modifies only static columns
I was reading the following article about Cassandra:
http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1/#.UzIcL-ddVRw
and it seemed to imply you can have varying column keys in cassandra for a given row key. Is that true? And if its true, how do you allow for varying row keys.
The reason I think this might be true is because say we have a user and it can like many items and we simply want the userId to be the rowkey. We let this rowKey (userID) map to all the items that specific user might like. Each specific user might like a different number of items. Therefore, if we could have multiple column keys, one for each itemID each user likes, then we could solve the problem that way.
Therefore, is it possible to have varying length of cassandra column keys for a specific rowKey? (and how do you do it)
Providing an example and/or some cql code would be awesome!
The thing that is confusing me is that I have seen some .cql files and they define keyspaces before hand and it seems pretty inflexible on how to make it dynamic, i.e. allow it to have additional columns as we please. For example:
CREATE TABLE IF NOT EXISTS results (
test blob,
tid timeuuid,
result text,
PRIMARY KEY(test, tid)
);
How can this even allow growing columns? Don't we need to specify the name before hand anyway?Or additional custom columns as the application desires?
Yes, you can have a varying number of columns per row_key. From a relational perspective, it's not obvious that tid is the name of a variable. It acts as a placeholder for the variable column key. Note in the inserts statements below, "tid", "result", and "data" are never mentioned in the statement.
CREATE TABLE IF NOT EXISTS results (
data blob,
tid timeuuid,
result text,
PRIMARY KEY(test, tid)
);
So in your example, you need to identify the row_key, column_key, and payload of the table.
The primary key contains both the row_key and column_key.
Test is your row_key.
tid is your column_key.
data is your payload.
The following inserts are all valid:
INSERT your_keyspace.results('row_key_1', 'a4a70900-24e1-11df-8924-001ff3591711', 'blob_1');
INSERT your_keyspace.results('row_key_1', 'a4a70900-24e1-11df-8924-001ff3591712', 'blob_2');
#notice that the column_key changed but the row_key remained the same
INSERT your_keyspace.results('row_key_2', 'a4a70900-24e1-11df-8924-001ff3591711', 'blob_3');
See here
Did you thought of exploring collection support in cassandra for handling such relations in colocated way{e.g. on same data node}.
Not sure if it helps, but what about keeping user id as row key and a map containing item id as key and some value?
-Vivel