Creating a Lookup Table
in [Visual Basic]
|
Prev: Datagrid problem
Next: Virtual memory increasing.
From: Webbiz on 7 Mar 2010 18:56 I'm going to create a lookup table for my charting application. There aren't going to be very many items in this table, most likely less than a 100. For the majority, no more than 20 items. This table is to hold a symbol reference for the charts the user creates. For example, say the user is viewing a chart of Cotton. How this chart is actually named will be different for each user as they can name it whatever they want. So what I want to do is give the user the ability to assign the symbol (CT) to any chart that refers to Cotton. This way, when the user pulls up a chart of Cotton in the future with the specific name the user originally gave the chart (ex: "May Cotton 2010" or "Cotton May 2010" or "My Cotton Chart 0510" or whatever, the program can lookup with the symbol is and retrieve "CT". Now before you ask why this is not assigned when the chart was originally created, the answer is thus: This program is already out there and many users have already created and named many charts. If I add a new field to the data structure that currently describes the chart (such as the datafile name, the file path, the name the user gave the data, etc.), this would cause problems because this information is in a sequential file followed by data for all the tools that the chart may or may not have. The file load routine knows the order and structure size of each item (which is variable). Therefore, this lookup table has to be a new addition to an existing program. I'm thinking the route to go is to create a dynamic array due to its small size. Then if the user selects a chart and runs a task that needs to know what symbol is attached to it, I can then just loop through the array looking for an item that matches the user named chart and grab the symbol. If the user later deletes the chart, I'll have to loop through the array again, find the item, delete it, then run a 'gap fill' of some sort on the array to remove the empty element. If there is a better way to do this I'd like to find out what it is. I know that a DB could be added to the program, but it just seems like a lot more overhead in code/time for something that won't likely get bigger than 20 and definitely not 100. Ideas? Suggestions? Thanks. Webbiz PS: If structure item "Symbol" of type String is known never to be larger than 2 characters, is it better to define it as below or to define it as 2 bytes within the structure def below? And if better to assign it as 2 bytes, I assume that is String * 2? Examples: Type SYMBOLS ChartName as String Symbol as String End Type Public gSymbols() as SYMBOLS .... gSymbols(0).ChartName = "Soybeans" gSymbols(0).Symbol = "S" gSymbols(1).ChartName = "Apr Live Cattle 2009" gSymbols(1).Symbol = "LC" etc. etc.
From: Jim Mack on 7 Mar 2010 20:09 Webbiz wrote: > I'm going to create a lookup table for my charting application. > > There aren't going to be very many items in this table, most likely > less than a 100. For the majority, no more than 20 items. > > This table is to hold a symbol reference for the charts the user > creates. For example, say the user is viewing a chart of Cotton. How > this chart is actually named will be different for each user as they > can name it whatever they want. So what I want to do is give the > user the ability to assign the symbol (CT) to any chart that refers > to Cotton. This way, when the user pulls up a chart of Cotton in the > future with the specific name the user originally gave the chart > (ex: "May Cotton 2010" or "Cotton May 2010" or "My Cotton Chart > 0510" or whatever, the program can lookup with the symbol is and > retrieve "CT". > > Now before you ask why this is not assigned when the chart was > originally created, the answer is thus: > > This program is already out there and many users have already > created and named many charts. If I add a new field to the data > structure that currently describes the chart (such as the datafile > name, the file path, the name the user gave the data, etc.), this > would cause problems because this information is in a sequential > file followed by data for all the tools that the chart may or may > not have. The file load routine knows the order and structure size > of each item (which is variable). > > Therefore, this lookup table has to be a new addition to an existing > program. > > I'm thinking the route to go is to create a dynamic array due to its > small size. Then if the user selects a chart and runs a task that > needs to know what symbol is attached to it, I can then just loop > through the array looking for an item that matches the user named > chart and grab the symbol. > > If the user later deletes the chart, I'll have to loop through the > array again, find the item, delete it, then run a 'gap fill' of some > sort on the array to remove the empty element. > > If there is a better way to do this I'd like to find out what it > is. I know that a DB could be added to the program, but it just > seems like a lot more overhead in code/time for something that > won't likely get bigger than 20 and definitely not 100. > > Ideas? Suggestions? > > Thanks. > > Webbiz > > PS: If structure item "Symbol" of type String is known never to be > larger than 2 characters, is it better to define it as below or to > define it as 2 bytes within the structure def below? And if better > to assign it as 2 bytes, I assume that is String * 2? > > > Examples: > > Type SYMBOLS > ChartName as String > Symbol as String > End Type > > Public gSymbols() as SYMBOLS > > ... > > gSymbols(0).ChartName = "Soybeans" > gSymbols(0).Symbol = "S" > > gSymbols(1).ChartName = "Apr Live Cattle 2009" > gSymbols(1).Symbol = "LC" > > etc. etc. With fewer than 100 symbols, practically anything you do will feel instantaneous. Since you're carrying the Symbol field in the array, the actual array order doesn't matter and a deletion can just mean swapping the deleted element with the last element, then ReDim Preserve the array one element smaller. No shuffling needed. -- Jim
From: Webbiz on 7 Mar 2010 23:33 On Sun, 7 Mar 2010 20:09:27 -0500, "Jim Mack" <jmack(a)mdxi.nospam.com> wrote: >Webbiz wrote: >> I'm going to create a lookup table for my charting application. >> >> There aren't going to be very many items in this table, most likely >> less than a 100. For the majority, no more than 20 items. >> >> This table is to hold a symbol reference for the charts the user >> creates. For example, say the user is viewing a chart of Cotton. How >> this chart is actually named will be different for each user as they >> can name it whatever they want. So what I want to do is give the >> user the ability to assign the symbol (CT) to any chart that refers >> to Cotton. This way, when the user pulls up a chart of Cotton in the >> future with the specific name the user originally gave the chart >> (ex: "May Cotton 2010" or "Cotton May 2010" or "My Cotton Chart >> 0510" or whatever, the program can lookup with the symbol is and >> retrieve "CT". >> >> Now before you ask why this is not assigned when the chart was >> originally created, the answer is thus: >> >> This program is already out there and many users have already >> created and named many charts. If I add a new field to the data >> structure that currently describes the chart (such as the datafile >> name, the file path, the name the user gave the data, etc.), this >> would cause problems because this information is in a sequential >> file followed by data for all the tools that the chart may or may >> not have. The file load routine knows the order and structure size >> of each item (which is variable). >> >> Therefore, this lookup table has to be a new addition to an existing >> program. >> >> I'm thinking the route to go is to create a dynamic array due to its >> small size. Then if the user selects a chart and runs a task that >> needs to know what symbol is attached to it, I can then just loop >> through the array looking for an item that matches the user named >> chart and grab the symbol. >> >> If the user later deletes the chart, I'll have to loop through the >> array again, find the item, delete it, then run a 'gap fill' of some >> sort on the array to remove the empty element. >> >> If there is a better way to do this I'd like to find out what it >> is. I know that a DB could be added to the program, but it just >> seems like a lot more overhead in code/time for something that >> won't likely get bigger than 20 and definitely not 100. >> >> Ideas? Suggestions? >> >> Thanks. >> >> Webbiz >> >> PS: If structure item "Symbol" of type String is known never to be >> larger than 2 characters, is it better to define it as below or to >> define it as 2 bytes within the structure def below? And if better >> to assign it as 2 bytes, I assume that is String * 2? >> >> >> Examples: >> >> Type SYMBOLS >> ChartName as String >> Symbol as String >> End Type >> >> Public gSymbols() as SYMBOLS >> >> ... >> >> gSymbols(0).ChartName = "Soybeans" >> gSymbols(0).Symbol = "S" >> >> gSymbols(1).ChartName = "Apr Live Cattle 2009" >> gSymbols(1).Symbol = "LC" >> >> etc. etc. > >With fewer than 100 symbols, practically anything you do will feel >instantaneous. > >Since you're carrying the Symbol field in the array, the actual array >order doesn't matter and a deletion can just mean swapping the deleted >element with the last element, then ReDim Preserve the array one >element smaller. No shuffling needed. So you feel using an array as I mentioned is the way to go? Webbiz
From: Ivar on 8 Mar 2010 03:36 Sounds like a job for a collection of classes!!
From: Jim Mack on 8 Mar 2010 08:12
Webbiz wrote: > > > So you feel using an array as I mentioned is the way to go? Maybe not if you were starting from scratch, but here? Sure. It's a tiny amount of data in the larger scheme. Practically anything you do will be simple and fast. I wouldn't use String * 2, because I never use FL strings. If you're searching on that field there will be a lot of unnecessary conversions to VL string and back. Better to just keep them as String. Actually, if the data set won't often change during a run, then at runtime (or whenever) I might concatenate all the .symbols into one string, space-padded to a width of two in each section, and delimited by something like pipes: |ST|R |AB|C |GM| ... etc Scanning for "C" then is very fast: Posn = Instr(Search$, "|C ") \ 3 ' -1 if 0-based array Of course, if you don't search very often such optimizations are academic. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion" |