Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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! -- Ignore unavailable to you. Want to Upgrade?

To: SI Bob who wrote (18656)	6/10/2003 5:05:46 PM
From: Jon Tara	Read Replies (1) \| Respond to of 32918

You gotta admit, I was darn close, Bob. I don't think you have to look any further for the cause of the delays - you've found it. BTW, when I said GUI, your "text-based URL stuff" would qualify for what I was thinking off. But it doesn't seem to be the problem, given your explanation of what happens with the message-renumbering. What I had in mind was this: you do a "delete a post". The database gets locked. You get an "are you sure" button. The database is still locked until you select "yes" or "cancel". Probably an improbable situation given that it's a web-based interface. It'd be REALLY dumb to do this, HTTP being a sessionless protocol, and you'd NEVER select "yes" or "cancel". Of course, it's equally dumb in an executable. But people do it all the time. :( The lock would generally be released when the program is closed. But not when Bob goes for coffee. So, I thought the stop-gap solution might have been "don't go for coffee while you are doing this". I agree, renumbering keys in a large database is a particularly eggregarious design flaw. Somebody didn't understand the relational model. In the mean time, maybe you could do your deleting at night. :)

To: SI Bob who wrote (18656)	6/11/2003 10:16:25 AM
From: Rick Faurot	Read Replies (1) \| Respond to of 32918

Site still fast at 10:15 EST...approaching the molasses zone <g>

To: SI Bob who wrote (18656)	6/12/2003 1:28:19 AM
From: E. Charters	Read Replies (1) \| Respond to 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<:-}