Might be incredibly naive but it's troubling me nonetheless. As part of my coursework, I have to create a database system for imaginary customers purchasing an item that firstly needs to be made. One problem I'm having is allocating multiple stock items into the works orders table against one particular product ID. So for example, how would I get 4 legs and a table top which would come under two individual ID's (legs and table top) against the product id containing 'table'? I'm currently working with SQL plus.
Image of my ERM is here for clarification
Related
Consider the following scenario (if it helps think Northwind Orders / OrderDetails).
I have two tables LandingHeaders and LandingDetails, that record details about commercial fishing trips. Typically, over the course of a week, a fishing vessel can make several trips to sea, and so will end up with several LandingHeader/LandingDetail records.
At the end of each week the company that purchases the results of these fishing trips need to work out the value of each landing made by each vessel and then pay the owner of that vessel whatever money is due. To add to fun there are some vessels owned by the same person, so the company purchasing the fish would prefer if the value of all the landings from all of the vessels owned by a given individual were amalgamated into a single payment.
Until now the information required to perform this task was spread across more that a simple master-detail table structure and as such it has required several stored procedures (along with the judicious use of dictionaries in the main application doing the work) to achieve the desired end result. External circumstances beyond my control have forced some major database changes and I have taken the opportunity to restructure the LandingHeader table such that it contains all the necessary information that might be needed.
From the landing Header table I need to record the following fields;
LandingHeaderId of sql type int
VesselOwnerId of sql type int
LandingDate (Just used as part of query in reality) of sql type datetime
From the LandingDetails Table I need to record the following fields;
ProductId of sql type int
Quantity of sql type decimal (10,2)
UnitPrice of sql type money
I have been thinking about creating a query that takes as Parameters VesselOwnerID , SartDate and EndDate.
As output I need to know which LandingId's are associated with the owner and the total Quantity for each Distinct ProductId (along with the UnitPrice which will be the same for each ProductId over the selected period) spread over the various landingDetails associated with the LandingHeaders over the given period.
I have been thinking along the lines of output rows that might look a little like this;
Can this sort of thing be done from a standard master - detail type table relationship or will I still need to resort to multiple stored procedures.
A longer term goal is to have a query that could be used to produce xml that could be adapted for use with a web api.
I am fairly new to SQL queries. I want to display the same product that has been serviced at three different labs or service stations.
I want to list and display the macbook represented by the id at the three different stations (or more) being displayed too.
Ok, so normally on stackoverflow, people tend to show what they tried and why it didn't work. In fact this question will probably be closed as too broad, but I empathize with starting with sql. But I will match the broadness of your question with a broad answer.
You should splt the tables up. I might try to have three tables:
A table describing each product with unique id
A table describing each service location with a unique id
A table describing each transaction with a unique id consisting of product ID and location id
Then when you need the data you would perform a join which would return the table containing the information you want.
I am thinking about problem in our database.
I have one table for our products. It has few columns that it's for all products common. But products belongs to a manufacture. And each manufacture need some columns for the specification of product. So I am thinking about distributions for our table..
I think that have it all in one table is waste for memory. Because for example I have 20k products for Apple and 30k for Asus, 40k for MSI.. so if I have it all in one table for columns for apple will be NULL for 70k records..
Another idea was that I have few tables for each manufacture and in products has some key that pointing to specific table with columns for Apple.. for example key can be apple1, apple2 and so on. But with this idea it was quite difficult to show all products with theirs specific columns.
So I want to ask if someone thinking about this problem in database.
I am using SQL Server 2012 for our database.
Thanks for any help to this problem.
You can use such structure...
It's just example...
If You want to compare specifications, table with product data will be more complex...
Databases are built to handle information as a collection of related sets ... and to use selection criteria to get you what you want to work with. You should design depending on how your information elements work .. something like:
Manufacturer table (with information that may be peculiar to a
manufacturer (e.g. address, telephone, etc.)
Product table , with a foreign key reference to Manufacturer
You can then select information for, say, Apple with something like
select xxx
from Product p, Manufacturer m
where p.manufacturerID = m.manufacturerID and m.name = "Apple"
We currently have a SQL database with a table that holds online sales for our company, which sells products using other websites (say, Amazon). The table schema has been set up to hold specific sale data/attributes provided by the website our items are currently sold on (say, Site A).
We are expanding sales to other websites that provide different attributes than Site A uses when an item is sold (e.g. Site A might provide a unique sales id number, and site B might not provide a unique sales id number, but also provide some other info that Site A doesn't provide that we still need to capture).
The question is do I add a separate table for sales on each 'site' that we sell on, as the schema will be different, or try to combine all sales into one table, no matter the platform, leaving some columns null if it doesn't pertain to the particular platform? Or maybe a hybrid approach, separating only the attributes that aren't common among the two sites into separate tables, while a "master" sales table holds attributes that are shared (sale_price, sale_date, etc)?
There are also other tables in play that hold internal information (product Ids, costs, etc), that are linked to the sales table via a unique identifier. Whichever route I choose, I'd need come up with a unique identifier I could use across all tables (auto incremented sale_id, e.g.), and store that in a table for reference/joins.
Any suggestions are welcomed!
A sale is a sale >> same data belongs to the same table. I would definitely not recommend splitting your sales to several tables as this creates lots of difficulty for all that might follow: sales statistics and so on. Try to keep all sales in one table.
If it's a very small project, it might be the best shot to integrate the different fields into one table. Otherwise you might try to create profiles for every sale platform: In this case, use an Entity-Attribute-Value model.
Do not add a table for each site. It sounds like you have a many to many relationship between sites and attributes, so set up your database that way. Also, for any unique identifier you need, create it yourself.
I'm working on an ERP application where multiple inventories need to be dynamically supported, ie. each depot/branch needs a separate stock value for each product. One approach - avoiding using static table columns - is to have a separate Stock table as follows:
[Product]
Code
...
[Branch]
Code
...
[Stock]
ProductCode
BranchCode
StockValue
...
This effectively becomes a many-to-many relationship separated by the Stock table. Immediately there appears to be pitfalls in this approach, for instance:
If there are 5 branches (depots), and 50k product lines, then there will be 5*50k Stock lines. Is this excessive?
Each time a Product is added, 5 new Stock lines need to be added - one for each Branch.
Each time a Branch is added, 50k new Stock lines need to be added.
The main rationale behind this is to avoid using static columns (which may lead to modifying the mapping files as new Branches are added). So it is supposed to be more dynamic.
Has anyone worked with a similar concept in the past and may perhaps have a more efficient solution? Or if this appears to be a suitable solution, then what NHibernate association method may be most effective?
Thanks.
I would create a separate entity -- Warehouse and Stores are common names -- as a container for stock. Then create a many-to-many relationship between a Branch and the Warehouses they can access Stock from. This gives you the flexibility to have stock stored at the branch and another location (rented space) or allow multiple branches to pull stock from multiple warehouses. Robust ERP systems further classify stock locations into shelf and position, for example.
Unless every product is stocked at every branch then I don't see that your list of potential pitfalls are valid. Using the Warehouse model, Stock is a record in a many-to-many table containing the number of items in stock at a warehouse. If the record does not exist than there are none at that location.