I have three tables, DISTRIBUTION_LIST, USERS, and ADDRESSES.
Single object 'distribution_list' has multiple users and addresses.
I want to create transaction which will write to those three table together and FOREIGN_KEY in tables USERS and ADDRESSES is PRIMARY_KEY from DISTRIBUTION_LIST which is AUTO INCREMENT.
Actually I have described my problem already, how to know PRIMARY_KEY from DISTRIBUTION_LIST when I create statement to insert data into USERS and ADDRESSES? One solution to calculate PRIMARY_KEY manually, but possible there's more elegant solution for this task?
Related
My DynamoDB table currently has the PK, SK and a GSI called "EmailIndex".
The idea behind this is that when users create their account, the username will be set as the PK and the email would be set as the EmailIndex GSI.
This should let me allow the user to login with either the username or the email.
Is it possible to reliably ensure there is no duplicated EmailIndex record? If for example, two different people enter the exact same email at the exact same time with different usernames, how can I ensure both users don't end up creating a record with the same GSI?
Right now I'm under the assumption that this isn't actually possible with DynamoDB. In which case, what would be the acceptable and recommended approach of allowing username or email logins instead of mandating one or the other?
There isn't a way to guarantee unique values on a GSI. What I've done in the past to solve this is to have two records for the user, one with the data you have today, and one that is keyed on the email address. When doing a Put operation you can use a transaction to be sure both records succeed. You can still put the email in the GSI on the main record and use that for querying, or use the second record instead, and duplicate the data (which is what the GSI would do if you have the projection set to ALL).
What is the difference between hide and unselecting 'enable load'? Both options result in the table/field not showing up on the report.
It's not about the report. It's also about efficiency and storage.
There are situations when queries serve as intermediary data sources, which are only used for joins into other tables and after that are not required for any visuals. In that case, you don't need to load the table into the data model at all and the data in that table will not use up space in the data model.
This helps keep the data model cleaner and the PBIX file smaller. Hiding tables from the report does not do that.
Edit after comment: Here is a scenario where I would disable data load of a query: Say I have a customer table with customer ID, name, region and a hundred other columns. It has 100,000 customers, most of them are historic, only 10,000 are active. In my Transaction table I have only the customer ID, but I want to report by the region.
I can load the customer table into Power Query, then join it to the Transaction table and keep only the region in the Transaction table. I don't need any other details from the customer table because all my reporting only drills down to region level, not individual customer. Also my report is focused on a segment of my business that involves only a fraction of my existing customers. Therefore, I don't need the whole customer table in the data model. I save the Customer query as a connection only, and don't load it into the data model to save the space.
Yes, I could load it and I could use a relationships instead of the join, but by loading just the region field for a subset of customers, I can keep the model much leaner.
I’m quite new to NoSQL and DynamoDB and I used to RDBMS. I’m designing database for a game and we're using DynamoDB and AWS Lambda for our backend. I created a table name “Users” for player profile that contains the user information and resources. Because the game has inventory system I also created a table name “UserItems”.
It’s all good until I realized DynamoDB don’t have transaction and any operation that is executed on both table (for example using an item that increase resource) has a chance of failure on one table while success on other and will cause missing data which affect our customers.
So I was thinking maybe my multiple tables design is not good since it’s a habit of me to design multiple table when I’m working with RDBMS. Which let me to think of storing the entire “UserItems” as hash in “Users” but I’m not sure this is a good practice because the size of a single row in Users table will be really big (we may have 500 unique items per users) and each time I pull or put data from/to “Users” (most of the time don’t need “UserItems” data) the read/write throughput will be also really large.
What should I do, keep the multiple tables design and handle transaction manually or switch to single table design? Or maybe there is a 3rd option?
Updated: more information about my use case
Currently I have 2 tables
Users: UserId (key), Username, Gold
UserItems: UserId (partition key), ItemId (sort key), Name, GoldValue
Scenarios:
User buy an item: Users.Gold will be deduced, new UserItem will be add to UserItems table.
User sell an item: Users.Gold will be increased, the Item will be deleted from UserItems table.
In both scenarios above I will have to do 2 update operation for 2 tables which without transaction there is a chance one of them failed.
To solve that I consider using single table solution which is a single Users table with 4 columns UserId(key), Username, Gold, UserItems. However there are two things I'm worried about:
Data in UserItems might be come to big for a single cell because one user could have up to 500 items.
To add/delete item I have to pull the UserItems from dynamodb, add/delete item and then put it back into Users. So I have to do 1 read and 1 write operation for 1 action. And because of issue (1) the read/write data size could become really big.
FWIW, the AWS documentation on NoSQL Design for DynamoDB suggests to use a single table:
As a general rule, you should maintain as few tables as possible in a
DynamoDB application. As emphasized earlier, most well designed
applications require only one table, unless there is a specific reason
for using multiple tables.
Exceptions are cases where high-volume time series data are involved,
or datasets that have very different access patterns—but these are
exceptions. A single table with inverted indexes can usually enable
simple queries to create and retrieve the complex hierarchical data
structures required by your application.
NoSql database is best suited for non-trasactional data. If you bring normalization(splitting your data into multiple tables) into noSQL, then you are beating the whole purpose of it. If performance is what matters most, then you should consider only having a single table for your use case. DynamoDB supports Range Keys, and also supports Secondary Indices. For your usecase, it would be better to redesign your table to use Range Keys.
If you can share more details about your current table, maybe i can help you with more inputs.
I have two tables in my Power Query editor. User and Account.
I am trying to add a column to User that counts how many accounts are owned per user.
To do this I have a staging query called UserAccountCount that references Accounts and performs a group on the User Id. It returns a two column table with User.Id and Count.
I then try to merge and expand the User query on the UserAccountCount but it returns a Expression.Error: A cyclic reference was encountered during evaluation..
I agree it is cyclical as I have referenced one query in the other. Is there a way, besides duplication, that I can reference the queries.
I am trying to minimise duplicated code.
I tried to use Table.Buffer so that it would stop evaluating and possibly impact the order that the queries are run.
I should note that the Account table, joins and merges on the User table to bring in the User.Name before it is referenced by UserAccountCount.
Is it bad design to do this in a staging query. Should I just do this using an AddColumn formula?
I would add User.Name to your Group By in your UserAccountCount Query.
Then I would remove the Merge to the User table from the Account Query. You should then be able to expand both the User.Name and Count columns after the Merge with UserAccountCount.
I want to know if it is possible to create custom fields only once and use them through out multiple entities. For instance if I want to have a field called "Partner" and have it in Leads, Opportunities and Account. Can I just create the field only once and have it accessed in three different entities?
Thanks in advance
Yes and no. You'll need to create the field on each entity but you can share the data between them.
One way is a shared option set. This lets you manage one list of items and use it over and over on different entities. Another way you could go about it is to have a new entity for the data you're storing, and instead of creating a field you create a lookup to that record. This would be good if you had a list of countries that you wanted to reference all over CRM.