I have a customer table and services table in SQL Server 2012. A customer can avail services if he wants, laundry, housekeeping, food.
In Customer table I have kept services as a multivalued attribute. When I resolve it, I make an associative entity for services table where I put C_id*, Service and Price.
My question is what query to write a subquery at time of table generation in of customer to enter a particular price for a service availed? Basically how to handle this? I would later use these to create an invoice when total bill calculated.
Likewise, I have member types as well. If a member is lifetime then allow 20 percent discount and seasonal 10 percent.
How to handle it? Subqueries?
Code snippets would help.
Related
Summary of my problem:
Our company offers two software products (for simplicity we'll call them product A and product B). In the past, when a client wanted to buy both products, the sales team would create a separate opportunity object for each product. Both of these opportunity objects have the same client ID (unique identifier for each client) and same close date but a different opportunity ID (unique identifier for each opportunity object).
In the present time, if a client wants to buy both products, the sales person will only create one opportunity object containing both products. This presents a challenge when comparing statistics from past years to the present as the past statistics are inflated to appear like 2 opportunities were closed when in reality it was one client buying the two products at the same time.
Example in table data format:
Simple example of data
What I am trying to achieve
In either my SQL query or later in Power BI, I would like to count these old opportunities as one. In other words, whenever an opportunity has the same client and same close date as another opportunity in the table, I want to count this once.
I attempted to flag this with a CASE statement unsuccessfully. I also tried to nest a query within a join but ran into issues because my query already has 4 JOINS and 6 WHERE statements. Any ideas? If I need to provide more examples or details, please let me know. THANKS!
Just add a column with the "main" opportunity id, then you can do a distinct count in Power BI on this column if you want only the "real" opportunities. You can use the OVER clause for this:
SELECT *,MIN(opportunityId) OVER (PARTITION BY ClientId,closeDate) as MainOpportunityId
FROM opportunities
I do descriptive analytics and reporting at a company that sells a wide range of products. We record sales transactions and everytime an item is sold, the following is recorded:
Customer ID (each customer has a unique ID)
Product ID (each product has a unique ID)
Sale date
(Other fields are recorded too - location of purchase, quantity, payment type, etc.)
We sell a few big ticket items, and what I'm wondering is if it's possible to predict whether a customer will buy one of the big ticket items based on their purchase history, using transactional data as described above. We have about 2 million rows of sales data spanning seven years, and in that time maybe 14,000 big ticket items have been sold to 5,000 out of 50,000 customers.
I use SQL Server 2008 R2 which has the data mining feature. I did some brief reading on it but can't figure out what model would be best, or if it's something that's even doable. Can someone point me in the right direction to get started?
Not sure if the SQL server data mining feature is useful. I took a look at the one for SQL 2012 and decided it wasn't.
As for your prediction, this would be a supervised learning problem (just pick any simple algorithm), where each customer is a row and your features would be the different products. Your positive labels then would then be the rows of customers that had bought big ticket items.
what you are looking for is called sequential pattern mining and the specific technique that you are looking for is called discrete event prediction. However with that being said, I don't think you will be able to do what you want to do with an out of the box solution on sql server.
I am building a new business application for my personal business which has close to ~100 transactions of sale and purchase per day. I am thinking of having Separate tables to record the sale and purchase with another linked table for Items that were sold and a seperate linked table with items that were purchased.
Example:
**SaleTable**
InvoiceNo
TotalAmt
**SaleTableDetail**
LinkedInvNo
ProductID
Quantity
Amount
etc.,
would this design be better or would it be more efficient to have one transactiontable with a column stating sale or purchase?
-From an App/Database/Query/Reporting Perspective
An invoice is not the same as a sales order. An invoice is a request for payment. A sales order is an agreement to sell products to a party at a price on a date.
A sales order is almost exactly the same as a purchase order, except you are the customer, and a sales order line item can reference a purchase order line item. You can put them in separate tables, but you should probably use Table Inheritance (CTI, extending from an abstract Order). Putting them in the same table with a "type" column is called Single Table Inheritance and is nice and simple.
Don't store totals in your operational db. You can put them in your analytic db though (warehouse).
You are starting small, thats a quick way to do. But, I am sure, very shortly you will run into differences between sale and purchase transactions, some fields will describe only a sale and some fields that will be applicable only for purchases.
In due course, you may want to keep track of modifications or a modification audit. Then you start having multiple rows for the same transaction with fields indicating obsoletion or you have to move history records to another table.
Also, consider the code-style-overhead in all your queries, you got to mention the Transaction Type as sale or purchase for simple queries.
It would be better to design your database with a model that maps business reality closest. At the highest level, everything may abstract to a "transaction", with date, amount and some kind of tag to indicate amount is paid or received against what context. That shouldn't mean we can have a table with Tag, Date, Amount, PayOrReceive to handle all the diverse transactions.
I have a database modeling related problem and would like you guys to give me sugestions how could i solve it.
I need to sell "virtual services". I made some tables: Clients, Services, Order, OrderLine. So a Order can contains multiples services. Each service has an "contract time". If i order a service it is valid for 30 days then i need to order it again if i want to continue using it. if i order a service for 30 days and 10 days has passed i still have 20 days. If i order it again i'll have 50 days.
How can i model the database to control this?
Looks like you just need to use Orderline and have the start date and end date valid for that particular order.
So you will have one entry for every renewal. And this table should have FKs to Service and Order.
I'm building a database that contains for each customer's purchase
Product Name
Product Manufacturer
Store
Date
Buyer's name
Buyer company
Some data such as product name, manufacturer, shop, buyer's name and the buyer's company back on themselves at the time.
Is it better to build them in separate tables and in the primary table to keep their indexes?
On the one hand it saves space on the server
On the other hand it overloads the server and requires more work
I would keep buyer information and product information in separate tables. There is no reason to store this information more then once.
In addition you could use a (relation like) table with buyer id, serialized array of product id's and date of the purchase.
buyer_id | {"prod1_id","prod2_id",...} | date
This way you get a table with all purchases that you can get whenever you want. This will increase the calls to the database but save on the storage.
Hope it makes sense to you.