We have the data tables from Netsuite ELT'd into a DW. I'm trying to build a query that relates TRANSACTIONS or TRANSACTION_LINES to the CUSTOMERS table.
What I've tried:
1.) transaction and transaction_lines does not have a customer_id so there's no direct join available
2.) None of the transaction mapping or link tables contain the customer id
3.) I've been browsing the schema browser https://www.netsuite.com/help/helpcenter/en_US/srbrowser/Browser2016_1/odbc/record/transaction.html, but I simply cannot figure out how to relate these two entities
Does anyone know how to relate transactions to customers?
Please note: This is specifically related to the Netsuite data model and how these two tables relate to each other. I'm not specifically looking for any SQL help, strictly how to associate a transaction with a customer.
The joining field is entity_id on transactions
select tl.item_id, tl.item_count
from transaction_lines tl, transactions t, customers c
where
c.customer_id = t.entity_d and tl.transaction_id = t.transaction_id
Your syntax may vary
Related
I've been using MongoDB for a few years now, and I'm starting to use Prisma's client, which seems to be providing excellent type safety. I'm not familiar at all with relational data storage, though...
This is how my database is looking:
Users are each associated with a single group
Each one of them can be a candidate in the group, and all vote for one of the group candidates during an election once they've been selected
What best practices would you advise me to follow here to store the votes? (I'm not talking about the privacy perspective specific to voting, this is a whole other topic, but only the performance & data storage stance)
Typically with MongoDB, I would create an embedded object in the Group document, with the User IDs of candidates as the keys, and an array of the User IDs of the voters for each candidate as the values.
But strong types & the relational database-inspired approach of Prisma seem to prevent me from doing anything like that, most likely for the better.
In a relational database, you would typically create a separate table to store the votes. Each row in the table would represent a single vote and would contain the following columns:
group_id: the ID of the group in which the vote took place
candidate_id: the ID of the candidate who received the vote
voter_id: the ID of the user who cast the vote
You can also add a timestamp column to store the date and time when the vote was cast.
To get the votes for a particular group, you would perform a query like this:
SELECT * FROM votes WHERE group_id = :groupId;
You can then use the results of this query to build the necessary data structures in your application.
Using a separate table to store votes has the advantage of keeping the data normalized, which can make it easier to work with and more performant. It also allows you to use foreign key constraints to ensure that each vote references a valid group and candidate.
I have a PowerBI report that uses RLS to make sure the respective users only see their respective companies information (sales etc)
The RLS is configured to the Users-table (DimUsers) as such: Email = Userprincipalname()
DimUsers is related to DimCompany with a one-to-one relationship, and then DimCompany filters FactSales and the rest of the data model.
This works fine. But i need to add more users to view the same company. Hence i will need more emails in DimUsers connected to the same DimUsers, and so it does not work with a one-to-one relationship anymore, and the RLS does not function. It needs to work for these setup:
How can i fix this issue?
Thanks a lot in advance :)
Your relationship should have "Cross filter direction" both and Apply security filter in both directions
In general to make RLS simple, introduce a table with all the valid combinations, here (UserPrincipalName,CompanyId). Then put the RLS predicate on that table and have it flow filters to the DimCompany table.
I have a database comprising of the following schema depicting the linkage between individuals who connect with multiple Advisors and these Advisors have affiliations with multiple organizations
Individuals--> Advisors (m:n relationship)
Advisors --> Enterprises (m:n relationship)
The business need is to enable search on all these concepts and organize results around AdvisorIds. As an example, display of a search result could be as follows
a) Advisor1-> connected to Individuals A,B,C; and linked to Enterprises X,Y
b) Advisor2-> connected to Individuals A, E; and linked to Enterprises M,X,Z
Towards this, we created a flattened table on these concepts and the relationship between them. Hence the same AdvisorId would appear in multiple rows
When I search for a string, I want to ensure that ALL records around an AdvisorId to be returned together irrespective of search score of the individual records.
One approach could be
a) first run an Azure Search and get a result of AdvisorId, ordered by search score of each record. This will repeat Advisor Ids
b) take a distinct set of AdvisorIds (across pages) via standard SQL
c) for each AdvisorId, pick all the related records via standard SQL
2 questions
Here a lot of processing in (b) and (c) will be done outside Azure leading to delays. Also, if I were to use pagination for (a), I am never sure of number of AdvisorId's, I end up with after the distinct operation
I wanted to check if there is a way to get the nested search implemented in Azure to do (a), (b) and (c) as a single API call
If I were to use facets for handling (a) and (b) together, how do I ensure that the ordering is based on the best search-score document within a facet
There isn't a way to achieve what you want in a single request unless you model your data differently. Instead of denormalizing the Individuals-Advisors and Advisors-Enterprises relationships, it may be possible instead to have one document per Advisor and use collections to store information about the related Individuals and Enterprises. This may or may not work for you depending on whether you need to supported correlated filtering on Individuals and Enterprises that are related to an Advisor. There is a whitepaper here that should help you evaluate whether this approach would work for you.
Another option might be to model Individuals, Advisors, and Enterprises as separate indexes, issue three queries, and do a client-side join. However, this is limited by the number of Advisor IDs you'd need to send in the queries on Individuals and Enterprises. Azure Search has limits on the size of filters that can make this impractical unless your queries have low recall.
We are working on making Azure Search better for scenarios like yours. For example, we're currently working on adding support for complex types. Please vote on User Voice and feel free to suggest other features that would help.
I want to create a database of events. Events by the same user would have the same user id. I could then execute queries to retrieve users who had done events A and B but not C.
I've had a look at Cassandra but I'm unclear about how I should model this data.
The approach I thought of would be:
Every entry in the database gets a unique id (because I think Cassandra requires a unique primary key?), and then I have one column which is my user id, non-unique. Then I am free to give each event other columns, depending on what is relevant to that event. So I might have some entries:
1,user1,event_column=registered,fname_column=James,lname_column=Mason
2,user2,event_column=deleted
3,user1,event_column=pageview,page_column=homepage
and so on.
Then I'm a bit unclear about how I would select users who had done A and B but not C. Could I do that with one query? Or would I need to bring into java all users who had done A, then all users who had done B and filter for users in common?
Does that approach sound possible and a good way to use Cassandra?
Are there other open source distributed databases which might be appropriate?
Thanks for your help!
With a secondary index on the "event_column" you can ask ...WHERE event_column IN ('A', 'B'), but you cannot do a NOT IN clause like in conventional SQL. (See also this answer).
An example of a database that supports your query is MongoDB where $nin and $in are similar to NOT IN (...) and IN (...), respectively. (MongoDB is a document database where Cassandra is a column database.)
In order to prevent a complete scan of all documents, remember to put a secondary index on the events property if only a minority of documents will contain the events that you search for.
i'm walking my first steps with nosql databases, but so far my knowledge is very basic. I try to set up a database for a small invoice system.
In SQL i'd create 4 Tables: Products, Customers , Invoices, and a match table for Invoice and the produts.
But how to do this with nosql? Do i even build relations or just build 1 document for each invoice.
You should keep in mind that NoSQL design is not only based on data structure but also strongly on data function. So you should first ask yourself what kind of queries you need to do over your data and take it from there.
First figure out how far you want to go with denormalization and aggregation. For instance: what sets of data will often require to query or update at once? And try to keep that to a single document even if it means duplicating data from other entities (i.e. Storing customer data along with the invoice data).
So ask yourself why you want to use non relational databases, and how will you use that data. Then decide which modeling techniques to apply and how far. The highly scalable blog has a great article about NoSQL data modeling if you care to give it a read.
... or just build 1 document for each invoice.
Yes, do that for the beginning. Imagine your data in the CouchDB as read-only copy of your data in the relational database. The docs are like the result of your SQL queries.
Do i even build relations?
Of course you can, its the same as in your SQL tables. You including ids of foreign docs and name the property regarding to the relation you want to express e.g. doc.customer_id in an invoice doc can point to the doc._id of a customer doc.
Its helpful you imagine the CouchDB views as "relations" e.g. you can create a view called InvoicesByCustomer with the example above.
But summarized i would recommend to begin with the 1 document for each invoice.-approach and follow #JavoSN hint ...
So you should first ask yourself what kind of queries you need to do over your data and take it from there
... when you know that clearly its time to dig deeper into your possibilities of document designs.