I am looking for a suggestion for the best way to achieve a solution to this problem. I have a table with 135 unique outcomes (prices), each price will effect the outcome of three seperate derivatives, as the price changes, so does the value of each of the three derivatives. Each derivative can have any 1 of up to 21 different quanities attached to it, of which the quanity of the derivative is multipied by the price outcome to get a result for a specific derivative quanity and price.
I have crossjoined the derivative to get all of the unique combonations (90,000+), but when I try to cross join the possible combonations with the prices, the system is too slow and often stops responding. I have also tried to insert each possible combonation using a while loop, extract the statistics needed and then run the next senerio, but to no avail.
In short, what is the best way to form a realitively massive crossjoin or iteration.
Matt
Related
I have one table in my access DB which contains a list of all devices that has been sold to our customer. We have only one customer and only one type of device. The table contains details like name, serial, warranty detail of device. Now we need to calculate the price for invoice purpose. The thing is that the price should be calculated depending on amount of sold devices and also we don't want to hard code the price instead we would like to use a separate table whit different category of prices and calculating the price based on this table, because of the prices changing frequently and so we should modify the price value only in one table.
We have 3 category of price : if customer bought 100 device then the unit price is 15$ else if 200 devices the unit price would be 10$ else if 300 then price for unit would be 5$. So based on these rules we will need to calculate the price.
So I'm looking for the right approach that would be for this problem.
This is a very open-ended question and is impossible to definitively answer without more information about the architecture of the database.
There are 3 different ways I usually perform a calculation inside my Access databases.
perform a calculation inside a query. For simple things.
perform a calculation inside a module function, that is called by a query. For complicated things.
perform a calculation inside a module vba subroutine, that is called by a button OnClick Event. For extremely complicated things.
You could do a cross join as long as you have a range wide enough to account for all possibilities (i.e. some ridiculous upper boundary like 9999999). Otherwise a subquery would work with the same WHERE clause:
SELECT Prices.Price
FROM Prices
WHERE (Prices.MinQuantity <= Invoice.Quantity) AND
(Prices.MaxQuantity >= Invoice.Quantity)
As Gustav and V-ball point out there are many ways to set this up depending on your needs.
I am struggling with some basics of MS Access 2010/2013. I am not sure if I did hit the limit of it or if I am just using the wrong procedure. I will explain what i need.
Take for example 5 items in a shop, where 3 are items and 2 are a combination of items.
They need to be presented in the same matter, i.e. the combinations of products (bundles), needs to have a number in the same series as those it contains. See figure below:
So far, I created 2 tables. 1 for stand alone products and 1 for bundles. Bundles should be able to include other bundles (This is where i get the problems).
If someone orders, lets say, 10 times Items 5, I need Access to count how many Motherboards (Item 1), how many CPU (item 2) etc. I need a full list of those items, so i hopefully should get a list that says:
10 x Motherboard
10 x CPU
10 x Cabinet
So i don't have to dig into each bundle. Hence, as i see it, the relationsship runs in sort of a loop.
I identify the items to be either a combination or product by a column with "yes/no".
If you have any suggestions, let me know, or if you think i hit the limit.
An alternative method is welcome, as well as a sample of a simple Access database.
For the record, the system is gonna be used for huge machines, creating lists of bolts, nuts, electrical equipment etc. The above is only to explain my thoughts.
Best Regards, Emil.
Let’s say I have an Angry Birds game.
I want to know how many players are buying the ‘mighty eagle’ weapon each month out of the players which bought the mighty eagle weapon in the previous months in their LTV in the system
I have the dates of all items bought per each client.
What I practically would like to have is a two dimensional
matrix that will tell me what the percentage of the players which moved from
LTV_month_X to LTV_month_Y for each combination of X<Y for a specific current
month?
An example:
example_png
(it didn't let me to put the pic inline so please press the link to see the pic)
Now, I have found a way to get the number of players moved
actually from from LTV_month_X to LTV_month_Y that LTV_month_Y is their current
month of activity within the system using SQL query and Excel Pivot table.
What I try find out is mainly is how to get the base number of those who potentially could do that transition.
A few definitions:
LTV_month_X = DATEDIFF(MONTH, first_eagle_month, specific_eagle_month)+1
Preferably I would like to have the solutions in ANSI-SQL, if not then MySQL or
MSSQL but no Oracle functions should be used at all.
Since I’m looking for the percentage of the transition two-steps plans could also work, first find the potential ones and the find the actual ones who moved to measure the retention from LTV_month_X to LTV_month_Y.
One last issue: I need for it to be possible to drill down and find the actual IDs of the clients who moved from any stage X to any other stage Y (>X).
The use of the term LTV here is not clear. I assume you mean the lifetime of the user.
If I understand the question, you are asking, based on a list of entities each with one or more events, how do I group (e.g. count) the entities by the month of the last event and the month of the one before last event.
in mysql, you can use a variable to do that. I'm not going to expalin the whole concept, but basically, when within a SELECT statement you write #var:=column, then that variable is assigned the value of that column, and you can use that to compare values between consectuive columns e.g.
LEAST(IF(#var=column,#same:=#same+1,#same:=0),#var:=column)
the use of LEAST is a trick to ensure execution order.
The two dimension you are looking for are
Actual purchase month
Relative purchase month
SELECT
player_id,
TRUNCATE(first_purchase,'MM') AS first_month ,
TRUNCATE(current_purchase_date ,'MM') AS purchase_month,
months_between(current_purchase _date, first_purchase_date)+1 AS relative_month,
SUM(purchase_amount) AS total_purchase,
COUNT(DISTINCT player_id) AS player_count
FROM ...
Now you can pivot purchase month to relative month and aggregate
I'm not a coder (just a script fiddler) and I've got a particular problem with Magento that I cannot explain in terms of code or data, so I need to explain the situation.
I sell configurable products that come in an array of options. These are furniture products that use various codes that describe the final SKU of the product. I've never fully written or listed every possible SKU outside of any e-commerce product I've used, but always used the in-app options, in Magento's case, custom options, to create an SKU as the customer orders the product.
Now I'm facing a nightmare as I'm finally getting a QuickBooks solution mapped out for our company, but I need to get a file with every possible SKU# to import into QB, so that we can use a download routine (ecc) to grab all the orders from Magento and pop them into QB without having to create each new product on the fly. Each one of my products has the following choices:
BaseSKU#
FinishColorSKU#
FabricComboSKU#
FabricColorSKU#
So, for instance, I sell a chair. The chair's base SKU# is 708. The chair comes in 7 finishes, each with it's own code, so now I have 7 SKU's. Each chair+finish comes in 5 fabric combination styles. Not actual fabric, just the way it's applied to the chair. So 7*5=35 is no problem. Now it starts to get tricky. 2 of those fabric combo styles use only 1 fabric. We have 60 fabrics. 35*60=2100. At this point, this is not impossible to create in excel, a bunch of copying and pasting, but it can be done. Now the other three fabric combo styles use 2 fabrics. I need to create a SKU for every possible combination of fabric. So 60*60=3600 possible combinations of the fabrics alone. Now combine that with 35 different chair+finish combo, that's 126,000 possible SKU's for one product. Multiply that times 300 products, there is no way I could do this by hand in Excel. The final SKU looks like these:
One color chair:
708-117-SC-5708
Chair708+Frame117+SingleColor+Color5708
Two color chair:
708-117-DC-5708-5709
Chair708+Frame117+DualColor+Color5708+Color5709
Now, since these possible combinations exist in the Magento Database, just not combined, is there any way to programmatically create all possible combinations and lump them into an Excel file, or csv, or ANYTHING? Is this possible in Excel? Maybe I just need to download the database, export the right table to Excel and do it there.
Any help would be really appreciated.
EDIT: Was thinking about this, and maybe the simplest way to ask this question would be:
How to make Magento output a list of all possible products and options?
You can use the export functionnality: System -> export/import -> dataflow - profiles -> Export All Products. It's pretty straight-forward to use, but feel free to ask if you need more help.
I am currently in the process of rolling a custom order-processing system. My current structure is pretty standard, invoices, purchase orders, and items are all kept in separate tables. Items know which form(s) they are on by keeping track of the form's id, but forms don't know what items are in them (in the database). This was all well and good until I had a new requirement added to the mix: stocking orders.
The way a stocking order works is that sometimes a customer places an order for more units than what is in stock, so we want to place an order with our supplier for enough units to fulfill the order and replenish our stock. However, we often have to build these orders up as the minimums are pretty high, so one stocking order is usually comprised of several customer orders (sometimes for the same item) PLUS a few line items that are NOT connected to an order and are just for stocking purposes.
This presents a problem with my current architecture because I now need to keep track of what comes in from the stocking orders as often suppliers ship partial orders, where items have been allocated, and which incoming items are for stock.
My initial idea was to create a new database table that mostly mimics the items table, but is kind of like an aggregate (but not calculated) table that only keeps track of the items and their corresponding metadata (how many units received, how many for stock, etc) for only the stocking orders. I would have to keep the two tables in synch if something changed from one of them (like a quantity).
Is this overkill, and maybe there's a better way to do it? Database architecture is definitely not my forte, so I was hoping that someone could either tell me that this is an ok way to do things or that there is a better, more correct way to do it.
Thanks so much!
For what it's worth, what I'm using: VB, .NET 4.0, MySQL 5.0
Also, if you want clarification on anything, please ask! I will be closely monitoring this question.
Visit databaseanswers.com. Navigate to "free data models", and look for "Inventory Management". You should find some good examples.
you didnt mention them but you will need tables for:
SUPPLIERS, ORDERS, and INVENTORY
also, the base tables you mention 'knowing about' - these probably need associative style many to many tables which tell you things like which items are on which order, and which suppliers supply which items, lead times, costs etc.
it would be helpful to see your actual schema.
I use a single Documents table, with a DocType field. Client documents (Order, Invoice, ProForma, Delivery, Credit Notes) are mixed with Suppliers documents (PO, Reception).
This makes it quite easy to calculate Client backorders, Supplier backorders, etc...
I am just a bit unhappy because I have different tables for SUPPLIERS and CLIENTS, and therefore the DOCUMENTS table has both a SupplierId field and a ClientId field, which is a bit bad. If I had to redo it I might consider a single Companies table containing both Clients and Suppliers.
I use a PK (DocId) that's autoincrement, and a unique key (DocNum) that's like XYY00000, with
x= doc type
YY= year
00000 = increment.
This is because a doc can be saved but is only at validation time it receives a DocNum.
To track backorders (Supplier or Client), you will need to have a Grouping field in the DocDetails table, so that if you have an Order line 12345, you copy that Link field to every Detail line related to it (invoice, Delivery).
Hope I am not to confusing. The thing works well, after 3 years and over 50,000 docs.
This approach also implies that you will have a stock holding which is allocated for orders - without individual item tracking its a bit tricky to manage this. Consider, customer A orders
3 pink widgets
1 blue widget
But you only have 1 pink widget in stock - you order 3 pink widgets, and 1 blue.
Customer B orders
2 pink widgets
But you've still only got 1 in stock - you order another pink widget
3 pink widgets arrive from the first supplier order. What are you going to do? You can either reserve all of them for customer A's order and wait for the blue and red widget to arrive, or you can fulfill customer B's order.
What if the lead time on a pink widget is 3 days and for a blue widget it's 3 weeks? Do you ship partial orders to your customers? Do you have a limit on the amount of stock you will hold?
Just keeping a new table of backorders is not going to suffice.
This stuff gets scary complicated really quickly. You certainly need to spend a lot more time analysing the problem.