I've got a logic-oriented issue, I think. I'm restructuring the database on my site to make it useful to the end user, and it's looking like this: I've got a list of seven products available, and each of them have an id of 1-7. I've got a submission table with an auto-incremented Id property (SubmissionId) to identify each unique submission, which may have multiple products (for example, a new customer may submit an add product form with EPL, Crime Fidelity, and Fiduciary), but not redundant products (can't have EPL and another EPL). I need to be able to link the product Id's to each submission in a workable way so that I can call it up to display the relevant information when a user calls up the submission to review it (basically like looking at their shopping cart). Obviously it's not feasible to create a table with all the possible iterations of 1-7 when there aren't necessarily 7 digits in the final count (because otherwise there would only be 49), so I was wondering if there was a way to combine each product id into a string, or something like it, insert that number into the ProductId column of the Submission table, and then use a SELECT WHERE LIKE statement to call up all the products associated with that particular SubmissionId?
For example, a user submits a new form, and the database autoincrements the value for column SubmissionId as 8. Then they add four products; EPL, Crime Fidelity, Fiduciary and Professional D&O. Those products have respective values of 1,3,4 and 6 in the column "ProductId" in the Product table. The collective ProductId value to be inserted into the Submission table would be 1346, and the logic to display the data associated with SubmissionId 8 would have a switch case statement looping through that ProductId to see if it contained each of the numbers 1-7 using the SELECT WHERE ProductId is LIKE (number), and then displaying the data from the relevant cases. How would I get the "1346" value to insert into the Submission table's ProductId column?
You should add a table that would link Product with Submission, eg. table S2P { Id, ProductId, SubmissionId } (I can't come up with better name). This is standard way to implement many to many relationship.
Check this link: http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php or google for many to many relationship to get more information.
Related
I want to stores many different products in my database(as well as in one table). With help of inheritance (Table per Concrete Type) ,i am keeping all common fields(date,customer,orderID) in parent table and made one child table for one product .
one child table => it holds many different product with same and different fields
ProductOne = {A,B,**C**}
ProductTwo = {A,B,**D**}
ProductThree ={A,B,**F**}
Now i made TableAllProduct and Field of tables are {A,B,C,D,F}
To reason to select this design ,because i am thinking about my future new product ,For example if we got new product with these exist fields{A,B,C,D,F} ,so we should able to store new product data in TableAllProduct table without any software upgrade (instead create new table as per Inheritance approach which required new code)
TableAllProduct can hold three different product ProductOne = {A,B,C} ProductTwo = {A,B,D} ProductThree ={A,B,F}
Next step is stores Data in TableAllProduct
As per given scenario, ProductOne and ProductTwo have common field {A,B} But A field stores data from ProductOne as well as for ProductTwo
ProductOne have following option=={data__A_1,data__A_2 ,data__A_3}
ProductTwo have following option =={data__B_1,data__B_2 }
which i brings from other table (Manny to Manny)
Here we breaks rules of RDBMS ,Because I need multiple foreign key at one column ,But RDBMS doesn't supports , To delete/edit of foreign key responsibilities/function can done with DELETE_trigger(which will check record in Category table )
In this way , i can stores multiple product in table for now and future.
What is disadvantage of this approach ?
Is there any other possibilities solutions to solve this problem with better way .(I know about Entity–attribute–value model ,but in our situation ,product doesn't not changes daily /weekly bases and EVA is too complex to maintain).Thanks
You need to normalize your data.
The model you've described can work. You need to have the AllProducts table only contain the attributes(columns) in common for all of the products. Attributes like name and SKU, and maybe a reference to the vendor/supplier.
Once you have identified the common attributes, the remaining attributes can be moved into a table specific to each product. The SpecificProduct table can use the PK of the AllProducts table as a PK and FK. Every record in SpecificProduct will also have a record in the AllProducts table. The complete data for a specific product consists of the attributes from the AllProducts table joined to the columns for the specific product table.
This strategy helps to keep the AllProducts table width small when a varied subset of attributes relates to a small subset of the records in the table. By reusing the AllProducts PK as the PK/FK of the specific products table, you ensure joins performance will be good as well.
I have been given an assignment to complete the following task:
I will be using C# and Sql server to solve the above. However i need an heads up on how many tables i will need since i am completely new to this. I have given this a try, if someone can solve my query its fine or can give me a better alternate solution altogether.
This is what i have tried uptill now.
I have made 3 tables uptill now as shown in image below:
Now if you notice in the second image i could make Order Number applicable only for one party. However, the issue i am still facing is that when one Party Orders more than one type of Product i will have to generate 2 PO Numbers in the Orders Table.
What is the solution to my issue here? How do i Normalize it further?
P.S. This might sound like a simple question as a simple question because this is my first attempt on Normalization.
Maybe you can use this design. Observe below that there is only 1 PO number per party per order. This assumes you want to manually supply the PO Number; otherwise, you can use the OrderID as a convenient autogenerated PO Number.
I would suggest adding another table called "Orders". This table will contain the information that will be the same for the entire order, such as PONumber, PODate, RefDate, PartyID. Then your OrdersDetail table will contain the information for each product ordered, such as ProductId, Quantity, Rate, Amount, OrderId (FK into the new Order table).
Also, don't make all the data types Text. Consider using a data type appropriate for the information being stored. I would also consider either not including Amount or making it a calculated field since it is calculated from other information in the same record (Quantity * Rate).
Further you may consider using a different value other then PONumber as the primary key. As a general rule the primary key would have no other purpose other then internally identifying record. I would suggest adding an OrderDetailsId and make that the primary key.
Edit: (I have added additional information to answer Lohits question below)
If I understand what you are stating in your question, the Party can have multiple Orders; on each order the party can purchase multiple products. Therefore there would be a one-to-many relationship between PartyDetails and Order, and a one-to-may relationship between Order and OrderDetail; and a one-to-one relationship between ProductDetails and OrderDetails. The Party table stores the information about the person purchasing the order. The Order table stores the information about each order the person places. The OrderDetails stores the information about each product the person purchases for each order. And the ProductDetails table stores a list of all products.
Here is a diagram of the data structure as I see it....Mind you it does not have every detail in it. But hopefully it will give you enough to get started.
4 tables:
Partyinformation: id, name, address
Productinformation: id, name, price
Orderinformation: id: dates etc
Orderline: orderID, ProductID, Amount
where orderID and ProductID are the foreignkeys into productinformation and orderinformation
Adding products to the (created) order just involves adding an productID and OrderID into [orderline] incrementing the amount when the same product is entered twice.
I am creating Windows Application Form using Visual Studio 2010.
For now, I am in this situation:
I allow users to add items into the system, each item they may have different brand, cost & suppliers and selling price for different customers.
For example,
Item1, Name: ABC, Brand: TIM and
Item2, Name: ABC, Brand: LD.
when the users want to insert the cost and suppliers information into Item1, when they click on the "ShowCost" button, another Windows Form will pop out for the users to fill in. And I'm planning to use DataGridView for that. I'm planning to use the Item Name and Brand for identifying the cost and selling price for the item
So here's my question,
How do I set the query or other solutions in order to check that when the name and brand of the item that the users enter, will show up the cost and the price of the specific items? what is the query that i need to write?
I have created 3 database tables which are ItemInfo(Name, Brand, etc), CostList(Name, Brand, SuppliersName, Cost) and SellingPrice(Name, Brand, CustomersName, SellingPrice).
How do I compare the data from ItemInfo tables to show the data in CostList?
Thanks for the help.
If you are using a database you should consider using Primairy keys. That way you can store information about a certain item in another table. In all three tables you use Name and Brand. I would have modeled my tables like this:
Items
ItemID (make this field an Auto incrementing integer field)
ItemName
Brand
SupplierID
Price
Clients
ClientID
ClientName
DiscountPercentage
PhoneNr
Suppliers
SupplierID
SupplierName
In the clients table the field SupplierID is a unique number. So when you want to refer to a supplier you simple fill in the SupplierID. For example in the items table the ItemID is the unique identifier for an item. The Supplier ID field is refers to the SupplierID field in the Suppliers table. In order to make sure your datamodel remains consistent I would recommend you to use Foreign key constraints. This makes sure you can not fill in any invalid ID's
Here's a short movie explaining some SQL basics
I want to take the customer id from a customer table, restaurant id from a restaurant table, and order id from order table. I want to store these values in a single table detail. How might I do this?
If, there's a common column in every table which can be useful to make joins, then you can use 'join' keyword for that purpose and can also refer Join for more details.
Out of my lack of SQL Server experience and taking into account that this task is a usual one for Line of Business applications, I'd like to ask, maybe there is a standard, common way of doing the following database operation:
Assume we have two tables, connected with each other by one-to-many relationship, for example SalesOderHeader and SalesOrderLines
http://s43.radikal.ru/i100/1002/1d/c664780e92d5.jpg
Field SalesHeaderNo is a PK in SalesOderHeader table and a FK in SalesOrderLines table.
In a front-end app a User selects some number of records in the SalesOderHeader table, using for example Date range, or IsSelected field by clicking checkbox fields in a GridView. Then User performs some operations (let it be just "move to another table") on selected range of Sales Orders.
My question is:
How, in this case, I can reach child records in the SalesOrderLines table for performing the same operations (in our case "move to another table") over these child records in as easy, correct, fast and elegant way as possible?
If you're okay with a T-SQL based solution (as opposed to C# / LINQ) - you could do something like this:
-- define a table to hold the primary keys of the selected master rows
DECLARE #MasterIDs TABLE (HeaderNo INT)
-- fill that table somehow, e.g. by passing in values from a C# apps or something
INSERT INTO dbo.NewTable(LineCodeNo, Item, Quantity, Price)
SELECT SalesLineCodeNo, Item, Quantity, Price
FROM dbo.SalesOrderLine sol
INNER JOIN #MasterIDs m ON m.HeaderNo = sol.SalesHeaderNo
With this, you can insert a whole set of rows from your child table into a new table based on a selection criteria.
Your question is still a bit vague to me in that I'm not exactly sure what would be entailed by "move to another table." Does that mean there is another table with the exact schema of both your sample tables?
However, here's stab at a solution. When a user commits on a SalesOrderHeader record, some operation will be performed that looks like:
Update SalesOrderHeader
Set....
Where SalesOrderHeaderNo = #SalesOrderHeaderNo
Or
Insert SomeOtherTable
Select ...
From SalesOrderHeader
Where SalesOrderHeaderNo = #SalesOrderHeaderNo
In that same operation, is there a reason you can't also do something to the line items such as:
Insert SomeOtherTableItems
Select ...
From SalesOrderLineItems
Where SalesOrderHeaderNo = #SalesOrderHeaderNo
I don't know about "Best Practices", but this is what I use:
var header = db.SalesOrderHeaders.SingleOrDefault(h => h.SaleHeaderNo == 14);
IEnumerable<SalesOrderLine> list = header.SalesOrderLines.AsEnumerable();
// now your list contains the "many" records for the header
foreach (SalesOrderLine line in list)
{
// some code
}
I tried to model it after your table design, but the names may be a little different.
Now whether this is the "best practices" way, I am not sure.
EDITED: Noticed that you want to update them all, possibly move to another table. Since LINQ-To-SQL can't do bulk inserts/updates, you would probably want to use T-SQL for that.