Then you could take it to the next level and include a client ID with each account. When you construct views include " and ChartTable.clientID = yadayada" and your data is reduced to that client only for the view.
Ben Petersen On 20 Oct 2002, at 1:23, Atrix Wolfe wrote: > we have different account number formats for different clients within > a single table but they share names of the fields so i bet i could do > this and just make the columns large enough to handle the largest > version of the field. Not a bad idea...im gonna play around with that > (: > > ----- Original Message ----- > From: "Ben Petersen" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, October 19, 2002 3:44 PM > Subject: Re: indexes and hashing > > > > Atrix, > > > > If you are allowed to work with the schema a bit you could make > > things more efficient. > > > > I assume your accounting number relates to something like a chart of > > accounts. Build your chart with the long number in a table (one > > occurrence only for each number) and a field for each component of > > the number. Use other tables as needed to ...describe... the > > components of the number. Finally, there should be a unique integer > > column in the table that represents your chart of accounts and that > > number should be used in your transaction tables to reference > > account numbers. So the key column in your transaction table may > > have 99 as a reference to your chart of accounts which has a user > > assigned number of "100-200-300-A". > > > > From there you can construct views, adhoc selects and reports > > very easily and they'll be pretty fast. This also has the advantage > > of being able to change that long number in just one place and have > > it reflect throughout the system. > > > > > > Ben Petersen > > > > > > On 19 Oct 2002, at 16:57, Atrix Wolfe wrote: > > > > > im using version 6.5 > > > > > > unfortunately this column is an accounting number made up of sever > > > fields seperated by dashes. We use the sget()'s to do things like > > > grab all accounting numbers from a specific location and other > > > such things. Also,since there are multiple accounting "types" the > > > size and location of the fields varies widely so i dont think we > > > could do the sget() idea although that is a neat idea i hadnt > > > thought of (: > > > > > > ----- Original Message ----- > > > From: Bernard Lis > > > To: [EMAIL PROTECTED] > > > Sent: Saturday, October 19, 2002 4:37 PM > > > Subject: Re: indexes and hashing > > > > > > > > > What version are you using ? > > > You could create a computed column with (sget( )) > > > Then set your index on the computed col. > > > > > > Bernie Lis > > > Megabytes, Inc. > > > ----- Original Message ----- > > > From: Atrix Wolfe > > > To: [EMAIL PROTECTED] > > > Sent: Saturday, October 19, 2002 5:46 PM > > > Subject: indexes and hashing > > > > > > > > > hello, im considering setting an index on a text (50) column > > > we have in a table. We have to do quite a few sget()'s on > > > this column so it runs slow under some circumstances and am > > > looking to speed it up. My question is 2 fold i guess...first > > > of all...are there other ways besides indexing to speed up > > > such a column? And my second question is that when i create > > > an index on this column it asks how many of the characters i > > > want to hash and that the rest will be preserved. I know what > > > hashing is...taking a string of data, putting it through a > > > function and the result is a smaller peice of data (im > > > assuming is used as the index value?) that should be > > > statisticly balanced for random input. I was wondering though > > > in such a situation is it better to have more of it hashed or > > > less? and in general...what are the pros and cons of hasing > > > more as opposed to less? > > > > > > Thanx, tryin to expand my r:mind (; > > > -Atrix > > > > > > ================================================ > > TO SEE MESSAGE POSTING GUIDELINES: > > Send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: INTRO rbase-l > > ================================================ > > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: UNSUBSCRIBE rbase-l > > ================================================ TO SEARCH ARCHIVES: > > http://www.mail-archive.com/rbase-l%40sonetmail.com/ > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In > the message body, put just two words: UNSUBSCRIBE rbase-l > ================================================ TO SEARCH ARCHIVES: > http://www.mail-archive.com/rbase-l%40sonetmail.com/ > ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
