I have two tables in sql server 2012 as:
CropPurchase(Date,CropId,CustId,Qty,Price,Discount,Paid)
CropSale(Date,CropId,VendorId,Qty,Price,Discount,Paid)
By joining transactions of these two tables I have to fetch an account on front end(C# app), called:
CropAccount(Date,CropId,CustId,VendorId,DebitQty,CreditQty,DebitAmnt,CreditAmnt,Balance).
I have to order this table by Date.
So the Question is, that what should be the good practice:
To Create another table which will Contain mixed records of both the tables and fetch this table on front end.
Or to fetch record directly from the two tables to front end and not creating a third table.(it can create problem while ordering by Date).
This depends. Usually you have different tables to represent different entities. So you have zero, one or many CropPurchase records per CropId, and zero, one or many CropSale records per CropId. Two different entities. And to get the data per CropId you will have to join one or both tables and Aggregate when needed. So stay with the two tables and join when needed. (You can write a view for convenience, though.)
If however there can be no more than one record in CropPurchase and CropSale per CropId, then we are no langer really talking about two different entities. We are talking merely of the one crop account identified by CropId having purchase and sale data. Then you should have one table instead of two.
Anyway: Don't keep the two tables and add a third holding their data redundantly. That will lead to problems sooner or later.
Please elaborate on the date order problems you fear you'll be facing.
Related
I've a mysql table "login" with columns name, userid, pass, email. and another table "info" with columns bio, skills, searchingfor, badge, likes, age
here, the 1st table is used to check login... and the rest is used for storing personal info of an user. but i have a search box where people can search user according to everything except bio & pass. I'm having problem joining the results from two tables so is it ok to put all in one table or is there a simplier way?
and if i put everything in a table would it be heavier for mysql queries to search if the database gets lots of data?
There is no higher load on your mysql server if you combine both tables. This is a valid idea, since it appears that you have a 1:1 relationship anyway, so the code get's easier. Actually the load will be lower, since you do not need a join which is actually very slow in relational database management systems. The performance (load) just depends on your indexes and filter requirements, but that is independent of whether you search in one or two tables.
On the other hand: there is no reason why you should not be able to join those tables as required. So maybe you want to solve your issue here first. And be it just to learn how to do do it ;-)
I've been tasked with building a quote-creation database for a set of users and I'm having trouble figuring out something. I've determined I'll need a many-to-many relationship for just about every table I create and I'll explain why..
*Note: I do not need to store these quotes, I only need to give users the ability to create quotes and print them
My main table, Boats, will have many records (We'll say Boat1, Boat2, Boat3, etc...)
One of my other tables, Motors, will have many motors (Motor1, Motor2, Motor3, etc...)
I'm assuming I'll need a join table to get these to marry up on a form. My problem is this:
If Boat1 can only use Motor1 and Motor3, but Boat2 can use Motor1, Motor2, Motor3, and Boat3 can only use Motor3... How do I determine this?
I've thought of having two columns in Motors, Motor_Desc & Boat_Desc, but then we're talking thousands of records. I don't know how to proceed :(
edit 5-30-2013
Table design for this question:
Boats
Boat_ID
Boat_Part
Boat_Desc
Motors
Motor_ID
Motor_Part
Motor_Desc
I don't think databases will support DB level support for row-dependent logic for whether a new entry is valid or not.
You can have a Boat/Motor valid table AND a Boat/Motor use table. Compare against the validity table before constructing the use table.
I'm trying to write a SQL query that satisfies multiple criteria.
Of these, most are connected via a column, so joins are possible, however, some queries are such that I'd have to search additional tables for the information. What would be the least expensive and best way to do this?
Let's say that we have a few tables.
One table contains information such as sales information for a server: the salesperson, client id, service lease term, timestamps etc. It is possible that a client has multiple sales but with a different "service". I'd need to pick up all of the different ones.
Another table has the quotes for the services, I'd need to pick some information out about this, whilst another, which could be joined to this one has some more information.
Those tables are linked by a common client ID, so joins are possible, but I'd also need to search the first table for multiple instances of the client ID. Of course, I'd want to restrict the search to certain timestamps, which I can easily do as the timestamps are stored in MySQL format.
Using MySQL I have table of users, a table of matches (Updated with the actual result) and a table called users_picks (at first it's always going to be 10 football matches pr. gameweek pr. league because there's only one league as of now, but more leagues will come along eventually, and some of them only have 8 matches pr. gameweek).
In the users_picks table should i store each 'pick' (by pick I mean both 'hometeam score' and 'awayteam score') in a different row, or have all 10 picks in one single row? Both with a FK for user and gameweek. All picks in one row would mean I had columns with appended numbers like this:
Option 1: [pick_id, user_id, league_id, gameweek_id, match1_hometeam_score, match1_awayteam_score, match2_hometeam_score, match2_awayteam_score ... etc]
and that option doesn't quite fill me with joy, and looks a bit stupid. Especially since there's going to be lots of potential NULLs in the db. The second option would mean eventually millions of rows. But would look like this:
Option 2: [pick_id, user_id, league_id, gameweek_id, match_id, hometeam_score, awayteam_score]
What's the best practice? And would it be a PITA to do all sorts of statistics using the second option? eg. Calculating how many matches a user has hit correctly in a specific round, how many alltime correct hits etc.
If I'm not making much sense, I'll try to elaborate anything. I just wan't my table design to be good from the start, so I won't have a huge headache in a couple of months.
Thanks in advance.
The second choice is much better than the first. This is called database normalisation and makes querying easier, not harder. I would suggest reading the linked article, and the related descriptions of the various "normal forms", and aiming for a 3rd Normal Form data structure as a minimum.
To see the flaw in your first option, imagine if there were to be included later a new league with 11 matches. Or 400.
You should read up about database normalization.
When you have a 1:n relation, like in your case one team having many matches, you would create two tables. One table "teams" and a second table "matches" where each row includes the ID of the team which played the match.
In the same manner you should also have separate tables for users, picks and leagues.
Option two is better, provided you INDEX your table properly, since (as you indicate) it will grow quite large. The pick_id is the primary key, but also create an INDEX on the user_id field, as likely the most common query will be
SELECT * FROM `users_pics` WHERE `user_id`=?;
to get all the picks for a given user.
I want to know what's the most optimized way to work with mysql.
I have a quite large database for orders. i have another table for previous orders, whenever the order is completed, it's erased from orders and is moved to previous orders.
should i keep using this mothod or put them all in the same table and add a column that flags if it's current or previous orders?
kfir
In general, moving data around tables is a sensitive process - data can easily get lost or corrupted. The question is how are you querying this table - if you search and filter through it on an often basis, you want to keep the table relatively small. If you only access it to read specific lines (using a direct primary key), the size of the table is less crucial, and then I would advise to keep a flag.
A third option you might want to consider, is having 3 tables - one for ongoing orders, one for historic orders, and one with the order details. That third table can be long and static, while you query the first two tables.
Lastly - at some point, you might want to move the historic data out of the table all together. Maybe you would keep a cron job that runs once a month and moves out data which is older than 6 months to a different, remote database.