Massive Tables!
- Thread starter psahdBg
- Start date
- Local time
- Today, 17:46
- Joined
- Sep 12, 2006
- Messages
- 16,094
part of the analysis is determining exactly what data you have.
You could now put all records in a single spreadsheet tab, and just use a simple data filter to identify the data in which you are interested. That's the point. Identifying that you REALLY just have one "set" of data.
That way you can add a fourth class of data without needing any extra work, other than assigning the appropriate designation. Or you could split your data into multiple classes without needing any further work.
Another vitally important thing, that you may or may not have noted, is that in a database you cannot refer to other rows in each table. In excel we often use a formula based no the previous row in excel. This is a complete no-no in a database. You deal with a "set" of data in its entirety. The order is unimportant. It's hard sometimes to grasp just how central this concept is.
the key to this is considering the above. Do all the above spreadsheets have the same, or broadly similar data columns. If so, you could add an extra column and enter either M, N, or A to distinguish the type of record.
You could now put all records in a single spreadsheet tab, and just use a simple data filter to identify the data in which you are interested. That's the point. Identifying that you REALLY just have one "set" of data.
That way you can add a fourth class of data without needing any extra work, other than assigning the appropriate designation. Or you could split your data into multiple classes without needing any further work.
Another vitally important thing, that you may or may not have noted, is that in a database you cannot refer to other rows in each table. In excel we often use a formula based no the previous row in excel. This is a complete no-no in a database. You deal with a "set" of data in its entirety. The order is unimportant. It's hard sometimes to grasp just how central this concept is.
