Develop Reference

Having join or multiple resultsets

I have the following 2 tables with a one to many relationship. The table ORDER and ORDER_DETAILS. I am using C# to call a stored procedure to do some processing but eventually it should return the orders with its corresponding details.
So the question is which one of the 2 below is more optimized.
Select the orders and joining with the order details, and then having the data in c#.
Having 2 result sets, 1 orders and the order order details, then building up the data in c#.
My guess is that since the join will repeat the same columns in the order table each order details, the 2nd option is best.
What are your views on the above.

#Steve asked the right question. You need to clarify that.
But I would in most of cases go for first option. Joining both the tables at database end and selecting only necessary columns for the front end.
In this way you need to transport lesser amount of data and in normal scenario it should be faster than getting data from both tables and building it in front end. But without knowing your proper context it might not be the best possible solution.

One table for different products with same fields but with different data range?

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.

How normalize the table Order Details

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.

Insert many rows to one table OR insert rows separately to many table?

I have two DataBase Table (SQL CE). A Teacher table and a A Class table. The two tables have One-to-Many relationship where one teacher has many classes (i.e. Class has a foreign key teacher_id). Number of teachers (rows) is inserted (or generated) through C# code in run time, so as classes
Which of the following is faster in INSERT and SELECT?
Each time a new teacher is INSERTed, a new Class Table is created (e.g. Class_teacher001) to store whichever classes the teacher has. In this case, each Class Table doesn't have to be so large and foreign key is not needed because table name would identify itself. But there will be one Teacher table and many Class_xxx Tables
Only one Teacher table and one Class table. Each class row has a foreign key pointing at the Teacher table. Only one Class table, but it will get very long. I worry searching and reading wil be slow

Regardless of which is faster, (2) is the way to go....simply create indexes to support your searches. This is how almost all relational databases are used.
The nightmare of maintaining option (1) makes me shudder

OK, where to start. First, the relationship between Teacher and Class is potentially many-to-many, but as described by you is at least one-to-many.
The first option is absolutely the wrong way to go. Never dynamically create tables. The second option is how this sort of thing is handled. Databases are powerful, written by very smart people (usually), and can handle many more rows than all the students at a given school.
As long as you properly index your tables, they can easily support hundreds of millions of records.

I also agree with Mitch Wheat. Because when you create an index your table physically sort according to our Teacher Be creating Combined Index of (Teacher_Id ,Class_Id).
Though its will Help to get fast retrieval Of Select Statment.

Unless you are already having performance problems, I would not worry about them. There are many things that can cause performance problems other than the number of rows, and they should be dealt with differently depending on what they are. You have to worry more about the number of columns in a table affecting performance than you do about the number of rows. Also the number of concurrent connections to the database. One million rows in a table is not that many, it is the other two items in conjunction with that many rows that will make a database slow. You should use the second option.

How can I take a different values from different tables and store in another table?

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.