I've been doing a lot of research on Cassandra data models but I'm stuck on how to Cassandra handles metadata(reference) tables.
For example, assuming I have an application within a RDBMS where customers initially register for an account and the application enters the information into a customer entity (customer_id, customer_name). The application also has a transaction table which record the items purchased using the customer_id as a foreign key.
How would I represent these entities in Cassandra starting with the initial registration of the customers and then showing the items purchased by a customer over time (also assuming that a customer may not purchase anything on the day of initial registration)
Thanks for your help
Related
I have a customer that owns a carpet cleaning business and we have all of his different franchisee's data in a multi-tenant database model and we would like to move this data into a data warehouse in snowflake. I don't want to have to build a separate database for each customer because then I have to keep each database up to date with the latest data model. I want to use 1 data model to rule them all. I have a tenant ID that I keep with each record to identify the franchisee's data. I want to give a set of credentials to each franchisee to where they can hook up their analytics tool of choice (tableau, power bi, etc.) and only get access to the rows that are applicable to them. Is there a way to secure the rows they see in each table based on their user. In other words some sort of row level access control similar to profiles in postgres. Are there any better methods for handling this type of scenario? Ultimately I want to maintain and manage the least number of elt jobs and data models.
This is the purpose of ether Secure Views, or Reader Accounts.
We are using both, and they have about the same technical hassle/setup costs. But we are using an internal tool to build/alter the schema's.
To expand on Simeon's answer:
You could have a single Snowflake account and create a Snowflake role & user for each franchisee. These roles would have access to a Secure View which uses the CURRENT_ROLE / CURRENT_USER context functions as in this example from the Snowflake documentation.
You'd have to have a role -> tennant ID "mapping table" which is used in the Secure View to limit the rows down to the correct franchisee.
I am creating an application that should allow users to create or join a group with other users. Every user in a group will have access to some common information. The users are currently stored in a Postgres database with attributes: name and email. I am trying to create a model for groups that would contain a list of authorized users that can access its material.
One approach I thought of was creating a new table in the database consisting of rows of groups and each group had a column: 'authorized_users' which contained an array. However, I read that this is bad practice in SQL.
Another approach would be to create a new table each time a group is created and store the authorized users in that table.
I was looking for help to see if there is an API for node that already performs this, or if any of you have suggestions on how to implement this group model.
You need a new table that keeps the users in groups info, modelling a many to many relationship:
users_groups:
user_id,
group_id,
(optional) can_read, can_write, etc
I have a question about transaction on Azure CosmosDB (with SQL API) where I have to edit two items on collection A and create other item on collection B.
I’m developing a project where there are exchange of points. So I have users with status of their points and I have to save the transaction for history. On a SQL database, I start a transactions, do the operation of update user A balance, update user B balance and create a new row on tickets with all details of operation and if it is good, end the transaction. But I have dudes about how to do on Azure CosmosDB. I have a collection where there are users with their balance, and other collection with tickets. So, with stored procedure, I can update user A and user B because both are on the same collection and if some of them fail to update, the collection isn’t edited (as transaction of SQL database), but, how to create the new ticket? Because If I have understood the documentation correctly, it works on same collection, but it doesn’t work with different collections.
Could you give me some advice about how to do it in order to do the 3 operations on the same transactions?
CosmosDB only supports transactions within the same partition.
This means that you cannot have cross containers transactions and you also cannot have transaction between 2 documents with different partition key values.
I have a query that get accounts for a business unit based on a set criteria. When using one business unit, the query works find and brings back the results. Running the same code, changing only the business unit, running with a different business unit, the result come back empty.
If I run this query in HeidiSQL it works for both business units.
Another feature to this problem is in the bad business unit, a Customer Care Rep can not get the results, yet Customer Care Supervisor can. In the good business unit, both can get the results.
This leads me to think there is a problem with security. However I have compared both business units teams and roles and they match.
Is there something else, that I am overlooking that could stop a team from getting data from the database.
From: https://andrewbschultz.com/2011/08/09/business-units-bus-and-security-roles-in-microsoft-dynamics-crm-2011-solution-exports/
Without BUs, the following security configurations would be possible:
A user could have access to his own CRM records
A user could have access to all CRM records
With BUs, the following additional security
configurations are possible:
A user can have access to all records owned by users in his business
unit
A user can have access to all records owned by users in his own
and any child business units
My understanding is that if the records are owned by a user from BU1, then users in BU2 won't be able to access them until ownership is transfered to a user in BU2.
In order to have users in both BUs access the same records, you have to share all of them with at least one (or maybe all) users in BU2.
We're in the design phase for building an audit trail in an existing web application. The application runs on Windows Azure and uses a SQL Azure database.
The audit logs must be filtered by user, or by object type (eg. show all action of a user, or show all actions that are performed on a object).
We have to choose how to store the data, should we use SQL Azure, or should we use table storage? We prefer table storage (cheaper)..
however the 'problem' with table storage is how to define the partition key. We have several thousand customers (the appplication users) in our SQL database, each in their own tenant. Using the tenant ID as partition key is not specific enough, so we have to add something to the partition key. So there's the issue: given the requirements for filtering, we can add a user ID to the partition key to make filtering by user easy, or we can add an object ID to make filtering by object easy.
So we see two possible solutions:
- use SQL Azure instead of table storage
- use table storage and use two tables with different partition keys, which means we duplicate all entries
Any ideas what's the best approach for our situation? Are there other, better solutions?
DocumentDB on Azure might be worth considering.
https://azure.microsoft.com/en-us/documentation/articles/documentdb-use-cases/
You can have audit trail stored in DocDB as JSON documents (user, activity, object fields and can index on all fields )
Azure Table Storage is appropriate to store log data. As Azure App services use Azure Table Storage to store the diagnosis logs.
In think you can consider to set the PartitionKey as your user's tenant name, and the RowKey is the user's ID. As according the Table Storage Data Model, we only need to keep:
Together the PartitionKey and RowKey uniquely identify every entity within a table
Alternatively, you can clarify your concern about:
Using the tenant ID as partition key is not specific enough, so we have to add something to the partition key
Additionally, you can refer https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/#overview for more info about design Azure Table Storage.
Any update, please feel free to let me know.
If you're worried about filtering in multiple ways - you could always write the same data to multiple partitions. It works really well. For example, in our app we have Staff and Customers. When there is an interaction we want to track/trace that applied to both of them (perhaps an over the phone Purchase), we will write the same information (typically as json) to our audit tables.
{
PurchaseId: 9485,
CustomerId: 138,
StaffId: 509,
ProductId: 707958,
Quantity: 20
Price: 31.99,
Date: '2017-08-15 15:48:39'
}
And we will write that same row to the following partitions: Product_707958, Customer_138, Staff_509. The row key is the same across the three rows in each partition: Purchase_9485. Now if I want to go and query everything that has happened for a given staff, customer, or item, I just grab the whole partition. The storage is dirt cheap, so who cares if you write it to multiple places?
Also, an idea for you considering you have multiple tenants - you could make the table name Tenant_[SomeId]. There are some other issues you might have to deal with, but it is in a sense another key to get at schema-less data.