SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
SI - Site Forums : Silicon Investor - Welcome New SI Members!
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: SI Bob who wrote (18656)6/12/2003 1:28:19 AM
From: E. Charters  Read Replies (1) of 32918
 
You need a number that is quick searchable as messages are keyed internally by table sequence number. This means that you cannot use a linked list which is performance optimal for a slow searched but often changed files.. as it is referentially keyed or linked not keyed. The questions is -- what takes place most often, or very often, deleting or searching?

SI must be search intensive, and new message insertion intensive.. So it should use a real number in a possibly binarily searched or directly numerically accessed file. This means that in changing the list new files are always added at the end.. and internal holes must be filled by moving every file.. or assigning new numbers.. quickly -- or when "nobody is looking".. so to speak.. this is thorny.. It's kind of like changing underwear with everybody every time a new man arrives at camp.

A way to do this may be with a duplicate table. You add new messages in one table at the end, this is the working table. You flag messages when deleted or no longer available. When doing this a new sequence number is entered in a "scratch field". This consecutive field key tracks the number of good retainable entries. It is decremented by one globally at each deletion. At a certain point in the proceedings, this field is used to "write out" a clone table that is the latest update to a whole other working disk. This is the clean cloned-table disk. It can have the new entries added at the same time to its end as the working table by numerically working backwards from each new entry. (As entries were deleted in the working table the sequence number field was decremented by one in each entry in the clone table as well.) Then when writing out the new table at wrap up time, you start at the first new entry in the clone table and work backwards to message number one with no deleted messages included as the flaggged message are left out.

Deletion is a low priority.. So deletion from a table can be left for a slow time on auto back up.. or the like. In other words you make a deletion table which does the "real deletion" at a later time on schedule..

EC<:-}
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  

HomeMailHotSubjectMarksPeopleMarksKeepersSettings
Terms Of UseContact UsCopyright/IP PolicyPrivacy PolicyAbout UsFAQAdvertise on SI
© 2025 Knight Sac Media.  Data provided by Twelve Data, Alpha Vantage, and CityFALCON News